Java EE에서 Jakarta EE로의 전환

자바 기술자라면 Java EE(Java Platform, Enterprise Edition) 또는 J2EE(Java 2 Platform, Enterprise Edition)를 들어봤을 것입니다. 자바를 이용한 서버 개발 플랫폼으로 한 때 엔터프라이즈 자바 기술을 선도하며 막강한 영향력을 발휘했지만 기술 변화와 시장 요구에 제때 대응하지 못하면서 현재는 명맥만 유지하는 암울한 상황에 처해 있습니다. 그럼에도 불구하고 자바EE는 가장 성공적인 상업용 표준 플랫폼의 하나이며 대부분의 웹 애플리케이션 서비스를 위한 미들웨어 기술로 꾸준히 사용되고 있습니다. 2018년 자바EE는 자카르타(Jakarta)EE로 명칭을 바꾸고 새로운 변화에 나섰습니다. 본 아티클에서는 오픈소스 기반으로 변경된 자카르타EE의 현재 모습을 살펴보고 미래를 전망해보겠습니다.

Java EE(Java Platform, Enterprise Edition)

자바EE는 1999년 썬 마이크로시스템즈가 J2EE(Java 2 Enterprise Edition) 명으로 발표한 분산 애플리케이션 개발 목적의 산업 표준 플랫폼입니다. 기업용 애플리케이션을 개발/실행하기 위한 기술과 환경을 제공하며 서블릿(Servlet), JSP, EJB, JDBC, JNDI, JMX, JTA 등의 알려진 기술을 포함하고 있습니다. 자바EE의 주요 목적은 특정 운영체제와 미들웨어에 종속되지 않고 정보 교환 및 애플리케이션 호환이 가능한 플랫폼을 제공하는 것입니다.

자바EE의 기술 사양은 자바SE(Java Platform, Standard Edition)와 동일하게 자바 커뮤니티 프로세스(Java Community Process, JCP)의 표준화 과정을 통해 만들어집니다. 새로운 기술 요건들은 자바 스펙 요구서(Java Specification Request, JSR)라는 표준 명세로 제안되며 해당 명세가 구현될 수 있음을 증명하는 참조 구현(Reference Implementations; RI)과 구현을 검증할 수 있는 기술 호환성 키트(Technology Compatibility Kits; TCK)가 제공됩니다. 이러한 명세들이 모여서 하나의 자바EE 버전이 정의되며 각 벤더들은 해당 명세를 구현하여 호환 구현(Compatible Implementations, CI)을 만듭니다. 이렇게 만들어진 호환 구현 제품이 웹 애플리케이션 서버(Web Application Server, WAS)이며 대표적으로 글래스피시(GlassFish), 제이보스(JBoss) EAP, 오픈 리버티(Open Liberty), 파야라(Payara), 웹로직(WebLogic), 와일드플라이(Wildfly) 등의 제품이 있습니다.

Java EE

• Web Profile(Servlet,JSP,JSF,CDI,EJB,JTA,JPA,Gean Validation)
• JAX_WS,JAX-RS,JASPIC,JNDI,JAX_RPC,JAXB,JACC,RMI,JAXR,JMS,JCA,DEPLOY,SAAJ,JAAS,JavaMail,MGMT

[그림 1] 자바EE 플랫폼 사양 다이어그램

자바EE는 출시 초창기에 기업용 자바 플랫폼이라는 새로운 생태계를 열며 큰 성과를 이뤘지만 현재는 상업용 플랫폼의 한계와 스프링 프레임워크(Spring Framework) 등 오픈소스 SW의 발전으로 빛을 잃어가고 있습니다. 더군다나 자바EE의 릴리즈 주기가 2년에서 4년으로 길어지면서 빠르게 변화하는 기술 트렌드를 반영하지 못한 것도 인기가 시들해진 이유 중 하나입니다.

오라클은 2017년 자바EE 8 릴리즈를 마지막으로 오픈소스 SW를 지원하는 비영리 단체인 이클립스 재단에 자바EE 프로젝트를 이관했습니다. 썬 마이크로시스템즈를 인수한 오라클이 사실상 자바EE의 수익화에 실패하면서 기술 주도권을 포기한 것으로 판단됩니다.

Sun Microsystems

