EJB vs CDI i wzorzec "Entity Boundary Control"

Question

Próbuję zrozumieć moją decyzję o CDI i EJB oraz o strukturze Entity Boundary Control (ECB). Moje rozumienie wzoru EBC polega na tym, że Granica jest początkiem i końcem granicy transakcji. Co więcej, CDI nie zapewnia obsługi transakcji, tak jak robi to EJB.

Jeśli więc chcę pomyślnie wdrożyć model EBC, to poniższe stwierdzenia są prawdziwe;

1. Mogę wykonać część graniczną z EJB (tj. @ Stateless, @stateful, @singleton) i warstwą Control z CDI lub EJB.
2. Mogę wdrożyć część Boundary and Control z CDI, ale implementować obsługę transakcji na granicy podobnej do (http://smokeandice.blogspot.com/2009/12/cdi-and-declarative-transactions.html)
3. Nie mogę wdrożyć granicy z CDI, a następnie rozpocząć korzystanie z EJB w warstwie kontrolnej.

Dzięki

Answer 1

I pomyślnie wdrożyć wzór EBC JavaEE 6 stosując EJB wyłącznie do granic i CDI dla kontrolerów. Typowym stosu w moim architektury wykorzystuje opatrzone JAX-RS adnotacji w celu realizacji usługi REST jako Boundary

CDI udało fasoli dla logiki biznesowej w zakresie @Dependent jako kontroler

CDI zarządzanych fasoli

• bezstanowego EJB w @Dependent zakres danych dostęp do obiektów, które wykorzystują WZP EntityManager do interakcji z bazą danych
• WZP podmiot fasoli

bezstanowy EJB, które tworzą Bounda ry są zawsze opatrzone adnotacją @TransactionAttribute (REQUIRED), która jest domyślna. Nie używam innych atrybutów transakcji. Dzięki temu możesz zapewnić, że każda interakcja z Granicą odbywa się dokładnie w jednej transakcji.

Używając tylko zakresu @Dependent dla zarządzanych komponentów bean CDI, można zagwarantować, że każdy wątek ma własne wystąpienie tych komponentów. Tak więc nie masz nigdy więcej niż jeden wątek, który uzyskuje dostęp do zarządzanego komponentu CDI w tym samym czasie. Pozwoli to uniknąć typowych problemów z współbieżnością.

Korzystanie z kombinacji większej wagi, połączonych EJB dla granicy i lekkich fasoli zarządzanych przez CDI dla reszty aplikacji jest bardzo dobre dla mnie.