stringtranslate.com

Frijoles empresariales de Jakarta

Jakarta Enterprise Beans ( EJB ; anteriormente Enterprise JavaBeans ) es una de las varias 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 empresarial de una aplicación. Un contenedor web EJB proporciona un entorno de ejecución para componentes de software relacionados con la web, incluida la seguridad informática , la gestión del ciclo de vida de los servlets de Java , el procesamiento de transacciones y otros servicios web . La especificación EJB es un subconjunto de la especificación Java EE . [1]

Especificación

La especificación EJB fue desarrollada originalmente en 1997 por IBM y luego 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 empresarial del lado del servidor (también llamado " back-end ") que se encuentra normalmente en las aplicaciones empresariales (a diferencia del software de interfaz de usuario "front-end" ). Este tipo de software aborda los mismos tipos de problemas y los programadores suelen volver a implementar las soluciones a estos problemas de forma repetida. Jakarta Enterprise Beans está pensado para gestionar problemas tan comunes como la persistencia , la integridad transaccional y la seguridad de forma estándar, lo que deja a los programadores libres para concentrarse 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 de Jakarta Enterprise Beans define las funciones que desempeñan el contenedor EJB y los EJB, así como la forma de implementar los EJB en un contenedor. Tenga en cuenta que la especificación de EJB no detalla cómo un servidor de aplicaciones proporciona persistencia (una tarea delegada a la especificación JPA), sino que detalla cómo la lógica empresarial 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 empresarial implicaba una reducción del rendimiento. Esto se debe a que la especificación original solo permitía la invocación de métodos remotos a través de CORBA (y otros protocolos opcionales), aunque la gran mayoría de las aplicaciones empresariales en realidad no requieren esta funcionalidad de computación distribuida . La especificación EJB 2.0 abordó este problema añadiendo el concepto de interfaces locales que podían ser invocadas directamente sin reducción del rendimiento por aplicaciones que no estuvieran distribuidas en varios servidores. [3]

La especificación EJB 3.0 ( JSR 220) fue un cambio con respecto a sus predecesoras, siguiendo un nuevo paradigma de peso ligero. EJB 3.0 muestra una influencia de Spring en su uso de objetos Java simples y su soporte para inyección de dependencia para simplificar la configuración e integración de sistemas heterogéneos. EJB 3.0 junto con la otra versión de EJB se puede integrar con MuleSoft -v4 utilizando el conector EJB de PlektonLabs certificado por MuleSoft. Gavin King, el creador de Hibernate , participó en el proceso EJB 3.0 y es un defensor abierto de la tecnología. Muchas características originalmente en Hibernate se incorporaron en la API de persistencia de Java , el reemplazo de 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 agregada al lenguaje Java con su lanzamiento 5.0) y la convención sobre la 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 liviano y casi una API completamente nueva, que tiene poca semejanza con las especificaciones EJB anteriores. [ cita requerida ]

Ejemplo

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

@Stateless clase pública CustomerService {       EntityManager privado entityManager ; public void addCustomer ( Customer customer ) { entityManager . persist ( customer ); } }

Lo anterior define una clase de servicio para la persistencia de un objeto de cliente (a través de un mapeo O/R ). El EJB se encarga de administrar el contexto de persistencia y el método addCustomer() es transaccional y seguro para subprocesos de manera predeterminada. Como se demostró, el EJB se enfoca solo en la lógica empresarial y la persistencia y no sabe nada sobre ninguna presentación en particular.

Una clase puede utilizar un EJB de este tipo, por ejemplo en la capa web, de la siguiente manera:

