java ee - que - ¿Qué es un EJB y qué hace?

ejb3 java (4)

He estado intentando saber qué son los beans EJB , ¿qué significa que sus instancias se gestionen en un grupo, bla, bla? Realmente no puede tener un buen control de ellos.

¿Puede explicarme qué son realmente (prácticamente para un programador de Java)? ¿Qué hacen? ¿Cuáles son sus propósitos? ¿Por qué realmente usarlos? (¿Por qué no solo apegarse a POJO ?) ¿ Quizás una aplicación de ejemplo?

Por favor refiérase solo a la información actualizada, que es EJB 3.1 . La información fechada sobre EJB puede ser engañosa.

Para principiantes de aprendizaje de EJB, tenga en cuenta:

Los EJB se basan en objetos distribuidos , esto se refiere a piezas de software que se ejecutan en varias máquinas (virtuales o físicas) vinculadas por una red .

¿Por qué realmente usarlos? (¿Por qué no solo te apegas a POJO?)

Si necesita un componente que acceda a la base de datos, o acceda a otros recursos de conectividad / directorio, o se acceda desde varios clientes, o sea un servicio SOA, los EJB de hoy en día suelen ser "más grandes, más fuertes, más rápidos (o al menos más escalables) y más simple "que POJOs. Son más valiosos para dar servicio a un gran número de usuarios a través de la red web o corporativa y algo menos valioso para aplicaciones pequeñas dentro de un departamento.

