EJB 3.1과 CDI는 어디에 사용합니까?

EJB 3.1과 CDI는 어디에 사용합니까?

---

GlassFish 3 및 EJB 3.1을 사용하는 Java EE 기반 제품을 만들고 있습니다.

내 응용 프로그램에는 스케줄러 세션 빈이 있으며 웹 서비스를 사용합니다. 최근에 CDI (Contexts and Dependency Injection) 를 지원하는 Apache TomEE 에 대해 알게되었습니다 . GlassFish 컨테이너는 CDI도 지원합니다.

CDI가 아직 제공하지 않은 기능이 필요없는 세션 Bean을 교체 할 수 있습니까? 그렇다면 어떤 혜택을 얻을 수 있습니까?

---

예, CDI와 EJB를 자유롭게 혼합하여 훌륭한 결과를 얻을 수 있습니다. 당신이 @WebServiceand 를 사용하는 것처럼 들리는데 @Schedule, 이는 EJB를 믹스에 추가하는 좋은 이유입니다.

EJB와 CDI가 서로 관련되어있는 일반적인 정보는 다음과 같습니다.

EJB> = CDI

EJB 는 CDI Bean이므로 CDI의 모든 이점을 갖습니다. 그 반대는 사실이 아닙니다 (아직). 따라서 논리가 실제로 "EJB + CDI vs CDI"로 변환되므로 "EJB vs CDI"를 생각하는 습관을 들이지 마십시오. 이는 이상한 방정식입니다.

향후 버전의 Java EE에서는 계속 조정될 것입니다. 어떤 수단을 정렬하는 것은 바로하지 않고, 사람들이 이미 할 수있는 일을 할 수있다 @Stateful, @Stateless또는 @Singleton상단의 주석.

구현 용어의 EJB 및 CDI

궁극적으로 EJB와 CDI는 프록시 구성 요소와 동일한 기본 디자인을 공유합니다. EJB 또는 CDI Bean에 대한 참조를 얻을 때 이는 실제 Bean이 아닙니다. 오히려 당신이 제공 한 대상은 가짜 (프록시)입니다. 이 가짜 객체에서 메소드를 호출하면 호출은 인터셉터, 데코레이터 등을 통해 호출을 보내고 트랜잭션 또는 보안 검사를 처리하는 컨테이너로 이동합니다. 모든 것이 끝나면 호출은 마침내 실제 객체로 가고 결과는 프록시를 통해 호출자에게 다시 전달됩니다.

차이점은 호출 할 오브젝트가 해결되는 방식에서만 발생합니다. "해결됨"은 컨테이너가 실제 인스턴스를 호출 할 위치와 방법을 의미합니다.

CDI에서 컨테이너는 "범위"를 찾습니다. 기본적으로 특정 기간 동안 (요청 @RequestScoped, HTTP 세션 @SessionScoped, 응용 프로그램 @ApplicationScoped, JSF 대화 @ConversationScoped또는 사용자 정의 범위 구현마다) 존재 하는 해시 맵입니다 .

EJB에서 컨테이너는 Bean이 유형 인 경우 해시 맵도 찾습니다 @Stateful. @Stateful빈은 또한 살고 범위에있는 다른 모든 콩 죽는 원인이 위 범위 주석을 사용할 수 있습니다. EJB @Stateful에서 본질적으로 "범위가 지정된"Bean입니다. 은 @Stateless기본적으로 인스턴스 풀 - 당신은 하나의 호출의 기간 동안 풀에서 인스턴스를 얻을. 는 @Singleton본질적으로@ApplicationScoped

기본적으로 "EJB"Bean으로 수행 할 수있는 모든 작업은 "CDI"Bean으로 수행 할 수 있어야합니다. 표지 아래에서 구분하기가 끔찍합니다. 인스턴스가 해결되는 방법을 제외하고 모든 배관은 동일합니다.

이 프록 싱을 수행 할 때 컨테이너가 제공하는 서비스 측면에서 현재 동일하지 않지만 Java EE 사양 수준에서 작업하고 있습니다.

성능 메모

"가벼운"또는 "무거운"정신적 이미지는 무시하십시오. 그게 전부 마케팅입니다. 그것들은 대부분 같은 내부 디자인을 가지고 있습니다. CDI 인스턴스 해상도는 약간 더 동적이고 상황에 따라 조금 더 복잡 할 수 있습니다. EJB 인스턴스 해상도는 상당히 정적이고 멍청하며 비교하면 간단합니다.

TomEE의 구현 관점에서 알 수 있듯이 EJB 호출과 CDI Bean 호출 사이에는 성능 차이가 전혀 없습니다.

