이미 필요한 JPA 구현이 있음

필자는 최근에 IBM® WebSphere® Application Server 환경 내에서의 Hibernate 사용에 관해 여러 건의 포럼 게시물, 이메일, 인스턴트 메시지 및 전화 통화에 답변해왔다. 이 주제에 관해서는 워낙 관심도가 높기 때문에, 필자에게 아직 직접 질문하지 못한 분께서는 여기에 소개하는 정보를 문서에 기록해두면 도움이 될 것이라 생각한다.

특히, 필자는 WebSphere Application Server 환경에서 Hibernate JPA를 사용하라고 언급할 것이다. 필자가 Hibernate "Classic"이라고 지칭하는 원래 Hibernate 프로그래밍 모델도 있다. 기존 Hibernate 프로그래밍 모델은 Java™ EE 5 스위트에 속하지 않으므로, 이 대화에 적절하지는 않다. WebSphere Application Server 환경 내에서 Hibernate "Classic" 프로그래밍 모델을 활용할 수 있는 방법을 설명한 Using Spring and Hibernate with WebSphere Application Server 기사가 여러 번 반복되었다. 이 사용법은 다른 유틸리티 프레임워크와 기본적으로 같다. 이것을 (공유) 라이브러리로 패키지화하여 애플리케이션에서 사용할 수 있지만, 전체 애플리케이션 서버 런타임의 필수 요소는 아니다.

이 기사에서 초점을 맞출 내용은 WebSphere Application Server 환경에서의 Hibernate JPA 사용이며, 실은 WebSphere Application Server가 이미 산업 표준의 JPA 구현을 제공하는 데 도대체 왜 Hibernate JPA를 사용하는가 하는 문제다.

위로

JPA란?

JPA는 Java Persistence API로서, Java EE 5에 있는 스펙의 EJB™ 3.0 제품군의 일부로 처음 도입된 표준 지속성 프레임워크이다. Java EE 6의 경우, JPA 2.0은 자체 JSR로 진전한다. 그 핵심에 있는 JPA는 O/R(Object/Relational) 맵핑 기능이지만, 여러 가지 다른 기능을 포함하는 방향으로 발전했다. JPA는 Java EE 스위트의 필수 요소이기 때문에, 그 기능이 EJB 컨테이너 및 웹 컨테이너뿐 아니라 트랜잭션 관리, 데이터베이스 연결 관리 및 보안 관리와 완전히 통합된다. JPA를 작성할 때 EJB CMP, JDO 및 Hibernate와 같은 다양한 기술이 적용되었다. 기존의 많은 Hibernate 사용자가 WebSphere Application Server 환경 내에서 이 프레임워크를 계속 사용하기를 원한다는 점은 놀랄 일이 아니다.

한 프로그래밍 모델(기존 모델)에서 다른 모델(JPA)로 이동하는 데는 시간과 자원이 필요하므로, Hibernate를 계속 사용하는 것은 거의 틀림없이 유효한 목표이다. 이런 투자를 해야 하는 타당성이 부족한 경우에는 효과가 있는 방법을 계속 사용해도 괜찮고, 오히려 권장되는 방법일 수도 있다.

그러나 JPA 표준으로 마이그레이션하고 그에 따른 이점을 누릴 계획이라면, Hibernate "Classic"에서 WebSphere JPA 솔루션으로 마이그레이션할 여러 가지 상당한 이유가 있다.

위로

WebSphere JPA 솔루션과 장점

WebSphere Application Server JPA 솔루션은 Apache OpenJPA 프로젝트를 기반으로 빌드된다.

• WebSphere Application Server V6.1 Feature Pack for EJB 3.0에 처음으로 JPA가 포함되었고, 이 버전은 OpenJPA 1.0.x 서비스 스트림을 기반으로 했다.
• WebSphere Application Server V7에서는 OpenJPA 1.2.x 스트림을 기반으로 업데이트된 JPA 구현을 포함한 전체 Java EE 5 스택을 제공했다.
• 가장 최근에는, WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API 2.0이 도입되었는데, 이 버전은 OpenJPA 2.0.x 스트림을 기반으로 한다.

