EJB 란 무엇이며 어떤 역할을합니까?

EJB빈이 무엇인지 , 그 인스턴스가 풀에서 관리되는 것을 의미하는 것은 무엇입니까? 실제로 그들을 잘 잡을 수는 없습니다.

그들이 실제로 무엇인지 설명해 줄 수 있습니까 (실제로 Java 프로그래머에게는)? 그들은 무엇을합니까? 그들의 목적은 무엇입니까? 왜 실제로 사용합니까? (왜 그냥 고집하지 POJO않습니까?) 아마도 예제 응용 프로그램입니까?

업데이트 된 정보, 즉를 참조하십시오 EJB 3.1. EJB에 대한 날짜 정보가 잘못 될 수 있습니다.

EJB 학습 초보자를위한 참고 사항 :

EJB는 분산 객체를 기반으로 하며, 네트워크로 연결된 여러 머신 (가상 또는 물리적)에서 실행되는 소프트웨어를 말합니다 .

왜 실제로 사용합니까? (POJO에만 집중하지 않는 이유는 무엇입니까?)

데이터베이스에 액세스하거나 다른 연결 / 디렉토리 리소스에 액세스하거나 여러 클라이언트에서 액세스하거나 SOA 서비스로 사용하려는 구성 요소가 필요한 경우 오늘날 EJB는 일반적으로 "더 크고 강력하고 빠르며 확장 성이 뛰어납니다" POJO보다 간단합니다. 웹 또는 회사 네트워크를 통해 많은 수의 사용자에게 서비스를 제공하는 데 가장 유용하고 부서 내의 작은 앱에 대해서는 다소 가치가 없습니다.

1. Loose Coupling으로 여러 애플리케이션 / 클라이언트에서 로직 재사용 / 공유
   EJB는 자신의 jar 파일로 패키징 할 수 있으며 여러 곳에서 배포 및 호출 할 수 있습니다. 그것들은 일반적인 구성 요소입니다. 실제로 POJO는 라이브러리로 디자인하고 항아리로 패키지 할 수 있습니다. 그러나 EJB는 로컬 Java 인터페이스, 투명한 RMI, JMS 비동기 메시지 및 SOAP / REST 웹 서비스를 통한 로컬 및 원격 네트워크 액세스를 모두 지원하므로 여러 (일관되지 않은) 배치로 잘라 내기 및 붙여 넣기 jar 종속성을 줄일 수 있습니다.
   SOA 서비스를 만드는 데 매우 유용합니다. 로컬 액세스에 사용될 경우 POJO입니다 (무료 컨테이너 서비스가 추가됨). 별도의 EJB 계층을 설계하면 캡슐화, 느슨한 결합 및 응집력을 극대화하는 데 특별한주의를 기울이고 복잡한 처리 및 데이터 모델로부터 호출자를 보호하는 깔끔한 인터페이스 (Facade)를 촉진합니다.

2. 확장 성 및 안정성 다양한 호출 메시지 / 프로세스 / 스레드에서 대량의 요청을 적용하는 경우 풀에서 사용 가능한 EJB 인스턴스에 먼저 분배 된 다음 대기합니다. 이는 초당 수신 요청 수가 서버가 처리 할 수있는 것보다 많으면 정상적으로 저하됩니다. 항상 일부 요청이 효율적으로 처리되고 초과 요청이 대기됩니다. 우리는 서버 "멜트 다운 (meltdown)"에 도달하지 못합니다. 모든 요청은 동시에 끔찍한 응답 시간을 경험할뿐 아니라 서버는 하드웨어 및 OS가 처리 할 수있는 것보다 많은 리소스에 액세스하려고하기 때문에 충돌이 발생합니다. EJB는 클러스터링 할 수있는 별도의 계층에 배포 할 수 있습니다. 이는 서버 간 장애 조치를 통해 안정성을 제공하며 하드웨어를 추가하여 선형으로 확장 할 수 있습니다.

3. 동시성 관리. 컨테이너는 여러 클라이언트가 EJB 인스턴스에 자동으로 안전하게 액세스하도록합니다. 컨테이너는 EJB 풀, 스레드 풀, 호출 큐를 관리하고 메소드 레벨 쓰기 잠금 (기본값) 또는 읽기 잠금 (@Lock (READ)을 통해)을 자동으로 수행합니다. 이를 통해 동시 쓰기 / 쓰기 충돌을 통해 데이터가 손상되는 것을 방지하고 읽기-쓰기 충돌을 방지하여 데이터를 일관되게 읽을 수 있습니다.
   이것은 주로 @Singleton 세션 Bean에 유용합니다. 여기서 Bean은 클라이언트 호출자간에 공통 상태를 조작하고 공유합니다. 이는 동시 코드 실행 및 데이터 액세스를 위해 고급 시나리오를 수동으로 구성하거나 프로그래밍 방식으로 제어하기 위해 쉽게 재정의 될 수 있습니다.

