Hispanopedia Wiki
Articulo de referencia

Yakarta Enterprise Beans

Jakarta Enterprise Beans ( EJB ; anteriormente Enterprise JavaBeans ) es una de las diversas API de Java para la construcción modular de software empresarial . EJB es un compone...

Hispanopedia WikiContenido en espanolLectura gratuita

Jakarta Enterprise Beans ( EJB ; anteriormente Enterprise JavaBeans ) es una de las diversas API de Java para la construcción modular de software empresarial . EJB es un componente de software del lado del servidor que encapsula la lógica de negocio de una aplicación. Un contenedor web EJB proporciona un entorno de ejecución para componentes de software relacionados con la web, incluyendo seguridad informática , gestión del ciclo de vida de los servlets Java , procesamiento de transacciones y otros servicios web . La especificación EJB es un subconjunto de la especificación Jakarta EE . [ 1 ]

Especificación

La especificación EJB fue desarrollada originalmente en 1997 por IBM y posteriormente adoptada por Sun Microsystems (EJB 1.0 y 1.1) en 1999 [ 2 ] y mejorada bajo el Proceso de la Comunidad Java como JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) y JSR 345 (EJB 3.2).

La especificación EJB proporciona una forma estándar de implementar el software de negocio del lado del servidor (también llamado " back-end ") que se encuentra habitualmente en las aplicaciones empresariales (a diferencia del software de interfaz de usuario "front-end" ). Este software aborda los mismos tipos de problemas, y los programadores suelen reimplementar repetidamente las soluciones a estos problemas. Jakarta Enterprise Beans está diseñado para gestionar de forma estandarizada aspectos comunes como la persistencia , la integridad transaccional y la seguridad , lo que permite a los programadores centrarse en las partes específicas del software empresarial en cuestión.

Responsabilidades generales

La especificación EJB detalla cómo un servidor de aplicaciones proporciona las siguientes responsabilidades:

Además, la especificación Jakarta Enterprise Beans define las funciones del contenedor EJB y de los EJB, así como la forma de implementarlos en un contenedor. Cabe destacar que la especificación EJB no detalla cómo un servidor de aplicaciones proporciona persistencia (tarea delegada a la especificación JPA), sino que describe cómo la lógica de negocio puede integrarse fácilmente con los servicios de persistencia que ofrece el servidor de aplicaciones.

Historia

Las empresas descubrieron que el uso de EJB para encapsular la lógica de negocio conllevaba una penalización en el rendimiento. Esto se debía a que la especificación original solo permitía la invocación remota de métodos a través de CORBA (y opcionalmente otros protocolos), a pesar de que la gran mayoría de las aplicaciones empresariales no requieren esta funcionalidad de computación distribuida . La especificación EJB 2.0 abordó esta preocupación añadiendo el concepto de interfaces locales, que podían ser llamadas directamente sin penalizaciones de rendimiento por aplicaciones que no estaban distribuidas en múltiples servidores. [ 3 ]

La especificación EJB 3.0 ( JSR 220) supuso un cambio respecto a sus predecesoras, siguiendo un nuevo paradigma ligero. EJB 3.0 muestra la influencia de Spring en el uso de objetos Java simples y en su compatibilidad con la inyección de dependencias para simplificar la configuración e integración de sistemas heterogéneos. EJB 3.0, junto con la otra versión de EJB, puede integrarse con MuleSoft v4 mediante el conector EJB de PlektonLabs certificado por MuleSoft . Gavin King, creador de Hibernate , participó en el proceso de EJB 3.0 y es un firme defensor de la tecnología. Muchas características originales de Hibernate se incorporaron a la API de persistencia de Java , que sustituye a los beans de entidad en EJB 3.0. La especificación EJB 3.0 se basa en gran medida en el uso de anotaciones (una característica añadida al lenguaje Java con su versión 5.0) y en la convención sobre configuración para permitir un estilo de codificación mucho menos verboso. En consecuencia, en términos prácticos, EJB 3.0 es mucho más ligero y prácticamente una API completamente nueva, con poca semejanza a las especificaciones EJB anteriores.

Ejemplo

A continuación se muestra un ejemplo básico de cómo se ve un EJB en código:

@Stateless public class CustomerService {private EntityManager entityManager ; public void addCustomer ( Customer customer ) { entityManager.persist ( customer ) ; } }​

Lo anterior define una clase de servicio para persistir un objeto Customer (mediante mapeo objeto-relacional ). El EJB se encarga de gestionar el contexto de persistencia y el método addCustomer() es transaccional y seguro para subprocesos por defecto. Como se ha demostrado, el EJB se centra únicamente en la lógica de negocio y la persistencia, sin tener en cuenta ninguna presentación específica.

Dicho EJB puede ser utilizado por una clase, por ejemplo, en la capa web, de la siguiente manera:

