Rod Johnson의 글을 통해 Interface21의 Java EE 6 JSR 참여와 Profiles의 등장을 알게 된 지 1년 8개월 지났다. JSR 번호로는 JSR 316인데, 2월 23일 명세서 재정(Specification)을 위한 최종 표결을 마쳤다. 이해관계자가 워낙 많은 표준인지라 긴 시간을 요하겠지만, 20개월이란 시간은 명세서 제정 과정을 느리게 느끼게 한다.1
Specification Lead인 Roberto Chinnici 블로그에서 Java EE에 대한 최근 상황을 설명하고 있다. JSR 316은 두 개의 명세서를 제정한다. 하나는 Java EE 6 자체 명세서이고, 다른 하나는 Web Profile 명세서이다. Web Profile 명세서를 이해하려면 Profiles 개념을 알아야 한다. Java EE 6 명세서 9장에서 Profiles를 다루고 있다. 5쪽 분량으로 정의와 규칙을 설명하고 있는데, 소개 부분만 발췌해본다.
간단히 정리하면 특정 애플리케이션 유형 혹은 영역에 맞춰 Java EE 플랫폼 일부 기술을 조합한 것이라 할 수 있다. 명세서에서 가상의 Java EE Portal Profile을 예로 들고 있긴 하지만, 현재는 Web Profile만이 유일한 프로파일로 존재한다.
그래서 Web Profile의 핵심은 플랫폼에서 어떤 기술을 선정했는가? 이다. 현재 최종 후보(Final Draft)에서 필수 요소(required components)는 다음과 같다:
•Servlet 3.0
•JavaServer Pages (JSP) 2.2
•Expression Language (EL) 2.2
•Debugging Support for Other Languages (JSR-45) 1.0
•Standard Tag Library for JavaServer Pages (JSTL) 1.2
•JavaServer Faces (JSF) 2.0
•Common Annotations for Java Platform (JSR-250) 1.1
•Enterprise JavaBeans (EJB) 3.1 Lite
•Java Transaction API (JTA) 1.1
•Java Persistence API (JPA) 2.0
가장 눈에 띄는 항목은 Enterprise JavaBeans (EJB) 3.1 Lite이다. 그리고 InfoQ 기사, Roberto 블로그에 달린 댓글을 보면 Web Beans 배제가 이슈이다. 눈에 띄는 부분을 발췌해본다.
참고로 Web Beans는 Spring이 채용하는 stateless 기반의 프로그래밍 모델을 비판하며 소개했던 Seam의 개발자인 Gavin King(Red Hat 소속)이 Specification Lead를 맡고 있다. Web Beans 명세서를 제정하는 JSR299에는 SpringSource가 참여하고 있지 않으며, JEE 6 제정에 Red Hat은 참여하고 있다.
한편, Web Profile 명세에도 다음과 같은 노트가 있다.
또 한 가지 흥미로운 사실은 리뷰 과정을 통해 JSR299를 Web Beans라는 새로운 이름 대신에 Contexts and Dependency Injection for Java로 바꾸고, 새로운 프로그래밍 모델로서가 아니라 JEE/EJB Lite container에 흡수시키기로 했다는 점이다.
JEE6와 Web Profile 그리고 JSR299의 변화 등을 살펴보면서 의문사항이 생겼다. Web Profile에 EJB Lite를 포함하는 이유는 J2EE without EJB 실현을 주도하던 Spring의 역할과 크게 다르지 않다. 게다가 Rod Johnson은 JEE6 제정에 직접 참여했다. 그렇다면, Spring은 Web Profile과 EJB 3.1 Lite를 지원할까? 그리고 JSR299와 Spring의 관계는 어떤 양상으로 발전할까?
답은 알 수 없지만, EJB 3.1 Lite를 살펴보면 앞으로 전개할 양상에 대해 어느 정도 짐작은 가능하다. JSR318 EJB 3.1 명세서에서 EJB Lite를 정의한 부분을 찾을 수 있었다.
EJB Lite는 Web Profile을 위한 EJB 실행 환경이다. EJB 3.1 Lite는 JSR318 페이지에서 공개한 다음 쟁점에 대한 산출물로 보인다.
정리를 해야겠다. Rod Johnson 말처럼 Java EE의 Profiles 개념은 혁신적이다. 하지만, 개념의 혁신이 개발자에게 즉각적으로 눈에 띄는 이익을 보장하지는 않는다. 20개월 걸려서 구워낸 결과물에서 호들갑을 떨만한 요소는 보이지 않았다. 마치 JPA가 CMP를 버리고, Hibernate가 입증한 방식을 수용했듯 Spring이 입증한 사실을 JEE에 반영하여 de facto 표준이 아닌 JEE 명세서로 만들려는 시도 정도로 보인다면 지나친 폄하일까?
EJB Lite는 Spring 사용자라면 굳이 필요할까 싶은 내용이다. 만일 JSF를 사용한다면, JSR299 + EJB Lite는 Spring 기반의 웹 프로그래밍 모델에 대안일 수는 있을 법하다. 아직 JSR29에 대해서는 잘 모른다. 오는 2월 28일 JCO 콘퍼런스에서 김태완님이 'Using Web Beans for Standard DI and Context management'라는 제목으로 실습(Hands-on-Lab) 강의를 2시간 동안 진행할 예정이다. 이번 JCO 콘퍼런스 TFT로 일하면서 Hands-on-Lab 강의 기획과 강사 섭외를 맡아서 편성한 네 개 강의 중 하나다. 가능하면 나도 실습에 참석해서 배워보고 싶다.
Specification Lead인 Roberto Chinnici 블로그에서 Java EE에 대한 최근 상황을 설명하고 있다. JSR 316은 두 개의 명세서를 제정한다. 하나는 Java EE 6 자체 명세서이고, 다른 하나는 Web Profile 명세서이다. Web Profile 명세서를 이해하려면 Profiles 개념을 알아야 한다. Java EE 6 명세서 9장에서 Profiles를 다루고 있다. 5쪽 분량으로 정의와 규칙을 설명하고 있는데, 소개 부분만 발췌해본다.
A Java EE profile (from now on, simply “a profile”) represents a configuration of the platform suited to a particular class of applications. A profile may contain a proper subset of the technologies contained in the platform. By doing so, a profile can effectively drop technologies which the platform supports but which are not generally useful in a particular domain. A profile may also add one or more technologies which are not present in the platform itself. For example, a hypothetical Java EE Portal Profile would likely include the Portlet API (JSR-286).
Additionally, a profile may tag certain technologies as optional. In this case, products implementing the profile may or may not include the technology in question. Naturally, if they do, they need to obey all the relevant requirements mandated by the profile specification. A product may implement two or more Java EE profiles, or the full platform and one or more Java EE profiles, as long as their combined requirements do not give rise to conflicts.
Additionally, a profile may tag certain technologies as optional. In this case, products implementing the profile may or may not include the technology in question. Naturally, if they do, they need to obey all the relevant requirements mandated by the profile specification. A product may implement two or more Java EE profiles, or the full platform and one or more Java EE profiles, as long as their combined requirements do not give rise to conflicts.
간단히 정리하면 특정 애플리케이션 유형 혹은 영역에 맞춰 Java EE 플랫폼 일부 기술을 조합한 것이라 할 수 있다. 명세서에서 가상의 Java EE Portal Profile을 예로 들고 있긴 하지만, 현재는 Web Profile만이 유일한 프로파일로 존재한다.
그래서 Web Profile의 핵심은 플랫폼에서 어떤 기술을 선정했는가? 이다. 현재 최종 후보(Final Draft)에서 필수 요소(required components)는 다음과 같다:
•Servlet 3.0
•JavaServer Pages (JSP) 2.2
•Expression Language (EL) 2.2
•Debugging Support for Other Languages (JSR-45) 1.0
•Standard Tag Library for JavaServer Pages (JSTL) 1.2
•JavaServer Faces (JSF) 2.0
•Common Annotations for Java Platform (JSR-250) 1.1
•Enterprise JavaBeans (EJB) 3.1 Lite
•Java Transaction API (JTA) 1.1
•Java Persistence API (JPA) 2.0
가장 눈에 띄는 항목은 Enterprise JavaBeans (EJB) 3.1 Lite이다. 그리고 InfoQ 기사, Roberto 블로그에 달린 댓글을 보면 Web Beans 배제가 이슈이다. 눈에 띄는 부분을 발췌해본다.
I also realize that WebBeans is controversial with the Spring folks,
but this adds fundamental things to web programming (not just JSF) such
as "conversation scope". I want to see this required as well.
Regarding EJB light, what benefit are we going to get from only stateless session beans that WebBeans doesn't already provide? If you do include it, I would expect EJB 3.1 Lite, not EJB 3.0 Lite (no local business interface required). The biggest thing from EJB that I would want to see in WebProfile is the EJB 3.1 Timer.
참고로 Web Beans는 Spring이 채용하는 stateless 기반의 프로그래밍 모델을 비판하며 소개했던 Seam의 개발자인 Gavin King(Red Hat 소속)이 Specification Lead를 맡고 있다. Web Beans 명세서를 제정하는 JSR299에는 SpringSource가 참여하고 있지 않으며, JEE 6 제정에 Red Hat은 참여하고 있다.
한편, Web Profile 명세에도 다음과 같은 노트가 있다.
The expert group would like to solicit feedback from the community on whether to include Web Beans (JSR-299) 1.0 in the full Java EE Platform (see Section 6.30 of the Platform specification) and/or in the Web Profile.
또 한 가지 흥미로운 사실은 리뷰 과정을 통해 JSR299를 Web Beans라는 새로운 이름 대신에 Contexts and Dependency Injection for Java로 바꾸고, 새로운 프로그래밍 모델로서가 아니라 JEE/EJB Lite container에 흡수시키기로 했다는 점이다.
JEE6와 Web Profile 그리고 JSR299의 변화 등을 살펴보면서 의문사항이 생겼다. Web Profile에 EJB Lite를 포함하는 이유는 J2EE without EJB 실현을 주도하던 Spring의 역할과 크게 다르지 않다. 게다가 Rod Johnson은 JEE6 제정에 직접 참여했다. 그렇다면, Spring은 Web Profile과 EJB 3.1 Lite를 지원할까? 그리고 JSR299와 Spring의 관계는 어떤 양상으로 발전할까?
답은 알 수 없지만, EJB 3.1 Lite를 살펴보면 앞으로 전개할 양상에 대해 어느 정도 짐작은 가능하다. JSR318 EJB 3.1 명세서에서 EJB Lite를 정의한 부분을 찾을 수 있었다.
The set of required APIs is divided into two categories : a complete set and a minimum set.The minimum set is also referred to as “EJB Lite.” This reflects the ability of Server Providers to provide an EJB 3.1 container within a product that implements the Java EE Full Profile or within a subset profile such as the Java EE Web Profile.
EJB Lite는 Web Profile을 위한 EJB 실행 환경이다. EJB 3.1 Lite는 JSR318 페이지에서 공개한 다음 쟁점에 대한 산출물로 보인다.
Support for direct use of EJBs in the servlet container,
including simplified packaging options.
정리를 해야겠다. Rod Johnson 말처럼 Java EE의 Profiles 개념은 혁신적이다. 하지만, 개념의 혁신이 개발자에게 즉각적으로 눈에 띄는 이익을 보장하지는 않는다. 20개월 걸려서 구워낸 결과물에서 호들갑을 떨만한 요소는 보이지 않았다. 마치 JPA가 CMP를 버리고, Hibernate가 입증한 방식을 수용했듯 Spring이 입증한 사실을 JEE에 반영하여 de facto 표준이 아닌 JEE 명세서로 만들려는 시도 정도로 보인다면 지나친 폄하일까?
EJB Lite는 Spring 사용자라면 굳이 필요할까 싶은 내용이다. 만일 JSF를 사용한다면, JSR299 + EJB Lite는 Spring 기반의 웹 프로그래밍 모델에 대안일 수는 있을 법하다. 아직 JSR29에 대해서는 잘 모른다. 오는 2월 28일 JCO 콘퍼런스에서 김태완님이 'Using Web Beans for Standard DI and Context management'라는 제목으로 실습(Hands-on-Lab) 강의를 2시간 동안 진행할 예정이다. 이번 JCO 콘퍼런스 TFT로 일하면서 Hands-on-Lab 강의 기획과 강사 섭외를 맡아서 편성한 네 개 강의 중 하나다. 가능하면 나도 실습에 참석해서 배워보고 싶다.
- 그 사이에 그 사이에 Interface21은 SpringSource로 회사 이름도 바꾸었다. [본문으로]