Reutilizando / Compartiendo Lógica a través de múltiples aplicaciones / clientes con Loose Coupling.
Los EJB se pueden empaquetar en sus propias jarras, desplegarse e invocarse desde muchos lugares. Son componentes comunes. Es cierto, los POJO pueden diseñarse (con cuidado) como bibliotecas y empaquetarse como frascos. Pero los EJB admiten el acceso a la red local y remota, incluso a través de la interfaz java local, RMI transparente, mensaje asíncrono JMS y servicio web SOAP / REST, ahorrándole a las dependencias jar de cortar y pegar múltiples despliegues (inconsistentes).
Son muy útiles para crear servicios SOA. Cuando se usan para acceso local, son POJO (con servicios de contenedores gratuitos agregados). El acto de diseñar una capa EJB separada promueve un cuidado extra para maximizar la encapsulación, el acoplamiento flexible y la cohesión, y promueve una interfaz limpia (Fachada), protegiendo a las personas que llaman de complejos procesamientos y modelos de datos.
Escalabilidad y confiabilidad Si aplica una gran cantidad de solicitudes desde varios mensajes / procesos / hilos de llamada, se distribuyen primero entre las instancias de EJB disponibles en el grupo y luego se ponen en cola. Esto significa que si el número de solicitudes entrantes por segundo es mayor de lo que el servidor puede manejar, nos degradamos con elegancia: siempre hay algunas solicitudes que se procesan de manera eficiente y las solicitudes en exceso se hacen esperar. No llegamos al "desastre" del servidor, donde TODAS las solicitudes experimentan un tiempo de respuesta terrible simultáneamente, además el servidor intenta acceder a más recursos de los que el hardware y el sistema operativo pueden manejar y, por lo tanto, se cuelgan. Los EJB pueden implementarse en un nivel separado que puede agruparse: esto brinda confiabilidad a través de conmutación por error desde un servidor a otro, además de que se puede agregar hardware para escalar linealmente.
Gestión de Concurrencia. El contenedor asegura que varias instancias de EJB sean accedidas de forma segura (en serie) por múltiples clientes. El contenedor administra el grupo de EJB, el grupo de subprocesos, la cola de invocación y realiza automáticamente el bloqueo de escritura a nivel de método (predeterminado) o el bloqueo de lectura (a través de @Lock (READ)). Esto protege los datos contra la corrupción a través de conflictos de escritura-escritura simultáneos y ayuda a que los datos se lean de manera consistente al evitar conflictos de lectura y escritura.
Esto es principalmente útil para los beans de sesión @Singleton, donde el bean está manipulando y compartiendo el estado común entre las llamadas de los clientes. Esto se puede descartar fácilmente para configurar manualmente o controlar mediante programación escenarios avanzados para la ejecución simultánea de código y el acceso a datos.
Manejo automatizado de transacciones.
No haga nada y todos sus métodos EJB se ejecuten en una transacción JTA. Si accede a una base de datos usando JPA o JDBC, se alista automáticamente en la transacción. Lo mismo para las invocaciones de JMS y JCA. Especifique @TransactionAttribute (someTransactionMode) antes de un método para especificar si / cómo ese método en particular participa en la transacción JTA, anulando el modo predeterminado: "Requerido".
Acceso a recursos / dependencias muy simple a través de inyección.
El contenedor buscará recursos y establecerá referencias de recursos como campos de instancia en el EJB: como conexiones JDBC almacenadas JNDI, conexiones / temas / colas JMS, otros EJB, transacciones JTA, contextos de persistencia del administrador de entidades JPA, unidades de persistencia de fábrica del administrador de entidades JPA y Recursos del adaptador JCA. por ejemplo, para configurar una referencia a otro EJB y una transacción JTA y un administrador de la entidad JPA y una fábrica de conexión JMS y una cola:
@Stateless public class MyAccountsBean { @EJB SomeOtherBeanClass someOtherBean; @Resource UserTransaction jtaTx; @PersistenceContext(unitName="AccountsPU") EntityManager em; @Resource QueueConnectionFactory accountsJMSfactory; @Resource Queue accountPaymentDestinationQueue; public List<Account> processAccounts(DepartmentId id) { // Use all of above instance variables with no additional setup. // They automatically partake in a (server coordinated) JTA transaction } }
Un servlet puede llamar a este bean localmente, simplemente declarando una variable de instancia:
@EJB MyAccountsBean accountsBean;
y luego simplemente llamar a sus ''métodos según lo deseado.
Interacción inteligente con JPA. De forma predeterminada, EntityManager inyectado como se indica arriba utiliza un contexto de persistencia con ámbito de transacción. Esto es perfecto para beans de sesión sin estado. Cuando se llama a un método EJB (sin estado), se crea un nuevo contexto de persistencia dentro de la nueva transacción, todas las instancias de objeto de entidad recuperadas / escritas en el DB son visibles solo dentro de esa llamada a método y están aisladas de otros métodos. Pero si se llama a otros EJB sin estado mediante el método, el contenedor los propaga y comparte con ellos la misma PC, por lo que las mismas entidades se comparten automáticamente de manera consistente a través de la PC en la misma transacción.
Si se declara un bean de sesión @Stateful, se logrará la misma afinidad inteligente con JPA al declarar que entityManager es de ámbito extendido: @PersistentContent (unitName = "AccountsPU, type = EXTENDED). Esto existe durante la vida de la sesión de bean, a través de múltiples llamadas y transacciones de bean, almacenamiento en memoria caché de copias de copias de las entidades de BD previamente recuperadas / escritas para que no necesiten ser recuperadas.
Gestión del ciclo de vida. El ciclo de vida de los EJB está administrado por contenedor. Según sea necesario, crea instancias EJB, borra e inicializa estado bean de sesión, apaga y activa, y llama a los métodos de devolución de ciclo de vida, por lo que el código EJB puede participar en operaciones de ciclo de vida para adquirir y liberar recursos o realizar otro comportamiento de inicialización y apagado. También captura todas las excepciones, las registra, retrotrae transacciones según sea necesario y arroja nuevas excepciones EJB o @ApplicationExceptions según sea necesario.
Gestion de seguridad. El control de acceso basado en roles para los EJB se puede configurar a través de una simple anotación o configuración XML. El servidor pasa automáticamente los detalles del usuario autenticado junto con cada llamada como contexto de seguridad (el principal y el rol de la llamada). Asegura que todas las reglas de RBAC se apliquen automáticamente para que los métodos no puedan ser llamados ilegalmente por la función incorrecta. Permite a los EJB acceder fácilmente a los detalles del usuario / rol para una comprobación programática adicional. Permite conectar el procesamiento de seguridad adicional (o incluso las herramientas de IAM) al contenedor de forma estándar.
Estandarización y Portabilidad. Las implementaciones de EJB cumplen con los estándares de Java EE y las convenciones de codificación, promoviendo la calidad y la facilidad de comprensión y mantenimiento. También promueve la portabilidad del código para los nuevos servidores de aplicaciones de proveedores, al garantizar que todos soporten las mismas características y comportamientos estándar, y al disuadir a los desarrolladores de adoptar accidentalmente propiedades patentadas.
características de proveedores no portátiles.
The Real Kicker: Simplicity. Todo lo anterior se puede hacer con un código muy simplificado, ya sea utilizando la configuración predeterminada para EJB en Java EE 6 o agregando algunas anotaciones. La codificación de las características empresariales / de fortaleza industrial en sus propios POJO sería mucho más voluminosa, compleja y propensa a errores. Una vez que comienzas a codificar con los EJB, son bastante fáciles de desarrollar y ofrecen un gran conjunto de beneficios de "viaje gratis".

En la especificación EJB original de hace 10 años, EJB era una gran molestia de productividad. Estaban hinchados, necesitaban muchos artefactos de código y configuración y proporcionaban aproximadamente 2/3 de los beneficios anteriores. La mayoría de los proyectos web en realidad no los usaban. Pero esto ha cambiado significativamente con 10 años de ajuste, revisión, mejora funcional y desarrollo de líneas de flujo. En Java EE 6 brindan la máxima resistencia industrial y simplicidad de uso.

¿¿Que es no gustar?? :-) :-)

Espero que esto de Oracle doc ayude a alguien como yo a entender el tema de EJB de una manera simple.

¿Qué es un Enterprise Bean? Escrito en el lenguaje de programación Java, un enterprise bean es un componente del lado del servidor que encapsula la lógica comercial de una aplicación. La lógica de negocios es el código que cumple el propósito de la aplicación. En una aplicación de control de inventario, por ejemplo, enterprise beans podría implementar la lógica comercial en métodos llamados checkInventoryLevel y orderProduct. Al invocar estos métodos, los clientes pueden acceder a los servicios de inventario proporcionados por la aplicación.
Beneficios de Enterprise Beans Por varias razones, enterprise beans simplifica el desarrollo de aplicaciones grandes y distribuidas. En primer lugar, como el contenedor EJB proporciona servicios de nivel de sistema a enterprise beans, el desarrollador de bean puede concentrarse en resolver problemas comerciales. El contenedor EJB, en lugar del desarrollador de bean, es responsable de los servicios a nivel de sistema, como la gestión de transacciones y la autorización de seguridad.
En segundo lugar, como los beans en lugar de los clientes contienen la lógica de negocios de la aplicación, el desarrollador del cliente puede centrarse en la presentación del cliente. El desarrollador del cliente no tiene que codificar las rutinas que implementan las reglas comerciales o las bases de datos de acceso. Como resultado, los clientes son más delgados, un beneficio que es particularmente importante para los clientes que se ejecutan en dispositivos pequeños.
En tercer lugar, como enterprise beans son componentes portátiles, el ensamblador de aplicaciones puede crear nuevas aplicaciones a partir de beans existentes. Estas aplicaciones se pueden ejecutar en cualquier servidor Java EE compatible siempre que utilicen las API estándar.
Cuándo utilizar Enterprise Beans Debería considerar el uso de enterprise beans si su aplicación cumple con alguno de los siguientes requisitos:
La aplicación debe ser escalable. Para dar cabida a un número creciente de usuarios, es posible que necesite distribuir los componentes de una aplicación en varias máquinas. Los beans empresariales de una aplicación no solo se pueden ejecutar en diferentes máquinas, sino que su ubicación seguirá siendo transparente para los clientes.
Las transacciones deben garantizar la integridad de los datos. Enterprise beans admite transacciones, los mecanismos que administran el acceso concurrente de objetos compartidos.
La aplicación tendrá una variedad de clientes. Con solo unas pocas líneas de código, los clientes remotos pueden ubicar fácilmente enterprise beans. Estos clientes pueden ser delgados, variados y numerosos.

La pregunta que más me interesa es cómo y dónde puedo usarlos. Para entender esto, primero tenemos que ver qué tipos de EJB existen. Hay 2 grandes categorías:

Habas
Frijoles con mensajes

Consideremos Session Beans. Son de 3 tipos:

Stateful : estos componentes mantienen el estado y son específicos para un cliente en múltiples solicitudes. Véalo como una sesión. El uso inmediato que se les puede dar es a los carritos de compras u otro tipo de sesiones (sesión de inicio de sesión, etc.)
Sin estado : estos son componentes independientes que no persisten la información entre las solicitudes, pero son únicos para el usuario. Uso inmediato que se me ocurre - Clases de servicio en la capa de servicio . Imagine OrderService . Otro gran uso para estos es exponer servicios web. De nuevo, esto estará en la capa de Servicio o totalmente separado.
Singleton : estos son los beans que existen por aplicación y se crean una vez y pueden reutilizarse / accederse varias veces. Inmediatamente me viene a la mente el componente Configuration , donde puede almacenar configuraciones de nivel de aplicación y acceder a ellas cuando las necesite desde cualquier lugar.

Ahora el resto de las capacidades o características se pueden usar en todas las capas en cualquiera de estas situaciones:

Seguridad : puede verificar los permisos con una anotación en el método que se llama. Esto puede suceder tanto en la capa de Servicio como en el Controlador si así lo desea.
Gestión de transacciones : este es el candidato obvio en la capa de Servicio o Persistencia
Inyección de Dependencia - nuevamente se usará en todas partes

Un gran uso en los tiempos modernos son los llamados Microservicios y Arquitecturas Orientadas a Servicios. Puede empaquetar algunos componentes de la lógica de negocios como EJB y distribuirlos en toda la organización, para ser utilizados por varios clientes (por cliente aquí me refiero a otras aplicaciones de back-end).

Y así. Ahora el gran inconveniente es que se vuelve muy dependiente del contenedor EJB y, aunque podría cambiar entre dos implementaciones de referencia, no podrá cambiar a algo más ligero: Tomcat, por ejemplo. Pero, ¿por qué querrías sacrificar todos los beneficios?

Un EJB es un componente de Java, que contiene lógica comercial, que se implementa en un contenedor y que se beneficia de los servicios técnicos proporcionados por el contenedor, generalmente de manera declarativa, gracias a las anotaciones:

gestión de transacciones: una transacción se puede iniciar automáticamente antes de que se invoque un método del EJB, y se compromete o se revierte una vez que este método retorna. Este contexto transaccional se propaga a llamadas a otros EJB.
gestión de la seguridad: se puede verificar que la persona que llama tiene las funciones necesarias para ejecutar el método.
Inyección de dependencia: otros EJB o recursos como un administrador de entidades JPA, un origen de datos JDBC, etc. se pueden inyectar en el EJB.
concurrencia: el contenedor se asegura de que solo un hilo a la vez invoca un método de su instancia de EJB.
distribución: algunos EJB se pueden llamar de forma remota, desde otra JVM.
conmutación por error y equilibrio de carga: los clientes remotos de sus EJB pueden redirigir automáticamente su llamada a otro servidor si es necesario.
administración de recursos: los beans con estado se pueden pasivar automáticamente al disco para limitar el consumo de memoria de su servidor.
... Probablemente he olvidado algunos puntos.