@Named @RequestScoped public class CustomerBacking { @EJB private CustomerService customerService ;public String addCustomer ( Customer customer ) { customerService . addCustomer ( customer ); context . addMessage (...); // abreviado para mayor brevedad return "customer_overview" ; } }

Lo anterior define un backing bean de JavaServer Faces (JSF) en el que el EJB se inyecta mediante la @EJBanotación. Su método addCustomer suele estar vinculado a algún componente de la interfaz de usuario, como un botón. A diferencia del EJB, el backing bean no contiene lógica de negocio ni código de persistencia, sino que delega estas responsabilidades al EJB. El backing bean sí conoce una presentación específica, de la que el EJB no tenía conocimiento.

Tipos de Enterprise Beans

Un contenedor EJB alberga dos tipos principales de beans:

  • Los beans de sesión [ 4 ] pueden ser "con estado", "sin estado" o "singleton" y se puede acceder a ellos mediante una interfaz local (misma JVM) o remota (diferente JVM) o directamente sin interfaz, [ 5 ] en cuyo caso se aplican las semánticas locales. Todos los beans de sesión admiten la ejecución asíncrona [ 6 ] para todas las vistas (local/remota/sin interfaz).
  • Beans controlados por mensajes (MDB, también conocidos como Message Beans). Los MDB también admiten la ejecución asíncrona, pero a través de un paradigma de mensajería.

Semillas de sesión

Beans de sesión con estado

Los Stateful Session Beans [ 7 ] son ​​objetos de negocio con estado : es decir, registran con qué cliente que realiza la llamada están tratando durante una sesión y el historial de sus solicitudes, por lo que el acceso a la instancia del bean está estrictamente limitado a un solo cliente durante su ciclo de vida. [ 8 ] Si se intenta el acceso concurrente a un solo bean, el contenedor serializa esas solicitudes, pero mediante la @AccessTimeoutanotación el contenedor puede lanzar una excepción. [ 9 ] El estado de los Stateful Session Beans puede persistirse (pasivarse) automáticamente por el contenedor para liberar memoria después de que el cliente no haya accedido al bean durante algún tiempo. El contexto de persistencia extendido de JPA es compatible explícitamente con los Stateful Session Beans. [ 10 ]

Ejemplos
  • El proceso de pago en una tienda en línea podría ser gestionado por un bean de sesión con estado que usaría su estado para realizar un seguimiento de en qué punto del proceso de pago se encuentra el cliente, posiblemente manteniendo bloqueos sobre los artículos que el cliente está comprando (desde el punto de vista de la arquitectura del sistema, sería menos ideal que el cliente gestionara esos bloqueos).

Beans de sesión sin estado

Los beans de sesión sin estado [ 11 ] son ​​objetos de negocio que no tienen estado asociado. Sin embargo, el acceso a una única instancia de bean sigue estando limitado a un solo cliente a la vez; el acceso concurrente al bean está prohibido. [ 8 ] Si se intenta el acceso concurrente a un único bean, el contenedor simplemente enruta cada solicitud a una instancia diferente. [ 12 ] Esto hace que un bean de sesión sin estado sea automáticamente seguro para subprocesos. Las variables de instancia se pueden usar durante una única llamada a un método desde un cliente al bean, pero no se garantiza que el contenido de esas variables de instancia se conserve entre diferentes llamadas a métodos de clientes . Las instancias de beans de sesión sin estado normalmente se agrupan. Si un segundo cliente accede a un bean específico justo después de que haya finalizado una llamada a un método realizada por un primer cliente, podría obtener la misma instancia. La falta de sobrecarga para mantener una conversación con el cliente que realiza la llamada hace que consuman menos recursos que los beans con estado.

Ejemplos
  • El envío de un correo electrónico al servicio de atención al cliente podría ser gestionado por un bean sin estado, ya que se trata de una operación única y no forma parte de un proceso de varios pasos.
  • Un usuario de un sitio web que haga clic en un cuadro de "manténgame informado de futuras actualizaciones" puede activar una llamada a un método asíncrono del bean de sesión para agregar al usuario a una lista en la base de datos de la empresa (esta llamada es asíncrona porque el usuario no necesita esperar para ser informado de su éxito o fracaso).
  • La obtención de múltiples datos independientes para un sitio web, como una lista de productos y el historial del usuario actual, también puede gestionarse mediante métodos asíncronos de un bean de sesión (estas llamadas son asíncronas porque se ejecutan en paralelo , lo que potencialmente mejora el rendimiento). En este caso, el método asíncrono devolverá una instancia de Future .

Granos de grano Singleton Session

Los Singleton Session Beans [ 13 ] [ 14 ] son ​​objetos de negocio con un estado compartido global dentro de una JVM. El acceso concurrente a la única instancia del bean puede ser controlado por el contenedor (concurrencia gestionada por el contenedor, CMC) o por el propio bean (concurrencia gestionada por el bean, BMC). La CMC se puede ajustar mediante la @Lockanotación, que designa si se utilizará un bloqueo de lectura o un bloqueo de escritura para una llamada a método. Además, los Singleton Session Beans pueden solicitar explícitamente ser instanciados cuando se inicia el contenedor EJB, utilizando la @Startupanotación.

Ejemplos
  • La carga de una lista de precios diaria global que sea la misma para todos los usuarios podría realizarse con un bean de sesión singleton, ya que esto evitará que la aplicación tenga que realizar la misma consulta a la base de datos una y otra vez...

beans controlados por mensajes

Los Message Driven Beans [ 15 ] son ​​objetos de negocio cuya ejecución se activa mediante mensajes en lugar de llamadas a métodos. El Message Driven Bean se utiliza, entre otras cosas, para proporcionar una abstracción de alto nivel y fácil de usar para la especificación JMS ( Java Message Service ) de nivel inferior. Puede suscribirse a colas de mensajes JMS o temas de mensajes, lo que normalmente ocurre a través del atributo activationConfig de la @MessageDrivenanotación. Se añadieron en EJB para permitir el procesamiento basado en eventos. A diferencia de los beans de sesión, un MDB no tiene una vista de cliente (Local/Remoto/Sin interfaz), es decir,  los clientes no pueden buscar una instancia de MDB. Un MDB simplemente escucha cualquier mensaje entrante en, por ejemplo, una cola o tema JMS y los procesa automáticamente. La especificación Java EE solo requiere compatibilidad con JMS, [ 16 ] pero los Message Driven Beans pueden admitir otros protocolos de mensajería. [ 17 ] [ 18 ] Dichos protocolos pueden ser asíncronos, pero también síncronos. Dado que los beans de sesión también pueden ser síncronos o asíncronos, la principal diferencia entre los beans controlados por sesión y los controlados por mensajes no es la sincronicidad, sino la diferencia entre la llamada a métodos (orientados a objetos) y la mensajería .

Ejemplos
  • El envío de una actualización de configuración a varios nodos podría realizarse enviando un mensaje JMS a un "tema de mensajes" y podría ser gestionado por un Message Driven Bean que escuche este tema (aquí se utiliza el paradigma de mensajes, ya que el remitente no necesita saber el número de consumidores, su ubicación ni siquiera su tipo exacto).
  • El envío de una tarea a un clúster de trabajo puede realizarse enviando un mensaje JMS a una "cola de mensajes" y también podría ser gestionado por un Message Driven Bean, pero en este caso escuchando una cola (se utiliza el paradigma de mensajes y la cola, ya que al remitente no le importa qué trabajador ejecuta la tarea, pero sí necesita la garantía de que una tarea se ejecute solo una vez).
  • El procesamiento de eventos de temporización del planificador Quartz puede ser gestionado por un Message Driven Bean (MDB); cuando se activa un disparador de Quartz , el MDB se invoca automáticamente. Dado que Java EE no reconoce Quartz de forma predeterminada, se necesitaría un adaptador de recursos JCA y el MDB se anotaría con una referencia a este. [ 19 ]

Ejecución

Los EJB se implementan en un contenedor EJB, generalmente dentro de un servidor de aplicaciones . La especificación describe cómo un EJB interactúa con su contenedor y cómo el código cliente interactúa con la combinación contenedor/EJB. Las clases EJB utilizadas por las aplicaciones se incluyen en el javax.ejbpaquete. (El javax.ejb.spipaquete es una interfaz de proveedor de servicios utilizada únicamente por las implementaciones de contenedores EJB).

Los clientes de EJB no instancian esos beans directamente mediante el operador `new` de Java, sino que deben obtener una referencia a través del contenedor EJB. Esta referencia generalmente no es una referencia al bean de implementación en sí, sino a un proxy , que implementa dinámicamente la interfaz de negocio local o remota solicitada por el cliente, o un subtipo del bean real. El proxy se puede convertir directamente a la interfaz o al bean, respectivamente. Se dice que un cliente tiene una "vista" del EJB, y la interfaz local, la interfaz remota y el subtipo del bean corresponden, respectivamente, a la vista local, la vista remota y la vista sin interfaz.

Este proxy es necesario para que el contenedor EJB pueda proporcionar de forma transparente servicios transversales ( similares a AOP ) a un bean, como transacciones, seguridad, interceptaciones, inyecciones y acceso remoto. Por ejemplo, un cliente invoca un método en el proxy, que primero inicia una transacción con la ayuda del contenedor EJB y luego llama al método del bean. Cuando el método del bean finaliza, el proxy termina la transacción (confirmándola o revirtiéndola) y devuelve el control al cliente.

El contenedor EJB es responsable de garantizar que el código del cliente tenga derechos de acceso suficientes a un EJB. [ 20 ] Los aspectos de seguridad se pueden aplicar de forma declarativa a un EJB mediante anotaciones. [ 21 ]

Actas

Los contenedores EJB deben admitir tanto transacciones ACID gestionadas por el contenedor como transacciones gestionadas por el bean. [ 22 ]

Las transacciones gestionadas por el contenedor (CMT) están activas por defecto para las llamadas a beans de sesión. Es decir, no se necesita ninguna configuración explícita. Este comportamiento puede ajustarse de forma declarativa por el bean mediante anotaciones y, si es necesario, dicha configuración puede sobrescribirse posteriormente en el descriptor de despliegue. El ajuste incluye desactivar las transacciones para todo el bean o métodos específicos, o solicitar estrategias alternativas para la propagación de transacciones e iniciar o unirse a una transacción. Estas estrategias se ocupan principalmente de lo que debería ocurrir si una transacción está o no en curso en el momento en que se llama al bean. Se admiten las siguientes variaciones: [ 23 ] [ 24 ]

Alternativamente, el bean también puede declarar mediante una anotación que desea gestionar las transacciones programáticamente a través de la API JTA . Este modo de operación se denomina Transacciones Gestionadas por el Bean (BMT), ya que el propio bean gestiona la transacción en lugar del contenedor. [ 25 ]

Eventos

JMS ( Java Message Service ) se utiliza para enviar mensajes desde beans a clientes, permitiendo que estos últimos reciban mensajes asíncronos. Los MDB pueden utilizarse para recibir mensajes de clientes de forma asíncrona mediante una cola JMS o un tema.

Servicios de nombres y directorios

Como alternativa a la inyección, los clientes de un EJB pueden obtener una referencia al objeto proxy del bean de sesión (el stub del EJB) mediante la Interfaz de Nombres y Directorios de Java (JNDI) . Esta alternativa se puede utilizar en casos donde la inyección no está disponible, como en código no administrado o clientes Java SE remotos independientes, o cuando es necesario determinar programáticamente qué bean obtener.

Los nombres JNDI para los beans de sesión EJB son asignados por el contenedor EJB a través del siguiente esquema: [ 26 ] [ 27 ] [ 28 ]

(Las entradas entre corchetes indican partes opcionales)

Se puede obtener un único bean con cualquier nombre que coincida con los patrones anteriores, dependiendo de la "ubicación" del cliente. Los clientes que se encuentren en el mismo módulo que el bean requerido pueden usar el ámbito del módulo y ámbitos superiores; los clientes que se encuentren en la misma aplicación que el bean requerido pueden usar el ámbito de la aplicación y superiores, etc.

Por ejemplo, el código que se ejecuta en el mismo módulo que el bean CustomerService (como se muestra en el ejemplo anterior de este artículo) podría usar el siguiente código para obtener una referencia (local) al mismo:

CustomerServiceLocal customerService = ( CustomerServiceLocal ) new InitialContext (). lookup ( "java:module/CustomerService" );

Ejecución remota/distribuida

Para comunicarse con un cliente escrito en el lenguaje de programación Java, un bean de sesión puede exponer una vista remota a través de una interfaz anotada con @Remote. [ 29 ] Esto permite que esos beans sean llamados desde clientes en otras JVM que pueden estar ejecutándose en otros sistemas (desde el punto de vista del contenedor EJB, cualquier código en otra JVM es remoto).

Los beans de sesión sin estado y singleton también pueden exponer una "vista de cliente de servicio web" para la comunicación remota a través de WSDL y SOAP o XML simple. [ 30 ] [ 31 ] [ 32 ] Esto sigue las especificaciones JAX-RPC y JAX-WS . Sin embargo, se propone la eliminación futura del soporte para JAX-RPC. [ 33 ] Para admitir JAX-WS, el bean de sesión se anota con @WebService, y los métodos que se van a exponer remotamente con @WebMethod.

Aunque la especificación EJB no menciona la exposición como servicios web RESTful de ninguna manera y no tiene soporte explícito para esta forma de comunicación, la especificación JAX-RS sí admite explícitamente EJB. [ 34 ] Siguiendo la especificación JAX-RS, los beans de sesión Stateless y Singleton pueden declararse como recursos raíz a través de la @Pathanotación y los métodos de negocio EJB pueden asignarse a métodos de recursos a través de las anotaciones @GET, @PUTy . Sin embargo @POST, @DELETEesto no cuenta como una "vista de cliente de servicio web", que se utiliza exclusivamente para JAX-WS y JAX-RPC.

La comunicación mediante servicios web es habitual para clientes que no están escritos en el lenguaje de programación Java, pero también resulta conveniente para clientes Java que tienen dificultades para acceder al servidor EJB a través de un cortafuegos. Además, los clientes Java pueden utilizar la comunicación basada en servicios web para sortear los requisitos complejos y poco definidos de las denominadas "bibliotecas de cliente"; un conjunto de archivos JAR que un cliente Java debe tener en su classpath para comunicarse con el servidor EJB remoto. Estas bibliotecas de cliente pueden entrar en conflicto con bibliotecas que el cliente ya pueda tener (por ejemplo, si el propio cliente es también un servidor Java EE completo), y se considera que dicho conflicto es muy difícil o imposible de resolver. [ 35 ]

Legado

Interfaces de usuario e interfaz empresarial requerida

Con EJB 2.1 y versiones anteriores, cada EJB debía proporcionar una clase de implementación Java y dos interfaces Java. El contenedor EJB creaba instancias de la clase de implementación Java para proporcionar la implementación del EJB. Las interfaces Java eran utilizadas por el código cliente del EJB.

Descriptor de despliegue requerido

Con EJB 2.1 y versiones anteriores, la especificación EJB requería la presencia de un descriptor de despliegue. Esto era necesario para implementar un mecanismo que permitiera desplegar los EJB de forma consistente, independientemente de la plataforma EJB específica elegida. En el descriptor de despliegue debía especificarse información sobre cómo debía desplegarse el bean (como el nombre de las interfaces local o remota, si debía almacenarse en una base de datos y cómo, etc.).

El descriptor de despliegue es un documento XML que contiene una entrada para cada EJB que se va a desplegar. Este documento XML especifica la siguiente información para cada EJB:

