EJB vs CDI and the "Entity Boundary Control" pattern

Question

Im trying to get my head around CDI and EJB and the Entity Boundary Control (ECB) pattern. My understanding of the ECB pattern is that the Boundary is the start and end of the transaction boundary. Further to that, CDI doesn't provide transaction support like an EJB does.

So if I want to implement the ECB pattern successfully, then the following are true;

1. I can Implement the Boundary portion with EJB's (i.e. @stateless, @stateful, @singleton) and the Control layer with CDI or EJB's.
2. I can Implement the Boundary and Control portion with CDI but implement transaction support in the Boundary similar to (http://smokeandice.blogspot.com/2009/12/cdi-and-declarative-transactions.html)
3. I can not implement the Boundary with CDI and then start using EJB's in the Control layer.

Thanks

Answer 1

I sucessfully implement the ECB pattern in JavaEE 6 using EJB's solely for the Boundaries and CDI for the Controllers. A typical stack in my architecture uses

• Stateless EJB's annotated with JAX-RS annotations to implement a REST service as Boundary
• CDI managed beans for business logic in the @Dependent scope as Controller
• CDI managed beans in the @Dependent scope for Data Access Objects which use JPA's EntityManager to interact with a database
• JPA entity beans

The stateless EJB's which form the Boundary are always annotated with @TransactionAttribute(REQUIRED) which is the default. I do not use other transaction attributes. Doing so, you can ensure that every interaction with the Boundary takes place in exactly one transaction.

By using only the @Dependent scope for the CDI managed beans, you can ensure that every thread has its own instance of that beans. So you have never more than one thread accessing a CDI managed bean at the same time. Doing so prevents you from the typical concurrency issues.

Using a combination of more heavy weight, pooled EJB's for the Boundary and lightweight CDI managed beans for the rest of the application performs very well for me.