DEPARTAMENTO DE SISTEMAS Enterprise Java Bean 3 (EJB 3) Agenda DEPARTAMENTO DE SISTEMAS • Introducción • EJB 3 o o o Características Beneficios Arquitectura EJB 3 • Session Bean o o o Stateless Session Bean Stateful Session Bean Localización Session Bean • Desarrollo por Componentes Introducción DEPARTAMENTO DE SISTEMAS Introducción DEPARTAMENTO DE SISTEMAS • Contenedor EJB 3 o o o o o o Soporta concurrencia Provee pools para administrar varias instancias de componentes, Balanceo de carga y clustering Provee (JNDI), para acceder a los EJB o a otros recursos Soporta Java RMI-IIOP (Remote Method Invocation run over Internet InterOrb Protocol), el cual permite el acceso remoto de un cliente a un session bean Soporta mensajería que proveen los message-driven beans Tomado de: EJB 3 in action Agenda DEPARTAMENTO DE SISTEMAS • Introducción • EJB 3 o o o Características Beneficios Arquitectura EJB 3 • Session Bean o o o Stateless Session Bean Stateful Session Bean Localización Session Bean • Desarrollo por Componentes EJB DEPARTAMENTO DE SISTEMAS “Enterprise JavaBeans is an architecture for componentbased transaction-oriented enterprise applications.” (JSR 220: Enterprise JavaBeansTM,Version 3.0) “Un enterprise bean es un componente de lado del servidor que encapsula la lógica del negocio de una aplicación”.(Java EE 5Tutorial) “Es una plataforma para construir aplicaciones de negocios portables, reutilizables y escalables usando lenguaje de programación JAVA” (EJB 3 In action, Debu Panda) Características DEPARTAMENTO DE SISTEMAS • Contienen lógica de negocio, que opera sobre los datos de la empresa • Las instancias de un enterprise bean son administradas en tiempo de ejecución por un contenedor • Los servicios como transacción y seguridad, pueden ser especificados junto con la lógica del negocio de la clase enterprise bean en la forma de anotaciones, o en un descriptor de despliegue XML • El acceso del cliente es mediado por el contenedor en el cual el enterprise bean es desplegado. Este acceso es transparente para el cliente • El contenedor asegura que los beans y sus clientes pueden ser desplegados en múltiples ambientes de ejecución sin recompilación • El estándar EJB 3 es desarrollado por Java Community Process (JCP) Beneficios DEPARTAMENTO DE SISTEMAS • Simplifican desarrollo, el contenedor EJB es responsable de la administración de transacciones y autorizaciones de seguridad. • La lógica del negocio reside en los enterprise beans y no en el lado del cliente, permitiendo que el desarrollo del lado del cliente esté desacoplado de la lógica del negocio. • Los enterprise bean son componentes portables, reutilizables y pueden ser desplegados en servidores que usen los estándares del API JEE. • Pueden residir en diferentes servidores y pueden ser invocados por un cliente remoto. Beneficios DEPARTAMENTO DE SISTEMAS • Se deben utilizar en los siguientes casos: o Aplicaciones que deben ser escalables, esto implica distribución de componentes a través de múltiples máquinas o Aseguramiento de integridad de los datos de las transacciones. Los enterprise beans soportan transacciones y el mecanismo que administra el acceso concurrente de objetos compartidos o Muti-usuarios locales y remotos EJBs DEPARTAMENTO DE SISTEMAS • Tipos de componentes EJB 3 o o o Session beans Message-driven beans Entity bean Tomado de: EJB 3 in action Estructura Enterprise Java Bean DEPARTAMENTO DE SISTEMAS • • Una aplicación EJB debe contener: o Componentes enterprise bean o Interfaces que definen los métodos que implementan las componentes o Clases helper: clases utilitarias requeridas por los enterprise bean Se empaqueta en un archivo EJB.jar, son portables y pueden ser empaquetados en un archivo EAR. Tomado del libro JavaEE Tutorial Agenda DEPARTAMENTO DE SISTEMAS • Introducción • EJB 3 o o o Características Beneficios Arquitectura EJB 3 • Session Bean o o o Stateless Session Bean Stateful Session Bean Localización Session Bean • Desarrollo por Componentes Session Bean DEPARTAMENTO DE SISTEMAS • Que son los componentes session bean? “Son una tecnología EJB que permiten encapsular procesos de negocio” (EJB 3 developer guide) Cliente Web, local o remoto Contenedor EJB 3 Interfaz Clase Bean Provee todas las definiciones de los métodos Provee implementaciones de los métodos Implementa Local Remota Session Bean DEPARTAMENTO DE SISTEMAS • Características: o o o o o o Vida corta, si el servidor falla la sesión se pierde No manejan persistencia No es compartido entre clientes Pueden actualizar y crear entidades, estas últimas son persistentes Un cliente (WEB como JSP o servlet y un cliente aplicación standalone) interactúa con un session bean a través de la invocación de sus métodos (esta invocación se llama sesión) Un componente session bean es un POJO anotado. Tomado de: EJB 3 in action Session Bean DEPARTAMENTO DE SISTEMAS • Un session bean está compuesto por una o más interfaces y una clase de implementación. • Un cliente puede acceder a un session bean solamente a través de métodos definidos en la interfaz del bean. • La interfaz de define la vista al cliente de un bean. • Un Session Bean puede ser invocado a través de RMI a través de una interfaz: o Remota o Local Session Bean DEPARTAMENTO DE SISTEMAS • Un cliente remoto invoca una interfaz remota de un session bean Tomado del libro EJB 3 Developer Guide Session Bean DEPARTAMENTO DE SISTEMAS • El cliente remoto puede ejecutarse en una máquina diferente y una JVM diferente al enterprise bean que accede. • Un cliente remoto puede ser un componente web, una aplicación cliente u otro enterprise bean. • Para el cliente remoto la ubicación del enterprise bean es transparente • La interfaz remota define el ciclo de vida de los métodos que son especificados en el enterprise bean. Session Bean DEPARTAMENTO DE SISTEMAS • Definición de un session bean con interfaz remota. o o Definir la interfaz anotada con @Remote Definir la clase que implementa la interfaz Estado Opcional Session Bean DEPARTAMENTO DE SISTEMAS • Un cliente local puede invocar un session bean a través de una interfaz local. En este caso el cliente reside en la misma instancia del session bean. Tomado del libro EJB 3 Developer Guide Session Bean DEPARTAMENTO DE SISTEMAS • El cliente local debe correr en la misma JVM que los enterprise bean que accede • El cliente local puede ser un componente web u otro enterprise bean. • La interfaz local define el ciclo de vida de los métodos del bean. • La interfaz por defecto es local Session Bean DEPARTAMENTO DE SISTEMAS • Definición de un session bean con interfaz local. o o Definir la interfaz anotada con @Local Definir la clase que implementa la interfaz Session Bean DEPARTAMENTO DE SISTEMAS • El estado de un objeto se compone de los valores de sus variables de instancia. • Las instancias de las variables representan el estado de una única sesión cliente-bean. • El estado de la interacción del cliente con el bean es llamado estado conversacional. • Modos de estado de administración o o Stateful Stateless Stateful Session Bean DEPARTAMENTO DE SISTEMAS • • El estado se mantiene durante la sesión del cliente con el bean. La instancia es reservada para el cliente y cada una almacena la información del cliente. • La sesión finaliza si el cliente remueve el bean o finaliza su sesión. Adicionar artículos Realizar compra Agregar información adicional compra Stateful Session Bean DEPARTAMENTO DE SISTEMAS • Definición de un session bean con estado Ciclo de vida bean con estado DEPARTAMENTO DE SISTEMAS El método remove es el único que es invocado directamente por el cliente El contendor decide desactivar el bean El cliente inicia el ciclo de vida obteniendo una referencia al bean de sesión -stateful 1. 2. El cliente invoca algún método del negocio durante la desactivación Stateless Session Bean DEPARTAMENTO DE SISTEMAS • No mantiene un estado conversacional con el cliente. o • Cuando un cliente invoca los métodos de un stateless bean, las variables de instancia del bean pueden contener un estado específico del cliente, pero sólo por la duración de la invocación. Cuando el método finaliza, el estado del cliente específico no debería mantenerse. Las instancias pueden estar compartidas por los clientes. El contenedor tiene un pool de instancias, cuando el cliente invoca un método se asigna una instancia, cuando la libere es retornada al pool. Stateless Session Bean DEPARTAMENTO DE SISTEMAS • • Ofrecen mejor escalabilidad para aplicaciones con gran cantidad de clientes Puede implementar un web service, pero no otros tipos de enterprise beans. Ciclo de vida bean sin estado DEPARTAMENTO DE SISTEMAS El cliente inicia el ciclo de vida obteniendo una referencia al bean de sesión -stateful 1. Callback Session Bean DEPARTAMENTO DE SISTEMAS • Los métodos Callback son métodos del bean (no expuestos en la interfaz) que el contenedor llama para notificar la transición del ciclo de vida de un bean • Cuando el evento ocurre el contenedor invoca al método callback correspondiente y los métodos pueden ser utilizados para mejorar rendimiento • Estos métodos son marcados con anotaciones como @PostContruct y @PreDestroy y para los stateful session bean se agregan @PrePassivate y @PostActivate Session Beans DEPARTAMENTO DE SISTEMAS Los métodos Callback: Deben ser públicos, sin retorno (void), y sin parámetros. Utilizan las siguientes anotaciones @PostConstruct: invocado sobre una instancia recientemente creada después de la inyección (o JNDI lookup) de todas las dependencias y antes de la invocación del primer método (javax.annotation.PostConstruct) @PreDestroy: invocado luego de que un método anotado con @Remove ha terminado y antes de que el contenedor elimine la instancia del bean (javax.annotation.PreDestroy) @PrePassivate: invocado antes de que el contenedor desactive (passivave) el bean, el contenedor elimina temporalmente el bean y lo salva en memoria secundaria (javax.ejb.PrePassivate) @PostActivate: invocado después de que el contenedor mueve el bean de memoria secundaria a estado activo (active) (javax.ejb.PostActivate) Localización Enterprise Bean DEPARTAMENTO DE SISTEMAS Tomado: EJB 3 in action • Con JNDI es responsabilidad del cliente hacer la localización y obtener la referencia al objeto. • Con EJB 3, usted puede utilizar la inyección de dependencia, dejando que el contenedor se responsabilice de inyectar un objeto basado sobre la declaración de la independencia JNDI DEPARTAMENTO DE SISTEMAS Acceso desde un componente a otros componentes o recursos (e.g., bases de datos) Un servlet puede invocar métodos remotos de un enterprise bean que consulta información de una bd JNDI es un servicio de nombres que permite a un componente localizar otros componentes o recursos Habilita a las aplicaciones para acceder múltiples servicios de nombres y de directorios. Por ejemplo servicios como LDAP, NDS,DNS, y NIS. Ofrece los métodos de Asociar un nombre con un objeto (binding) Buscar un objeto (lookup) El uso de JNDI en aplicaciones Java EE permite almacenar o consultar cualquier objeto de java: acceso a sistemas y aplicaciones Legado JNDI DEPARTAMENTO DE SISTEMAS Un administrador crea un recurso en un namespace de JNDI En el servidor de aplicaciones se pueden crear recursos con la consola de administración o el comando asadmin Las aplicaciones utilizan anotaciones para acceder a los recursos. Cuando una aplicación utiliza la “inyección” del recurso, el servidor de aplicaciones invoca el API JNDI (@Resource) La aplicación puede hacer llamados directos del API JNDI Un recurso y su nombre JNDI son ligados por el servicio de nombres Un recurso nuevo es creado en JNDI con la asociación del nombre del recurso en el namespace de JNDI (bind del recurso) Namespace: conjunto de todos los nombres de un servicio de nombres JNDI - Ejemplo DEPARTAMENTO DE SISTEMAS Acceso a una base de datos con el API JDBC: recurso JDBC con información sobre Servidor de BD Nombre de la BD Protocolo de red utilizado para la comunicación Un objeto DataSource es una fábrica de conexiones de una fuente de datos específica. El método getConnection retorna una conexión física a la fuente de datos Si el objeto DataSource es registrado con JNDI, una aplicación puede utilizar el API JNDI (lookup) para obtener el objeto y posteriormente conectarse a la fuente de datos Las aplicaciones utilizando el API de persistencia especifican la fuente de datos en el archivo persistence.xml <jta-data-source>jdbc/MyOrderDB</jta-data-source> Este punto es el único que referencia algo sobre el objeto JDBC JNDI DEPARTAMENTO DE SISTEMAS • Los servicios de nombres de Java EE proveen ambientes de nombres JNDI a las aplicaciones cliente, enterprise beans, y componente web • Un naming environment permite personalizar a un componente sin acceder o cambiar el código fuente de los componentes • Un contenedor implementa el ambiente de los componentes como un contexto de nombres • Contexto es un objeto cuyo estado tiene asociados un conjunto de relaciones entre nombres y objetos (bindings) • Un contexto tiene asociado una convención de nombres • Contexto inicial es el punto de partida para hacer las operaciones • En JNDI todas las operaciones son realizadas en un contexto JNDI DEPARTAMENTO DE SISTEMAS Un componente Java EE puede localizar su contexto de nombres con JNDI Un componente puede crear un objeto javax.naming.InitialContext y buscar su contexto bajo el nombre de java:comp/env. Un componente Java EE puede acceder nombres provistos por el sistema (named system-provided) y objetos definidos por los usuarios (user-defined objects) Nombres de objetos provistos por el sistema (e.g., objetos JTA) son almacenados en el contexto java:comp/env Según el tipo de objeto a definir por el usuario el subcontexto para registrarlo varía Enterprise beans: java:comp/env/ejb JDBC DataSource: java:comp/env/jdbc JNDI DEPARTAMENTO DE SISTEMAS Ejemplo con propiedades del ambiente Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL, args[2]); //rmi://localhost:1099 Context ctxt = new InitialContext(env); Compute comp = (Compute) ctxt.lookup(name); Ejemplo con archivo de configuración de las propiedades Context initial = new InitialContext(); Object objref = initial.lookup("java:comp/env/ejb/SimpleConverter”); Archivo build.xml <target name="run" depends="buildjar"> <java fork="true" classname="client.ComputePi"> <classpath path="${build}" /> <classpath path="${compute}" /> … <sysproperty key="java.naming.factory.initial" value="com.sun.jndi.rmi.registry.RegistryContextFactory" /> <sysproperty key="java.naming.provider.url" value="rmi://${hostname}:${port}" /> </java> </target> JNDI DEPARTAMENTO DE SISTEMAS Las propiedades del ambiente JNDI se deben configurar de acuerdo con las características del proveedor del servicio que se va a utilizar Las propiedades se clasifican en: Estándares (java.naming……): java.naming.factory.initial Específicas del servicio (java.naming.service……): java.naming.corba.orb Característica específica (java.naming.feature….): java.naming.security.sasl Especificas del proveedor: com.sun.jndi.ldap.trace.ber JNDI DEPARTAMENTO DE SISTEMAS java.naming.factory.initial nombre de la clase de la fábrica del contexto inicial La clase debe implementar la interface InitialContextFactory Ejemplo valores: com.sun.jndi.ldap.LdapCtxFactory com.sun.jndi.rmi.registry.RegistryContextFactory JNDI DEPARTAMENTO DE SISTEMAS java.naming.provider.url El URL para configurar el proveedor del servicio definido en la propiedad "java.naming.factory.initial" Ejemplo valores: ldap://localhost:389/o=JNDITutorial rmi://localhost:1099 Localización Enterprise Bean DEPARTAMENTO DE SISTEMAS • La localización se puede realizar definiendo explícitamente la búsqueda con JNDI. Localización Enterprise Bean DEPARTAMENTO DE SISTEMAS @EJB private HelloUser helloUser; void hello() { helloUser.saludo(“Pepito"); } Inyección @Stateless public class HelloUserBean implement HelloUser { public void saludo(String nombre) { System.out.println("Hola " + nombre + " bienvenido a EJB 3!"); } } • • • Un cliente de aplicación JEE para referir la instancia de un enterprise bean lo puede realizar a través de la anotación estática @EJB. El contenedor EJB es el que inyecta en cada objeto los objetos según las anotaciones que incluya. EJB3 permite reemplazar los descriptores XML por anotaciones en el código Localización Enterprise Bean DEPARTAMENTO DE SISTEMAS Inyección JNDI DEPARTAMENTO DE SISTEMAS • @EJB o o Declaración del atributo Método Setter • Atributos Opcionales o beanName o beanInterface o Nombre de la clase Ejb-name si el EJB tiene un descriptor XML Interface local o remota mappedName Nombre JNDI JNDI DEPARTAMENTO DE SISTEMAS Partes de un @Resource name: nombre del recurso en JNDI type: el tipo (Java) del recurso authenticationType: tipo de autenticación para utilizar el recurso shareable: indica si el recurso puede ser compartido mappedName: nombre específico de la implementación que indica que el recurso puede ser mapeado a description: descripción del recurso Ejemplos de estilos de inyección: atributos, métodos y clases Atributos: public class SomeClass { @Resource(name="customerDB") private javax.sql.DataSource myDB; ... } Métodos public class SomeClass { private javax.sql.DataSource myDB; ... @Resource (name="customerDB") private void setMyDB(javax.sql.DataSource ds) { myDB = ds; } Clases @Resource(name="myMessageQueue", type="javax.jms.ConnectionFactory") public class SomeMessageBean { …} Session Beans - Anotaciones DEPARTAMENTO DE SISTEMAS Interface @Remote: indica que se trata de una interfaz de negocio remota @Local: acceso al bean de forma local únicamente Clase @stateless similar a @stateful /* bean de sesión con estado */ Indica que el bean de sesión es sin estado Dependiendo del contenedor Se crea el stub del bean Registra en JNDI el bean con el nombre lógico "java:comp/env/ejb/ nombreBean“ o con un nombre dado en la anotación @EJB Aplica para interfaces remotas únicamente Genera el lookup del bean de sesión en JNDI con el nombre "java:comp/ env/ejb/nombreBean“ En serviciosCliente.java @EJB(name = "co.com.uniandes.ejemplo.servicios.IServiciosProducto") private IServiciosProducto serviciosProducto; @Resource Inyección de recursos @Resource(name="jdbc/sqetestDB",type=javax.sql.DataSource.class) public javax.sql.DataSource myTestDB; Agenda DEPARTAMENTO DE SISTEMAS • Introducción • EJB 3 o o o Características Beneficios Arquitectura EJB 3 • Session Bean o o o Stateless Session Bean Stateful Session Bean Localización Session Bean • Desarrollo por Componentes Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Existen diferentes estrategias de diseño para desarrollar software basado en componentes • El objetivo de esta sesión es proveer una guía general de diseño o Basada en el diseño orientado por objetos o Interfaces de Negocio o Defición de los contratos entre componentes antes de la implementación Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Diseño de Componentes con UML-2.0 o o o o o Interfaces Puertos Clasificadores Estructurados Componentes Conectores Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Interfaces o o Requeridas Provistas Tomado de [2] página 12 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Puertos o o o o Similar a las interfaces, describe como un clasificador interactúa con el ambiente A diferencia de las interfaces cada puerto es un punto de interacción diferente Pueden tener tipos y Multiplicidad Puede tener interfaces Tomado de [2] página 13 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Clasificadores Estructurados o Una nueva manera de representar descomposición de clasificadores Tomado de [2] página 14 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Componentes o UML 1.4 “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces” [OMG 01, p. 2-31] o UML 2.0 “a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment” [OMG 03, p. 136]. o Extienden el comportamiento de las clases (a nivel de metamodelo) Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS Tomado de [2] página 16 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Conectores o Representa un enlace de comunicación entre dos o mas elementos conectables (puertos, interfaces) Assembly Delegation Tomado de [2] páginas 17-18 DEPARTAMENTO DE SISTEMAS Desarrollo por Componentes • Actividades a Desarrollar durante el Diseño o Identificar los Elementos o Asignar responsabilidades a los elementos o Diseñar las Interfaces o Verificar los requerimientos funcionales o Comparar contra escenarios o Analizar interacciones o Analizar la Flexibilidad del sistema 56 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 1. Identificar los Elementos o Utilizar los requerimientos identificar responsabilidades o Identificar elementos funcionales que cumplirán esas responsabilidades o Evaluar los elementos identificados contra los criterios de diseño deseables o Iterar sobre los pasos anteriores hasta obtener un conjunto de elementos razonable 57 funcionales para Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 2. Asignar Responsabilidades a los Elementos o 58 Después de identificar elementos candidatos, se les asignan responsabilidades claras Información manejada Servicios Ofrecidos Actividades iniciadas por este elemento Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 3. Diseñar las Interfaces o Para cada interface expuesta por el elemento definir claramente o Para su definición se puede utilizar 59 Operaciones ofrecidas por la interfaz Naturaleza de la Interfaz (mensaje, RPC, WebService) Entradas Salidas Precondiciones Efectos de cada operación Lenguajes de programación IDLs UML DataFlow Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 4. Verificar los requerimientos funcionales o Hacer el seguimiento de cada requerimiento, utilizando la estructura funcional o Es aconsejable utilizar una tabla de requerimientos funcionales contra elementos del modelo estructural 60 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 5. Comparar contra Escenarios o Analizar la estructura funcional propuesta, en conjunto con los stakeholders, a través de escenarios de uso. • 6. Análisis de Interacciones o Analizar la estructura propuesta en busca de interacciones excesivas • 7. Análisis de Flexibilidad o 61 “what if ” escenarios Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Algunas errores frecuentes o o o o o o Mala definición de interfaces Mala definición de responsabilidades Elementos de Infraestructura modelados como elementos funcionales Nivel inapropiado de detalle Número elevado de dependencias “God Element” / “Manager” 62 50% de las responsabilidades en menos del 25% de los elementos Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Lista de Chequeo o Su modelo tiene entre 15 y 20 elementos? o Todos los elementos tienen nombre, responsabilidades claras e interfaces claramente definidas? o Todas las interacciones entre los elementos ocurren a través de interfaces y conectores entre ellas o Los elementos tienen una alta cohesión? o Los elementos muestran un bajo acoplamiento? o Se ha validado la estructura requerimientos funcionales? o Ha considerado como se porta la arquitectura en escenarios hipotéticos de cambio? o El punto de vista tiene en cuenta los intereses de los stakeholders? propuesta contra los Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • Ejemplo – Sistema de Reserva de Cuartos [2] 64 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 1. Identificar Elementos 65 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 1. Identificar Elementos 66 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 2. Asignar Responsabilidades 67 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 3. Diseñar las Interfaces 68 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 3. Diseñar las Interfaces 69 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 3. Diseñar las Interfaces 70 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 4. Verificar Requerimientos Funcionales 71 Desarrollo por Componentes DEPARTAMENTO DE SISTEMAS • 5. Verificar Escenarios • 6. Analizar Interacciones 72 Bibliografía DEPARTAMENTO DE SISTEMAS • EJB 3 in action. Panda Debu, Rahman Reza, Lane Derek. Manning. 2007. • EJB 3 Developer Guide. Sikora, Michael. 2008. • JSR 220: Enterprise JavaBeansTM,Version 3.0. Sun Microsystems. • The Java™ EE 5 Tutorial Third Edition. For Sun Java System Application Server Platform Edition 9. Eric Jendrock. 2006.