  • Nombre de la interfaz de inicio
  • Clase Java para el Bean (objeto de negocio)
  • Interfaz Java para la interfaz Home
  • Interfaz Java para el objeto de negocio
  • Almacenamiento persistente (solo para Entity Beans)
  • Roles y permisos de seguridad
  • Con estado o sin estado (para beans de sesión)

Los contenedores EJB antiguos de muchos proveedores requerían más información de despliegue que la especificada en la especificación EJB. Esta información adicional debía proporcionarse en archivos XML independientes o en algún otro formato de archivo de configuración . Por lo general, el proveedor de la plataforma EJB ofrecía sus propias herramientas para leer este descriptor de despliegue y, posiblemente, generaba un conjunto de clases que implementaban las interfaces Home y Remote, ahora obsoletas.

Desde EJB 3.0 ( JSR 220 ), el descriptor XML se reemplaza por anotaciones Java definidas en la implementación del Enterprise Bean (a nivel de código fuente), aunque aún es posible usar un descriptor XML en lugar de (o además de) las anotaciones. Si se aplican un descriptor XML y anotaciones al mismo atributo dentro de un Enterprise Bean, la definición XML sobrescribe la anotación correspondiente a nivel de código fuente, aunque algunos elementos XML también pueden ser aditivos (por ejemplo, una propiedad activation-config-property en XML con un nombre diferente al ya definido mediante una @ActivationConfigPropertyanotación se agregará en lugar de reemplazar todas las propiedades existentes).

Variaciones de contenedores

A partir de EJB 3.1, la especificación EJB define dos variantes del contenedor EJB: una versión completa y una versión limitada. La versión limitada se ajusta a un subconjunto específico de la especificación llamado EJB 3.1 Lite [ 36 ] [ 37 ] y forma parte del perfil web de Java EE 6 (que a su vez es un subconjunto de la especificación completa de Java EE 6).

EJB 3.1 Lite excluye la compatibilidad con las siguientes características: [ 38 ]

