¿Qué es un EJB, y qué hace?

¿Por qué realmente usarlos? (¿Por qué no simplemente se adhieren a POJO?)

SI necesita un componente que acceda a la base de datos, o acceda a otros recursos de conectividad/ directorio, o se accede desde múltiples clientes, o se pretende que sea un servicio SOA, EJBs hoy en día son generalmente "más grandes, más fuertes, más rápidos (o al menos más escalables) y más simples" que POJOs. 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 pequeñas aplicaciones dentro de un departamento.

1. Reutilizar / Compartir Lógica a través de múltiples aplicaciones / clientes con Acoplamiento Suelto.
   EJB se pueden empaquetar en sus propios frascos, implementarse e invocarse desde muchos lugares. Son componentes comunes. Es cierto, POJOs puede ser (con cuidado!) diseñado como bibliotecas y empaquetado en frascos. Pero EJBs admite acceso a redes locales y remotas, incluyendo a través de la interfaz java local, RMI transparente, mensaje asíncrono JMS y servicio web SOAP / REST, ahorro de cortar y pegar dependencias jar con múltiples (inconsistente?) despliegue.
   Son muy útiles para crear servicios SOA. Cuando se utilizan para el acceso local son POJOs (con servicios de contenedores gratuitos añadidos). El acto de diseñar una capa EJB separada promueve un cuidado adicional para maximizar la encapsulación, el acoplamiento suelto y la cohesión, y promueve una interfaz limpia (Fachada), protegiendo a las personas que llaman del procesamiento y los datos complejos modelo.

2. Escalabilidad y Fiabilidad Si aplica un número masivo de solicitudes de varios mensajes/procesos de llamadas / threads, se distribuyen a través de las instancias EJB disponibles en el grupo primero y luego 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 gracia - siempre hay algunos las solicitudes se procesan de manera eficiente y las solicitudes en exceso se hacen esperar. Nos no llegue a "meltdown" del servidor , donde TODAS las solicitudes experimentan un tiempo de respuesta terrible simultáneamente, además, el servidor intenta acceder a más recursos que el hardware y el sistema operativo puede manejar y por lo tanto se bloquea. EJBs se pueden implementar en niveles separados que pueden ser clustered-esto brinda confiabilidad a través de la conmutación por error de un servidor a otro, además el hardware se puede agregar para escalar linealmente.

3. Gestión de Concurrencia. El contenedor garantiza que las instancias EJB se accedan automáticamente de forma segura (en serie) por múltiples clientes. El contenedor administra el EJB pool, el thread pool, el cola de invocación, y realiza automáticamente el bloqueo de escritura a nivel de método (predeterminado) o leer bloqueo (a través de @ Lock (LEER)). Esto protege los datos de la corrupción a través de conflictos de escritura-escritura concurrentes, y ayuda a que los datos se lean de manera consistente al prevenir enfrentamientos de lectura y escritura.
   Esto es principalmente útil para @ Singleton session beans, donde el bean está manipulando y compartir el estado común entre los clientes que llaman. Esto puede ser fácilmente eliminado manualmente configurar o mediante programación controle escenarios avanzados para la ejecución concurrente de código y acceso a datos.

4. Manejo automatizado de transacciones.
   No haga nada en absoluto y se ejecutarán todos sus métodos EJB en una transacción JTA. Si accedes a una base de datos usando JPA o JDBC, es automáticamente se alistó en la transacción. Lo mismo para las invocaciones JMS y JCA. Especificar @TransactionAttribute (someTransactionMode) antes de un método para especificar si / cómo método particular participa en la transacción JTA, anulando modo predeterminado: "Requerido".

5. 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 EJB: tales como conexiones JDBC almacenadas JNDI, conexiones JMS / temas / colas, otros EJBs, JTA Transactions, JPA entity manager persistence contexts, JPA entity manager unidades de persistencia de fábrica y recursos de adaptador JCA. por ejemplo, para configurar una referencia a otra transacción EJB & a JTA & a entidad JPA Gerente & una fábrica y cola de conexión JMS:

   @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 como se desee.