4. 자동 거래 처리.
   전혀 수행하지 않으며 모든 EJB 메소드가 JTA 트랜잭션에서 실행됩니다. JPA 또는 JDBC를 사용하여 데이터베이스에 액세스하면 자동으로 트랜잭션에 참여합니다. JMS 및 JCA 호출에 대해서도 동일합니다. 특정 메소드가 JTA 트랜잭션에 참여하는지 여부와 방법을 지정하기 위해 메소드 앞에 @TransactionAttribute (someTransactionMode)를 지정하여 "필수"기본 모드를 대체하십시오.

5. 주입을 통한 매우 간단한 리소스 / 종속성 액세스
   컨테이너는 JNDI 저장 JDBC 연결, JMS 연결 / 주제 / 큐, 기타 EJB, JTA 트랜잭션, JPA 엔티티 관리자 지속성 컨텍스트, JPA 엔티티 관리자 팩토리 지속성 단위 및 EJB와 같은 EJB에서 인스턴스 필드로 자원을 찾고 자원 참조를 설정합니다. JCA 어댑터 자원. 예 : 다른 EJB 및 JTA 트랜잭션 및 JPA 엔티티 관리자 및 JMS 연결 팩토리 및 큐에 대한 참조를 설정하려면 다음을 수행하십시오.

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   서블릿은 단순히 인스턴스 변수를 선언하여이 Bean을 로컬로 호출 할 수 있습니다.

   @EJB MyAccountsBean accountsBean;    
   

   그런 다음 원하는대로 메소드를 호출하면됩니다.

6. JPA와의 스마트 한 상호 작용. 기본적으로 위와 같이 주입 된 EntityManager는 트랜잭션 범위 지속성 컨텍스트를 사용합니다. 이것은 상태 비 저장 세션 Bean에 적합합니다. (상태 비 저장) EJB 메소드가 호출되면 새 트랜잭션 내에서 새 지속성 컨텍스트가 작성되고 DB에 검색 / 기록 된 모든 엔티티 오브젝트 인스턴스는 해당 메소드 호출 내에서만 볼 수 있으며 다른 메소드와 분리됩니다. 그러나 메소드에서 다른 상태 비 저장 EJB를 호출하면 컨테이너가 동일한 PC를 전파하고 공유하므로 동일한 엔티티가 동일한 트랜잭션의 PC를 통해 일관된 방식으로 자동 공유됩니다.
   @Stateful 세션 Bean이 선언 된 경우 entityManager를 확장 범위 1로 선언하여 JPA와 동등한 스마트 유사성을 달성합니다. @ PersistentContent (unitName = "AccountsPU, type = EXTENDED) 이것은 Bean 세션의 수명 동안 존재합니다. 여러 Bean 호출 및 트랜잭션에서 이전에 검색 / 기록 된 DB 엔티티의 메모리 내 사본을 캐싱하므로 다시 검색 할 필요가 없습니다.

7. 라이프 사이클 관리. EJB의 수명주기는 컨테이너 관리입니다. 필요에 따라 EJB 인스턴스를 작성하고, 상태 저장 세션 Bean 상태를 지우고 초기화하며, 패시 베이트 및 활성화하고, 라이프 사이클 콜백 메소드를 호출하여 EJB 코드가 라이프 사이클 조작에 참여하여 자원을 확보 및 해제하거나 다른 초기화 및 종료 동작을 수행 할 수 있습니다. 또한 모든 예외를 캡처하고 기록하며 필요에 따라 트랜잭션을 롤백하며 필요에 따라 새 EJB 예외 또는 @ApplicationExceptions를 발생시킵니다.

8. 보안 관리. EJB에 대한 역할 기반 액세스 제어는 간단한 주석 또는 XML 설정을 통해 구성 할 수 있습니다. 서버는 인증 된 사용자 세부 정보를 각 호출과 함께 보안 컨텍스트 (호출 주체 및 역할)로 자동 전달합니다. 모든 RBAC 규칙이 자동으로 적용되므로 잘못된 역할로 인해 메소드를 불법적으로 호출 할 수 없습니다. EJB는 추가적인 프로그래밍 검사를 위해 사용자 / 역할 세부 사항에 쉽게 액세스 할 수 있습니다. 추가 보안 처리 (또는 IAM 도구)를 표준 방식으로 컨테이너에 연결할 수 있습니다.

9. 표준화 및 이식성. EJB 구현은 Java EE 표준 및 코딩 규칙을 준수하여 품질을 높이고 이해 및 유지 보수를 용이하게합니다. 또한 동일한 표준 기능과 동작을 모두 지원하고 개발자가 실수로 독점적 인
   비 이동식 벤더 기능을 채택하지 않도록함으로써 코드를 새로운 벤더 앱 서버 로 이식 할 수 있습니다.

10. 실제 키커 : 단순성. 위의 모든 작업은 Java EE 6 내 EJB에 대한 기본 설정을 사용하거나 몇 가지 주석을 추가하여 매우 간소화 된 코드로 수행 할 수 있습니다. 자신의 POJO에 엔터프라이즈 / 산업용 기능을 코딩하는 것은 훨씬 더 규모가 크고 복잡하며 오류가 발생하기 쉽습니다. EJB로 코딩을 시작하면 개발하기가 쉬우 며 "무료 승차"이점을 제공합니다.

10 년 전의 원래 EJB 사양에서 EJB는 주요 생산성 문제였습니다. 그것들은 부풀어 오르고 많은 코드와 구성 아티팩트가 필요했으며 위의 이점 중 약 2/3를 제공했습니다. 대부분의 웹 프로젝트는 실제로 사용하지 않았습니다. 그러나 이것은 10 년간의 조정, 정밀 검사, 기능 향상 및 개발 흐름에 따라 크게 바뀌 었습니다. Java EE 6에서는 최대 수준의 산업 강도와 사용 편의성을 제공합니다.

싫어하는 것 ?? :-) :-)