  • Interfaces remotas
  • Interoperabilidad RMI-IIOP
  • Puntos finales de servicios web JAX-WS
  • Servicio de temporizador EJB ( @Schedule, @Timeout)
  • Invocaciones asíncronas de beans de sesión ( @Asynchronous)
  • beans controlados por mensajes

EJB 3.2 Lite excluye menos funcionalidades. En particular, ya no excluye @Asynchronousni @Schedule/ @Timeout, pero @Scheduleno admite el atributo "persistent" que sí admite la versión completa de EJB 3.2. La lista completa de funcionalidades excluidas para EJB 3.2 Lite es:

  • Interfaces remotas
  • Interoperabilidad RMI-IIOP
  • Puntos finales de servicios web JAX-WS
  • Temporizadores persistentes (atributo "persistente" activado @Schedule)
  • beans controlados por mensajes

Historial de versiones

EJB 4.0, versión final (22/05/2020)

Jakarta Enterprise Beans 4.0 , como parte de Jakarta EE 9, fue una versión de herramientas que principalmente movió los nombres de los paquetes de API del javax.ejbpaquete de nivel superior al jakarta.ejbpaquete de nivel superior. [ 39 ]

Otros cambios incluyeron la eliminación de API obsoletas que no tenía sentido trasladar al nuevo paquete de nivel superior y la eliminación de características que dependían de características que se eliminaron de Java o de otras partes de Jakarta EE 9. Se eliminaron las siguientes API:

