¿Qué es un EJB y qué hace?

Solución:

¿Por qué usarlos realmente? (¿Por qué no seguir con POJO?)

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

1. Reutilizar / compartir lógica en múltiples aplicaciones / clientes con acoplamiento suelto.
   Los EJB se pueden empaquetar en sus propios frascos, implementar e invocar desde muchos lugares. Son componentes comunes. Es cierto que 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, lo que ahorra de dependencias de jar de cortar y pegar con implementaciones múltiples (¿inconsistentes?).
   Son muy útiles para crear servicios SOA. Cuando se utilizan para acceso local, son POJO (con servicios de contenedor gratuitos agregados). El acto de diseñar una capa EJB separada promueve un cuidado adicional para maximizar la encapsulación, el acoplamiento flojo y la cohesión, y promueve una interfaz limpia (Fachada), protegiendo a las personas que llaman de modelos complejos de procesamiento y datos.

2. Escalabilidad y confiabilidad Si aplica una gran cantidad de solicitudes de varios mensajes / procesos / subprocesos de llamada, primero se distribuyen 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, lo degradamos con gracia: siempre hay algunas solicitudes que se procesan de manera eficiente y las solicitudes en exceso se hacen esperar. No llegamos al “colapso” 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 bloquea. Los EJB se pueden implementar en niveles separados que se pueden agrupar; esto brinda confiabilidad a través de la conmutación por error de un servidor a otro, además de que se puede agregar hardware para escalar linealmente.

3. Gestión de concurrencia. El contenedor garantiza que varios clientes accedan automáticamente a las instancias de EJB de forma segura (en serie). El contenedor administra el grupo EJB, el grupo de subprocesos, la cola de invocación y automáticamente realiza 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 de la corrupción a través de conflictos de escritura y 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 de @Singleton, donde el bean está manipulando y compartiendo un estado común entre los llamadores de clientes. Esto se puede anular 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 los datos.

4. Manejo automatizado de transacciones.
   No haga nada en absoluto y todos sus métodos EJB se ejecutarán en una transacción JTA. Si accede a una base de datos utilizando JPA o JDBC, se inscribe automáticamente en la transacción. Lo mismo para las invocaciones 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”.

5. Acceso muy simple a recursos / dependencias mediante 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 entidad JPA y una fábrica de conexiones 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 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 llamando a sus ‘métodos como desee.

6. Interacción inteligente con JPA. De forma predeterminada, el EntityManager inyectado como arriba usa un contexto de persistencia con alcance 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 la base de datos son visibles solo dentro de esa llamada al método y están aisladas de otros métodos. Pero si el método llama a otros EJB sin estado, el contenedor se propaga y comparte la misma PC con ellos, por lo que las mismas entidades se comparten automáticamente de manera coherente a través de la PC en la misma transacción.
   Si se declara un bean de sesión @Stateful, se logra la misma afinidad inteligente con JPA al declarar el entityManager como uno de alcance extendido: @PersistentContent (unitName = “AccountsPU, type = EXTENDED). Esto existe durante la vida útil de la sesión del bean, a través de múltiples llamadas y transacciones de beans, almacenando en caché copias en memoria de entidades de base de datos previamente recuperadas / escritas para que no sea necesario volver a recuperarlas.

7. Gestión del ciclo de vida. El ciclo de vida de los EJB se gestiona mediante contenedores. Según sea necesario, crea instancias de EJB, borra e inicializa el estado del bean de sesión con estado, pasiva y activa, y llama a los métodos de devolución de llamada del ciclo de vida, por lo que el código EJB puede participar en las operaciones del 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, revierte transacciones según sea necesario y lanza nuevas excepciones EJB o @ApplicationExceptions según sea necesario.

8. Gestion de seguridad. El control de acceso basado en roles a los EJB se puede configurar mediante una simple anotación o una 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). Garantiza que todas las reglas de RBAC se apliquen automáticamente para que los métodos no puedan ser invocados ilegalmente por el rol incorrecto. Permite a los EJB acceder fácilmente a los detalles del usuario / rol para una verificación programática adicional. Permite conectar un procesamiento de seguridad adicional (o incluso herramientas IAM) al contenedor de forma estándar.