EJB는 비즈니스 로직을 포함하는 Java 구성 요소이며, 컨테이너에 배치하며, 주석으로 인해 일반적으로 선언적인 방식으로 컨테이너가 제공하는 기술 서비스를 활용할 수 있습니다.

• 트랜잭션 관리 : EJB의 메소드를 호출하기 전에 트랜잭션을 자동으로 시작하고이 메소드가 리턴되면 커미트 또는 롤백 할 수 있습니다. 이 트랜잭션 컨텍스트는 다른 EJB에 대한 호출로 전파됩니다.
• 보안 관리 : 호출자가 메소드를 실행하는 데 필요한 역할을 가지고 있는지 확인할 수 있습니다.
• 의존성 주입 : 다른 EJB 또는 JPA 엔티티 관리자, JDBC 데이터 소스 등과 같은 자원을 EJB에 주입 할 수 있습니다.
• 동시성 : 컨테이너는 한 번에 하나의 스레드 만 EJB 인스턴스의 메소드를 호출하도록합니다.
• 배포 : 일부 EJB는 다른 JVM에서 원격으로 호출 할 수 있습니다.
• 장애 조치 및로드 밸런싱 : EJB의 원격 클라이언트는 필요에 따라 자동으로 호출을 다른 서버로 리디렉션 할 수 있습니다.
• 자원 관리 : 서버의 메모리 소비를 제한하기 위해 Stateful Bean을 디스크에 자동으로 비활성화 할 수 있습니다.
• ... 아마도 몇 가지 점을 잊었을 것입니다.

Oracle doc 의이 내용이 나와 같은 사람이 간단한 방법으로 EJB 주제를 이해하는 데 도움이되기를 바랍니다.

Enterprise Bean이란 무엇입니까? Java 프로그래밍 언어로 작성된 Enterprise Bean은 응용 프로그램의 비즈니스 논리를 캡슐화하는 서버 측 구성 요소입니다. 비즈니스 로직은 응용 프로그램의 목적을 충족시키는 코드입니다. 예를 들어, 재고 제어 애플리케이션에서 엔터프라이즈 Bean은 checkInventoryLevel 및 orderProduct라는 메소드에서 비즈니스 로직을 구현할 수 있습니다. 클라이언트는 이러한 메소드를 호출하여 애플리케이션이 제공하는 재고 서비스에 액세스 할 수 있습니다.

Enterprise Beans의 이점 여러 가지 이유로 Enterprise Bean은 대규모 분산 응용 프로그램의 개발을 단순화합니다. 첫째, EJB 컨테이너는 엔터프라이즈 Bean에 시스템 레벨 서비스를 제공하므로 Bean 개발자는 비즈니스 문제점 해결에 집중할 수 있습니다. Bean 개발자가 아닌 EJB 컨테이너는 트랜잭션 관리 및 보안 권한 부여와 같은 시스템 레벨 서비스를 담당합니다.