  • métodos que dependían de java.security.Identitylos cuales se han eliminado de Java 14.
  • métodos que se basan en Jakarta XML RPC para reflejar la eliminación de XML RPC de la plataforma Jakarta EE 9.
  • Método obsoleto EJBContext.getEnvironment().
  • "Soporte para la interoperabilidad distribuida" para reflejar la eliminación de CORBA de Java 11 y la plataforma Jakarta EE 9.

Otros cambios menores incluyen marcar el grupo de API de Enterprise Beans 2.x como "Opcional" y hacer que la Scheduleanotación sea repetible.

EJB 3.2.6, versión final (23/08/2019)

Jakarta Enterprise Beans 3.2 , como parte de Jakarta EE 8, y a pesar de seguir utilizando la abreviatura "EJB", este conjunto de API ha sido renombrado oficialmente a "Jakarta Enterprise Beans" por la Fundación Eclipse para no infringir la marca registrada "Java" de Oracle.

EJB 3.2, versión final (28/05/2013)

JSR 345. Enterprise JavaBeans 3.2 fue una versión relativamente menor que principalmente contenía aclaraciones de la especificación y eliminó algunas restricciones impuestas por la misma, pero que con el tiempo pareció no tener ninguna utilidad real. También se exigió que algunas características completas de EJB existentes estuvieran en EJB 3 lite, y la funcionalidad que se propuso eliminar en EJB 3.1 se eliminó (se hizo opcional). [ 40 ] [ 41 ]

Se añadieron las siguientes características:

  • La pasivación de un bean de sesión con estado se puede desactivar mediante un atributo en @Statefulla anotación (passivationCapable = false).
  • TimerService puede recuperar todos los temporizadores activos en el mismo módulo EJB (anteriormente solo podía recuperar los temporizadores del bean en el que se llamaba a TimerService).
  • Los métodos del ciclo de vida (por ejemplo @PostConstruct) pueden ser transaccionales para beans de sesión con estado utilizando la @TransactionAttributeanotación existente.
  • Interfaz de cierre automático implementada por un contenedor integrable.

EJB 3.1, versión final (10/12/2009)

JSR 318. El propósito de la especificación Enterprise JavaBeans 3.1 es simplificar aún más la arquitectura EJB reduciendo su complejidad desde el punto de vista del desarrollador, al tiempo que se añade nueva funcionalidad en respuesta a las necesidades de la comunidad:

  • Vista local sin interfaz (Vista sin interfaz)
  • Empaquetado .war de componentes EJB
  • EJB Lite: definición de un subconjunto de EJB
  • Nombres JNDI globales de EJB portátiles
  • Singletons (Granos de sesión individuales)
  • Eventos de inicialización y cierre de la aplicación
  • Mejoras en el servicio de temporizador EJB
  • Asincronía simple ( @Asynchronouspara beans de sesión)

EJB 3.0, versión final (11/05/2006)

JSR 220 - Cambios importantes : Esta versión simplificó enormemente la escritura de EJBs, utilizando "anotaciones" en lugar de los complejos "descriptores de despliegue" empleados en la versión 2.x. El uso de interfaces home y remote, así como del archivo ejb-jar.xml, ya no era necesario en esta versión, pues se sustituyó por una interfaz de negocio y un bean que implementa dicha interfaz.

EJB 2.1, versión final (24/11/2003)

JSR 153 - Cambios importantes :

  • Compatibilidad con servicios web (novedad): los beans de sesión sin estado pueden invocarse a través de SOAP / HTTP . Además, un EJB puede acceder fácilmente a un servicio web mediante la nueva referencia de servicio.
  • Servicio de temporizador EJB (nuevo): Mecanismo basado en eventos para invocar EJBs en momentos específicos.
  • Los beans controlados por mensajes aceptan mensajes de fuentes distintas a JMS .
  • Se han añadido destinos de mensajes (la misma idea que las referencias EJB, las referencias de recursos, etc.).
  • Nuevas funcionalidades del lenguaje de consulta EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT y MOD.
  • El esquema XML se utiliza para especificar descriptores de despliegue, reemplazando a los DTD.

EJB 2.0, versión final (22/08/2001)

JSR 19 - Cambios importantes : Objetivos generales :