이 모든 결과물에서는 OpenJPA 다운로드 사이트에서 구할 수 있는 것과 같은 2진 파일을 사용하므로, Apache OpenJPA에 대해 작성된 어떤 애플리케이션이라도 WebSphere Application Server 환경에서 수정 없이 계속 실행될 것이라 확신해도 된다.

물론, WebSphere Application Server에는 매우 완전하고 기능이 풍부한 JPA 솔루션을 제공하기 위해 정의된 플러그 지점을 통해 기본 OpenJPA 결과물 이상의 추가 기능도 있다.

• 사용 용이성

  WebSphere JPA 솔루션은 WebSphere Application Server 오퍼링에 완전히 통합된다. 사용자 환경에서 기능 팩 솔루션 중 하나를 사용하든 WebSphere Application Server v7을 사용하든 상관없이, JPA 솔루션은 추가 구성이나 패키징 없이 바로 사용할 수 있다.

  이 통합된 JAP 솔루션(그림 1) 때문에, WebSphere Application Server는 기본 OpenJPA 2진 파일에 대한 기능적 확장을 제공할 수 있다. 향상된 영역으로는 IBM DB2® 확장(특히, pureQuery 통합 및 잠금 최적화), 성능, 구성 및 관리 지원, 보안 지원, 확장된 추적 및 로깅 지원, 메시지 로깅을 위한 자국어 지원 등이 있다.

  
  
  그림 1. WebSphere JPA 아키텍처
  
  
  

  WebSphere Application Server JPA 솔루션을 사용하면 대체 JPA 제공자를 설치하여 WebSphere Application Server 런타임에서 사용할 수 있다. 예를 들어, Hibernate JPA 사용은 가능하지만, WebSphere Application Server 확장 중 아무 것도 Hibernate JPA 제공자와 함께 사용할 수 없을 것이다. 그 밖에도, Hibernate JPA 솔루션의 패키징은 간단한 문제가 아니다(참고자료 참조). 따라서 결론적인 이점은 WebSphere Application Server가 대체 JPA 제공자의 사용을 지원한다는 점이지만, 이 접근 방법에는 단점이 있다.

• 지원 비용 절감

  완전한 WebSphere JPA 솔루션에는 전체 IBM 제품 서비스와 지원이 포함되는데, 이는 곧 발견되는 어떤 문제점이라도 일반적인 지원 채널을 통해 해결될 것임을 의미한다. JPA 개발팀에 소속된 대부분의 구성원은 Apache OpenJPA 프로젝트에서 커미터로서 활발하게 활동하고 있다. Apache OpenJPA 프로젝트에서 문제가 로그되고 해결된다. 그런 다음, 이런 업데이트는 편리하게 일반적인 WebSphere 지원 프로세스의 일부로 전달된다.

  WebSphere JPA 솔루션의 또 다른 주요 이점은 릴리스 간 호환성 지원이다. 한 WebSphere Application Server 릴리스에서 (전체 버전과 기능 팩을 포함한) 다음 릴리스로의 마이그레이션은 최대한 쉬워야 한다는 점이 중요하고, JPA 마이그레이션 역시 원활하게 진행하기 위한 모든 시도가 이루어진다. 새 JPA 또는 Java EE 스펙에서 제품에 대해 호환되지 않는 변경을 강제하는 경우, 일반적으로 올바른 작동을 달성하기 위한 문서와 "되돌리기 옵션"이 제공된다. OpenJPA의 유연한 패키징 아키텍처 때문에, WebSphere Application Server는 OpenJPA의 적합하지 않은 모든 작동을 대체하여 릴리스 간에 WebSphere Application Server 사용 경험을 일관되게 만들 수 있다.

  Hibernate JPA와 같은 대체 JPA 제공자를 사용하는 경우에는 대체 JAP 제공자에 대해 정의된 플러그 지점에서 WebSphere Application Server 지원이 중지된다. (오브젝트 맵핑, 데이터베이스 상호 작용, 성능 문제 등과 같은) 대체 JPA 제공자에서 검색된 모든 문제점은 그 제공자로 해결할 필요가 있다. 여기에는 지원을 위한 포럼을 사용하거나 외부 서비스 계약을 체결하는 과정이 포함될 수 있다. 분명히, 편리하지는 않다.

