Download Enterprise JavaBeans

Enterprise JavaBeans
Arquitectura de Componentes Java en el Servidor
Whitepaper – Mayo 1999
© Ideal Business
CONTENIDOS
¿Qué es EJB, y para qué se necesita?
3
¿Quién soporta EJB?
4
¿Qué es exactamente EJB?
5
¿Cómo se desarrollan, despliegan y gestionan las EJB?
12
¿Cómo se integra EJB con los sistemas externos?
14
¿Cuál es el futuro de EJB?
14
Conclusión
15
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
2
¿Qué es EJB, y para qué se necesita?
Desde el nacimiento de la WWW, han venido apareciendo nuevas tecnologías en todas las
direcciones. Ahora resulta casi imposible mantenerse al día de estas tecnologías, a la
velocidad a la que se introducen y evolucionan.
Por lo tanto, ¿por qué añadir EJB a esta lista de tecnologías? Quizás deba volver a incidirse
sobre por qué middleware en general o servidores de aplicación en particular, y después sea
interesante analizar las ventajas (e inconvenientes) de situar Java como base de la ‘capa
intermedia’.
El modelo de componentes de servidor Enterprise JavaBeans (EJB) define una arquitectura
estándar para servidores de aplicación Java. Los objetivos esenciales de EJB son:
•
•
•
Portabilidad a través de diferentes servidores de aplicación.
Reusabilidad de componentes.
Incremento de la productividad de los desarrolladores.
EJB satisface estos objetivos al automatizar un buen número de servicios de middleware,
como la gestión del ciclo de vida de los objetos, gestión de estado, transacciones, seguridad,
y persistencia de objetos. Én vez de escribir llamadas a un API propietario directamente en
los componentes de aplicación, EJB permite a los desarrolladores especificar requisitos del
middleware mediante opciones de tiempo de ejecución. Un servidor de aplicaciones basado
en EJB implementa automáticamente los servicios para su uso por las aplicaciones, de
manera muy transparente al desarrollador de componentes.
El modelo EJB es parte de la plataforma Enterprise Java de Sun Microsystems, un entorno
Java robusto que soporta sistemas de aplicación de misión crítica altamente distribuidos.
‘Pegamento’ entre clientes y servidores
En el frontal existen múltiples clientes y servidores (puestos/navegadores, PDAs, NCs,
NetPCs…). Como backend hay aún una mayor heterogeneidad en cuanto a plataformas y
fuentes de datos. El middleware Java de la especificación EJB conecta ambos mundos. En
otras palabras, la lógica de negocio puede implementarse como componentes reusables en
la capa intermedia, proporcionando acceso a cualqiuer tipo de cliente al backend.
Escalabilidad
La solución inicial (HTML + CGI) no es escalable, y las APIs propietarias como NSAPI o
ISAPI no mejoran sustancialmente la escalabilidad. La mayor parte de los servidores de
aplicación, por contra, se basan en tecnologías estándar y sí se diseñaron con la
escalabilidad en mente. Estos productos proporcionan características como ‘pooling’ de
recursos, tolerancia a fallos, seguridad, gestión de sistemas, etc.
‘Todo en uno’
Muchos servidores de aplicación son ‘todo en uno’, es decir, soportan los protocolos
necesarios para proporcionar un entorno completo de desarrollo de aplicaciones. Algunos
servidores de aplicación soportan HTTP, RMI, EJB, Servlets, JNDI, JDBC, y CORBA/IIOP.
Esto evita la necesidad de disponer de múltiples servidores (p.ej. un servidor web, un ORB y
unos componentes de servidor RMI dispersos).
Productividad
EJB incrementa la productividad de los desarrolladores dado que éstos no han de
preocuparse sobre programación a bajo nivel (tal como seguridad, pooling de conexiones,
gestión transaccional, control de estado, persistencia, o multithreading). Los desarrolladores
símplemente se concentran en describir la lógica de negocio, desarrollando la enterprise
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
3
bean como si sólo fuera a existir un único cliente. Teniendo en cuenta que en una aplicación
típica C/S más del 80% del código se dedica a temas ajenos a la lógica de negocio, resultan
evidentes las mejoras de productividad esperables del middleware, y en particular de EJB.
Arquitectura de componentes abiertos de servidor
En las últimas dos décadas, la mayor parte de los productos basados en servidor han venido
utilizando APIs propietarias, de manera que no ha sido posible disponer de componentes
‘plug&play’ más allá de los componentes provistos por cada fabricante particular. EJB cambia
este estado de cosas, proporcionando portabilidad a través de plataformas y vendedores.
Dado que EJB establece un estándar en tecnología de componentes de servidor, todos los
vendedores deben incorporar el conjunto de funcionalidades básicas en sus productos de
servidor, dejando eventualmente a terceras partes la producción de componentes reusables
como enterprise beans; así, puede usarse una bean para validación de tarjetas de crédito,
gestión de pedidos, cifrado y firma digital, etc.
Programación Orientada a Objetos en el Servidor
Gracias a los orígenes de Java como lenguaje orientado a objetos, y al modelo de
componentes EJB, las organizaciones pueden crear y utilizar componentes reusables que
aporten las características de la programación orientada a objetos (encapsulación,
polimorfismo, herencia) y sus potenciales beneficios (reusabilidad, posibilidad de establecer
interfaces bien definidos, independencia de plataforma e incluso de lenguaje de
programación, etc.), sin la curva de aprendizaje que requiere la tecnología de orientación a
objetos. Uno de los elementos esenciales de la tecnología de objetos es el empaquetamiento
de los datos y la lógica para su procesamiento en objetos. Además de estos elementos
esenciales, EJB permite utilizar contenedores (containers) y Entity Beans que pueden
traducir fuentes de datos en objetos. Esto elimina la duplicidad de código para acceder a
datos residentes en una base de datos y para acceder a los datos encapsulados por un
objeto.
Java en la capa intermedia
EJB ofrece todas las características de Java (portabilidad, seguridad, gestión automática de
memoria, servicios de directorio, serialización) a la capa intermedia.
Soporte de otros lenguajes y CORBA
EJB define explícitamente el soporte a otros lenguajes y CORBA porque el vendedor del
middleware (o servidor de aplicación) maneja los aspectos relacionados con el protocolo de
comunicaciones, y NO el programador de aplicaciones o de beans. En EJB el protocolo de
comunicación entre componentes es RMI (Remote Method Invocation); sin embargo, desde
la especificación EJB 1.0 se proporcionan interfaces con CORBA, y existen vendedores que
ofrecen soporte DCOM.
¿Quién soporta EJB?
Recordemos de nuevo que EJB no es un producto; es una especificación. Uno de los
objetivos esenciales de EJB es la portabilidad a través de plataformas y vendedores. Multitud
de vendedores soportan EJB 1.0, y EJB 1.1/2.0 están a punto de ver la luz. La siguienta tabla
muestra una lista parcial de vendedores que han asumido el estándar EJB.
Vendedor
BEA Systems
Bluestone
Gemstone
IBM
Information Builders
Inprise
Lotus
Producto
WebLogic Application Server
Sapphire/Web
Gemstone/J
Websphere
Parlay Application Server
Inprise Application Server
Notes/Domino
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
4
Netscape
Novera
Oracle
Persistence
Progress
Secant
Silverstream
Sun
Sybase
Valto Systems
Wall Data
Netscape Application Server (Kiva)
jBusiness
Oracle Application Server
Pow erTier for EJB
Aptivity, Webspeed
Extreme Enterprise Server for EJB
Silverstream Application Server
NetDynamics
Enterprise Application Server
Ejipt
Cyberprise Server
¿Qué es exactamente EJB?
EJB es parte de la iniciativa JPE (Java Platform for the Enterprise). Las JavaBeans
introdujeron una forma estándar de desarrollar y usar componentes Java en el lado del
cliente. De manera similar, EJB sirve como arquitectura de componentes Java en el lado del
servidor.
EJB permite que los desarrolladores de software construyan objetos de negocio de servidor
(o capa intermedia) reusables (‘enterprise beans’). Sin embargo, EJB lleva más lejos aún el
concepto de objetos reusables, proporcionando programación basada en atributos para
definir dinámicamente comportamiento transaccional, seguridad y modelo de ciclo de vida en
aplicaciones EJB. Por ejemplo, usando técnicas basadas en atributos, la misma entreprise
bean (en su forma binaria – esto es, fichero .class o JAR) puede ofrecer diferente
comportamiento transaccional en diferentes aplicaciones. Además, el método de persistencia
de una enterprise bean puede alterarse durante el despliegue , sin tener que recodificarla.
Una Entity Bean puede usar una base de datos relacional o CICS; el desarrollador de la bean
no necesita conocer estos ‘detalles’.
Para proporcionar una imagen más concreta de EJB, se examinarán sus objetivos,
características, roles y responsabilidades, y las restricciones de programación que impone.
Objetivos
La especificación EJB definen ciertos objetivos para los vendedores de middleware Java que
deseen implementar este estándar. Por citar algunos:
§
§
§
§
§
§
Arquitectura de componentes Java distribuidos estándar.
Portabilidad a través de plataformas y proveedores.
Incremento de productividad mediante simplicidad (el desarrollador no ha de preocuparse
sobre gestión de estados, multithreading, protocolos y conexiones de red, pooling de
recursos, etc.).
Compatibilidad con otros lenguajes de programación y CORBA.
Abarca desarrollo, despliegue y gestión.
Compatibilidad con inversiones existentes en infraestructuras de sistemas y plataformas.
Arquitectura
La arquitectura EJB pretende alcanzar los objetivos expuestos usando una capa de
infraestructura abstracta denominada ‘contenedor’ (container). Un contenedor proporciona un
entorno de ejecución consistente, y aisla al componente de las diferencias entre los
servidores de aplicación de diferentes proveedores. Como se aprecia en la figura, un
componente EJB (o simplemente, un enterprise bean) se despliega en un contenedor EJB,
dentro de un servidor EJB.
Una componente de aplicación (enterprise bean) se ejecuta dentro de un contenedor EJB,
que se ejecuta a su vez bajo un servidor de aplicación EJB. Cuando se despliega una
componente, se establecen requisitos de runtime usando objetos descriptores de despliegue.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
5
Basado en estos requisitos, el contenedor genera un objeto de contexto (usado por el
contenedor para gestionar el componente), un interfaz EJB home (usado por el cliente para
crear, buscar y destruir el objeto) y un interfaz de objeto EJB (usado por el cliente para
acceder a los métodos de negocio del componente, actuando como objeto proxy). Los
métodos de negocio pueden también personalizarse en tiempo de despliegue, estableciendo
valores en el objeto de entorno. Durante la ejecución, el contenedor EJB intercepta todas las
llamadas e invoca automáticamente los servicios de middleware.
Arquitectura EJB
Pooling de recursos
Tolerancia a fallos
Conectividad
Multithreading
Cache de datos
Control concurrencia
métodos
Servidor de Aplicaciones EJB
Proporciona gestión de recursos y servicios middleware
(gestión de recursos, transacciones, seguridad, persistencia)
Contenedor EJB
Invoca automáticamente servicios para la EB
basándose en requisitos definidos en los
descriptores de despliegue (ciclo de vida, gestión
de estados, transacciones, seguridad, persistencia)
Objeto EJB
métodos
(vista de cliente)
Enterprise
Bean
Cliente
create
lookup
destroy
Contexto
EJB home
(ID del bean)
create
lookup
destroy
Descriptores
de despliegue
Entorno
El servidor de EJB proporciona gestión de recursos y servicios middleware, como
multithreading, gestión de sesiones, pooling de conexiones a fuentes de datos, cache de
datos, gestión de estado, gestión de transacciones, control de concurrencia, seguridad, y
persistencia. La especificación EJB no define cómo se implementan estos servicios, de modo
que las mayores diferencias en productos de servidor de aplicación residen en la calidad de
estos servicios. El contenedor EJB oculta las diferencias entre diferentes servidores de
aplicación: cualquier servidor de aplicación Java puede convertirse en un servidor EJB si se
proporciona una implementación de contenedor EJB compatible con la especificación.
El contenedor EJB gestiona el enterprise bean, invocando los servicios middleware
necesarios. En tiempo de despliegue, se describen los parámetros de funcionamiento
relativos a estos servicios middleware, en unos objetos de descriptor de requisitos.
Basándose en estos objetos, el contenedor genera en tiempo de ejecución un objeto de
contexto que se usará para mantener parámetros de runtime, requisitos de servicio, e
información de estado para cada instancia de una componente. El contenedor genera
asimismo dos interfaces ‘envoltorio’ para el acceso desde el cliente. El interfaz EJB home
permite crear, localizar y destruir instancias de la componente, mientras que el interfaz de
objeto remoto EJB identifica una única instancia de componente, usándose por los clientes
para invocar los métodos de negocio del componente. En tiempo de ejecución el contenedor
intercepta todas las invocaciones realizadas por el cliente contra los dos interfaces (home
EJB y objeto remoto EJB), invocando automáticamente los servicios de middleware.
Características
Para satisfacer los objetivos arriba expuestos, EJB incorpora multitud de características que
hacen a esta arquitectura de componentes distribuidos tan atractiva. La tabla siguientes
proporciona una imagen de estas características (que se desarrollan en lo que sigue):
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
6
Característica
Modelo de Componentes
Persistencia de Objetos
Gestión Transaccional
Gestión de Excepciones
Seguridad
Servicio de Nombres y Directorio
Protocolo de red
Soporte para CORBA
Programación basada en atributos
Despliegue
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
Soportado a través de
Session Beans
Entity Beans
Entity Beans (EJB Containers)
JTS/JTA
javax.jts.UserTransaction
Extensiones propietarias
En cliente y en servidor
java.security
Métodos ligados a la seguridad en javax.ejb.EJBContext
Propiedades de descriptor de despliegue (ACLs de Java,
propiedades RunAs)
JNDI (Java Naming and Directory Interface)
RMI/JRMP
IIOP (a través del mapping CORBA)
(otros)
Mapping CORBA (ejb.idl)
Fichero descriptor de despliegue
Fichero JAR de la EJB
Tres tipos de enterprise beans
EJB define tres tipos de enterprise beans: beans de sesión sin estado (stateless session
beans), beans de sesión con estado (stateful session beans) y beans de entidad (entity
beans).
Beans de sesión sin estado – simples y ligeras (es decir, fáciles de desarrollar, con bajos
requisitos en tiempo de ejecución. Cualquier información de estado, en caso de que fuera
necesaria, se mantiene por el cliente, llevando a una escalabilidad teórica infinita. Dado que
este tipo de bean no mantiene estado, los beans de sesión no están ligados a un cliente
particular, de manera que cualquier instancia de un bean de esta clase puede usarse para
dar servicio a un cliente.
Beans de sesión con estado – Proporcionan una gestión de estado transparente en el lado
del servidor. Dado que el estado se mantiene en este tipo de EJB, el servidor de aplicación
maneja pares cliente-bean. En otras palabras, cada instancia de una cierta EJB se crea bajo
petición de un cliente concreto, y en principio es un recurso privado para ese cliente (aunque
puede compartirse entre clientes, usando el handle del bean). En esencia, una bean con
estado actúa como una extensión del cliente, con la salvedad de que cierta carga del cliente
se distribuye en el servidor de aplicaciones. Los datos de estado no sobreviven a una caida
del servidor, salvo que la implementación particular soporte persistencia frente a caidas del
servidor. Los beans con estado pueden acceder a recursos persistentes (como bases de
datos o ficheros) pero, a diferencia de los beans de entidad, no representan datos. Por
ejemplo, una bean con estado puede acceder a una base de datos via JDBC, o a través de
una bean de entidad.
Beans de entidad – Objetos persistentes, que representan una vista de objeto de una
determinada fuente de datos. Para entender mejor este concepto, puede imaginarse una
bean de entidad como una fila en una base de datos. Una bean de entidad puede crearse,
instanciarse como fila, y eliminarse – usando los métodos create(), findxxx y remove(),
de la misma manera que una fila en una base de datos puede INSERTarse, SELECTionarse
o borrarse (DELETE). Una bean de entidad vive en un contenedor EJB, proporcionado por el
proveedor del servidor de aplicaciones para varias fuentes de datos (Oracle, CICS, SAP/R3,
etc.); ¡el desarrollador de la bean de entidad no tiene que conocer los detalles de la fuente de
datos! Múltiples clientes pueden acceder a la misma bean de entidad concurrentemente – tal
concurrencia la gestiona el contenedor EJB.
Cada instancia de una bean de identidad se identifica a través de una única clave primaria.
Las beans de entidad pueden crearse bien creando un objeto (mediante un método
Create() de una factoría de objetos) o insertando directamente datos en la fuente de datos.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
7
Dado que el estado de la bean se mantiene en la fuente de datos, este tipo de beans pueden
recuperarse ante una caida del sistema.
La decisión de qué tipo de bean usar es un aspecto más de diseño que de desarrollo.
Algunas reglas:
1.
2.
Usar bean de entidad en vez de beans de sesión si no se desea embeber funciones de
base de datos (p.ej. JDBC) en las EJB, y además desean aprovecharse las
características de control automático de transacción, pooling de recursos, y persistencia
manejada por el contenedor EJB. Piénsese en una bean de sesión como una extensión
del cliente en el servidor, sin persistencia ‘per se’ (cuando el cliente o el servidor
finalizan, la bean deja de existir), mientras que una bean de entidad puede entenderse
como representación de datos persistentes.
Si se decide por una bean de sesión, escoger ‘con estado’ o ‘sin estado’ representa el
decidir cuánta carga se sitúa en el servidor y cuánta en el cliente. En otras palabras, si
se mantiene el estado en el servidor (bean con estado), el servidor tendrá mayor
sobrecarga, mientras que una bean sin estado supone que si hay que mantener
información de estado, tal información se sitúa en el cliente.
Pese a las diferencias, las beans de sesión y entidad comparten las siguientes
características:
•
•
•
•
•
•
Puede obtenerse un manejador o handle (java.ejb.Handle) usando el método
getHandle().
Editando sus propiedades de entorno, una bean puede personalizarse durante el
despliegue.
Las instancias de las EJB pueden crearse y gestionarse en tiempo de ejecución por el
servidor de aplicaciones.
Ciertos atributos de la EJB, como el modo transaccional y la seguridad, pueden
manipularse en tiempo de despliegue usando las herramientas de despliegue en servidor
de EJB.
Ambos tipos soportan semántica transaccional.
Ambos tipos pueden crearse y destruirse usando create() y remove().
La siguiente figura muestra las interrelaciones entre los distintos elementos de un servidor de
aplicaciones. Nótese lo siguiente: Un servidor puede tener múltiples contenedores (cada uno
de ellos correspondería típicamente a una fuente de datos). Un contenedor aloja múltiples
beans (de sesión y/o entidad). Una bean de entidad representa una fila de una fuente de
datos, pudiendo estar compartidas entre múltiples clientes, y permitiendo accesos
concurrentes. Los beans de sesión con estado están asociados a un único cliente, mientras
que los beans sin estado se instancian de un ‘pool’ en caso necesario.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
8
Relaciones entre EJBs
Capa de
Cliente
Cliente 1
Capa de
Negocio
Pool de
beans sin
estado
Capa de
Datos
Contenedor EJB
Oracle
Bean de entidad
Fila 1
Bean de entidad
Cliente 1
Cliente 3
Instancia 1 de
bean de sesión
Bean de entidad
con estado
Instancia 2 de
bean de sesión
con estado
contenedor EJB
basado en ficheros
contenedor EJB
MQSeries
Fila 2
Fila 3
contenedor EJB
CICS
Persistencia
Una de las características claves del modelo EJB es la persistencia, que puede implantarse a
nivel de bean de entidad o a nivel de contenedor.
En el primer caso, el desarrollador sobrecarga los métodos ejbLoad() y ejbStore(), para
almacenar la información residente en los atributos del bean de entidad en una fuente de
datos mediante, por ejemplo, JDBC. Este mecanismo es el más flexible (pues el
desarrollador define cómo se almacenan los datos) pero liga a nivel de código la bean con el
almacén de datos. Algunos proveedores están empezando a proporcionar herramientas de
traducción objeto-relacional a través de las cuales pueden definirse joins complejos, y
proporcionar accesos por programa a estas queries. Otra alternativa son las vistas de base
de datos, si bien muchas bases de datos no permiten la actualización de múltiples tablas
desde una vista.
Si la persistencia la proporciona el contenedor EJB, en general el proveedor incorpora una
herramienta de traducción objeto-relacional para enlazar atributos del bean con campos del
almacén de datos. Por citar un ejemplo, Persistence Software proporciona una herramienta,
PowerTier ObjectBuilder, para automatizar la traducción entre objetos bean (considerando
herencia, agregación y asociación) a tablas relacionales.
Aunque el proceso de traducción puede ser tedioso, las ventajas de esta aproximación
superan con creces los inconvenientes: Se genera automáticamente el código para mover los
datos entre los campos del bean y el almacén de datos. Además, un bean de entidad puede
hacerse persistente respecto a otra fuente de datos sin más que situarla en otro contenedor y
establecer el nuevo mapping. Además, el contenedor puede optimizar el acceso a datos
mediante mecanismos de cache a nivel de contenedor, haciendo innecesario acceder al
almacén de datos en cada petición. Los tipos de contenedores más habituales son los
relacionales (típicamente basados en drivers nativos o en JDBC), si bien existen
implantaciones para fuentes de datos no relacionales (3270, CICS, MQSeries, TXSeries,
Tuxedo, ficheros planos...).
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
9
Herramienta de mapping Objeto-Relacional de Persistence PowerTier
Gestión transaccional
EJB soporta transacciones planas, basadas en la especificación CORBA OTS (Object
Transaction Service) 1.1. Con esta facilidad, el desarrollador queda liberado de definir los
detalles de la transacción, tema especialmente complejo si se habla de transacciones
distribuidas, two-phase commit y otras lindezas.
Las transacciones en un entorno EJB pueden manejarse de dos maneras. En la primera, el
desarrollador puede contralar por programa el alcance de la transacción usando el interfaz
javax.jts.UserTransaction, en el cliente o en el bean. En la segunda posibilidad, el
servidor de aplicaciones gestiona los límites de la transacción usando atributos de
transacción durante el despliegue. Ni que decir tiene que esta segunda posibilidad es más
flexible, si bien la primera puede ser necesaria para aquellas transacciones complejas que no
puedan modelarse mediante las facilidades del servidor de aplicaciones.
Los valores del atributo de transacción definidos en EJB y qué tiene lugar cuando se invoca
una operación en una entreprise bean se muestran a continuación:
Valor del atributo de transacción
TX_NOT_SUPPORTED
TX_BEAN_MANAGED
TX_REQUIRED
TX_SUPPORTS
TX_REQUIRES_NEW
TX_MANDATORY
Cómo se invoca la enterprise bean
Sin ámbito transaccional
La bean puede usar el interfaz javax.jts.UserTransaction para
establecer los parámetros de la transacción. Este interfaz puede
obtenerse invocando el método
javax.ejb.SessionContext.getUserTransaction().
Si el cliente está asociado con un contexto de transacción, la
enterprise bean se invoca en el mismo contexto; en otro caso, el
contenedor inicia una nueva transacción antes de la invocación del
método, y la aplica (commit) tras el retorno del método.
Invocada en el ámbito transaccional del cliente, si se tiene uno. En
caso contrario, sin ámbito transaccional.
Como TX_REQUIRED, pero siempre se invoca una nueva
transacción, ignorando cualquier contexto.
Invocada en el ámbito de la transacción del cliente. Si el cliente no
tiene, se lanza excepción
javax.transaction.TransactionRequiredException.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
10
EJB permite asimismo definir el nivel de aislamiento de la transacción, concepto a través del
cual se proporciona visibilidad de los cambios efectuados por una transacción a otras. Los
valores válidos son:
TRANSACTION_READ_UNCOMMITED, TRANSACTION_READ_COMMITED,
TRANSACTION_REPEATABLE_READ y TRANSACTION_SERIALIZABLE.
JDBC 2.0 introduce una extensión estándar (paquete javax.sql) que incluye soporte a
transacciones distribuidas, además de mecanismos de pool de conexiones y conjuntos de
filas (rowsets). Java proporciona soporte de transacciones distribuidas mediante JTA (Java
Transaction API) y JTS (Java Transaction Service). Es posible, por ejemplo, asociar un driver
JDBC a un gestor de transacciones externo usando el interfaz estándar XA de The Open
Group (javax.sql.XADataSource, javax.sql.XAConnection).
Seguridad
EJB usa la clase java.security.Identity para describir a los usuarios y roles. Es
responsabilidad del servidor de aplicaciones (o del contenedor EJB) efectuar la traducción
con una identidad real (por ejemplo, el DN de un certificado X.509 usado para autenticar a un
usuario). Esta información la obtiene la instancia de la bean a través de los métodos
getCallerIdentity
e
isCallerInRole(Identity
ident) de la clase
javax.ejb.EJBContext.
EJB usa para la autorización el modelo de listas de control de accesos (ACLs) en el
descriptor de despliegue. EJB define atributos RunAsMode y RunAsIdentity, para definir la
identidad a asociar con la ejecución de métodos del enterprise bean y para llamadas a
gestores de recursos (como JDBC). Los valores válidos de RunAsMode son
SPECIFIED_IDENTITY, CLIENT_IDENTITY y SYSTEM_IDENTITY (cuenta privilegiada).
Servicio de directorio y protocolos de red
EJB usa JNDI (Java Naming and Directory Interface) como servicio de nombres. Mediante
JNDI, un cliente busca un interfaz home EJB. Es responsabilidad del contenedor mantener la
información necesaria para que JNDI pueda proporcionar la referencia al interfaz home del
bean.
La especificación EJB define RMI (Remote Method Invocation) y el protocolo asociado
(JRMP) como protocolo por defecto para invocación remota de métodos de objetos Java.
EJB proporciona también una traducción CORBA/IIOP, de manera que clientes CORBA
puedan invocar enterprise beans. Esencialmente esto se logra mediante ficheros IDL
proporcionados para las clases e interfaces estándar de EJB, combinados con ficheros IDL
ligados a enterprise beans.
No obstante, EJB puede usar cualquier protocolo (HTTP, DCOM, etc.). En cualquier caso, el
desarrollador no tiene que preocuparse por el protocolo, pues el proveedor se ocupa de los
detalles de conectividad.
Algunos ejemplos de conexión:
•
•
•
Un navegador puede descargar una página HTML que contenga un servlet simple. Este
servlet puede invocar métodos de los enterprise beans, via RMI, o actuar como un cliente
Java frente a enterprise beans.
Un applet, o una aplicación Java, pueden invocar directamente al enterprise bean.
Una aplicación CORBA o ActiveX/DCOM, usando una pasarela, pueden acceder al
enterprise bean.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
11
¿Cómo se desarrollan, despliegan y gestionan las EJB?
El ciclo de vida de una enterprise bean comprende los siguientes pasos:
•
•
•
•
Desarrollar el enterprise bean (clases de la bean, e interfaces home y remoto).
Desplegar el enterprise bean (descriptor de despliegue, fichero manifest, propiedades de
entorno, y JAR).
Ensamblar la aplicación (desplegar y probar la conectividad en todas las capas).
Gestionar las beans y los elementos relacionados.
Desarrollo
Para cada enterprise bean, deben desarrollarse tres piezas:
•
La clase propia de la bean (que encierra la lógica de negocio). La bean sobrecarga
métodos como ejbCreate(), o setSessionContext() –en el caso de una bean de
sesión. Básicamente, se implementa alguno de los interfaces definidos en el paquete
javax.ejb, como EntityBean o SessionBean. Ejemplo:
import javax.ejb.*;
import java.rmi.*;
public class BuscaPersonasBean implements SessionBean {
SessionContext sessionContext;
public void ejbCreate() throws CreateException, RemoteException {}
public void setSessionContext(SessionContext sc)
throws RemoteException {
sessionContext = sc;
}
// Métodos de negocio
public String obtenerNombre(int DNI) {
String Nombre = null;
// Obtiene el nombre de una fuente de datos
return Nombre;
}
}
•
Su interfaz home (lo que un cliente obtiene via JNDI, y que el cliente u otras enterprise
beans puede usar para crear instancias del objeto remoto, usado como manejador ‘proxy’
frente a la verdadera bean). Ejemplo:
import javax.ejb.*;
import java.rmi.*;
public interface BuscaPersonasHome extends EJBHome {
public BuscaPersonas create()
throws CreateException, RemoteException;
}
•
Su interfaz ‘objeto remoto’
import javax.ejb.*;
import java.rmi.*;
public interface BuscaPersonas extends EJBObject {
public String obtenerNombre(int DNI) throws RemoteException;
}
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
12
(Nótese la convención de nombres, añadiendo ‘Bean’ al nombre de la clase en la
implementación de la bean, y ‘Home’ al nombre de la clase en la definición del interfaz
home).
Una vez que el enterprise bean se despliega, ¿qué aspecto tendría un cliente Java? En
primer lugar, el cliente usaría JNDI para localizar el interfaz home del bean remoto. Usando
el método create() apropiado del interfaz home, obtendría una instancia del objeto remoto, y
usando sus métodos, invocar los métodos del bean. Por ejemplo:
// Inicializacion
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"persistence.jndi.TengahInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "system");
env.put(Context.SECURITY_CREDENTIALS, "xyz");
InitialContext ic = new InitialContext(env);
// Obtiene interfaces home y de objeto remoto
BuscaPersonasHome bph =
(BuscaPersonasHome)ic.lookup("statefulSession.BuscaPersonas");
BuscaPersonas bp = bph.create();
// Invoca el método remoto
System.out.println("Nombre = " + bp.obtenerNombre(123456789));
La siguiente tabla refleja los métodos, clases e interfaces relacionados con los enterprise
beans.
Tipo de Bean
•
Sesión
•
•
•
•
Entidad
•
•
•
Métodos, clases e interfaces
Métodos : ejbRemove, ejbActivate, ejbPassivate,
setSessionContext(SessionContext)
Clases: SessionContext, Handle, EJBObject, EJBHome
Interfaces: SessionBean
Métodos SessionContext: getEJBObject, getCallerIdentity(),
getEJBHome(), getEnvironment(), getRollbackOnly(),
getUserTransaction(), isCallerInRole(Identity), setRollbackOnly()
Métodos : ejbActivate(), ejbLoad(), ejbPassivate(), ejbRemove(),
ejbStore(), setEntityContext(EntityContext(),
unsetEntityContext().
Clases: Handle, EJBObject, EJBHome
Interfaces: EntityBean
Métodos EntityContext: getPrimaryKey(), getEJBObject,
getCallerIdentity(), getEJBHome(), getEnvironment(),
getRollbackOnly(), getUserTransaction(), isCallerInRole(Identity),
setRollbackOnly()
Despliegue
El despliegue es un proceso en cinco pasos:
1.
2.
3.
Creación de un fichero de descriptor de despliegue para cada enterprise bean,
típicamente usando una herramienta gráfica. En el caso de beans de entidad, debe
especificarse la propiedad containerManagedField para establecer la lista de campos
para los que el contenedor EJB debe generar llamadas de acceso.
Proporcionar un fichero manifest que liste todos los descriptores de despliegue.
Especificar aquellas propiedades de entorno que el bean precise en tiempo de ejecución.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
13
4.
5.
Empaquetar el descriptor de despliegue, fichero manifest y las clases asociadas al bean
(.class del propio bean, del interfaz home y del interfaz objeto remoto) en un fichero JAR.
Desplegar el bean usando la herramienta proporcionada por el software del servidor de
aplicaciones.
Gestión
Las principales diferencias en funcionalidad en los proveedores de servidores de aplicación
compatibles con EBJ residen en las herramientas y consola de gestión. Las funciones que se
contemplan suelen incluir:
•
•
•
•
•
La configuración de componentes, recursos, usuarios y grupos.
La monitorización en tiempo real de servidores de aplicación, componentes,
contenedores y clientes.
La capacidad de establecer controles de acceso para clientes, contenedores y
componentes.
La capacidad de definir el número de usuarios concurrentes que pueden ejecutar un
cliente o contenedor específico, y el número de instancias permitidas para cada usuario o
grupo.
Vista histórica y en tiempo real de eventos ligados a la operación del servidor.
¿Cómo se integra EJB con los sistemas externos?
Los proveedores de servidores de aplicación basados en EJB abordan el acceso a los datos
de diversas maneras. Algunos proporcionan drivers JDBC para acceso a bases de datos
relacionales. Otros se basan en drivers ODBC estándar y la pasarela JDBC-ODBC para el
acceso desde clases Java. En ciertos casos se hace uso de drivers nativos, que ofrecen
mayor funcionalidad y rendimiento (usando, por ejemplo, directamente OCI para acceso a
Oracle). La mayoría ofrece también acceso a CICS e IMS, VSAM, DB2, MQSeries, TN3270,
SAP, Peoplesoft, etc. En última instancia, siempre es posible disponer de APIs
proporcionadas por el fabricante del monitor de transacciones o base de datos, basadas en
JNI (Java Native Interface) típicamente desarrolladas en C/C++ y encapsulables en forma de
clases Java.
En cualquier caso, el acceso a fuentes de datos externas es uno de los elementos a tener
más en cuenta a la hora de seleccionar un producto de servidor de aplicación basado en
EJB.
¿Cuál es el futuro de EJB?
EJB es una tecnología novedosa y muy prometedora, dado el gran soporte que está
recibiendo por parte de la industria. Muchas características interesantes aparecerán en la
versión 2.0 de la especificación EJB. Además, en CORBA 3 se incluyen especificaciones
ligadas al mapping de objetos CORBA y enterprise beans. Éstas se tratarán com
componentes CORBA en productos ORB, sin grandes problemas dado que los modelos
CORBA y EJB son muy similares.
La siguiente tabla muestra el desarrollo de la especificación EJB en los próximos meses.
Nombre
Clave
Moscone
Planificación
Características
Revisión preliminar: Principios de 1999
Definicióm más detallada de la
Public review: mediados de 1999
especificación, e información de
Especificación Final: Hacia finales de 1999
despliegue en XML.
Además de las especificaciones, Sun producirá una
implantación de referencia y un conjunto de tests de
compatibilidad.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
14
Nombre
Clave
Javits
Planificación
6 a 9 meses tras la publicación de moscone
Milano
6 a 9 meses tras la publicación de Javits
Características
Conectores estándar para sistemas
externos de diversos tipos.
Definición completa de entidades
Los proveedores de ORB jugarán un importante papel en EJB dada la portabilidad inherente
entre CORBA y EJB. Se tenderá asimismo a incorporar en mayor medida el estándar JTA en
cuanto a soporte transaccional.
Conclusión
Cuando se introdujeron las JavaBeans en JDK 1.1, se convirtieron en el modelo de facto
para componentes GUI. Con EJB, ya se dispone del modelo de componentes Java para
servidor.
El hecho de disponer de la misma funcionalidad de base en todos los productos basados en
EJB permite proteger la inversión en middleware. Los proveedores de este tipo de soluciones
podrán concentrarse en las funcionalidades extra, como el soporte de fuentes de datos
backend de toda índole, así como características que aporten robustez y escalabilidad a la
solución, como tolerancia transparente a fallos a nivel de sesión, balance de cargas, y
agregación de servidores en clusters. Y pese a que existe un camino por recorrer, el
middleware Java es ya una realidad.
Enterprise JavaBeans: Arquitectura de Componentes Java en el Servidor
15