  • La arquitectura de componentes estándar para construir aplicaciones empresariales distribuidas orientadas a objetos en Java .
  • Permitir la creación de aplicaciones distribuidas mediante la combinación de componentes desarrollados con herramientas de diferentes proveedores .
  • Facilitar la escritura de aplicaciones (empresariales): Los desarrolladores de aplicaciones no tendrán que comprender los detalles de bajo nivel de la gestión de transacciones y estados, la multihilo, la agrupación de conexiones y otras API complejas de bajo nivel.
  • Seguirá la filosofía de Java de " Escribir una vez, ejecutar en cualquier lugar " . Un Enterprise Bean se puede desarrollar una vez y luego implementar en múltiples plataformas sin necesidad de recompilación ni modificación del código fuente.
  • Abordar los aspectos de desarrollo, implementación y ejecución del ciclo de vida de una aplicación empresarial.
  • Definir los contratos que permitan a las herramientas de múltiples proveedores desarrollar e implementar componentes que puedan interoperar en tiempo de ejecución.
  • Debe ser compatible con las plataformas de servidor existentes. Los proveedores podrán ampliar sus productos actuales para que sean compatibles con EJB.
  • Debe ser compatible con otras API de Java .
  • Proporcionar interoperabilidad entre los beans empresariales y los componentes Java EE, así como con las aplicaciones de lenguajes de programación que no sean Java.
  • Debe ser compatible con los protocolos CORBA (RMI-IIOP).

EJB 1.1, versión final (17/12/1999)

Cambios importantes :

  • descriptores de despliegue XML
  • Contextos JNDI predeterminados
  • RMI sobre IIOP
  • Seguridad: basada en roles, no en métodos.
  • Compatibilidad con Entity Bean: obligatoria, no opcional.

Objetivos para la versión 1.1:

  • Proporcionar un mejor soporte para el ensamblaje y la implementación de aplicaciones.
  • Especifique con mayor detalle las responsabilidades de cada rol de EJB.

EJB 1.0 (24-03-1998)

Anunciado en JavaOne 1998 , [ 42 ] Tercera conferencia de desarrolladores de Java de Sun (del 24 al 27 de marzo) Objetivos para la versión 1.0:

  • Se definieron los distintos "Roles EJB" que asume la arquitectura del componente.
  • Se definió la vista del cliente de los Enterprise Beans.
  • Definió la vista del desarrollador de Enterprise Bean.
  • Se definieron las responsabilidades de un proveedor de contenedores EJB y un proveedor de servidores; juntos, estos conforman un sistema que admite el despliegue y la ejecución de beans empresariales.

Referencias

