¿Cómo se comparan CDI y EJB? interactuar?


Estoy teniendo dificultades para entender cómo interactúan los dos y dónde se encuentra el límite entre ellos. ¿Se superponen? Hay redundancias entre ellos?

Sé que hay anotaciones asociadas con ambos, pero no he podido encontrar una lista completa para ambos con descripciones breves. No estoy seguro de si esto ayudaría a aclarar cómo difieren o dónde se superponen.

Realmente confundido. Yo (creo que) entiendo EJB razonablemente bien, supongo que estoy teniendo un momento difícil entender exactamente lo que CDI trae a la mesa y cómo suplanta o mejora lo que EJB ya ofrece.

Author: Tim, 2011-01-13

3 answers

CDI - se trata de inyección de dependencia. Significa que puede inyectar la implementación de la interfaz en cualquier lugar. Este objeto puede ser cualquier cosa, puede no estar relacionado con EJB. Aquí es un ejemplo de cómo inyectar generador aleatorio usando CDI. No hay nada sobre EJB. Va a usar CDI cuando quiera inyectar servicios que no sean EJB, diferentes implementaciones o algoritmos (por lo que no necesita EJB allí en absoluto).
EJB usted entiende, y probablemente usted está confundido por @ EJB anotación-it le permite inyectar implementación en su servicio o lo que sea. La idea principal es que la clase, donde se inyecta, debe ser administrada por EJB container. Parece que CDI entiende lo que es EJB, por lo que en el servidor compatible con Java EE 6, en su servlet puede escribir ambos

@EJB EJBService ejbService;

Y

@Inject EJBService ejbService;

Eso es lo que puede hacerte confuso, pero eso es probablemente lo único que es el puente entre EJB y CDI.

Cuando estamos hablando de CDI, puede inyectar otros objetos en CDI clases administradas (solo deben ser creadas por marcos compatibles con CDI).

Qué más ofrece CDI... Por ejemplo, utiliza Struts 2 como MVC framework (solo ejemplo), y está limitado aquí, incluso usando EJB 3.1: no puede usar la anotación @EJB en la acción Struts, no es administrada por el contenedor. Pero cuando se agrega Struts2-CDI plugin, se puede escribir allí @ Inyectar anotación para la misma cosa (por lo que no se necesita más búsqueda JNDI). De esta manera aumenta la potencia EJB. Pero como he mencionado antes, lo que inyecte con CDI-no importa si está relacionado con EJB o no, y esa es su potencia

PS. enlace actualizado al ejemplo

 47
Author: Maxym,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-24 07:06:07

Actualmente es un poco confuso, ya que ahora hay varios modelos de componentes en Java EE. Son CDI, EJB3 y JSF Managed Beans.

CDI es el nuevo chico en el bloque. Característica de frijoles CDIdependency injection, scoping y un event bus. Los frijoles CDI son los más flexibles con respecto a la inyección y el alcance. El event bus es muy ligero y muy adecuado incluso para las aplicaciones web más simples. Además de esto, CDI también expone un muy característica avanzada llamada portable extensions, que es una especie de mecanismo de plug-in para que los proveedores proporcionen funcionalidad adicional a Java EE que puede estar disponible en todas las implementaciones (Glassfish, JBoss AS, Websphere, etc).

EJB3 los frijoles se adaptaron del antiguo modelo de componentes EJB2 heredado* y fueron los primeros frijoles en Java EE en ser manejados por frijoles a través de una anotación. EJB3 frijoles característica dependency injection, declarative transactions, declarative security, pooling, concurrency control, asynchronous execution y remoting.

Dependencia la inyección en los frijoles EJB3 no es tan flexible como en los frijoles CDI y los frijoles EJB3 no tienen un concepto de alcance. Sin embargo, EJB3 beans son transaccionales y agrupados por defecto**, dos cosas muy útiles que CDI ha decidido dejar en el dominio de EJB3. Los otros artículos mencionados tampoco están disponibles en CDI. EJB3 no tiene bus de eventos propio, sin embargo, pero tiene un tipo especial de bean para escuchar mensajes; el bean basado en mensajes. Esto se puede utilizar para recibir mensajes de Java Sistema de mensajería o de cualquier otro sistema que tenga un adaptador de recursos JCA. Usar mensajería completa para eventos simples es mucho más pesado que el CDI event bus y EJB3 solo define un oyente, no una API de productor.