둘째, 클라이언트가 아닌 Bean에 애플리케이션의 비즈니스 로직이 포함되어 있으므로 클라이언트 개발자는 클라이언트 프리젠 테이션에 집중할 수 있습니다. 클라이언트 개발자는 비즈니스 규칙을 구현하거나 데이터베이스에 액세스하는 루틴을 코딩 할 필요가 없습니다. 결과적으로 클라이언트가 더 얇아져 작은 장치에서 실행되는 클라이언트에게 특히 중요합니다.

셋째, 엔터프라이즈 Bean은 이식 가능한 컴포넌트이므로 애플리케이션 어셈블러는 기존 Bean에서 새 애플리케이션을 빌드 할 수 있습니다. 이러한 응용 프로그램은 표준 API를 사용하는 경우 호환되는 모든 Java EE 서버에서 실행될 수 있습니다.

엔터프라이즈 Bean 사용시기 애플리케이션에 다음 요구 사항이있는 경우 엔터프라이즈 Bean 사용을 고려해야합니다.

응용 프로그램은 확장 가능해야합니다. 점점 더 많은 사용자를 수용하기 위해 여러 컴퓨터에 응용 프로그램 구성 요소를 배포해야 할 수 있습니다. 응용 프로그램의 엔터프라이즈 Bean은 다른 시스템에서 실행될 수있을뿐만 아니라 클라이언트의 위치도 투명하게 유지됩니다.

트랜잭션은 데이터 무결성을 보장해야합니다. Enterprise Bean은 공유 객체의 동시 액세스를 관리하는 메커니즘 인 트랜잭션을 지원합니다.

응용 프로그램에는 다양한 클라이언트가 있습니다. 몇 줄의 코드만으로 원격 클라이언트는 엔터프라이즈 Bean을 쉽게 찾을 수 있습니다. 이러한 클라이언트는 얇고 다양하며 다양 할 수 있습니다.

가장 관심있는 질문은 어떻게 그리고 어디서 사용할 수 있는가입니다. 이를 이해하려면 먼저 어떤 유형의 EJB가 있는지 확인해야합니다. 두 가지 큰 범주가 있습니다.

1. 세션 빈
2. 메시지 구동 Bean

Session Beans를 고려해 봅시다. 그들은 3 가지 종류입니다 :

1. 상태 저장 -이 구성 요소는 상태를 유지하며 여러 요청에서 클라이언트에 따라 다릅니다. 세션으로 참조하십시오. 이것들은 즉시 쇼핑 카트 또는 다른 유형의 세션 (로그인 세션 등)에 사용될 수 있습니다.
2. 상태 비 저장 -이들은 요청간에 정보를 유지하지 않는 자체 포함 된 구성 요소이지만 사용자에게 고유합니다. 서비스 계층의 마음에 드는 서비스 클래스 . 상상 해봐OrderService . 이것에 대한 또 다른 큰 용도는 웹 서비스를 노출시키는 것입니다. 다시, 이것은 서비스 계층에 있거나 완전히 분리되어 있습니다.
3. 싱글 톤 (Singleton) -이것은 애플리케이션 당 존재하는 Bean이며 한 번 작성되며 여러 번 재사용 / 액세스 할 수 있습니다. Configuration애플리케이션 레벨 구성을 저장하고 언제 어디서나 필요할 때 액세스 할 수 있는 구성 요소가 즉시 떠 오릅니다.

이제 모든 상황에서 나머지 기능 또는 기능을 여러 계층에 걸쳐 사용할 수 있습니다.

• 보안 -호출 된 메소드에 대한 주석으로 권한을 확인할 수 있습니다. 원하는 경우 서비스 계층과 컨트롤러에서 발생할 수 있습니다.
• 트랜잭션 관리 -이것은 서비스 계층 또는 지속성 계층에서 확실한 후보입니다.
• 의존성 주입 -모든 곳에서 다시 사용됩니다

현대에서 가장 많이 사용되는 것은 소위 마이크로 서비스 및 서비스 지향 아키텍처입니다. 일부 비즈니스 로직 구성 요소를 EJB로 패키지하고이를 여러 조직에 분배하여 여러 클라이언트에서 사용할 수 있습니다 (클라이언트는 다른 백엔드 애플리케이션을 의미 함).

등등. 이제 가장 큰 단점은 EJB 컨테이너에 크게 의존한다는 것입니다. 2 개의 참조 구현간에 전환 할 수 있지만 Tomcat과 같이 더 가벼운 것으로 전환 할 수는 없습니다. 그러나 왜 모든 혜택을 희생하고 싶습니까?