@Named @RequestScoped clase pública CustomerBacking { @EJB servicioAlienteprivado servicioAliente ;​         public String addCustomer ( Customer customer ) { customerService.addCustomer ( customer ) ; context.addMessage (...); // abreviado para abreviar return " customer_overview" ; } }

Lo anterior define un bean de respaldo JavaServer Faces (JSF) en el que se inyecta el EJB por medio de la @EJBanotación. Su método addCustomer normalmente está vinculado a algún componente de la interfaz de usuario, como un botón. A diferencia del EJB, el bean de respaldo no contiene ninguna lógica empresarial ni código de persistencia, sino que delega dichas preocupaciones al EJB. El bean de respaldo sí conoce una presentación en particular, de la que el EJB no tenía conocimiento.

Tipos de Enterprise Beans

Un contenedor EJB contiene dos tipos principales de beans:

Beans de sesión

Beans de sesión con estado

Los Stateful Session Beans [7] son ​​objetos de negocio que tienen estado : es decir, mantienen un registro de con qué cliente que realiza la llamada están tratando a lo largo de una sesión y del historial de sus solicitudes, y por lo tanto el acceso a la instancia del bean está estrictamente limitado a un solo cliente durante su vida útil. [8] Si se intenta el acceso simultáneo a un solo bean de todos modos, el contenedor serializa esas solicitudes, pero a través de la @AccessTimeoutanotación el contenedor puede en su lugar lanzar una excepción. [9] El estado de los beans de sesión con estado puede ser persistido (pasivado) 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 explícitamente compatible con los Stateful Session Beans. [10]

Ejemplos

Beans de sesión sin estado

Los beans de sesión sin estado [11] son ​​objetos comerciales que no tienen un estado asociado a ellos. Sin embargo, el acceso a una única instancia de bean todavía está limitado a un solo cliente a la vez, el acceso simultáneo al bean está prohibido. [8] Si se intenta el acceso simultáneo 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 utilizar durante una única llamada de método desde un cliente al bean, pero no se garantiza que el contenido de esas variables de instancia se conserve en diferentes llamadas de método de cliente . 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 de 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

Beans de sesión Singleton

Los Singleton Session Beans [13] [14] son ​​objetos comerciales que tienen un estado compartido global dentro de una JVM. El acceso simultáneo a la única instancia de bean puede ser controlado por el contenedor (Concurrencia administrada por contenedor, CMC) o por el bean mismo (Concurrencia administrada por bean, BMC). La CMC puede ajustarse utilizando la @Lockanotación, que designa si se utilizará un bloqueo de lectura o un bloqueo de escritura para una llamada de 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

Beans controlados por mensajes

Los Message Driven Beans [15] son ​​objetos de negocios cuya ejecución es activada por mensajes en lugar de por llamadas de método. El Message Driven Bean se utiliza, entre otras cosas, para proporcionar una abstracción de alto nivel y facilidad de uso 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 agregaron en EJB para permitir el procesamiento impulsado por eventos. A diferencia de los beans de sesión, un MDB no tiene una vista de cliente (local/remota/sin interfaz), es decir, los clientes no pueden buscar una instancia MDB. Un MDB solo escucha cualquier mensaje entrante en, por ejemplo, una cola o tema JMS y los procesa automáticamente. La especificación Java EE solo requiere soporte JMS, [16] pero los Message Driven Beans pueden admitir otros protocolos de mensajería. [17] [18] Dichos protocolos pueden ser asincrónicos pero también pueden ser sincrónicos. Dado que los beans de sesión también pueden ser sincrónicos o asincrónicos, 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

Ejecución

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

Los clientes de los EJB no instancian esos beans directamente a través del operador new de Java, sino que deben obtener una referencia a través del contenedor EJB. Esta referencia no suele ser una referencia al bean de implementación en sí, sino a un proxy , que implementa dinámicamente la interfaz empresarial local o remota que solicitó el cliente o un subtipo del bean real. El proxy puede entonces convertirse directamente en la interfaz o el bean respectivamente. Se dice que un cliente tiene una "vista" en el EJB, y la interfaz local, la interfaz remota y el subtipo de bean en sí corresponden respectivamente a la vista local, la vista remota y la vista sin interfaz.

Este proxy es necesario para dar al contenedor EJB la oportunidad de proporcionar de forma transparente servicios transversales ( similares a AOP ) a un bean, como transacciones, seguridad, intercepciones, inyecciones y comunicación remota. Como ejemplo, un cliente invoca un método en un proxy, que primero iniciará una transacción con la ayuda del contenedor EJB y luego llamará al método del bean real. Cuando el método del bean regresa, el proxy finaliza la transacción (es decir, confirmándola o haciendo una reversión) y transfiere el control nuevamente al cliente.

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

Actas

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

Las transacciones administradas por contenedor (CMT) están activas de forma predeterminada para las llamadas a los beans de sesión. Es decir, no se necesita ninguna configuración explícita. Este comportamiento puede ajustarse de forma declarativa mediante anotaciones por parte del bean y, si es necesario, dicha configuración puede anularse posteriormente en el descriptor de implementación. El ajuste incluye la desactivación de transacciones para todo el bean o métodos específicos, o la solicitud de estrategias alternativas para la propagación de transacciones y el inicio o la incorporación de una transacción. Dichas estrategias se ocupan principalmente de lo que debería suceder 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]

Como alternativa, el bean también puede declarar mediante una anotación que desea gestionar transacciones de forma programática a través de la API JTA . Este modo de funcionamiento se denomina Transacciones gestionadas por 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, para permitir que estos reciban mensajes asincrónicos desde estos beans. Los MDB se pueden utilizar para recibir mensajes de clientes de forma asincrónica 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 Java Naming and Directory Interface (JNDI) . Esta alternativa se puede utilizar en casos en los que la inyección no está disponible, como en código no administrado o clientes remotos independientes de Java SE, 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 solo bean con cualquier nombre que coincida con los patrones anteriores, según la "ubicación" del cliente. Los clientes que se encuentran en el mismo módulo que el bean requerido pueden usar el ámbito del módulo y ámbitos mayores, los clientes que se encuentran en la misma aplicación que el bean requerido pueden usar el ámbito de la aplicación y ámbitos mayores, etc.

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

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 se llamen 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 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 eliminar la compatibilidad con JAX-RPC en el futuro. [33] Para admitir JAX-WS, el bean de sesión se anota con @WebService, y los métodos que se van a exponer de forma remota 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 se pueden declarar como recursos raíz a través de la @Pathanotación y los métodos comerciales EJB se pueden mapear 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 usa exclusivamente para JAX-WS y JAX-RPC.

La comunicación a través de servicios web es típica para clientes que no están escritos en el lenguaje de programación Java, pero también es conveniente para clientes Java que tienen problemas para llegar al servidor EJB a través de un cortafuegos. Además, los clientes Java pueden utilizar la comunicación basada en servicios web para eludir los requisitos arcanos y mal definidos de las denominadas "bibliotecas de cliente"; un conjunto de archivos jar que un cliente Java debe tener en su ruta de clases 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 también es un servidor Java EE completo) y se considera que un conflicto de este tipo es muy difícil o imposible de resolver. [35]

