Leí mucho sobre cómo reemplazar EJB con CDI Beans, ya que a menudo ofrecen la misma funcionalidad, etc. Esto me hizo pensar a dónde pertenecen los frijoles CDI. Con EJB, sabía que pertenecían a EJB-Container (Figura 1-7, https://docs.oracle.com/javaee/6/tutorial/doc/bnacj.html ), pero con CDI realmente no puedo pensar en el separación entre Web- y EJB-Container. ¿Los beans CDI están 'administrados' en el contenedor Web o EJB?
Tengo la sensación de que las fronteras se desdibujan. Con los EJB, simplemente pensé que el contenedor EJB representaba mi nivel comercial. Pero ahora los límites entre el nivel empresarial y el nivel de presentación son más lógicos.
Entonces, si ahora hago más uso de beans CDI donde sea posible, ¿es posible y una buena práctica comunicar eventos desde el nivel comercial al nivel de presentación a través de CDI Events?
Cuando quiero escribir una aplicación con varios servidores de aplicaciones para equilibrar la carga, ¿necesito la capacidad de comunicación remota de los EJB? ¿O utiliza el equilibrio de carga afín de sesión para tal propósito?
ACTUALIZAR:
Lo pensé un poco más y creo que no es tan fácil de responder. Como en el enlace que publiqué, los beans administrados pertenecen tanto al contenedor web como al contenedor ejb. Así que creo que puede colocar beans con ámbito CDI (solicitud, sesión) en el contenedor web, ya que el contenedor ejb no sabe nada sobre estos ámbitos. Pero, ¿qué pasa con los beans con ámbito de aplicación?
También noté que estos bordes borrosos también se deben a cómo el servidor de aplicaciones maneja el BeanManager. En este blog https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ se explica que hay diferentes formas en que los servidores de aplicaciones manejan BeanManagers. No parece haber una especificación clara para esto.
La pregunta es realmente difícil de responder, así que toma lo que digo con pinzas. No es preciso, pero trata de darle una visión más clara de lo que está pasando.
CDI tiene su propio contenedor , así que si eso te ayuda, puedes imaginar los frijoles sentados en su propio contenedor. ¿Y por qué tienen su propio contenedor? Bueno, porque se ocupa del ciclo de vida, al igual que lo hace un contenedor EJB. Creación y destrucción de beans bajo demanda, inyección de dependencias... Pero con CDI, el contenedor generalmente tiene un "ámbito" (¡no hay conexión con los ámbitos de CDI aquí!) por aplicación implementada. Por ejemplo, en su servidor de aplicaciones, tendrá un contenedor de este tipo para cada WAR, mientras que con EJB solo habrá un contenedor (después de todo, es por eso que puede tener interfaces remotas y búsqueda jndi).
Como quiera que lo imagine, los bordes son realmente borrosos y una de las razones es que cualquier bean EJB también es automáticamente un bean CDI. Lo que significa que ahora los tiene sentados en dos contenedores a la vez (son solo proxies, pero aún así).
En cuanto a los niveles, CDI puede estar en cualquier lugar, desde la capa de la base de datos (administradores de entidades de manejo como beans), pasando por una capa comercial junto con EJB hasta la capa de presentación donde, en JSF, se refieren los beans directamente a través de @Named . El CDI está ahí para que usted convierta el mundo en frijoles y usted elija qué manejará CDI y qué no.
Entonces, si ahora hago más uso de beans CDI donde sea posible, ¿es posible y una buena práctica comunicar eventos desde el nivel comercial al nivel de presentación a través de CDI Events?
Por todos los medios, ese es un buen enfoque. Le brinda un acoplamiento muy flexible y puede fácilmente afinar los eventos para limitar los esfuerzos de comunicación. Además, si pudiera usar CDI 2.0, también obtendría eventos asíncronos, incluso mejor.