• J2EE : Servlet, JSP, EJB 1.2, JMS - 1999~2003
• Java EE 5 : EJB 3, JSF, JPA, JAX_WS - May. 2006
• Java EE 6 : CDI, JAX_RS, Beab Validation, Web Profile - Dec. 2009

Oracle

• Java EE 7 : JSON-P, HTML 5, WebSocket, Batch -Apr. 2013
• Java EE 8 : JSON-B, Security,HTTP/2 - Sep. 2017

Eclipse

• Jakarta EE 8 : Java EE 8, compatibility, release - Sep. 2019
• Jakarta EE 9 : Jakarta. ,namespace, transition -Nov. 20202

[그림 2] 자바EE 버전 히스토리

새로운 시작, Jakarta EE(Jakarta, Enterprise Edition)

이클립스 재단으로 이관된 자바EE의 공식 명칭은 자카르타EE, 프로젝트 명은 EE4J(Eclipse Enterprise for Java)로 변경되었습니다. 자카르타EE는 기존 JCP 정책이 아닌 오픈소스 기반의 자카르타EE 사양 프로세스(Jakarta EE Specification Process, JESP)라는 개방적이고 중립적인 정책을 따릅니다. 오라클이 자바EE 프로젝트는 이관했지만 자바 상표권은 여전히 보유하고 있기 때문에 자바 네임스페이스 사용에 제약이 있었습니다. 이러한 이유로 자카르타EE에서는 자바 네임스페이스가 Jakarta로, API 패키지명은 javax.* 에서 Jakarta.* 로 변경되었습니다. 2020년 12월 발표한 자카르타의 네임스페이스 변화는 기존 개발자들에게 다소 혼란을 줄 것으로 예상됩니다. 이와 별개로 기존 사양 중 XML Registries, XML RPC, Deployment 등 일부 관련 없는 기술들은 자카르타EE에서 사라졌습니다.

자카르타EE는 자바EE를 대체하지 않았고 둘 다 공존하고 있습니다. 자카르타EE는 자바EE 8에서 하드포크된 새로운 플랫폼으로 기존 자바EE와 호환되지 않습니다. 자바EE는 계속 유지되지만 8 버전을 마지막으로 더 이상의 릴리즈와 추가 기능은 제공되지 않고 있습니다. 개발자는 자바EE를 계속 사용할 것인지 아니면 자카르타EE로 마이그레이션 할 것인지를 선택해야 합니다. 다행히도 자카르타EE로 마이그레이션을 지원하는 도구가 제공되고 자바EE에 대한 패치도 계속 나올 것이기 때문에 당장 큰 이슈는 없을 것으로 예상됩니다.

자카르타EE의 핵심 목표는 '클라우드 네이티브 환경을 위한 엔터프라이즈 자바 기술'로 마이크로서비스, 컨테이너 등의 최신 기술 트렌드를 반영하고자 합니다. 이클립스 재단은 이전부터 마이크로서비스를 위한 표준 플랫폼으로 마이크로프로파일(MicroProfile) 프로젝트를 진행하고 있었기에 동일 선상에서 EE4J 프로젝트와 협력하고 통합할 것으로 예상됩니다. 최신 버전인 자카르타EE 9 릴리즈에는 새로운 기술 사양을 포함하고 있지 않습니다. 자카르타 네임스페이스 변경을 완료하고 관련 없는 사양을 정리하는데 중점을 두며 향후 혁신을 위한 준비를 하는 것으로 보여집니다. 현재까지 알려진 자카르타EE의 차기 버전 관련 정보 중 자카르타 NoSQL 사양과 모듈화에 대해 간략하게 살펴보겠습니다.

Jakarta NoSQL

자카르타EE 10에 추가되는 첫 번째 기술 사양은 자카르타 NoSQL입니다. 자카르타 NoSQL은 자바 애플리케이션과 NoSQL 데이터베이스를 통합하기 위한 표준으로 RDBMS의 통합을 위한 JDBC(Java DataBase Connectivity) 사양과 비슷한 개념입니다. 클라우드 환경에서 대용량 데이터 처리를 위한 NoSQL의 활용도는 꾸준히 증가할 것으로 예상되며 이러한 배경에서 새로운 NoSQL 표준이 제안되었습니다.
NoSQL은 Key-Value(아마존 다이나모DB, 레디스), Column(아파치 HBase, 아파치 카산드라), Document(아파치 카우치DB, 몽고DB), Graph(Neo4j, 인포그리드) 등의 여러 가지 데이터 유형이 있습니다. 자카르타 NoSQL은 다양한 유형의 NoSQL 데이터베이스를 하나의 표준 API로 통합하기 위해 통신 계층(Communication Layer)과 매핑 계층(Mapping Layer)을 분리하고 NoSQL 유형별로 4개의 모듈을 포함하고 있습니다.