Legado

Interfaces de inicio e interfaz empresarial requerida

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

Descriptor de implementación requerido

Con EJB 2.1 y versiones anteriores, la especificación de EJB requería que existiera un descriptor de implementación. Esto era necesario para implementar un mecanismo que permitiera que los EJB se implementaran de manera consistente independientemente de la plataforma EJB específica que se eligiera. La información sobre cómo se debía implementar el bean (como el nombre de las interfaces de inicio o remotas, si se debía almacenar el bean en una base de datos y cómo hacerlo, etc.) debía especificarse en el descriptor de implementación.

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

Los contenedores EJB antiguos de muchos proveedores requerían más información de implementación que la que se proporcionaba en la especificación EJB. Requerían la información adicional como archivos XML separados o algún otro formato de archivo de configuración. Un proveedor de plataforma EJB generalmente proporcionaba sus propias herramientas que leían este descriptor de implementación y posiblemente generaban 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 establecidas en la implementación del Enterprise Bean (a nivel de fuente), aunque todavía es posible utilizar un descriptor XML en lugar de (o además de) las anotaciones. Si un descriptor XML y anotaciones se aplican al mismo atributo dentro de un Enterprise Bean, la definición XML anula la anotación de nivel de fuente correspondiente, aunque algunos elementos XML también pueden ser aditivos (por ejemplo, @ActivationConfigPropertyse agregará una propiedad de configuración de activación en XML con un nombre diferente al que ya se definió mediante una anotación 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 adhiere a un subconjunto adecuado de la especificación denominada EJB 3.1 Lite [36] [37] y es parte del perfil web de Java EE 6 (que es a su vez un subconjunto de la especificación completa de Java EE 6).

EJB 3.1 Lite excluye el soporte para las siguientes características: [38]

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

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ían sentido trasladar al nuevo paquete de nivel superior y la eliminación de funciones que dependían de funciones que se eliminaron de Java o de otras partes de Jakarta EE 9. Se eliminaron las siguientes API:

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 que todavía se utiliza la abreviatura "EJB", este conjunto de API ha sido renombrado oficialmente a "Jakarta Enterprise Beans" por la Fundación Eclipse para no pisotear 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 contenía principalmente aclaraciones de especificaciones y eliminó algunas restricciones impuestas por la especificación, pero con el tiempo pareció no tener un propósito real. También se exigió que algunas características EJB completas existentes estuvieran en EJB 3 lite y la funcionalidad que se propuso eliminar en EJB 3.1 efectivamente se eliminó (se hizo opcional). [40] [41]

Se agregaron las siguientes características:

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 al reducir su complejidad desde el punto de vista del desarrollador, al mismo tiempo que agrega nueva funcionalidad en respuesta a las necesidades de la comunidad:

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

JSR 220 - Cambios importantes : Esta versión facilitó mucho la escritura de EJB, utilizando "anotaciones" en lugar de los complejos "descriptores de implementación" utilizados en la versión 2.x. El uso de interfaces de inicio y remotas y el archivo ejb-jar.xml ya no eran necesarios en esta versión, ya que se reemplazaron con una interfaz empresarial y un bean que implementa la interfaz.

EJB 2.1, versión final (24 de noviembre de 2003)

JSR 153 – Cambios importantes :

EJB 2.0, versión final (22 de agosto de 2001)

JSR 19 - Cambios principales : Objetivos generales :

EJB 1.1, versión final (17 de diciembre de 1999)

Cambios importantes :

Objetivos para la versión 1.1:

EJB 1.0 (24 de marzo de 1998)

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

Referencias

  1. ^ "Tecnología Enterprise JavaBeans". www.oracle.com . Consultado el 15 de diciembre de 2016 .
  2. ^ Diseño y desarrollo J2EE , 2002 Wrox Press Ltd., pág. 5.
  3. ^ Diseño y desarrollo J2EE , 2002, Wrox Press Ltd., pág. 19.
  4. ^ JSR 318, 4.1, http://jcp.org/en/jsr/detail?id=318
  5. ^ "Interfaces empresariales locales opcionales (blog de Ken Saks)". Archivado desde el 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. ^ ab 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 estado". Archivado desde el original el 16 de marzo de 2008. Consultado 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. ^ "EJB Singleton". Openejb.apache.org . 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. ^ Desarrollo de Quartz MDB (29 de abril de 2009). "Desarrollo de 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 desde el 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 desde el original el 29 de diciembre de 2011. Consultado el 17 de junio de 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 desde el 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: Contenidos requeridos 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, funciones principales. Jakarta Enterprise Beans 4.0. Jakarta EE . 5 de noviembre de 2020. Consultado el 5 de diciembre de 2020 .
  40. ^ "¿Qué novedades hay en EJB 3.2? - ¡Java EE 7 avanza a paso firme! (Arun Gupta, Miles to go ...)" . Consultado el 1 de junio de 2016 .
  41. ^ "Si no sabías lo que viene en EJB 3.2... (Weblog de Marina Vatkina)". Archivado desde el 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 .

Enlaces externos