With the advent of CDI a new powerful concept joined JEE - but how does it fit into my "big picture"? I would like to share my current understanding and gladly receive any hints, refinements and observations in order to progress to a better understanding.

From what I understood, CDI beans live in "contexts". Containers manage the life-cycle of these contexts according to outside events. When creating a context, containers try to populate this context with the appropriate bean instances (if required to do so). On the other hand, CDI beans do not provide "traditional" container services such as transactions, security, webservices and multi-threading support - these are subject to EJB functionality. Furthermore, even if explicitly excluded from the CDI bean list, any SFSB can easily be dealt with "as-if" it were a CDI bean (there's a lot of stuff on that in the documentation).

Putting these things together I came up with the following pattern (a variation of model-view-controller)

• There is something like a "unit of user experience" which is probably exactly the same thing as a conversation. It may or may not span various views (xhtml-files).
• Each "conversation" contains a controller which is a @ConversationScoped @Named CDI bean. This controller provides EL access to fields and methods. It also wraps the GUI state around business objects. A controller has a "open" and a "close" JSF Action that begin() and end() the conversation.
• The JSF actions in the Controllers operate on business objects. In order to do so, they get POJOs that are JPA entities. These POJOS implement the business functionality.
• The Controllers find the POJOs to deal with using "Services" (roughly CRUD Services, coarsly-grained at containment-top-level). These Services are SFSB (but not CDI beans). They get @Injected into the CDI Controllers. Only methods in these Services have access to the EntityManager (which has EXTENDED type). The Services are @LocalBeans so that the CDI beans get references to managed entity POJOs and can traverse relations as they like (because the EntityManager keeps on as long as its SFSB lives; since the SFSB is @Injected into a @ConversationScoped CDI bean, this will be the duration of the conversation).
• Additionally, according to A.Bien: Since EXTENDED EntityManagers do not require transactions, the SFSB have (mostly) a @TransactionAttribute(NEVER). There is only a save() method that has @TransactionAttribute(REQUIRES_NEW) - but no method body.

Personally I feel it is necessary to distinguish between Controller (CDI bean) and Service (SFSB) because of "separation of concerns": the Service could provide functionality as webservice as well, whereas the controller is tightly coupled to its xhtml views, page flows and user experience in general.

Any remarks welcome!

Kind regards,

Bernhard