Hibernate의 아버지인 Gavin King [1]은 개발자들에게 Java EE 6 플랫폼으로 업그레이드할 것을 권장했으며, 현재 업그레이드를 꺼리는 것은 사실 근거가 없다고 지적했습니다.
Java EE 6이 출시된 후 새로운 플랫폼으로 업그레이드하는 데 많은 저항이 있었습니다. 이러한 반대의 대부분은 Tomcat/Jetty 및 일부 오픈 소스 프레임워크(예: Hibernate 및 Spring) 사용자에 의해 제기됩니다.
물론 비표준 오픈 소스 기술을 선택하면 많은 이점이 있습니다. 또한 EE 6에서는 관심 있는 오픈 소스 프레임워크를 사용할 수 있습니다. Servlet 3과 CDI는 타사 프레임워크를 원활하게 통합할 수 있습니다. 따라서 EE 6을 사용하지 않을 이유가 없습니다. 그런데 누군가 이렇게 말하는 것을 보았습니다.
EE 애플리케이션 서버로 업그레이드하기가 어렵습니다.
이는 실제 기술적인 문제라기보다는 특정 조직의 정치적인 문제로 보입니다. 물론 GlassFish나 JBoss와 같은 서버를 업그레이드하는 것은 매우 사소한 작업입니다. (타사 프레임워크를 업그레이드하는 것은 훨씬 더 고통스럽습니다.) 일부 조직에서는 서버 업그레이드를 위한 프로세스가 매우 중요하지만 서버 내에서 실행되는 프레임워크를 업그레이드하는 프로세스는 그리 많지 않습니다. 따라서 개발팀이 타사 프레임워크를 업그레이드하는 것이 더 쉽습니다.
Java EE를 버리는 것보다 더 설득력 있고 더 나은 프로세스를 개발하는 것이 가장 중요하다고 생각합니다. 오래되고 오래된 서버 플랫폼에서 애플리케이션을 실행하는 것과 관련된 많은 위험이 있으며 프로세스는 그러한 관행을 장려해서는 안 됩니다.
그러나 실용적인 관점에서 보면 거의 모든 사람들이 가까운 시일 내에 Servlet 3으로 업그레이드할 계획입니다. Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle 또는 WebSphere를 사용하든 이는 서버 업그레이드를 의미합니다. 골든타임인 EE 6 Web Profile로 업그레이드할 수 있는 절호의 기회입니다.
EE 애플리케이션 서버가 너무 큽니다.
반대 의견은 EE Server에 (현재) 사용할 수 없는 많은 기능이 포함되어 있다는 것입니다. 반대자들의 주장에는 일반적으로 jar 패키지의 크기와 서블릿 엔진 + 타사 프레임워크 및 EE 애플리케이션 서버가 차지하는 디스크 공간에 대한 논의가 포함됩니다. 사실 이 주장은 문제가 있습니다.
논의되는 디스크 사용량과 디스크 공간은 실제로 $로 측정하면 사소한 것이며 서버 설치 패키지의 크기보다 응용 프로그램 war 패키지가 훨씬 더 중요합니다. 서버에는 실제로 war 크기를 최소화하기 위한 많은 기능이 포함되어 있습니다.
게다가 가장 설득력 있는 점은 Java EE 6 Web Profile이 전혀 크지 않다는 점이라고 생각합니다. 인증된 웹 프로필 서버가 시장에 출시되면 대규모 EE 애플리케이션 서버와 소규모 서블릿 컨테이너 간의 균형을 찾을 수 있습니다.
나쁜 J2EE와 EJB2!
JCP의 표준화 프로세스를 사용하면 이 문제는 실제로 더 이상 존재하지 않습니다.
1. EJB2가 등장한 지 8년이 되었습니다! 여전히 최선의 선택인가요?
2. JCP의 지속적인 표준화를 통해 좋은 사양이 병합되었으며, 그 중 일부는 매우 확실하게 사용할 수 있습니다. 그러나 JCP는 표준화에 100% 성공하지 못합니다.
3. EE 6 플랫폼에서 작업하는 모든 사람은 EJB2 및 J2EE를 싫어합니다. 그렇기 때문에 사람들은 이러한 문제를 해결하기 위해 지속적으로 JCP에 가입하고 있습니다. 예를 들어, Hibernate의 창립자이자 이 기사의 저자입니다. 정말로 그에게 EJB2에 대한 교훈을 가르치고 싶나요? :-)
4. Entity Beans에 종사하는 거의 모든 사람들이 이제 은퇴했습니다!
실제로 Java EE 6 웹 프로필이면 충분합니다. Java EE 6을 직접 사용해 보지 않으면 개발에 있어 EE6의 이점을 실제로 느낄 수 없습니다.
애플리케이션 서버 이식성은 정말 미스터리입니다!
정말? 많은 사람들이 자신의 애플리케이션을 분할하여 다른 애플리케이션 서버에 배포하는 것을 볼 수 있습니까? 아, 저는 이것이 100% 완벽한 응용 프로그램 0-변경 이식, 즉 이식성에 대한 플라톤적 이상을 의미하는 것을 보았습니다. 절대 진리와 플라톤적 이상에 대한 약점을 이해하지만 먼저 예를 살펴보겠습니다.
이식성 문제에 대한 매우 일반적인 관점은 다음과 같습니다.
코드의 9%, 외부 메타데이터의 85%는 다양한 서버 플랫폼에서 완벽하게 호환되며 나머지 1%와 15%는 적절하게 분할될 수 있습니다.
비표준 단일 공급업체 컨테이너 아키텍처에 연결된 0% 코드, 80% 외부 메타데이터
이러한 점을 나누다가 갑자기 이 섹션의 주제를 애플리케이션 서버 이식성이 너무 신비해서 컨테이너 이식성에 전혀 관심이 없다로 바꾸고 싶었습니다. 테마 변경 아이디어는 서버 이식성 문제가 현실이며 많은 조직에 매우 유용할 것임을 확인시켜 줍니다.
나는 항상 EE 6 기술 관리자가 아닌 사람들로부터 EE 6에 대한 실제 리뷰를 보고 싶었습니다. 위에 언급된 주장 중 일부는 실제 세계에서 나온 것이 아니기 때문에 EE 플랫폼에서 애플리케이션 개발의 실제 기술 문제에 대한 논의를 촉발하기가 어렵습니다. 최신 JCP 사양은 반EE 진영을 떠난 것으로 보이지만(일시적으로?) 성공에 대한 실질적인 뒷받침이 부족합니다.
편집자 주:
[1] Gavin King: Hibernate 창립자, EJB3 전문가 위원회 회원, JBoss 핵심 회원 중 한 명, Seam 프레임워크 리더, JSR-299(CDI) 사양 리더, "Hibernate in Action" 책의 저자 .
출처: Java EE 6으로 업그레이드해야 합니다.