  1. ↑ "Especificación de Jakarta Enterprise Beans" . jakarta.ee . Consultado el 6 de abril de 2025 .
  2. ↑ Diseño y desarrollo de J2EE , 2002 Wrox Press Ltd., pág. 5.
  3. ↑ Diseño y desarrollo de J2EE , 2002, Wrox Press Ltd., pág. 19.
  4. ↑ JSR 318, 4.1, http://jcp.org/en/jsr/detail?id=318
  5. ↑ "Interfaces comerciales locales opcionales (Blog de Ken Saks)" . Archivado del original el 19 de noviembre de 2015. Consultado el 1 de junio de 2016 .
  6. ↑ JSR 318, 4.5, http://jcp.org/en/jsr/detail?id=318
  7. ↑ JSR 318, 4.6, http://jcp.org/en/jsr/detail?id=318
  8. 1 2 JSR 318, 4.10.3, http://jcp.org/en/jsr/detail?id=318
  9. ↑ JSR 318, 4.3.14, 21.4.2, http://jcp.org/en/jsr/detail?id=318
  10. ↑ "Contexto de persistencia en Stateful" . Archivado del original el 16 de marzo de 2008. Recuperado el 1 de junio de 2016 .
  11. ↑ JSR 318, 4.7, http://jcp.org/en/jsr/detail?id=318
  12. ↑ JSR 318, 4.3.14, http://jcp.org/en/jsr/detail?id=318
  13. ↑ JSR 318, 4.8, http://jcp.org/en/jsr/detail?id=318
  14. ↑ "Singleton EJB" . Openejb.apache.org. Archivado del original el 24 de mayo de 2010. Consultado el 17 de junio de 2012 .
  15. ↑ JSR 318, 5.1, http://jcp.org/en/jsr/detail?id=318
  16. ↑ JSR 318, 5.7.2, http://jcp.org/en/jsr/detail?id=318
  17. ↑ JSR 318, 5.4.2, http://jcp.org/en/jsr/detail?id=318
  18. ↑ JSR 318, 5.6.2, http://jcp.org/en/jsr/detail?id=318
  19. ↑ Desarrollando Quartz MDB (29 de abril de 2009). "Desarrollando Quartz MDB" . Mastertheboss.com . Consultado el 17 de junio de 2012 .
  20. ↑ JSR 318, Capítulo 17, http://jcp.org/en/jsr/detail?id=318
  21. ↑ "Anotaciones de seguridad" . Openejb.apache.org . Consultado el 17 de junio de 2012 .
  22. ↑ JSR 318, Capítulo 13, http://jcp.org/en/jsr/detail?id=318
  23. ↑ JSR 318, 13.6.2, http://jcp.org/en/jsr/detail?id=318
  24. ↑ "Anotaciones de transacciones" . Openejb.apache.org . Consultado el 17 de junio de 2012 .
  25. ↑ JSR 318, 13.3.6, http://jcp.org/en/jsr/detail?id=318
  26. ↑ JSR 318, 4.4, http://jcp.org/en/jsr/detail?id=318
  27. ↑ "Nombres JNDI globales portátiles (MaheshKannan)" . Blogs.oracle.com. Archivado del original el 20 de junio de 2011. Consultado el 17 de junio de 2012 .
  28. ↑ "Nombres JNDI globales portátiles (Blog de Ken Saks)" . Blogs.oracle.com. Archivado del original el 29/12/2011 . Consultado el 17/06/2012 .
  29. ↑ JSR 318, Capítulo 15, http://jcp.org/en/jsr/detail?id=318
  30. ↑ JSR 318, 2.6, http://jcp.org/en/jsr/detail?id=318
  31. ↑ JSR 318, 3.2.4, http://jcp.org/en/jsr/detail?id=318
  32. ↑ JSR 318, 4.3.6, http://jcp.org/en/jsr/detail?id=318
  33. ↑ JSR 318, 2.7, http://jcp.org/en/jsr/detail?id=318
  34. ↑ JSR 311, Capítulo 6.2, http://jcp.org/en/jsr/detail?id=311
  35. ↑ "Comunicación entre JBoss AS 5 y JBoss AS 6 | JBoss AS | Comunidad JBoss" . Community.jboss.org . Consultado el 17 de junio de 2012 .
  36. ↑ "Perfil web de Resin Java EE 6 - Resin 3.0" . Wiki.caucho.com. 12 de febrero de 2010. Archivado del original el 23 de marzo de 2012. Consultado el 17 de junio de 2012 .
  37. ↑ JSR 318, 21.1 EJB 3.1 Lite, http://jcp.org/en/jsr/detail?id=318
  38. ↑ JSR 318, Tabla 27 - Contenido requerido de la API EJB 3.1 Lite y Full EJB 3.1, http://jcp.org/en/jsr/detail?id=318
  39. ↑ "Novedades de esta versión" . Jakarta Enterprise Beans, características principales . Jakarta Enterprise Beans 4.0. Jakarta EE . 5 de noviembre de 2020. Consultado el 5 de diciembre de 2020 .
  40. ↑ "¿Qué hay de nuevo en EJB 3.2 ? - ¡Java EE 7 sigue avanzando! (Arun Gupta, Miles to go ...)" . Consultado el 1 de junio de 2016 . 
  41. ↑ "Si no sabías lo que viene en EJB 3.2... (Blog de Marina Vatkina)" . Archivado del original el 4 de marzo de 2016. Consultado el 1 de junio de 2016 .
  42. ↑ "Informe de viaje a la conferencia JavaOne: Tecnología Enterprise JavaBeans: Desarrollo e implementación de aplicaciones empresariales como componentes" . Alephnaught.com . Consultado el 17 de junio de 2012 .
  • Sitio web oficialEdita esto en Wikidata
  • Javadocs de la API de Java EE 8
  • Especificación de Jakarta Enterprise Beans
  • Documentación Javadoc de la API EJB 3.0
  • Especificación EJB 3.0
  • Tutorial de EJB 3.0 de Sun
  • Glosario de EJB (3.0)
  • Preguntas frecuentes de EJB
  • JSR 345 (EJB 3.2)
  • JSR 318 (EJB 3.1)
  • JSR 220 (EJB 3.0)
  • JSR 153 (EJB 2.1)
  • JSR 19 (EJB 2.0)
  • "Trabajando con beans controlados por mensajes" de EJB3 en acción, segunda edición.
  • El cliente invoca un EJB
Lecturas relacionadas
6 articulos
Lista de API de JavaLista de API de JavaHay dos tipos de interfaces de programación de aplicaciones (API) del lenguaje de programación Java :Software empresarialEl software empresarial , también conocido como software de aplicación empresarial ( EAS ), es un software informático que se utiliza para satisfac...Componente de softwareComponente de softwareUn componente de software es una unidad modular de software que encapsula una funcionalidad específica. [ 1 ] Las características deseadas de un co...iconoModelo cliente-servidorEl modelo cliente-servidor es un patrón de mensajería en una estructura de aplicación distribuida que divide las tareas o cargas de trabajo entre l...Encapsulación (programación informática)Encapsulación (programación informática)En los sistemas de software, la encapsulación se refiere a la agrupación de datos con los mecanismos o métodos que operan sobre ellos. También pued...Lógica empresarialLógica empresarialEn el software informático , la lógica empresarial o lógica de dominio es la parte del programa que codifica las reglas empresariales del mundo rea...