오늘은 Java EE가 무엇인지, Java EE 애플리케이션 아키텍처의 기능은 무엇인지, 그리고 이 플랫폼의 다양한 기술에 대해 설명하겠습니다. 주제 자체는 광범위하지만 기본에만 국한되지는 않습니다. 마지막에는 Java EE와 Spring Framework를 간략히 비교하고 "무엇을 배우는 것이 더 좋은가"라는 질문에 답할 것입니다. (스포일러: 물론 모든 것을 배워야 합니다 =) ) 기본부터 시작하겠습니다.
자바 EE - 그게 뭐죠?
Java EE 는 Java SE를 기반으로 구축된 플랫폼으로, 확장 가능하고 안정적이며 안전한 대규모 다중 계층 네트워크 애플리케이션을 개발하고 실행하기 위한 API 및 런타임 환경을 제공합니다. 이러한 응용 프로그램은 대기업이 직면한 문제를 해결하므로 엔터프라이즈 응용 프로그램이라고 합니다. 그러나 이러한 유형의 애플리케이션과 Java EE가 제공하는 이점을 활용할 수 있는 곳은 대기업과 정부 기관만이 아닙니다. Java EE 플랫폼이 제공하는 솔루션은 개별 개발자와 소규모 조직에 유용하며 때로는 단순히 필요한 경우도 있습니다.
자바 EE 개발
Java EE는 1998년에 형성된 JCP(Java Community Process)를 통해 개발되었습니다. 이를 통해 관심 있는 당사자는 Java 언어 플랫폼 사양의 향후 버전을 형성하는 데 참여할 수 있습니다. 이 프로세스의 기본은 Java 플랫폼에 추가되도록 제안된 사양과 기술을 설명하는 공식 문서인 JSR(Java 사양 요청)입니다. 이러한 요청은 커뮤니티 구성원(일반 개발자 및 회사)이 수행합니다. 후자에는 Oracle, Red Hat, IBM, Apache 등이 포함됩니다. 저것들. 그들은 Java에 포함시키고 싶은 새로운 기능과 장점을 제안합니다. 그런 다음 투표를 통해 다음 버전에 무엇을 포함할지 결정합니다. Java EE 버전 기록은 다음과 같습니다.
J2EE 1.2(1999년 12월)
J2EE 1.3(2001년 9월)
J2EE 1.4(2003년 11월)
자바 EE 5(2006년 5월)
자바 EE 6(2009년 12월)
자바 EE 7(5월)
자바 EE 8(2017년 8월)
자카르타 EE 8 (2019년 9월)
2017년에는 플랫폼 개발의 새로운 이정표가 발생했습니다. Oracle은 Java EE 개발에 대한 제어권을 Eclipse Foundation으로 이전했습니다. 그리고 2018년 4월, Java EE는 Java EE 8과 완벽하게 호환되는 Jakarta EE로 이름이 변경되었습니다.
Java EE 애플리케이션 아키텍처
짧은 소개. 이해를 더 쉽게 하기 위해 Java EE 애플리케이션의 구조와 앞으로 사용할 몇 가지 용어에 대해 이야기하겠습니다. Java EE 애플리케이션에는 두 가지 주요 특성이 있는 구조가 있습니다.
첫째, 다단계. Java EE 애플리케이션은 다중 계층으로 구성되어 있으며 이에 대해서는 나중에 자세히 설명하겠습니다.
둘째, 중첩. 내부에 구성 요소 컨테이너가 있는 Java EE 서버(또는 애플리케이션 서버)가 있습니다. 이 컨테이너에는 (빙고!) 구성 요소가 들어 있습니다.
Java EE 애플리케이션의 아키텍처를 설명하기 위해 먼저 레이어에 대해 이야기해 보겠습니다. 레벨은 어떻게 되나요? 다양한 수준에서 어떤 Java EE 기술이 사용됩니까? 다음으로 애플리케이션 서버, 구성 요소 컨테이너 및 구성 요소 자체가 상호 연결되는 방법에 대해 설명합니다. 하지만 이 모든 것은 같은 것을 다른 각도에서 본 것이므로 여기서 순서는 그다지 중요하지 않다는 점을 명심하세요.
적용 수준
다중 계층 애플리케이션은 기능 원칙에 따라 격리된 모듈(레벨, 레이어)로 구분된 애플리케이션입니다. 일반적으로(Java EE 개발 컨텍스트 포함) 엔터프라이즈 애플리케이션은 세 가지 수준으로 나뉩니다.
고객;
평균 수준;
데이터 액세스 수준.
클라이언트 계층은 Java EE 서버(중간 계층)에 데이터를 요청하는 애플리케이션입니다. 그러면 서버는 클라이언트의 요청을 처리하고 이에 대한 응답을 반환합니다. 클라이언트 애플리케이션은 브라우저, 독립 실행형 애플리케이션(모바일 또는 데스크톱) 또는 그래픽 인터페이스가 없는 기타 서버 애플리케이션일 수 있습니다.
중간 레벨은 다시 웹 레벨과 비즈니스 로직 레벨로 나누어집니다.
웹 계층은 클라이언트와 비즈니스 논리 계층 간의 상호 작용을 제공하는 일부 구성 요소로 구성됩니다.
웹 수준에서는 다음 Java EE 기술이 사용됩니다.
JSF(JavaServer Faces) 기술;
JSP(자바 서버 페이지);
표현 언어(EL);
서블릿;
Java EE(CDI)에 대한 컨텍스트 및 종속성 주입.
비즈니스 로직 계층은 애플리케이션의 모든 비즈니스 로직을 구현하는 구성 요소로 구성됩니다. 비즈니스 로직은 특정 비즈니스 영역(금융 산업, 은행, 전자 상거래)의 요구 사항을 충족하는 기능을 제공하는 코드입니다. 이 레벨은 전체 시스템의 핵심으로 간주될 수 있습니다.
이 수준에 관련된 기술은 다음과 같습니다.
EJB(엔터프라이즈 JavaBeans);
JAX-RS RESTful 웹 서비스;
Java Persistence API 엔터티;
자바 메시지 서비스.
데이터 액세스 수준. 이 레벨을 EIS(Enterprise Information System) 레벨이라고도 합니다. EIS는 다양한 데이터베이스 서버, ERP(Enterprise Resource Planning) 전사적 자원 관리 시스템 및 기타 데이터 소스로 구성됩니다. 비즈니스 논리 계층은 데이터를 위해 이 계층에 액세스합니다.
이 수준에서는 다음과 같은 기술을 찾을 수 있습니다.
자바 데이터베이스 연결 API(JDBC);
자바 지속성 API;
Java EE 커넥터 아키텍처;
JTA(Java 트랜잭션 API).
애플리케이션 서버, 컨테이너, 구성 요소
Wikipedia에서 Java EE의 정의를 살펴보겠습니다. Java EE는 Java 언어에 대한 사양 및 관련 문서 세트로, 중견 기업과 대기업의 작업을 위한 서버 플랫폼의 아키텍처를 설명합니다. 이러한 맥락에서 "사양 집합"이 무엇을 의미하는지 더 잘 이해하기 위해 Java 인터페이스를 비유해 보겠습니다. Java 인터페이스 자체에는 기능이 없습니다. 이는 단순히 일부 기능이 구현되는 계약을 정의합니다. 그러나 다른 클래스는 인터페이스를 구현합니다. 또한 하나의 인터페이스에는 여러 구현이 있을 수 있으며 각 구현은 일부 세부 사항이 서로 다를 수 있습니다. 사양은 완전 똑같습니다. Naked Java EE는 단지 사양 집합일 뿐입니다. 이러한 사양은 다양한 Java EE 서버에 의해 구현됩니다. Java EE 서버는 Java EE 플랫폼 API를 구현하고 표준 Java EE 서비스를 제공하는 서버 애플리케이션입니다. Java EE 서버를 애플리케이션 서버라고도 합니다. 서버 데이터에는 응용 프로그램 구성 요소가 포함될 수 있으며, 각 구성 요소는 다중 수준 계층 구조의 자체 수준에 해당합니다. Java EE 서버는 컨테이너 형태로 이러한 구성 요소에 다양한 서비스를 제공합니다. 컨테이너는 호스팅하는 구성 요소와 구성 요소를 지원하는 하위 수준 플랫폼 독립적 기능 간의 인터페이스입니다. 컨테이너는 호스팅하는 구성 요소에 특정 서비스를 제공합니다. 예를 들어 개발 수명주기 관리, 종속성 주입, 동시성 등이 있습니다. 컨테이너는 기술적 복잡성을 숨기고 이식성을 높입니다. Java EE에는 네 가지 유형의 컨테이너가 있습니다.
애플릿 컨테이너는 대부분의 브라우저에서 구현됩니다. 애플릿을 개발할 때 컨테이너가 보안 환경을 제공하는 동안 애플리케이션의 시각적 측면에 집중할 수 있습니다.
ACC(애플리케이션 클라이언트 컨테이너)에는 Java SE 애플리케이션에서 주입, 보안 관리 및 이름 지정 서비스와 같은 기능을 구현하는 데 필요한 Java 클래스, 라이브러리 및 기타 파일 세트가 포함되어 있습니다.
웹 컨테이너는 웹 구성 요소(서블릿, EJB Lite 구성 요소, JSP 페이지, 필터, 리스너, JSF 페이지 및 웹 서비스)를 관리하고 실행하기 위한 핵심 서비스를 제공합니다. 서블릿의 인스턴스화, 초기화 및 호출, HTTP 및 HTTPS 프로토콜 지원을 담당합니다. 이 컨테이너는 클라이언트 브라우저에 웹페이지를 제공하는 데 사용됩니다.
EJB(Enterprise Java Bean) 컨테이너는 애플리케이션의 비즈니스 로직 계층을 포함하는 EJB 모델 구성 요소를 관리하고 실행하는 역할을 담당합니다. 이는 새로운 EJB Bean 엔터티를 생성하고 수명 주기를 관리하며 트랜잭션, 보안, 동시성, 배포, 이름 지정 또는 비동기 호출 기능과 같은 서비스를 제공합니다.
또한 Java EE에는 Java EE 사양 구현이 지원해야 하는 네 가지 유형의 구성 요소 가 있습니다 .
애플릿은 브라우저에서 실행되는 그래픽 사용자 인터페이스(GUI) 응용 프로그램입니다. 풍부한 Swing API를 활용하여 강력한 사용자 인터페이스를 생성합니다.
애플리케이션은 클라이언트 측에서 실행되는 프로그램입니다. 일반적으로 GUI(그래픽 사용자 인터페이스)이며 일괄 처리에 사용됩니다.
웹 애플리케이션(서블릿과 해당 필터, 웹 이벤트 리스너, JSP 및 JSF 페이지로 구성) - 웹 컨테이너에서 실행되고 웹 클라이언트의 HTTP 요청에 응답합니다. 서블릿은 SOAP 및 RESTful 웹 서비스 엔드포인트도 지원합니다.
엔터프라이즈 애플리케이션(Enterprise Java Bean, Java 메시지 서비스, Java 트랜잭션 API, 비동기 호출, 시간 서비스로 구축)은 EJB 컨테이너에서 실행됩니다. 컨테이너 관리 EJB는 트랜잭션 비즈니스 로직을 처리합니다. RMI(또는 SOAP 및 RESTful 웹 서비스의 경우 HTTP)를 통해 로컬 또는 원격으로 액세스할 수 있습니다.
아래 다이어그램은 일반적인 Java EE 애플리케이션 아키텍처를 보여줍니다.
기술
그래서 우리는 아키텍처를 정리했습니다. 전체적인 구조가 명확해야 합니다. 아키텍처 구성 요소를 설명하는 과정에서 EJB, JSP 등과 같은 일부 Java EE 기술을 다루었습니다. 이제 좀 더 자세히 살펴보겠습니다. 아래 표에는 클라이언트 수준에서 주로 사용되는 기술이 나와 있습니다.
기술
목적
서블릿
클라이언트 요청을 동적으로 처리하고 응답(일반적으로 HTML 페이지)을 생성하는 Java 클래스입니다.
JSF(자바 서버 페이스)
사용자 인터페이스를 사용하여 웹 애플리케이션을 구축하기 위한 프레임워크입니다. 페이지에 사용자 인터페이스 구성 요소(예: 필드 및 버튼)를 포함하고, 이러한 구성 요소를 변환 및 검증하고, 이 데이터를 서버 측 저장소에 저장할 수 있습니다.
Java Server Faces Facelets 기술
JSP 페이지 대신 XHTML 페이지를 사용하는 JSF 애플리케이션의 하위 유형입니다.
JSP(자바 서버 페이지)
서블릿으로 컴파일되는 텍스트 문서입니다. 정적 페이지(예: HTML 페이지)에 동적 콘텐츠를 추가할 수 있습니다.
JSTL(Java Server Pages 표준 태그 라이브러리)
JSP 페이지의 컨텍스트에서 핵심 기능을 캡슐화하는 태그 라이브러리입니다.
표현 언어
Java EE 구성 요소에 액세스하기 위해 JSP 및 Facelets 페이지에서 사용되는 표준 태그 세트입니다.
Java EE(CDI)에 대한 컨텍스트 및 종속성 주입
구성요소의 라이프사이클을 관리하고 안전한 방식으로 클라이언트 객체에 구성요소를 삽입하기 위해 Java EE 컨테이너에서 제공하는 서비스 세트를 나타냅니다.
Java Bean 구성 요소
애플리케이션 페이지의 임시 데이터 저장소 역할을 하는 개체입니다.
아래 표는 비즈니스 로직 수준에서 사용되는 기술을 보여줍니다.
기술
목적
Enterprise Java Bean(엔터프라이즈 Bean) 구성요소
EJB는 애플리케이션의 핵심 기능을 포함하는 관리 Bean입니다.
JAX-RS RESTful 웹 서비스
REST 아키텍처 스타일을 준수하는 웹 서비스를 개발하기 위한 API입니다.
JAX-WS 웹 서비스 엔드포인트
SOAP 웹 서비스를 생성하고 사용하기 위한 API입니다.
JPA(Java Persistence API) 엔터티
데이터 저장소의 데이터에 액세스하고 해당 데이터를 Java 프로그래밍 언어 개체로 변환하거나 그 반대로 변환하기 위한 API입니다.
Java EE 관리 Bean
애플리케이션의 비즈니스 로직을 제공하지만 EJB의 트랜잭션 또는 보안 기능이 필요하지 않은 관리 Bean입니다.
자바 메시지 서비스
JMS(Java Message Service) API는 Java EE 애플리케이션 구성 요소가 메시지를 생성, 전송, 수신 및 읽을 수 있도록 하는 메시징 표준입니다. 이를 통해 구성 요소 간의 분산되고 안정적인 비동기 통신이 보장됩니다.
아래 표는 데이터 액세스 계층에서 사용되는 기술을 보여줍니다.
기술
목적
JDBC(Java 데이터베이스 연결 API)
데이터 저장소에서 데이터에 액세스하고 검색하기 위한 하위 수준 API입니다. JDBC의 일반적인 용도는 특정 데이터베이스에 대한 SQL 쿼리를 작성하는 것입니다.
자바 지속성 API
데이터 저장소의 데이터에 액세스하고 해당 데이터를 Java 프로그래밍 언어 개체로 변환하거나 그 반대로 변환하기 위한 API입니다. JDBC에 비해 훨씬 높은 수준의 API입니다. 개발자로부터 JDBC의 모든 복잡성을 숨깁니다.
Java EE 커넥터 아키텍처
다음과 같은 다른 기업 리소스를 연결하기 위한 API:
ERP(전사적자원관리, 전사적자원관리시스템),
CRM(영어: Customer Relationship Management, 고객 관계 관리 시스템).
자바 트랜잭션 API(JTA)
분산 트랜잭션과 여러 데이터 저장소에 걸친 트랜잭션을 포함하여 트랜잭션을 정의하고 관리하기 위한 API입니다.
자바 EE와 스프링
Spring Framework는 Java EE의 경쟁자로 간주됩니다. 이 두 플랫폼의 발전 과정을 살펴보면 흥미로운 그림이 나타난다. Java EE의 첫 번째 버전은 IBM의 참여로 만들어졌습니다. 결과적으로는 멋있었지만, 투박하고 무겁고 사용하기 불편했습니다. 개발자들은 많은 수의 구성 파일을 유지해야 하는 필요성과 개발을 복잡하게 만드는 기타 이유로 인해 어려움을 겪었습니다. 동시에 Spring IoC가 탄생했습니다. 작고 아름답고 사용하기 쉬운 도서관이었습니다. 구성 파일도 사용했는데 Java EE와 달리 하나만 있었습니다. Spring의 단순성으로 인해 거의 모든 사람들이 자신의 프로젝트에서 이 프레임워크를 사용하기 시작했습니다. 그리고 Spring과 Java EE는 동일한 경로를 시작했지만 다른 끝에서 시작되었습니다. Spring의 개발자인 Pivotal Software는 Java 개발자의 가능한 요구 사항과 불가능한 요구 사항을 모두 충족하기 위해 프로젝트를 계속 출시하기 시작했습니다. 점차 이전에 Spring이라고 불렸던 것이 먼저 프로젝트 중 하나가 되었고 이후 Spring Core의 다른 여러 프로젝트와 완전히 병합되었습니다. 이 모든 것이 원래 스프링과 비교했을 때 Spring이 불가피하게 복잡해지게 만들었습니다. 시간이 지남에 따라 복잡한 Spring 종속성을 모두 추적하는 것이 매우 어려워졌고 모든 것을 자체적으로 로드하고 실행하는 별도의 라이브러리에 대한 필요성이 생겼습니다(이제 사랑받는 Spring Boot가 어딘가에서 문제가 발생했습니다).
그동안 JCP는 Java EE 내에서 가능한 모든 것을 최대한 단순화하기 위해 한 가지 작업을 진행해 왔습니다. 결과적으로 최신 EJB에서는 Bean을 설명하기 위해 클래스 위에 하나의 주석을 지정하는 것으로 충분하며, 이는 개발자에게 Enterprise Java Beans 기술의 모든 기능에 대한 액세스를 제공합니다. 그리고 유사한 단순화가 Java EE 내의 모든 사양에 영향을 미쳤습니다. 결과적으로 Spring과 Java EE는 기능면에서 대략 동등합니다. 어떤 것은 더 좋고 어떤 것은 더 나쁩니다. 그러나 전체적으로 보면 큰 차이는 없습니다. 업무의 복잡성도 마찬가지다. Spring과 Java EE는 모두 훌륭한 도구입니다. 아마도 Java로 엔터프라이즈 네트워크 애플리케이션을 구축하기 위해 현재 존재하는 최고일 것입니다. 그러나 Java EE는 일반적으로 Enterprise Application Server 내에서만 작동할 수 있으며(Tomcat은 하나가 아님) Spring 스택의 애플리케이션은 모든 것(동일한 Tomcat)에서 실행될 수 있으며 심지어 서버 없이도 실행될 수 있습니다. 그 자체로는 독립적입니다). 이로 인해 Spring은 소규모 프런트 엔드 GUI 애플리케이션 또는 마이크로서비스 아키텍처를 개발하는 데 이상적인 도구가 됩니다. 그러나 애플리케이션 서버에 대한 의존성을 제거하면 Spring 애플리케이션의 확장성에 부정적인 영향을 미쳤습니다. 그리고 Java EE는 확장 가능한 모놀리식 클러스터 애플리케이션을 구현하는 데 매우 적합합니다. Spring Framework에 익숙한 개발자는 현재 노동 시장에서 더 큰 수요를 보이고 있습니다. 역사적으로 이런 일이 일어났습니다. Java EE가 지나치게 복잡했던 시기에 Spring은 "고객 기반을 확보했습니다." 하지만 아직까지 Spring이나 Java EE에서 무엇을 배워야 하는지에 대한 명확한 답은 없습니다. 초보자에게는 다음과 같은 조언이 주어질 수 있습니다. 두 플랫폼 모두에 대해 (적어도 표면적으로는) 알아보세요. Java EE와 Spring 모두에서 작은 홈 프로젝트를 작성합니다. 그런 다음 직장에 필요할 프레임워크를 더 자세히 살펴보세요. 결과적으로 Spring과 Java EE 간 전환이 어렵지 않습니다.
결과
물론 큰 주제를 하나의 기사로 다룰 수는 없습니다! 수많은 새로운 용어를 사용한 후에는 이 지식을 실제 사례에 "적용"하고 싶을 것입니다. 따라서 우리는 계속해서 Java EE를 연구할 것입니다. 다음 기사에서는 Java EE 개발을 위한 로컬 환경 설정에 대한 실용적인 교훈을 찾을 수 있습니다.
GO TO FULL VERSION