Java EE Architecture - Where do CDI Beans belong to?

Question

I read a lot about replacing EJBs with CDI Beans as they often offers the same functionality and so on. This made me think of where CDI beans belong to. With EJBs I knew they belong to be EJB-Container (Figure 1-7, https://docs.oracle.com/javaee/6/tutorial/doc/bnacj.html), but with CDI I can not really think of the seperation between Web- and EJB-Container. Are the CDI beans 'managed' in the Web- or EJB-Container?

I have the feeling that the borders become blurred. With EJBs I simply thougt the EJB Container kind of represents my business tier. But now the borders between business tier and presentation tier are more logically.

So if I now make more use of CDI beans where possible, is it possible and good practice to communicate events from the business tier to the presentation tier via CDI Events?

When I want to write an application with multiple application servers for load balancing, do I need the remoting capability of EJBs? Or do you use session affine load balancing for such purpose?

UPDATE:

I thought about that a bit further and I think that it is not that easy to answer. As in the link i posted, managed beans belongs to the Web container as well as to the ejb container. So I think you can place CDI scoped beans (request, session) to the web container, as the ejb container doesn't know anything about this scopes. But whats about application scoped beans?

I also noticed that this blurry borders are also caused by how the application server handles the BeanManager. In this blog https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ is explained, that there are different ways how application servers handles BeanManagers. There seems to be no clear specification for this.

Answer 1

The question is really difficult to answer, so take what I say with a pinch of salt. It is not precise, but tries to give you a clearer view of what's going on.

CDI has it's own container, so if that helps you, you can imagine the beans sitting in their own container. And why do they have their own container? Well, because it takes care about the lifecycle, much as an EJB container does. On-demand bean creation and destruction, injection of dependencies... But with CDI, the container is usually "scoped" (no connection to CDI scopes here!) per application deployed. E.g. on your application server, you will have such a container for each WAR, whereas with EJB there will be one container only (after all, that's why you can have remote interfaces and jndi lookup).

However you imagine it, the borders are indeed blurred and one of the reasons for that is that any EJB bean is automatically a CDI bean too. Meaning you now have them sitting in two containers at a time (it's only proxies, but still).

Tier-wise, CDI can be anywhere - ranging from database layer (handling entity managers as beans), over a business layer alongside EJB up to presentation layer where, in JSF, you refer the beans directly via @Named. The CDI is there for you to turn the world into beans and you choose what will be handled by CDI and what will not.

So if I now make more use of CDI beans where possible, is it possible and good practice to communicate events from the business tier to the presentation tier via CDI Events?

By all means, that's a good approach. It gives you very loose coupling and you can easily fine-grain the events to limit the communication efforts. Also, if you could use CDI 2.0, you would get asynchronous events as well - even better.