9. Estandarización y portabilidad. Las implementaciones de EJB se ajustan a los estándares y convenciones de codificación de Java EE, lo que promueve la calidad y la facilidad de comprensión y mantenimiento. También promueve la portabilidad del código a los servidores de aplicaciones de nuevos proveedores, asegurándose de que todos admitan las mismas características y comportamientos estándar y desalentando a los desarrolladores de adoptar accidentalmente
   características de proveedores no portátiles.

10. The Real Kicker: Simplicidad. Todo lo anterior se puede hacer con un código muy optimizado, ya sea usando la configuración predeterminada para EJB dentro de Java EE 6 o agregando algunas anotaciones. Codificar características de fuerza empresarial / industrial en sus propios POJO sería camino más voluminoso, complejo y propenso a errores. Una vez que comienza a codificar con EJB, son bastante fáciles de desarrollar y brindan un gran conjunto de beneficios “gratuitos”.

En la especificación EJB original de hace 10 años, los EJB eran un problema de productividad importante. Estaban inflados, necesitaban mucho código y artefactos de 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 ajustes, revisiones, mejoras funcionales y optimización del desarrollo. En Java EE 6, proporcionan una fuerza industrial de máximo nivel y simplicidad de uso.

¿¿Que es no gustar?? 🙂 🙂

Un EJB es un componente Java, que contiene lógica empresarial, que se despliega en un contenedor, y que se beneficia de los servicios técnicos proporcionados por el contenedor, generalmente de forma 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 de EJB, y se puede confirmar o deshacer una vez que este método regrese. Este contexto transaccional se propaga a llamadas a otros EJB.
• gestión de la seguridad: se puede comprobar que la persona que llama tiene los roles necesarios para ejecutar el método.
• inyección de dependencia: otros EJB, o recursos como un administrador de entidad JPA, una fuente 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.
• gestió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.

Espero que esto de Oracle doc ayude a alguien como yo a comprender 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 empresarial de una aplicación. La lógica empresarial es el código que cumple el propósito de la aplicación. En una aplicación de control de inventario, por ejemplo, los enterprise beans pueden implementar la lógica empresarial en métodos denominados checkInventoryLevel y orderProduct. Al invocar estos métodos, los clientes pueden acceder a los servicios de inventario proporcionados por la aplicación.

Beneficios de los Enterprise Beans Por varias razones, los Enterprise Beans simplifican el desarrollo de grandes aplicaciones distribuidas. Primero, debido a que el contenedor EJB proporciona servicios a nivel de sistema a los beans empresariales, el desarrollador de beans puede concentrarse en resolver problemas comerciales. El contenedor EJB, en lugar del desarrollador de beans, es responsable de los servicios a nivel del sistema, como la gestión de transacciones y la autorización de seguridad.

En segundo lugar, debido a que los beans en lugar de los clientes contienen la lógica empresarial 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, dado que los beans enterprise son componentes portátiles, el ensamblador de aplicaciones puede crear nuevas aplicaciones a partir de beans existentes. Estas aplicaciones pueden ejecutarse en cualquier servidor Java EE compatible siempre que utilicen las API estándar.

Cuándo usar Enterprise Beans Debería considerar el uso de Enterprise Beans si su aplicación tiene alguno de los siguientes requisitos:

La aplicación debe ser escalable. Para adaptarse a un número creciente de usuarios, es posible que deba distribuir los componentes de una aplicación en varias máquinas. Los beans de empresa de una aplicación no solo pueden ejecutarse en diferentes máquinas, sino que también su ubicación permanecerá transparente para los clientes.

Las transacciones deben garantizar la integridad de los datos. Los beans empresariales admiten 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 localizar fácilmente los beans empresariales. Estos clientes pueden ser delgados, diversos y numerosos.

Reseñas y puntuaciones del artículo

Si te gusta este mundo, tienes la opción de dejar una sección acerca de qué le añadirías a esta sección.

---

---

Utiliza Nuestro Buscador