IT/모바일
저자: 다이온 알마에르(Dion Almaer), 역 weblogger 김대곤
자바 프로그래머들은 객체 다루기를 좋아한다. 응용 프로그램의 경우 항상 그런 것은 아니지만 빈번하게 영속적으로 정보를 저장해 줄 필요가 있다. 대부분의 서버 개발자들은 주로 관계형 데이터베이스의 조회 작업시 데이터베이스에 접속하기 위해서 JDBC API를 사용해 왔다. 이미 객체를 저장하는 모델을 가지고 있다고 해도, 객체 저장을 위한 새로운 모델을 만드는 것은 가치 있는 일이다. 객체의 값들을 데이터베이스로 저장하는 프로그램을 작성하는 것은 고통스러운 작업이 될 수 있다. 또한 객체들간의 관계를 저장시키는 것은 복잡하고 다루기 힘든 작업이 될 것이다. 직렬화 메커니즘은 객체를 취하여 객체의 내용을 스트림 형태로 저장할 수 있게 해 주지만 여러 사용자들을 동시에 공유하지는 못한다.
개발자들이 객체와 데이터베이스를 매핑(Mapping)시키는 작업을 걱정하지 않고 비즈니스 솔루션을 개발할 수 있도록 하는 자바 데이터 객체(Java Data Objects, Java Community Press내의 JSR012로 명명된 명세)가 등장하게 되었다. JDO API는 개발자들이 한 번의 작성으로 데이터베이스에 무관하게 사용할 수 있는 표준 API다. 동시에 인터페이스를 구현한 여러 개의 구현 클래스들이 존재한다. 이것은 한 번 JDBC를 작성하여 JDBC 드라이버만 교체함으로써 오라클, Sybase 등 여러 데이터베이스에 접속하는 것과 유사하다. 오라클 OCI 라이브러리나 Sybase Dblib를 공부하지 않아도 된다는 것은 기쁜 일이다. 적어도 나에게는 그렇다.
자바의 표준 스팩으로 등록 요청 됨에 따라, JDO가 모두의 지지를 받는 것은 아니다. 어떤 사람들은 객체 저장을 수행하는 객체들의 표준화에 대하여 찬성하지만 어떤 사람들은 비판한다. 스팩이 발표된 이후, 크라이그 러셀(Craig Russell)은 비판자들과 논쟁하게 되었다.
JDO의 상용 제품의 출시
그 결과 우리는 엔터프라이즈 환경에서 객체를 저장하는 표준 API를 가지게 되었다. 객체 저장 작업을 계속해 오고 있는 개발업체들은 어떤 생각을 가지고 있을까? 지난해 6월 유명한 CocoBase O/R 매핑 솔루션 업체인 Thougth.inc는 벤더 독립적인 객체 저장 기술을 발표했다. 발표된 기사는 JDO의 설계 방식에 대하여 부정적인 시각을 보이고 있다. "많은 사람들이 ODMG와 JDO의 설계를 자바의 Open Access, 플랫폼 독립성, 컴포넌트 재사용의 취지를 손상시킨다고 생각한다. CocoBase의 아키텍쳐는 자바 클래스들을 벤더 독립적으로 만들지만 다른 접근법들은 소스 또는 바이너리 코드를 특정 벤더에 강하게 종속 시킨다. 다른 시스템들은 특정 벤더에 의해 처리되고 통합된 자바 클래스들의 계층구조를 생성한다. 이러한 계층구조는 타 벤더와 완벽하게 호환되지 않는다." JDO의 개발자인 크라이그 러셀은 반론을 제시해야 했다. 그는 Thougth.inc가 JDO의 구현 세부사항을 싫어하는 진짜 이유는 JDO 클래스 파일들이 바이트 코드의 수정을 요구하며, 특정 코드를 추가해야 하기 때문이라고 주장했다. CocoBase의 솔루션은 순수한 객체 모델을 감싸고 있고, 특정 클래스의 상속을 강요하거나 바이트코드 처리를 요구하지 않는다. Severside.com에서 기사 내용, 크라이그 러셀의 반론, Thougth사의 재반론을 볼 수 있다. 흥미로운 읽을 거리가 될 것이다.
만약 여러분중에 Thougth를 지지하고, 객체를 저장하는데 더 좋은 방법이 있다고 생각한다면, 자신만의 방법을 만들어 볼 것인가? 아니면 자신의 의견에 귀 기울이도록 노력하면서 표준에 동조할 것인가?
모든 O/R 제품 업체들이 JDO의 표준 API를 사용하여 개발하기 시작한다면 이상적일 것이다. 그렇지만 TOPLink의 경우, JDO의 특정 수준까지는 지원하겠지만 성능 측면에서 빈약하다고 생각되는 부분에 대해서는 자체 API를 제공한다는 입장을 취할 것으로 보인다. O/R 매핑 툴은 편리하다. 개발자들이 직접 O/R매핑을 위한 코딩을 한다는 것은 불합리하다. 우리가 어떠한 작업을 원한다 하더라도 툴은 그 기능을 제공해야 한다. 어떤 면에서는 자바는 SmallTalk에 비해 아직까지 지원 툴이 뒤쳐져 있다. 미래에는 개발자들의 비즈니스의 요구사항 해결에 더욱 집중할 수 있도록 툴이 지원하는 부분이 더욱 확대되어야 할 것이다. JDO에 대한 더 많은 비판들이 존재하며, 크라이그는 그 비판들에 대하여 만족할 만큼 설명하려고 노력해 왔다. 관심이 있다면 기사 끝에 있는 링크들을 살펴보기 바란다.
JDO와 엔터프라이즈 자바빈즈
JDO는 EJB 포럼에서도 논란을 일으키고 있다. JDO가 발표되자 일부 사람들은 JDO가 엔티티 빈이 수행했어야 할 역활이라고 주장하고 있다. 현재 엔티티 빈을 사용하는 경우는 매우 드물었다. 많은 사람들은 썬이 현재의 엔티티 빈을 포기하고, JDO와 결합시킬 것이라고 생각했다. 그러나 이러한 추측은 현실화 되지 않았으며 관계, EJB-QL, 로컬 인터페이스 지원하는 EJB 2.0 이 발표되었다. 소문에 의하면 썬과 EJB 그룹(BEA, IBM, Borland, Oracle 등)은 엔티티 빈에 많은 투자를 하였기 때문에 그것을 포기하지는 않을 것이라고 한다. 그리고 엔티티 빈이 좋지 않다는 것을 인정하고 공식 발표하는 것 또한 적절한 마케팅 전략으로도 아니라고 생각한다고 한다. 많은 EJB 개발자들이 CMP(Container Management Persistance)를 사용하기 보다는 O/R 매핑 기능을 Bean에 포함시키는 BMP(Bean Management Persistance)를 사용한다. 성능 때문에 JDBC를 사용하는 사람들은 이제 바로 JDO를 사용하려고 한다.
나는 여전히 CMP 엔티티 빈이 가능성이 있다고 생각한다. EJB 2.0 스팩에서는 개발업체들이 내부적으로 최적화 작업을 할 수 있도록 하는 것을 포함하여 뛰어난 성능을 위한 기능들을 지원하고 있다. 분산 객체로서의 엔티티 빈의 시대는 가고, 앞 단의 세션 빈과 엔티티 빈들을 가지는 현재의 구현 권고방식은 로컬 인터페이스로의 전환이 요구되어 질 것이다. 만약 그것이 현실화 된다면 엔티티 빈이 컴포넌트가 될 필요가 있는가?
EJB 안에서 사용되는 기술이 무엇이던지 간에 현재의 관건은 여전히 빈들을 자동 생성해 주는 툴과 고성능 엔진이다. TOPLink와 CocoBase는 매력적인 툴이다. 자동 생성된 Bean의 코드를 수정하지 않아도 된다면 나는 행복한 사람이다. 나는 단지 데이터베이스를 지정하고, 필드와 저장 프로시져를 선택하고 CMP(또는 BMP, 내가 원하는 다른 것) 생성 버튼을 누를 수 있다. 나는 표준이 성숙 되어감에 따라 새로운 툴의 시대가 도래할 것을 기대해 본다.
결론
JDO는 여전히 논란의 여지가 많은 주제이다. 스펙이 구현되어가는 것과 기술적인 성숙을 지켜보는 일은 앞으로도 계속해서 흥미진진한 일임에 틀림없다. JDO는 개발자들이 데이터 작업시 실제적인 도움을 주는 툴과 함께 엔터프라이즈 환경에서 사용되어질 가능성과 능력을 가지고 있다.
링크 다이온 알마에르(Dion Almaer)는 EJB/J2EE와 B2B 기술의 교육 분야의 선도 기업이며 TheServerSide.com의 J2EE의 커뮤니티를 후원하고 있는 미들웨어 회사(www.middleware-company.com)의 책임 기술자이다.
자바 프로그래머들은 객체 다루기를 좋아한다. 응용 프로그램의 경우 항상 그런 것은 아니지만 빈번하게 영속적으로 정보를 저장해 줄 필요가 있다. 대부분의 서버 개발자들은 주로 관계형 데이터베이스의 조회 작업시 데이터베이스에 접속하기 위해서 JDBC API를 사용해 왔다. 이미 객체를 저장하는 모델을 가지고 있다고 해도, 객체 저장을 위한 새로운 모델을 만드는 것은 가치 있는 일이다. 객체의 값들을 데이터베이스로 저장하는 프로그램을 작성하는 것은 고통스러운 작업이 될 수 있다. 또한 객체들간의 관계를 저장시키는 것은 복잡하고 다루기 힘든 작업이 될 것이다. 직렬화 메커니즘은 객체를 취하여 객체의 내용을 스트림 형태로 저장할 수 있게 해 주지만 여러 사용자들을 동시에 공유하지는 못한다.
개발자들이 객체와 데이터베이스를 매핑(Mapping)시키는 작업을 걱정하지 않고 비즈니스 솔루션을 개발할 수 있도록 하는 자바 데이터 객체(Java Data Objects, Java Community Press내의 JSR012로 명명된 명세)가 등장하게 되었다. JDO API는 개발자들이 한 번의 작성으로 데이터베이스에 무관하게 사용할 수 있는 표준 API다. 동시에 인터페이스를 구현한 여러 개의 구현 클래스들이 존재한다. 이것은 한 번 JDBC를 작성하여 JDBC 드라이버만 교체함으로써 오라클, Sybase 등 여러 데이터베이스에 접속하는 것과 유사하다. 오라클 OCI 라이브러리나 Sybase Dblib를 공부하지 않아도 된다는 것은 기쁜 일이다. 적어도 나에게는 그렇다.
자바의 표준 스팩으로 등록 요청 됨에 따라, JDO가 모두의 지지를 받는 것은 아니다. 어떤 사람들은 객체 저장을 수행하는 객체들의 표준화에 대하여 찬성하지만 어떤 사람들은 비판한다. 스팩이 발표된 이후, 크라이그 러셀(Craig Russell)은 비판자들과 논쟁하게 되었다.
JDO의 상용 제품의 출시
그 결과 우리는 엔터프라이즈 환경에서 객체를 저장하는 표준 API를 가지게 되었다. 객체 저장 작업을 계속해 오고 있는 개발업체들은 어떤 생각을 가지고 있을까? 지난해 6월 유명한 CocoBase O/R 매핑 솔루션 업체인 Thougth.inc는 벤더 독립적인 객체 저장 기술을 발표했다. 발표된 기사는 JDO의 설계 방식에 대하여 부정적인 시각을 보이고 있다. "많은 사람들이 ODMG와 JDO의 설계를 자바의 Open Access, 플랫폼 독립성, 컴포넌트 재사용의 취지를 손상시킨다고 생각한다. CocoBase의 아키텍쳐는 자바 클래스들을 벤더 독립적으로 만들지만 다른 접근법들은 소스 또는 바이너리 코드를 특정 벤더에 강하게 종속 시킨다. 다른 시스템들은 특정 벤더에 의해 처리되고 통합된 자바 클래스들의 계층구조를 생성한다. 이러한 계층구조는 타 벤더와 완벽하게 호환되지 않는다." JDO의 개발자인 크라이그 러셀은 반론을 제시해야 했다. 그는 Thougth.inc가 JDO의 구현 세부사항을 싫어하는 진짜 이유는 JDO 클래스 파일들이 바이트 코드의 수정을 요구하며, 특정 코드를 추가해야 하기 때문이라고 주장했다. CocoBase의 솔루션은 순수한 객체 모델을 감싸고 있고, 특정 클래스의 상속을 강요하거나 바이트코드 처리를 요구하지 않는다. Severside.com에서 기사 내용, 크라이그 러셀의 반론, Thougth사의 재반론을 볼 수 있다. 흥미로운 읽을 거리가 될 것이다.
만약 여러분중에 Thougth를 지지하고, 객체를 저장하는데 더 좋은 방법이 있다고 생각한다면, 자신만의 방법을 만들어 볼 것인가? 아니면 자신의 의견에 귀 기울이도록 노력하면서 표준에 동조할 것인가?
모든 O/R 제품 업체들이 JDO의 표준 API를 사용하여 개발하기 시작한다면 이상적일 것이다. 그렇지만 TOPLink의 경우, JDO의 특정 수준까지는 지원하겠지만 성능 측면에서 빈약하다고 생각되는 부분에 대해서는 자체 API를 제공한다는 입장을 취할 것으로 보인다. O/R 매핑 툴은 편리하다. 개발자들이 직접 O/R매핑을 위한 코딩을 한다는 것은 불합리하다. 우리가 어떠한 작업을 원한다 하더라도 툴은 그 기능을 제공해야 한다. 어떤 면에서는 자바는 SmallTalk에 비해 아직까지 지원 툴이 뒤쳐져 있다. 미래에는 개발자들의 비즈니스의 요구사항 해결에 더욱 집중할 수 있도록 툴이 지원하는 부분이 더욱 확대되어야 할 것이다. JDO에 대한 더 많은 비판들이 존재하며, 크라이그는 그 비판들에 대하여 만족할 만큼 설명하려고 노력해 왔다. 관심이 있다면 기사 끝에 있는 링크들을 살펴보기 바란다.
JDO와 엔터프라이즈 자바빈즈
JDO는 EJB 포럼에서도 논란을 일으키고 있다. JDO가 발표되자 일부 사람들은 JDO가 엔티티 빈이 수행했어야 할 역활이라고 주장하고 있다. 현재 엔티티 빈을 사용하는 경우는 매우 드물었다. 많은 사람들은 썬이 현재의 엔티티 빈을 포기하고, JDO와 결합시킬 것이라고 생각했다. 그러나 이러한 추측은 현실화 되지 않았으며 관계, EJB-QL, 로컬 인터페이스 지원하는 EJB 2.0 이 발표되었다. 소문에 의하면 썬과 EJB 그룹(BEA, IBM, Borland, Oracle 등)은 엔티티 빈에 많은 투자를 하였기 때문에 그것을 포기하지는 않을 것이라고 한다. 그리고 엔티티 빈이 좋지 않다는 것을 인정하고 공식 발표하는 것 또한 적절한 마케팅 전략으로도 아니라고 생각한다고 한다. 많은 EJB 개발자들이 CMP(Container Management Persistance)를 사용하기 보다는 O/R 매핑 기능을 Bean에 포함시키는 BMP(Bean Management Persistance)를 사용한다. 성능 때문에 JDBC를 사용하는 사람들은 이제 바로 JDO를 사용하려고 한다.
나는 여전히 CMP 엔티티 빈이 가능성이 있다고 생각한다. EJB 2.0 스팩에서는 개발업체들이 내부적으로 최적화 작업을 할 수 있도록 하는 것을 포함하여 뛰어난 성능을 위한 기능들을 지원하고 있다. 분산 객체로서의 엔티티 빈의 시대는 가고, 앞 단의 세션 빈과 엔티티 빈들을 가지는 현재의 구현 권고방식은 로컬 인터페이스로의 전환이 요구되어 질 것이다. 만약 그것이 현실화 된다면 엔티티 빈이 컴포넌트가 될 필요가 있는가?
EJB 안에서 사용되는 기술이 무엇이던지 간에 현재의 관건은 여전히 빈들을 자동 생성해 주는 툴과 고성능 엔진이다. TOPLink와 CocoBase는 매력적인 툴이다. 자동 생성된 Bean의 코드를 수정하지 않아도 된다면 나는 행복한 사람이다. 나는 단지 데이터베이스를 지정하고, 필드와 저장 프로시져를 선택하고 CMP(또는 BMP, 내가 원하는 다른 것) 생성 버튼을 누를 수 있다. 나는 표준이 성숙 되어감에 따라 새로운 툴의 시대가 도래할 것을 기대해 본다.
결론
JDO는 여전히 논란의 여지가 많은 주제이다. 스펙이 구현되어가는 것과 기술적인 성숙을 지켜보는 일은 앞으로도 계속해서 흥미진진한 일임에 틀림없다. JDO는 개발자들이 데이터 작업시 실제적인 도움을 주는 툴과 함께 엔터프라이즈 환경에서 사용되어질 가능성과 능력을 가지고 있다.
링크 다이온 알마에르(Dion Almaer)는 EJB/J2EE와 B2B 기술의 교육 분야의 선도 기업이며 TheServerSide.com의 J2EE의 커뮤니티를 후원하고 있는 미들웨어 회사(www.middleware-company.com)의 책임 기술자이다.
TAG :
이전 글 : 파이썬 1.6b1 라이센스의 숨겨진 뒷 이야기
다음 글 : 맥 OS X 에서 애플스크립트 입문
최신 콘텐츠