• 성능 개선

  레코드의 경우, 성능 비교가 복잡할 수 있다. JPA 제공자가 개발하고 승격하는 모든 성능 벤치마크와 심지어는 웹에 게시되는 소위 "독립적인" JPA 벤치마크에서도 다른 JPA 제공자보다 특정 JPA 제공자에 호의를 보이는 경향이 있다. 추가 라이센스 부여 문제와 이런 유형의 특정 JPA 벤치마크가 성가실 수 있다.

  이런 이유와 다른 이유 때문에, IBM은 일반적으로 산업 표준 벤치마크에 의존한다. 예를 들어, SpecJEnterprise는 애플리케이션 서버의 여러 가지 측면을 고려하지만, 지속성 프레임워크에 초점을 맞춘다. SpecJEnterprise 벤치마크의 75-80%는 지속성 계층(즉, JPA 제공자)에 의존하는 것으로 추정되었다. SpecJEnterprise 1Q2010 비교에서는 2010년 2분기와 그 이후에 비슷한 결과를 보여, 이 분야에서 WebSphere가 최고임을 분명히 알 수 있다.

  IBM은 업계 벤치마크를 실행하고 다른 방법도 동원하여 기본 작업(작성, 검색, 업데이트, 삭제)을 기준으로 다른 솔루션에 비해 WebSphere Application Server JPA 솔루션의 성능을 항상 비교한다. 모델이 다양하다는 점이 WebSphere JPA 솔루션이 계속 최고의 성능을 발휘할 뿐 아니라, WebSphere Application Server의 경험과 전체적인 이점을 극대화할 수 있는 요인인 것으로 평가된다.

위로

결론

결론적으로, Hibernate JPA나 다른 JPA 제공자로 옮겨가지 않고 WebSphere JPA 솔루션을 계속 고수하는 것이 비즈니스 관점에서나 개발 관점에서 합리적일 뿐 아니라, 그냥 상식적으로 생각해봐도 전체적으로 합당한 결정이다. 사용 용이성, 비용 절감, 성능 개선 및 만족스러운 경험은 WebSphere Application Server로부터 받는 이익을 극대화할 뿐 아니라, 개발 노력의 성과를 극대화하는 데도 도움이 된다.

참고자료

교육

• Using Spring and Hibernate with WebSphere Application Server
  
  
• JSR-000220 Enterprise JavaBeans 3.0 specification
  
  
• JSR-000317 Java Persistence 2.0 specification
  
  
• Comment lines: An update on Java Persistence API 2.0
  
  
• Apache OpenJPA project
  
  
• Using third-party persistence providers
  
  
• Alternate JPA Providers in WebSphere Application Server(PDF 545KB)
  
  
• SPECjEnterprise2010
  
  
• First Quarter 2010 SPECjEnterprise2010 Results
  
  
• IBM developerWorks WebSphere 페이지
  
  

제품 및 기술 얻기

• WebSphere Application Server
  
  
• WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API 2.0
  
  
• WebSphere Application Server Feature Pack for EJB 3.0
  
  

토론

• 포럼: JPA and websphere 7
  
  
• 블로그: WebSphere and Java Persistence
  
  

필자소개

아티클 순위

의견

위로

목차

• 이미 필요한 JPA 구현이 있음
• JPA란?
• WebSphere JPA 솔루션과 장점
• 결론
• 참고자료
• 필자소개
• 의견