[jakarta-ee] 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에서는 최대 수준의 산업 강도와 사용 편의성을 제공합니다.

싫어하는 것 ?? 🙂 🙂

답변