자카르 기업 콩

Jakarta Enterprise Beans
자바빈즈와 혼동하지 않기 위해서입니다.

자카르타 엔터프라이즈 빈스(EJB, 이전 Enterprise JavaBeans)는 엔터프라이즈 소프트웨어의 모듈식 구축을 위한 여러 자바 API 중 하나이다.EJB는 애플리케이션의 비즈니스 로직을 캡슐화하는 서버측 소프트웨어 구성요소다.EJB 웹 컨테이너는 컴퓨터 보안, 자바 서블릿 라이프사이클 관리, 트랜잭션 처리 및 기타 웹 서비스를 포함한 웹 관련 소프트웨어 구성요소를 위한 런타임 환경을 제공한다.EJB 규격은 Java EE 규격의 하위 집합이다.[1]

사양

The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999[2] and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) and JSR 345 (EJB 3.2).

EJB 규격은 ('프론트 엔드' 사용자 인터페이스 소프트웨어가 아닌) 엔터프라이즈 애플리케이션에서 일반적으로 발견되는 서버측("백엔드"라고도 함) '비즈니스' 소프트웨어를 구현하는 표준 방법을 제공한다.그러한 소프트웨어는 동일한 유형의 문제를 해결하며, 이러한 문제에 대한 해결책은 프로그래머에 의해 반복적으로 재실행되는 경우가 많다.자카르타 엔터프라이즈 빈스는 지속성, 트랜잭션 무결성 및 보안과 같은 일반적인 우려를 표준적인 방법으로 처리하여 프로그래머들이 가까이에 있는 기업 소프트웨어의 특정 부분에 자유롭게 집중할 수 있도록 하기 위한 것이다.

일반 책임

EJB 규격에는 애플리케이션 서버가 다음과 같은 책임을 제공하는 방법이 자세히 설명되어 있다.

또한 자카르타 엔터프라이즈 빈스 규격은 EJB 컨테이너와 EJB가 수행하는 역할과 컨테이너에 EJB를 전개하는 방법을 정의한다.EJB 규격은 애플리케이션 서버가 지속성을 제공하는 방법(JPA 규격에 위임된 작업)을 자세히 설명하지 않고, 대신 비즈니스 로직이 애플리케이션 서버가 제공하는 지속성 서비스와 쉽게 통합할 수 있는 방법을 자세히 설명한다는 점에 유의한다.

역사

기업들은 EJB를 사용하여 비즈니스 논리를 캡슐화하는 것이 성과 저하를 가져온다는 것을 발견했다.이는 대다수의 비즈니스 애플리케이션에서 실제로 이러한 분산 컴퓨팅 기능이 필요하지 않더라도 CORBA(및 선택적으로 다른 프로토콜)를 통한 원격 방법 호출에만 원래 규격이 허용되었기 때문이다.EJB 2.0 규격은 여러 서버에 분산되지 않은 애플리케이션에 의해 성능 저하 없이 직접 호출될 수 있는 로컬 인터페이스 개념을 추가함으로써 이러한 우려를 해결했다.[3]

EJB 3.0 규격(JSR 220)은 새로운 경량화 패러다임을 따르는 이전 모델과는 다른 것이었다.EJB 3.0은 Spring의 영향을 받아 일반 Java 객체의 사용과 이질적인 시스템의 구성과 통합을 단순화하기 위한 종속성 주입에 대한 지원을 보여준다.EJB 3.0은 다른 버전의 EJB와 함께 MuleSoft 공인 PlektonLabs EJB Connector를 사용하여 MuleSoft-v4와 통합할 수 있다.브라이버나이트의 창시자인 개빈 킹은 EJB 3.0 프로세스에 참여했으며 이 기술을 거침없이 옹호하고 있다.원래 최대 절전 모드에서는 많은 기능이 EJB 3.0에서 엔티티 콩을 대체하는 자바 지속성 API에 통합되었다.EJB 3.0 규격은 훨씬 덜 장황한 코딩 스타일을 가능하게 하기 위해 주석 사용(5.0 릴리스로 자바 언어에 추가된 기능)과 구성에 대한 규약에 크게 의존한다.따라서 실제적인 측면에서 EJB 3.0은 훨씬 가볍고 이전 EJB 규격과 거의 유사하지 않은 완전히 새로운 API이다.[citation needed]

예

다음은 코드에서 EJB가 어떻게 보이는지 보여주는 기본적인 예다.

@스테이트리스  공중의 계급 고객 서비스 {        사유의 엔티티매니저 엔티티매니저;        공중의 공허하게 하다 addCustomer(고객 고객) {      엔티티매니저.고집을 부리다(고객);    }  }

위의 내용은 (O/R 매핑을 통해) 고객 객체를 유지하기 위한 서비스 클래스를 정의한다.EJB는 지속성 컨텍스트 관리를 담당하고 addCustomer() 방법은 기본적으로 트랜잭션 및 스레드-세이프다.입증된 바와 같이 EJB는 비즈니스 논리와 지속성에만 초점을 맞추고 특정 프레젠테이션에 대해서는 아무것도 모른다.

그러한 EJB는 다음과 같은 웹 계층의 클래스에 의해 사용될 수 있다.