[그림 3] 자카르타 NoSQL 계층 구조

NoSQL 서버와 통신을 위한 통신 계층은 RDBMS의 JDBC API/Driver와 같은 역할을 담당합니다. NoSQL의 각 유형(Key-Value, Column, Document, Graph)별로 API/Driver를 구분하며 애플리케이션은 동일한 유형의 다른 NoSQL 데이터베이스와 호환성을 가질 수 있습니다. 매핑 계층은 데이터 모델을 정의합니다. 기존 JPA(Java Persistence API), 하이버네이트(Hibernate) 등의 ORM에 적용된 주석을 선언하는 방법이 사용되며 Bean Validation, CDI(Contexts and Dependency Injection) 기술이 동일하게 활용됩니다.

모듈화(Modularity) 지원

모듈화는 컨테이너와 마이크로서비스 환경을 위해 자바 런타임을 경량화하는 것입니다. 풀 스택(Full Stack)인 자바EE 플랫폼 전체를 클라우드 네이티브 환경에 올리는 것은 상당히 비효율적이며 실제 사용되는 모듈만으로 런타임을 구성할 수 있는 경량화 기술이 요구됩니다. 일부 벤더가 자체적인 경량화 기능을 제공하고 자바EE 6에서 웹 프로파일(Web Profile)이라는 간소화 된 WAS 사양을 선보였지만 효용성과 활용도가 낮았습니다. 스프링 프레임워크의 경량화 버전인 스프링 부트(Spring Boot)가 마이크로서비스 환경에서 좋은 반응을 얻고 있는 점에 주목할 필요가 있습니다. 자바 플랫폼의 모듈화 기술은 자바 SE 9에서 JPMS(Java Platform Module System)가 표준으로 이미 지원되고 있습니다. 모듈화는 클라우드 네이티브 환경을 위한 주요 이슈이기 때문에 향후 자카르타EE 릴리즈에 포함될 것으로 예상됩니다.

마치며

자카르타EE는 클라우드 네이티브를 목표로 방향성을 설정했지만 장기적인 로드맵이나 마일스톤은 부족한 상태입니다. 당장은 흥미로운 릴리즈가 없기 때문에 자바EE에서 자카르타EE로 이동할 이유는 없어 보입니다. 아마도 자바EE를 기반으로 하는 스프링 프레임워크, 스프링 부트, 아파치 톰캣(Apache Tomcat) 등이 자카르타EE를 채택하는 시점부터 많은 전환이 이뤄질 것으로 예상됩니다.

자카르타EE 인증을 획득한 WAS는 현재까지 18개 제품으로 이전 자바EE 8의 9개와 비교했을 때 그 시작은 순탄한 것으로 보여집니다. 특히 오픈소스 프로젝트의 참여 규칙인 특정 기업에 종속되지 않는 개방성과 투명성이 긍정적인 영향을 끼쳤을 것으로 생각됩니다. 대표적인 오픈소스 WAS인 와일드플라이(Wildfly) 역시 선도적으로 자카르타EE로의 전환을 진행하고 있으며 자카르타EE 8(자바EE 8)을 지원하는 기본 버전과 새로운 자카르타EE 9를 지원하는 프리뷰 버전을 동시에 발표했습니다.

엔터프라이즈 자바 생태계를 구축하고 발전시켜온 자바EE는 오랜 노력과 공헌에도 불구하고 상업 벤더 중심의 폐쇄적인 정책과 영리를 목적으로 운영되어 많은 비판을 받았습니다. 자카르타EE는 자바EE의 실패에서 교훈을 얻어 잃어버린 명성을 되찾을 수 있기를 기대해봅니다.


References
- https://blogs.oracle.com/javamagazine/transition-from-java-ee-to-jakarta-ee
- https://jakarta.ee/specifications/platform/8/platform-spec-8.html
- https://www.eclipse.org/org/workinggroups/jakarta_ee_faq.php


▶  해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶  해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.