기본적으로 POJO, CDI, EJB

물론 이점이없는 경우 CDI 또는 EJB를 사용하지 마십시오. 주입, 이벤트, 인터셉터, 데코레이터, 라이프 사이클 추적 등을 원할 때 CDI에 버리십시오. 대부분의 시간입니다.

그 기본을 넘어, 유용한 컨테이너 서비스의 수는 당신이 당신의 CDI의도 빈 추가하여 EJB 할 경우에만 사용 할 수있는 옵션이있다 @Stateful, @Stateless또는 @Singleton거기에있다.

다음은 EJB를 분류 할 때의 짧은 목록입니다.

JAX-WS 사용

JAX-WS 노출 @WebService. 내가 게으른. (가) 때 @WebService또한 EJB, 당신은 그것을 나열하고있는 서블릿으로 매핑 할 필요가 없습니다 web.xml파일. 그것은 나에게 일이다. 또한 아래에 언급 된 다른 기능을 사용할 수있는 옵션이 있습니다. 그래서 그것은 나에게 쉬운 일이 아닙니다.

에 사용 가능 @Stateless하고 @Singleton단지.

JAX-RS 사용

를 통해 JAX-RS 리소스를 노출합니다 @Path. 나는 여전히 게으르다. RESTful 서비스가 EJB 인 경우에도 자동 발견이 발생하여 JAX-RS Application서브 클래스 또는 이와 유사한 항목 에 추가 할 필요가 없습니다 . 또한 @WebService아래 언급 된 훌륭한 기능 중 하나를 사용하거나 사용하려는 경우 와 동일한 bean을 노출 할 수 있습니다.

에 사용 가능 @Stateless하고 @Singleton단지.

시동 로직

를 통해 시작시로드합니다 @Startup. CDI에는 현재 이에 상응하는 것이 없습니다. 어떻게 든 AfterStartup컨테이너 수명주기에서 이벤트 와 같은 것을 추가하지 못했습니다 . 우리가이 작업을 수행했다면, 당신은 단순히 @ApplicationScoped그것을 듣고 있는 bean을 가질 수 있었을 것 @Singleton입니다 @Startup. CDI 1.1 목록에 있습니다.

사용 가능합니다 @Singleton.

병렬 작업

@Asynchronous메소드 호출. 서버 측 환경에서는 스레드 시작이 필요 없습니다. 스레드가 너무 많으면 성능이 저하됩니다. 이 주석을 사용하면 컨테이너의 스레드 풀을 사용하여 수행하는 작업을 병렬화 할 수 있습니다. 대단해.

에 사용할 수 @Stateful, @Stateless과 @Singleton.

스케줄링 작업

@Schedule or ScheduleExpression is basically a cron or Quartz functionality. Also very awesome. Most containers just use Quartz under the covers for this. Most people don't know, however, that scheduling work in Java EE is transactional! If you update a database then schedule some work and one of them fails, both will automatically cleaned up. If the EntityManager persist call fails or there is a problem flushing, there is no need to un-schedule the work. Yay, transactions.

Available to @Stateless and @Singleton only.

Using EntityManagers in a JTA transaction

The above note on transactions of course requires you to use a JTA managed EntityManager. You can use them with plain "CDI", but without the container-managed transactions it can get really monotonous duplicating the UserTransaction commit/rollback logic.

Available to all Java EE components including CDI, JSF @ManagedBean, @WebServlet, @WebListener, @WebFilter, etc. The @TransactionAttribute annotation, however, is available to @Stateful, @Stateless and @Singleton only.

Keeping JTA managed EntityManager

The EXTENDED managed EntityManager allows you to keep an EntityManager open between JTA transactions and not lose the cached data. Good feature for the right time and place. Use responsibly :)

Available to @Stateful only.

Easy synchronization

When you need synchronization, the @Lock(READ) and @Lock(WRITE) annotations are pretty excellent. It allows you to get concurrent access management for free. Skip all the ReentrantReadWriteLock plumbing. In the same bucket is @AccessTimeout, which allows you to say how long a thread should wait to get access to the bean instance before giving up.

Available to @Singleton beans only.

---

if you are really not using any of the features of ejb 3.1 the answer is simple. but guess your questiion indicates you suspect there are ejb 3.1 conceptes you are benefiting from without being aware of them. one example might be that the container can keep a pool of slsb ready to be used, so that jms and database connections dont have to injected as part of request

참고URL : https://stackoverflow.com/questions/13487987/where-to-use-ejb-3-1-and-cdi