6. Interacción inteligente con JPA. De forma predeterminada, el EntityManager inyectado como se ha indicado anteriormente utiliza una persistencia en el ámbito de la transacción contexto. Esto es perfecto para frijoles de sesión sin estado. Cuando un método EJB (sin estado) se llama, se crea un nuevo contexto de persistencia dentro del nuevo transacción, todos las instancias de objeto de entidad recuperadas / escritas en la base de datos son visibles solo dentro de método de llamada y están aislados de otros métodos. Pero si otros EJB apátridas son llamado por el método, el contenedor se propaga y comparte el mismo PC con ellos, por lo mismo las entidades se comparten automáticamente de manera consistente a través del PC en el mismo transacción.
   Si se declara un bean de sesión @Stateful, la afinidad inteligente igual con JPA se logra mediante declarando el EntityManager como un alcance extendido uno: @PersistentContent (unitName= " AccountsPU, type = EXTENDED). Esto existe para la vida de la sesión de bean, a través de múltiples llamadas y transacciones de bean, almacena en caché copias en memoria de entidades de BD previamente recuperadas / escritas para que no necesiten ser re-recuperadas.

7. Gestión del Ciclo de Vida. El ciclo de vida de EJBs se administra en contenedores. Según sea necesario, crea instancias EJB, borra e inicializa el estado de bean de la sesión con estado, activa y activa y llama métodos de devolución de llamada del ciclo de vida, por lo que el código EJB puede participar en adquiera y libere recursos, o realice otro comportamiento de inicialización y apagado. También captura todas las excepciones, las registra, revierte las transacciones según sea necesario y lanza nuevas excepciones EJB o @ApplicationExceptions según sea necesario.

8. Gestión de la Seguridad. El control de acceso basado en roles a EJBs se puede configurar a través de una simple anotación o XML configuración. El servidor pasa automáticamente la detalles de usuario autenticados junto con cada llamar como contexto de seguridad (el principal y el rol de la llamada). Asegura que todos los RBAC las reglas se aplican automáticamente para que los métodos no puedan ser llamados ilegalmente por el papel equivocado. Permite a EJBs acceder fácilmente a los detalles de usuario / rol para una programación adicional comprobación. Permite conectar el procesamiento de seguridad adicional (o incluso las herramientas IAM) al contenedor de forma estándar.

9. Estandarización y Portabilidad. EJB implementaciones conforme a los estándares Java EE y convenciones de codificación, promoviendo la calidad y facilidad de comprensión y mantenimiento. También promueve la portabilidad del código a los nuevos servidores de aplicaciones del proveedor, asegurando que todos admitan las mismas características estándar y comportamientos, y al desalentar a los desarrolladores de adoptar accidentalmente propiedad
   características de proveedores no portátiles.

10. El Verdadero Truco: La simplicidad. Todo lo anterior se puede hacer con código muy simplificado, ya sea utilizando la configuración predeterminada para EJBs dentro de Java EE 6, o añadiendo algunas anotaciones. Codificar características de la fuerza de la empresa/industrial en su propio POJOs haría ser de manera más voluminoso, complejo y propenso a errores. Una vez que comience a codificar con EJBs, son bastante fáciles de desarrollar y brindan un gran conjunto de beneficios de "viaje gratis".

En la especificación original de EJB de hace 10 años, EJB eran un problema importante de productividad. Estaban hinchados, necesitaban muchos artefactos de código y configuración y proporcionaban alrededor de 2/3 de los beneficios anteriores. La mayoría de los proyectos web en realidad no los utilizan. Pero esto ha cambiado significativamente con 10 años de ajuste, revisión, mejora funcional y alineamiento de la corriente de desarrollo. En Java EE 6 proporcionan el máximo nivel de resistencia industrial y simplicidad de uso.

¿Qué es lo que no me gusta?? :-) :-)