JSF Managed Beans han existido en Java EE desde que se incluyó JSF. También cuentan con dependency injection y scoping. JSF Managed Beans introdujo el concepto de alcance declarativo. Originalmente los alcances eran bastante limitados y en la misma versión de Java EE donde EJB3 beans ya podía ser declarado a través de anotaciones, JSF Managed Beans todavía tenía que ser declarado en XML. La versión actual de JSF Managed Beans también se declara finalmente a través de una anotación y los ámbitos se expanden con un ámbito de vista y la capacidad de crear ámbitos personalizados. El ámbito de vista, que recuerda los datos entre las solicitudes a la misma página es una característica única de JSF Managed Beans.

Aparte del alcance de la vista, todavía hay muy poco para los frijoles administrados por JSF en Java EE 6. El alcance de la vista que falta en CDI es desafortunado, ya que de lo contrario CDI habría sido un súper conjunto perfecto de lo que ofrece JSF Managed Beans. Actualización: En Java EE 7/JSF 2.2 a CDI compatible @ViewScoped se ha añadido, haciendo CDI de hecho ese super set perfecto. Actualización 2: En JSF2.3 los frijoles administrados por JSF han sido obsoletos a favor de los frijoles administrados por CDI.

Con EJB3 y CDI la situación no es tan clara. El modelo de componentes EJB3 y API ofrece una gran cantidad de servicios que CDI no ofrece, por lo que normalmente EJB3 no puede ser reemplazado por CDI. Por otro lado, CDI se puede usar en combinación con EJB3, por ejemplo, agregando soporte de scope a EJBs.

Reza Rahman, miembro del grupo de expertos e implementador de una implementación de CDI llamada CanDI, ha insinuado con frecuencia que los servicios asociados con el modelo de componentes EJB3 se pueden adaptar como un conjunto de anotaciones de CDI. Si eso sucediera, todos los frijoles manejados en Java EE podrían convertirse en CDI frijol. Esto no significa que EJB3 desaparezca o se vuelva obsoleto, sino que su funcionalidad se expondrá a través de CDI en lugar de a través de anotaciones propias de EJB como @Stateless y @EJB.

Update

David Blevins de TomEE y OpenEJB fame explica muy bien las diferencias y similitudes entre CDI y EJB en su blog: CDI, cuándo romper el EJBs

* Aunque es solo un incremento en el número de versión, EJB3 frijoles fueron para el en su mayor parte, un tipo completamente diferente de bean: un pojo simple que se convierte en un "bean administrado" mediante la aplicación de una simple anotación única, en comparación con el modelo en EJB2 donde se requería un descriptor de implementación XML pesado y excesivamente detallado para cada bean, además de que se requería que el bean implementara varias interfaces de componentes extremadamente pesadas y en su mayor parte sin sentido.

** Los frijoles de sesión sin estado son típicamente frijoles de sesión con estado agrupados por lo general no (pero pueden ser). Para ambos tipos, la agrupación es opcional y la especificación EJB no lo exige de ninguna manera.

 184
Author: Arjan Tijms,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-08-09 06:45:08

Albert Einstein: If you can't explain it simply, you don't understand it well enough

Ejbs y CDI son bastante fáciles de entender.

Ejbs:

  1. Siempre estará anotado por calificadores de ámbito, por ejemplo, @Stateless, @Stateful, @Request, etc
  2. Las instancias de Ejbs son controladas por el framework Java EE y agrupadas. It is the duty of EE framework to provide the instances for the consumer.

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

El fabricante de automóviles está anotado con un alcance Ejbs específico, por lo tanto, es Ejb

CDI:

  1. No gestionadas enteramente por EE framework, las instancias tienen que ser creadas por usted mismo.
  2. Siempre es dependiente. permítanme explicar "Dependiente" con un ejemplo:

    class Specification { private String color; private String model; //- Getter and Setter }

La clase Specification es CDI, ya que no está anotada con ámbitos Ejb y también esto tiene que inicializarse por su framework code not EE. Un punto a tener en cuenta aquí es que como no anotamos la clase Specification, está anotada por defecto por @Dependent anotación.

@Dependent  <- By default added 
class Specification { ... }

Further reading: Es necesario estudiar más entre Ejbs scope annotation y CDI scope annotation, que aclarará aún más el concepto

 -1
Author: HA S,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-08-09 01:28:39