@이름  @RequestScoped 공중의 계급 고객백킹 {    @EJB     사유의 고객 서비스 고객 서비스;     공중의 끈 addCustomer(고객 고객) {       고객 서비스.addCustomer(고객);       문맥.addMessage(...); // 간결성을 위해 줄임말       돌아오다 "customer_properties";    } }

위 내용은 EJB가 @EJB 주석을 통해 주입되는 JavaServer Faces(JSF) 백업 콩을 정의한다.그것의 addCustomer 방법은 일반적으로 버튼과 같은 일부 UI 구성요소에 바인딩되어 있다.EJB와는 달리, 백업 콩에는 어떠한 비즈니스 논리나 지속성 코드가 포함되어 있지 않지만, 그러한 우려를 EJB에 위임한다.배접 콩은 특정 프리젠테이션에 대해 알고 있는데, 그 중 EJB는 전혀 알지 못했다.

엔터프라이즈 원두의 종류

EJB 컨테이너에는 두 가지 주요 유형의 원두가 들어 있다.

  • 세션 Beans는[4] "Stateful", "Stateless" 또는 "Singleton" 중 하나일 수 있고 Local(동일한 JVM) 또는 Remote(다른 JVM) 인터페이스를 통해 또는 인터페이스 없이 직접 액세스할 수 있으며,[5] 이 경우 로컬 의미론이 적용된다.모든 세션 빈은 모든 보기(로컬/원격/인터페이스 없음)에 대해 비동기 실행을[6] 지원한다.
  • 메시지 구동 콩(MDB, Message Beans라고도 함)MDB는 또한 비동기 실행을 지원하지만 메시징 패러다임을 통해서도 지원한다.

세션 콩

스테이트풀 세션 콩

참고 항목:대화 상태(Java EE)

Stateful Session Beans는[7] 상태를 가지는 비즈니스 개체로, 즉, 세션 내내 어떤 클라이언트를 다루고 있는지 추적하기 때문에 콩 인스턴스에 대한 액세스는 한 번에 하나의 클라이언트로만 엄격히 제한된다.[8]단일 콩에 대한 동시 액세스를 시도하는 경우 컨테이너가 @Access를 통해 요청을 직렬화함컨테이너가 대신 예외를 발생시킬 수 있는 시간 초과 주석.[9]상태 저장 세션 콩의 상태는 고객이 콩에 얼마 동안 액세스하지 않은 후 용기에 의해 자동으로 유지(허용)되어 메모리를 확보할 수 있다.JPA 확장 지속성 컨텍스트는 Stateful Session Beans에 의해 명시적으로 지원된다.[10]

예
  • 웹 스토어에서 체크아웃을 하는 것은 고객이 구매하는 품목의 잠금장치를 유지하는 것으로서 고객이 체크아웃 과정에 있는 위치를 추적하기 위해 상태를 사용하는 상태 저장 세션 빈에 의해 처리될 수 있다(시스템 아키텍처의 관점에서, 고객이 그러한 잠금장치를 관리하도록 하는 것이 덜 이상적일 것이다).

상태 비저장 세션 콩

상태 비저장 세션 콩은[11] 관련 상태가 없는 비즈니스 개체다.단, 콩 인스턴스 하나에 대한 접근은 여전히 한 번에 하나의 클라이언트로 제한되며, 콩에 대한 동시 접근은 금지된다.[8]콩 하나에 대한 동시 액세스를 시도할 경우 컨테이너는 각 요청을 다른 인스턴스로 라우팅하기만 하면 된다.[12]이것은 상태 비저장 세션 콩을 자동으로 안전하게 만든다.인스턴스(instance) 변수는 클라이언트에서 bean으로 단일 메서드를 호출하는 동안 사용될 수 있지만, 인스턴스(instance) 변수의 내용은 다른 클라이언트 메서드 호출에 걸쳐 보존되도록 보장되지 않는다.상태 비저장 세션 콩의 인스턴스는 일반적으로 풀링된다.두 번째 클라이언트가 첫 번째 클라이언트의 메서드 호출을 완료한 직후에 특정 콩에 액세스하면 동일한 인스턴스를 얻을 수 있다.전화를 거는 고객과의 대화를 유지하기 위한 오버헤드가 부족하기 때문에 그들은 상태 좋은 콩보다 자원 집약도가 떨어진다.

예
  • 고객 지원부에 이메일을 보내는 것은 일회성 작업이며 다단계 프로세스의 일부가 아니기 때문에 상태 비저장 콩이 처리할 수 있다.
  • "향후 업데이트에 대한 알림" 상자를 클릭하는 웹 사이트의 사용자는 세션 빈의 비동기식 호출로 사용자를 회사의 데이터베이스에 있는 목록에 추가시킬 수 있다(이 호출은 성공 또는 실패에 대한 알림을 받기 위해 기다릴 필요가 없으므로 비동기식 호출임).
  • 제품 목록 및 현재 사용자의 기록과 같은 웹 사이트에 대해 여러 개의 독립적인 데이터 조각을 가져오는 것은 세션 빈의 비동기식 방법으로도 처리될 수 있다(이러한 통화는 그러한 방식으로 병렬로 실행될 수 있기 때문에 성능이 잠재적으로 향상될 수 있기 때문에 비동기식이다).이 경우 비동기식 방법은 Future 인스턴스를 반환한다.

싱글톤 세션 콩

Singleton Session Beans는[13][14] JVM 내에서 글로벌 공유 상태를 가지는 비즈니스 객체다.하나뿐인 빈 인스턴스에 대한 동시 액세스는 컨테이너(컨테이너 관리 동시성, CMC) 또는 빈 자체(빈 관리 동시성, BMC)로 제어할 수 있다. CMC는 읽기 잠금 또는 쓰기 잠금을 메서드 호출에 사용할지 지정하는 @Lock 주석을 사용하여 CMC를 조정할 수 있다.또한 Singleton Session Beans는 @Startup 주석을 사용하여 EJB 컨테이너가 시작될 때 인스턴스화되도록 명시적으로 요청할 수 있다.

예
  • 모든 사용자에 대해 동일한 글로벌 일일 가격 리스트를 로드하는 것은 단일 세션 빈으로 수행될 수 있다. 이렇게 하면 응용 프로그램이 데이터베이스에 동일한 쿼리를 반복해서 수행해야 하는 것을 방지할 수 있기 때문이다.

메시지 구동 콩

메시지 기반 콩은[15] 메서드 호출 대신 메시지에 의해 실행이 트리거되는 비즈니스 개체다.메시지 구동 빈은 하위 수준의 JMS(Java Message Service) 사양에 대해 높은 수준의 사용 편의성 추상화를 제공하기 위해 여러 가지 용도로 사용된다.일반적으로 @MessageDriven 주석의 activationConfig 속성을 통해 발생하는 JMS 메시지 대기열 또는 메시지 항목에 가입할 수 있다.그것들은 EJB에 추가되어 이벤트 중심 처리를 가능하게 했다.세션 콩과 달리 MDB에는 클라이언트 보기(로컬/원격/인터페이스 없음)가 없으므로 클라이언트에서 MDB 인스턴스를 검색할 수 없다.MDB는 JMS 대기열이나 주제와 같이 수신되는 메시지를 수신하여 자동으로 처리한다.Java EE 사양에는 JMS 지원만 필요하지만 Message Driven Beans는 다른 메시징 프로토콜을 지원할 수 있다.[16][17][18]그러한 프로토콜은 비동기적일 수 있지만 동기화할 수도 있다.세션 콩은 동기식이나 비동기식도 가능하기 때문에 세션 콩과 메시지 기반 콩의 가장 큰 차이는 동시성이 아니라 (객체 지향적) 호출과 메시징의 차이다.

예
  • 여러 노드에 구성 업데이트를 보내는 것은 '메시지 주제'에 JMS 메시지를 보내는 것으로 이루어질 수 있으며, 이 주제를 듣고 있는 메시지 기반 빈에 의해 처리될 수 있다(발신자가 소비자의 수, 위치 또는 정확한 유형을 알 필요가 없기 때문에 메시지 패러다임이 여기서 사용된다).
  • 작업 클러스터에 작업을 제출하는 것은 JMS 메시지를 '메시지 대기열'로 전송하여 수행될 수도 있고 Message Driven에 의해 처리될 수도 있지만, 이번에는 대기열을 청취하는 것(메시지 패러다임과 대기열이 사용됨, 보낸 사람이 작업을 실행하는 데 신경을 쓸 필요가 없지만 작업이 실행된다는 것만을 보장할 필요가 있기 때문이다.한 번
  • Quartz 스케줄러에서 발생하는 타이밍 이벤트는 Message Driven Bean으로 처리할 수 있으며, Quartz 트리거가 실행되면 MDB가 자동으로 호출된다.Java EE는 기본적으로 Quartz에 대해 모르기 때문에 JCA 리소스 어댑터가 필요하며 이를 참조하여 MDB에 주석을 달 것이다.[19]

실행

EJB는 일반적으로 애플리케이션 서버 내에서 EJB 컨테이너에 배치된다.규격은 EJB가 컨테이너와 상호작용하는 방법과 클라이언트 코드가 컨테이너/EJB 조합과 상호작용하는 방법을 설명한다.애플리케이션에 사용되는 EJB 클래스는javax.ejb꾸러미(더)javax.ejb.spi패키지는 EJB 컨테이너 구현에 의해서만 사용되는 서비스 제공자 인터페이스다.)

EJB의 고객은 Java의 새로운 운영자를 통해 직접 콩을 인스턴스화하지 않고 대신 EJB 컨테이너를 통해 참조를 얻어야 한다.이 참조는 일반적으로 구현 빈 자체에 대한 참조가 아니라 클라이언트가 요청한 로컬 또는 원격 비즈니스 인터페이스를 동적으로 구현하거나 실제 콩의 하위 유형을 동적으로 구현하는 프록시에 대한 참조다.그러면 프록시는 인터페이스나 콩에 직접 주조될 수 있다.클라이언트는 EJB에 '뷰'가 있다고 하며, 로컬 인터페이스, 원격 인터페이스, 빈 타입 자체는 각각 로컬 뷰, 원격 뷰, 무인터페이스 뷰와 일치한다.

이 대리인은 EJB 컨테이너에 거래, 보안, 가로채기, 주사, 원격조종과 같은 콩에 교차 절단(AOP 유사) 서비스를 투명하게 제공할 수 있는 기회를 주기 위해 필요하다.예를 들어, 클라이언트는 프록시에서 메소드를 호출하는데, 이 메소드는 먼저 EJB 컨테이너의 도움을 받아 거래를 시작한 다음 실제 콩 메소드를 호출한다.bean 메소드가 반환되면 프록시는 트랜잭션을 종료하고(즉, 이를 커밋하거나 롤백하여) 제어권을 클라이언트로 다시 이전한다.

EJB 컨테이너는 클라이언트 코드가 EJB에 대한 충분한 액세스 권한을 갖도록 보장하는 책임을 진다.[20]보안 측면은 주석을 통해 EJB에 선언적으로 적용할 수 있다.[21]

트랜잭션

EJB 컨테이너는 컨테이너 관리 AID 트랜잭션과 콩 관리 트랜잭션을 모두 지원해야 한다.[22]

CMT(컨테이너 관리 트랜잭션)는 기본적으로 세션 콩에 대한 호출에 대해 활성화되어 있다.즉, 명시적인 구성이 필요하지 않다.이러한 동작은 주석을 통해 콩에 의해 선언적으로 조정될 수 있으며, 필요한 경우 그러한 구성은 나중에 배치 설명자에서 재정의될 수 있다.튜닝에는 전체 콩 또는 특정 방법에 대한 트랜잭션을 끄거나, 트랜잭션 전파를 위한 대체 전략을 요청하고 거래를 시작하거나 참여하는 것이 포함된다.그러한 전략들은 주로 거래가 진행 중이거나 이미 콩을 부르는 시점에 진행 중이거나 진행 중이 아니라면 어떤 일이 일어나야 하는지를 다룬다.다음과 같은 변형이 지원된다.[23][24]

선언적 트랜잭션 관리 유형
유형 설명
의무적인 클라이언트가 트랜잭션을 시작하지 않은 경우 예외가 발생한다.그렇지 않으면 클라이언트의 트랜잭션이 사용된다.
필수의 클라이언트가 거래를 시작한 경우, 그것은 사용된다.그렇지 않으면 새로운 거래가 시작된다.(명시적 유형이 지정되지 않은 경우 기본값)
필요_NEW 클라이언트가 거래를 시작한 경우, 거래는 중단된다.새로운 거래는 항상 시작된다.
Supports 클라이언트가 거래를 시작한 경우, 그것은 사용된다.그렇지 않으면 어떤 거래도 사용되지 않는다.
NOT_Supported 클라이언트가 거래를 시작한 경우, 거래는 중단된다.새 트랜잭션이 시작되지 않음.
NEVE 클라이언트가 트랜잭션을 시작한 경우 예외가 발생한다.새 트랜잭션이 시작되지 않음.

또는, 빈은 주석을 통해 JTA API를 통해 프로그래밍 방식으로 트랜잭션을 처리하고 싶다고 선언할 수도 있다.이러한 운영 방식을 BMT(Bean Managed Transactions, BMT)라고 하는데, 이는 콩 자체가 컨테이너 대신 거래를 처리하기 때문이다.[25]

이벤트

JMS(Java Message Service, Java Message Service)는 클라이언트가 이러한 콩으로부터 비동기 메시지를 받을 수 있도록 하기 위해 콩에서 고객에게 메시지를 보내는 데 사용된다.MDB는 JMS 대기열 또는 주제 중 하나를 사용하여 비동기적으로 클라이언트로부터 메시지를 수신하는 데 사용될 수 있다.

이름 지정 및 디렉터리 서비스

주입의 대안으로 EJB 클라이언트는 JNDI(Java Naming and Directory Interface)를 사용하여 세션 빈의 프록시 객체(EJB 스텁)에 대한 참조를 얻을 수 있다.이 대안은 비관리 코드 또는 독립 실행형 Java SE 클라이언트와 같이 주입을 사용할 수 없는 경우 또는 프로그래밍 방식으로 어떤 콩을 얻을지 결정해야 하는 경우에 사용할 수 있다.

EJB 세션 콩의 JNDI 이름은 다음 체계를 통해 EJB 컨테이너에 의해 할당된다.[26][27][28]

JNDI 이름
범위 네임 패턴
글로벌 java:global[/<app-name]/[!<완전 자격-정규-이름>
적용 java:app/<bean-name>[!<완전 자격-정규-이름>
모듈 java:java/<bean-name>[!<완전 자격-정규-이름>

(대괄호 안에 있는 것은 선택적인 부분을 나타낸다.)

단 콩은 의뢰인의 '위치'에 따라 위의 패턴과 일치하는 어떤 이름으로도 얻을 수 있다.필요한 콩과 같은 모듈에 있는 클라이언트는 모듈 스코프와 더 큰 스코프를 사용할 수 있고, 필요한 콩과 같은 응용 프로그램에 있는 클라이언트는 앱 스코프 이상을 사용할 수 있다.

예: CustomerService bean과 동일한 모듈에서 실행되는 코드(이 기사 앞부분의 예에서 제시된)는 다음과 같은 코드를 사용하여 이에 대한 (로컬) 참조를 얻을 수 있다.

CustomerServiceLocal 고객 서비스 =     (CustomerServiceLocal) 새로운 InitialContext().찾다("java:module/CustomerService");

원격 실행/분산 실행

자바 프로그래밍 언어로 작성된 클라이언트와의 통신의 경우 세션 빈은 @Remote 주석이 달린 인터페이스를 통해 원격 보기를 노출할 수 있다.[29]이를 통해 콩이 다른 (원격) 시스템에 위치할 수 있는 다른 JVM의 클라이언트에서 호출될 수 있다.EJB 컨테이너의 관점에서, 다른 JVM의 모든 코드는 원격이다.

또한 상태 비저장 세션 콩은 WSDL과 SOAP 또는 일반 XML을 통한 원격 통신을 위한 "웹 서비스 클라이언트 보기"를 노출할 수 있다.[30][31][32] 이는 JAX-RPC 및 JAX-WS 규격을 따른다.그러나 향후 제거를 위해 JAX-RPC 지원이 제안된다.[33]JAX-WS를 지원하기 위해 세션 빈에 @WebService 주석과 @WebMethod 주석으로 원격으로 노출되는 방법을 주석으로 한다.

EJB 규격은 노출을 어떤 방식으로든 RESTful 웹 서비스로 언급하지 않으며 이러한 형태의 통신에 대한 명시적인 지원은 없지만, JAX-RS 규격은 EJB를 명시적으로 지원한다.[34]JAX-RS 사양에 따라 상태 비저장 및 Singleton 세션 콩은 @Path 주석을 통해 루트 리소스가 될 수 있으며, EJB 비즈니스 방법은 @GET, @PUT, @POST 및 @DELETE 주석을 통해 리소스 방법에 매핑할 수 있다.그러나 이것은 JAX-WS와 JAX-RPC 전용으로 사용되는 "웹 서비스 클라이언트 뷰"로 간주되지 않는다.

웹 서비스를 통한 통신은 자바 프로그래밍 언어로 작성되지 않은 클라이언트에 대해 일반적으로 이루어지지만, 방화벽을 통해 EJB 서버에 도달하는 데 어려움을 겪는 자바 클라이언트에게도 편리하다.또한 웹 서비스 기반 통신은 Java 클라이언트가 원격 EJB 서버와 통신하기 위해 클래스 경로에 가지고 있어야 하는 일련의 jar 파일인 소위 "클라이언트-libraries"에 대한 불가사의하고 잘못 정의된 요구사항을 우회하기 위해 Java 클라이언트에 의해 사용될 수 있다.이러한 클라이언트-라이브러리는 클라이언트가 이미 가지고 있을 수 있는 라이브러리(예: 클라이언트 자체가 완전한 Java EE 서버인 경우)와 충돌할 가능성이 있으며 이러한 충돌은 해결하기가 매우 어렵거나 불가능한 것으로 간주된다.[35]

레거시

홈 인터페이스 및 필수 비즈니스 인터페이스

"홈 인터페이스" 리디렉션다른 용도는 홈 인터페이스(해제)를 참조하십시오.

EJB 2.1 이하에서는 각 EJB가 Java 구현 클래스와 2개의 Java 인터페이스를 제공해야 했다.EJB 컨테이너는 EJB 구현을 제공하기 위해 Java 구현 클래스의 인스턴스를 생성했다.Java 인터페이스는 EJB의 클라이언트 코드에 의해 사용되었다.

필수 배포 설명자

EJB 2.1 이하에서는 EJB 규격에 배포 설명자가 있어야 했다.이는 선택된 특정 EJB 플랫폼과 관계없이 EJB를 일관성 있게 전개할 수 있는 메커니즘을 구현하기 위해 필요했다.콩을 어떻게 배치해야 하는지에 대한 정보(예: 홈 인터페이스 또는 원격 인터페이스의 이름, 콩을 데이터베이스에 저장할지 여부 및 방법 등)를 배치 설명자에 명시해야 했다.

배포 설명자는 배포할 각 EJB에 대한 항목이 있는 XML 문서다.이 XML 문서는 각 EJB에 대해 다음과 같은 정보를 명시한다.

  • 홈 인터페이스 이름
  • Bean용 Java 클래스(비즈니스 객체)
  • 홈 인터페이스용 Java 인터페이스
  • 비즈니스 개체의 Java 인터페이스
  • 영구 저장소(엔티티 원두 전용)
  • 보안 역할 및 권한
  • 상태 저장 또는 상태 비저장(세션 빈의 경우)

많은 공급업체의 오래된 EJB 컨테이너는 EJB 규격의 것보다 더 많은 배치 정보가 필요했다.별도의 XML 파일 또는 다른 구성 파일 형식으로 추가 정보가 필요할 수 있다.EJB 플랫폼 공급업체는 일반적으로 이 배치 설명자를 읽을 수 있는 자체 툴을 제공했으며, 현재 사용되지 않는 홈 및 원격 인터페이스를 구현할 클래스 세트를 생성했을 수 있다.

EJB 3.0(JSR 220) 이후 XML 설명자는 Enterprise Bean 구현(원본 수준)에 설정된 Java 주석으로 대체되지만 주석 대신(또는 추가) XML 설명자를 사용할 수 있다.XML 설명자와 주석이 Enterprise Bean 내의 동일한 속성에 모두 적용되는 경우, 일부 XML 요소도 가법적일 수 있지만(예: @ActivationConfigProperty Annota를 통해 이미 정의된 이름과 다른 XML의 활성화-config-property) XML 정의는 해당 소스 레벨 주석을 재정의한다.기존 속성을 모두 대체하는 대신 tion이 추가됨).

용기변형

EJB 3.1부터 EJB 규격은 EJB 컨테이너의 두 가지 변형 버전(전체 버전과 제한된 버전)을 정의한다.제한된 버전은 EJB 3.1 Lite라고 불리는 규격의 적절한 하위 집합을 고수하며, Java EE 6의 웹 프로파일(그 자체는 전체 Java EE 6 규격의 하위 집합)의 일부분이다.

EJB 3.1 Lite는 다음 기능에 대한 지원을 제외한다.[38]

  • 원격 인터페이스
  • RMI-IIOP 상호운용성
  • JAX-WS 웹 서비스 끝점
  • EJB 타이머 서비스(@Schedule, @Timeout)
  • 비동기 세션 빈 호출(@비동기식)
  • 메시지 구동 콩

EJB 3.2 Lite는 더 적은 기능을 제외한다.특히 @Asynchronous와 @Schedule/@를 더 이상 배제하지 않는다.시간 초과. 그러나 @Schedule의 경우 전체 EJB 3.2가 지원하는 "영구적" 특성을 지원하지 않는다.EJB 3.2 Lite의 전체 제외 목록은 다음과 같다.

  • 원격 인터페이스
  • RMI-IIOP 상호운용성
  • JAX-WS 웹 서비스 끝점
  • 영구 타이머(@Schedule의 "영구적" 특성)
  • 메시지 구동 콩

버전 이력

EJB 4.0, 최종 릴리스(2020-05-22)

자카르타 EE 9의 일부로 자카르타 Enterprise Beans 4.0은 API 패키지 이름을 상위 레벨에서 주로 이동시킨 툴링 릴리스였습니다.javax.ejb최상위권으로 포장하다jakarta.ejb꾸러미[39]

다른 변경사항으로는 새로운 최상위 패키지로 이동하는 데 무의미했던 사용되지 않는 API의 제거와 자카르타 EE 9의 Java 또는 다른 곳에서 제거된 기능에 의존하는 기능의 제거가 있었다.다음 API가 제거됨:

  • 에 의존하는 방법들java.security.Identity자바 14호에서 제거되었다.
  • 자카르타 EE 9 플랫폼에서 XML RPC의 제거를 반영하기 위해 자카르타 XML RPC에 의존하는 방법.
  • 불모의EJBContext.getEnvironment()방법의
  • Java 11 및 Jakarta EE 9 플랫폼에서 CORBA 제거를 반영하기 위한 "분산 상호운용성 지원"

기타 사소한 변경 사항으로는 Enterprise Beans 2.x API 그룹을 "선택 사항"으로 표시하고Schedule주석 반복 가능

EJB 3.2.6, 최종 릴리스(2019-08-23)

자카르타 EE 8의 일부로서, 그리고 여전히 "EJB"의 약자를 사용함에도 불구하고, 이 APIs의 집합은 공식적으로 Eclipse Foundation에 의해 "Jakarta Enterprise Beans"로 개명되어 Oracle "Java" 상표에 발을 붙이지 않게 되었다.

EJB 3.2, 최종 릴리스(2013-05-28)

JSR 345번지.Enterprise JavaBeans 3.2는 상대적으로 사소한 릴리스로, 주로 규격의 명확화를 포함하고 있으며 규격에 의해 부과된 일부 제한사항을 해제했지만 시간이 지남에 따라 실질적인 목적을 달성하지 못하는 것으로 보인다.기존의 몇 가지 전체 EJB 기능도 EJB 3 lite에 있어야 하며, EJB 3.1에서 폐기하도록 제안된 기능도 실제로 폐기(선택 사항)되었다.[40][41]

다음과 같은 기능이 추가되었다.

  • 상태 저장 세션 빈의 전달은 @상태 저장 주석의 속성을 통해 비활성화할 수 있다(passivationCapable = false).
  • TimerService는 동일한 EJB 모듈에 있는 모든 활성 타이머를 검색할 수 있다(이전에는 TimerService가 호출된 빈의 타이머만 검색할 수 있음).
  • 라이프사이클 방법(예: @PostConstruction)은 기존 @TransactionAttribute 주석을 사용하여 상태 저장 세션 빈에 대해 트랜잭션일 수 있음
  • 내장형 컨테이너에 의해 구현된 자동 압축식 인터페이스

EJB 3.1, 최종 릴리스(2009-12-10)

JSR 318.Enterprise JavaBeans 3.1 규격의 목적은 개발자의 관점에서 EJB 아키텍처의 복잡성을 줄이는 동시에 커뮤니티의 요구에 대응하여 새로운 기능을 추가함으로써 EJB 아키텍처를 더욱 단순화하는 것이다.

  • 인터페이스가 없는 로컬 보기(인터페이스 보기 없음)
  • EJB 구성 요소의 .war 포장
  • EJB Lite: EJB의 하위 집합 정의
  • 휴대용 EJB 글로벌 JNDI 이름
  • 단골격(싱글톤 세션 원두)
  • 응용 프로그램 초기화 및 종료 이벤트
  • EJB 타이머 서비스 향상
  • 단순 비동기식(세션 빈의 경우@비동기식)

EJB 3.0, 최종 릴리스(2006-05-11)

JSR 220 - 주요 변경 사항:이 릴리스는 버전 2.x에서 사용되는 복잡한 '배포 설명자'가 아닌 '알림'을 사용하여 EJB를 훨씬 쉽게 작성할 수 있게 했다.홈 및 원격 인터페이스와 ejb-jar.xml 파일의 사용도 이 릴리스에서는 더 이상 필요하지 않았으며, 비즈니스 인터페이스와 인터페이스를 구현하는 bean으로 대체되었다.

EJB 2.1, 최종 릴리스(2003-11-24)

JSR 153 - 주요 변경 사항:

  • 웹 서비스 지원(신규): SOAP/HTTP를 통해 상태 비저장 세션 콩을 호출할 수 있다.또한 EJB는 새로운 서비스 참조를 사용하여 웹 서비스에 쉽게 액세스할 수 있다.
  • EJB 타이머 서비스(신규):특정 시간에 EJB를 호출하기 위한 이벤트 기반 메커니즘.
  • 메시지 구동 콩은 JMS 이외의 소스로부터 메시지를 수신한다.
  • 메시지 수신처(EJB 참조, 자원 참조 등과 동일한 아이디어)가 추가되었다.
  • EJB 쿼리 언어(EJB-QL) 추가: 주문 기준, AVG, MIN, MAX, SUM, 카운트 및 MOD
  • XML 스키마는 배포 설명자를 지정하는 데 사용되며, DTD를 대체함

EJB 2.0, 최종 릴리스(2001-08-22)

JSR 19 - 주요 변경 사항:전체 목표:

  • Java에서 분산 객체 지향 비즈니스 애플리케이션을 구축하기 위한 표준 구성요소 아키텍처.
  • 여러 공급업체의 툴을 사용하여 개발한 구성요소를 결합하여 분산된 애플리케이션을 구축할 수 있도록 하십시오.
  • 간편한 애플리케이션 쓰기(기업):애플리케이션 개발자들은 낮은 수준의 트랜잭션 및 상태 관리 세부사항, 멀티스레딩, 연결 풀링 및 기타 복잡한 낮은 수준의 API를 이해할 필요가 없을 것이다.
  • Java의 "Write Once, Run Anywhere" 철학을 따를 것이다.엔터프라이즈 Bean은 1회 개발 후 재컴파일이나 소스 코드 수정 없이 여러 플랫폼에 배치될 수 있다.
  • 엔터프라이즈 애플리케이션 라이프사이클의 개발, 배포 및 런타임 측면을 해결하십시오.
  • 여러 벤더의 툴이 런타임에 상호 운용할 수 있는 구성요소를 개발하고 배치할 수 있는 계약을 정의하십시오.
  • 기존 서버 플랫폼과 호환 가능공급업체는 기존 제품을 EJB를 지원하도록 확장할 수 있을 것이다.
  • 다른 Java API와 호환 가능.
  • 엔터프라이즈 Beans 및 Java EE 구성 요소와 비 Java 프로그래밍 언어 응용 프로그램 간의 상호 운용성 제공
  • CORBA 프로토콜(RMI-IIOP)과 호환 가능.

EJB 1.1, 최종 릴리스(1999-12-17)

주요 변경 사항:

  • XML 배포 설명자
  • 기본 JNDI 컨텍스트
  • IIOP를 통한 RMI
  • 보안 - 역할 중심, 메서드 중심 아님
  • 엔티티 Bean 지원 - 선택이 아닌 필수

릴리즈 1.1의 목표:

  • 애플리케이션 어셈블리 및 배포에 대한 더 나은 지원 제공
  • 개별 EJB 역할의 책임을 보다 상세히 명시한다.

EJB 1.0(1998-03-24)

1998년 JavaOne에서 발표된 Sun의 세 번째 Java 개발자 회의(3월 24일 ~ 27일) 릴리즈 1.0 목표:[42]

  • 구성요소 아키텍처에 의해 가정되는 구별되는 "EJB 역할"을 정의한다.
  • 엔터프라이즈 Beans의 고객 뷰 정의.
  • 엔터프라이즈 Bean 개발자의 뷰 정의.
  • EJB 컨테이너 제공자 및 서버 제공자의 책임을 정의함. 이 두 가지가 함께 엔터프라이즈 Beans의 배포 및 실행을 지원하는 시스템을 구성함.

참조

  1. ^ "Enterprise JavaBeans Technology". www.oracle.com. Retrieved 2016-12-15.
  2. ^ J2EE Design and Development, press 2002 Wrox Press Ltd., 페이지 5.
  3. ^ J2EE Design and Development, 2002, Wrox Press Ltd, 페이지 19.
  4. ^ JSR 318, 4.1, http://jcp.org/en/jsr/detail?id=318
  5. ^ "Optional Local Business Interfaces (Ken Saks's Blog)". Archived from the original on 19 November 2015. Retrieved 1 June 2016.
  6. ^ JSR 318, 4.5, http://jcp.org/en/jsr/detail?id=318
  7. ^ JSR 318, 4.6, http://jcp.org/en/jsr/detail?id=318
  8. ^ a b JSR 318, 4.10.3, http://jcp.org/en/jsr/detail?id=318
  9. ^ JSR 318, 4.3.14, 21.4.2, http://jcp.org/en/jsr/detail?id=318
  10. ^ "Persistence Context in Stateful". Archived from the original on 16 March 2008. Retrieved 1 June 2016.
  11. ^ JSR 318, 4.7, http://jcp.org/en/jsr/detail?id=318
  12. ^ JSR 318, 4.3.14, http://jcp.org/en/jsr/detail?id=318
  13. ^ JSR 318, 4.8, http://jcp.org/en/jsr/detail?id=318
  14. ^ "Singleton EJB". Openejb.apache.org. Retrieved 2012-06-17.
  15. ^ JSR 318, 5.1, http://jcp.org/en/jsr/detail?id=318
  16. ^ JSR 318, 5.7.2, http://jcp.org/en/jsr/detail?id=318
  17. ^ JSR 318, 5.4.2, http://jcp.org/en/jsr/detail?id=318
  18. ^ JSR 318, 5.6.2, http://jcp.org/en/jsr/detail?id=318
  19. ^ Developing Quartz MDB (29 April 2009). "Developing Quartz MDB". Mastertheboss.com. Retrieved 2012-06-17.
  20. ^ JSR 318, 17장 http://jcp.org/en/jsr/detail?id=318
  21. ^ "Security Annotations". Openejb.apache.org. Retrieved 2012-06-17.
  22. ^ JSR 318, 13장 http://jcp.org/en/jsr/detail?id=318
  23. ^ JSR 318, 13.6.2, http://jcp.org/en/jsr/detail?id=318
  24. ^ "Transaction Annotations". Openejb.apache.org. Retrieved 2012-06-17.
  25. ^ JSR 318, 13.3.6, http://jcp.org/en/jsr/detail?id=318
  26. ^ JSR 318, 4.4, http://jcp.org/en/jsr/detail?id=318
  27. ^ "Portable Global JNDI names (MaheshKannan)". Blogs.oracle.com. Archived from the original on 2011-06-20. Retrieved 2012-06-17.
  28. ^ "Portable Global JNDI Names (Ken Saks's Blog)". Blogs.oracle.com. Archived from the original on 2011-12-29. Retrieved 2012-06-17.
  29. ^ JSR 318, 15장 http://jcp.org/en/jsr/detail?id=318
  30. ^ JSR 318, 2.6, http://jcp.org/en/jsr/detail?id=318
  31. ^ JSR 318, 3.2.4, http://jcp.org/en/jsr/detail?id=318
  32. ^ JSR 318, 4.3.6, http://jcp.org/en/jsr/detail?id=318
  33. ^ JSR 318, 2.7, http://jcp.org/en/jsr/detail?id=318
  34. ^ JSR 311, 6.2장 http://jcp.org/en/jsr/detail?id=311
  35. ^ "Communication between JBoss AS 5 and JBoss AS 6 JBoss AS JBoss Community". Community.jboss.org. Retrieved 2012-06-17.
  36. ^ "Resin Java EE 6 Web Profile - Resin 3.0". Wiki.caucho.com. 2010-02-12. Archived from the original on 2012-03-23. Retrieved 2012-06-17.
  37. ^ JSR 318, 21.1 EJB 3.1 Lite, http://jcp.org/en/jsr/detail?id=318
  38. ^ JSR 318, 표 27 - EJB 3.1 Lite 및 Full EJB 3.1 API의 필수 컨텐츠, http://jcp.org/en/jsr/detail?id=318
  39. ^ "What is New in This Release". Jakarta Enterprise Beans, Core Features. Jakarta Enterprise Beans 4.0. Jakarta EE. November 5, 2020. Retrieved 2020-12-05.
  40. ^ "What's new in EJB 3.2 ? - Java EE 7 chugging along! (Arun Gupta, Miles to go ...)". Retrieved 1 June 2016.
  41. ^ "If you didn't know what is coming in EJB 3.2... (Marina Vatkina's Weblog)". Archived from the original on 4 March 2016. Retrieved 1 June 2016.
  42. ^ "JavaOne Conference Trip Report: Enterprise JavaBeans Technology: Developing and Deploying Business Applications as Components". Alephnaught.com. Retrieved 2012-06-17.

외부 링크