Download Arquitecturas de objetos distribuidos con EJB

4° Encuentro Internacional de
Computación Aplicada
Arquitectura de Objetos Distribuidos
utilizando EJBs
Omar Gómez
[email protected]
Agenda
•
•
•
•
•
•
Arquitectura de Objetos Distribuidos
Arquitectura J2EE
Componentes EJB
Session Beans
Entity Beans
Ejemplo de aplicaciones Utilizando Session
Beans y Entity Beans
Arquitectura de Objetos
Distribuidos
• Cada entidad distribuida es un objeto que provee servicios
a otros objetos y reciben servicios de otros objetos.
• Los objetos pueden ser distribuidos entre un numero de
computadoras en una red y comunicarse a través de una
capa intermedia( middleware).
• El middleware actúa como un bus de software, este
proporciona un conjunto de servicios que permiten a los
objetos comunicarse, ser agregados y removidos de el
sistema, este middleware es llamado ORB (objeto
intermediario de solicitudes).
Arquitectura de Objetos
Distribuidos
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
Software bus
o5
o6
S (o5)
S (o6)
Ventajas del modelo de Arquitectura de
Objetos Distribuidos
• Arquitectura de sistema abierta, ya que
permite a nuevos recursos ser agregados
conforme sean requeridos.
• El sistema es flexible y escalable.
• Es posible reconfigurar el sistema
dinámicamente con objetos migrando entre
la red conforme sea requerido.
Principales estándares para middleware que
soportan computación de objetos distribuidos
•
•
•
CORBA( Common Object Request Broker Architectute ). conjunto de
estándares definidos por OMG, la OMG es un consorcio de mas de 500
compañías que promueven el desarrollo orientado a objetos. El estándar
CORBA define un enfoque genérico de maquina independiente para
computación de objetos distribuidos, un numero de implementaciones de este
estándar por diferencies vendedores a sido desarrollada, implementaciones en
CORBA son disponibles para Sistemas Operativos Unix y Microsoft.
DCOM ( Distributed Component Object Model ) estándar desarrollado por
Microsof y es integrado con dicho Sistema Operativo, es menos general que
CORBA, ofrece un soporte mas limitado de interoperatividad, solo funciona
en Sistemas Operativos Microsoft.
Java RMI ( Remote Method Invocation ). RMI permite a los objetos correr en
en distintas computadoras o en procesos separados para comunicarse con
algún otro objeto vía llamadas a métodos remotos
Objetos intermediarios de
solicitudes ( ORB )
• Los ORB manejan las comunicaciones de los
objetos. Este sabe de todos los objetos en el
sistema y sus interfaces.
• Al usar un ORB, la llamada al objeto se enlaza a
un stub IDL que define la interfaz de la llamada
del objeto.
• Al llamar a este stub resulta en llamadas al ORB el
cual entonces llama a los objetos necesarios a
través de un skeleton en IDL publicado que enlaza
la interfaz a la implementación del servicio.
Comunicación de objetos basados
en ORB
o1
o2
S (o1)
S (o2)
IDL
stub
IDL
skeleton
Object Request Broker
Comunicaciones inter-ORB
• Los ORBs no son usualmente programas
separados, sin embargo son un conjunto de objetos
en una librería que son enlazados con una
aplicación cuando esta es desarrollada.
• Los ORBs manejan comunicaciones entre objetos.
• Las Comunicaciones inter-ORB son usadas por
llamadas de objetos distribuidos.
• La comunicación entre los ORBs es hecha a través
del protocolo IIOP ( Internet Inter ORB ).
Comunicaciones inter-ORBs
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
IDL
IDL
IDL
IDL
Object Request Broker
Object Request Broker
Network
Protocolo IIOP
Arquitectura J2EE
• Sun Microsystems en colaboración con
otros miembros de la industria, han definido
una plataforma basada en componentes
llamada J2EE( Java 2 Enterprise Edition ).
• Esta plataforma cuenta con 4 tipos de
contenedores: contenedor de applets,
aplicación de cliente, web, ejb.
Aplicaciones J2EE
Contenedores J2EE, servicios y
plataformas
Algunos Servidores de
Aplicaciones que usan J2EE
•
•
•
•
•
iPlanet ( Sun Microsystems)
WebSphere ( IBM )
WebLogic ( bea )
Borland Enterprise Server ( Borland )
JBoss ( Jboss Group )
Objetos Distribuidos – El principio de
Enterprise Java Beans ( EJB )
• Un objeto distribuido es un objeto que puede ser
llamado desde un sistema remoto.
• La complejidad en las comunicaciones de la red es
oculta por stubs y skeletons.
Objetos Distribuidos en
Middleware
•
•
Algunos ejemplos de objetos Middleware Java RMI, CORBA, DCOM.
APIs en el Middleware son explícitamente invocadas por aplicaciones
de usuario para funciones a nivel del control de sistema( transacciones,
seguridad, etc. )
Componentes Basados en
Middleware
•
•
Ejemplos de componentes basados en Middleware: EJB, CORBA
Component Model, COM+
APIs en Middleware son invocadas implícitamente por el component
framework( contenedor de componentes )
Que son los Enterprise Java
Beans ( EJBs )?
•
Definen un modelo de componente estándar del server-side para Java
– Componente y responsabilidades de contenedor e interfaces
– Servicios de interfaces de sistema
•
•
Simplicidad en el desarrollo de enterprise-class, complejas
aplicaciones distribuidas
– Los desarrolladores se enfocan en la lógica de aplicación de
negocios
– Las funciones a nivel de sistema son controladas declarativamente
y realizadas por el contenedor de EJB
Soporte a la aplicación portabilidad y reusabilidad
– Componentes portables plug and play entre contenedores
Tecnologías primarias de EJB
• Java Remote Method Invocation ( RMI )
– Componentes EJB proporcionan interfaces
RMI
• Common Object Request Broker
Architecture( CORBA )
– Muchos conceptos de EJB vienen de CORBA
– Los contenedores EJBs son implementados en
RMI sobre IIOP
• interoperatividad con clientes y servidores CORBA
Tipos de Enterprise Beans
• Session Beans
– Modelan procesos de negocio
• Entity Beans
– Modelan datos de negocio
• Message-driven Beans
– Son capaces de recibir mensajes asíncronos
Roles en los EJBs
•
•
•
•
•
•
Enterprise bean proveedor
Ensamblador de la aplicación
Deployer
Administrador del sistema
Proveedor del Servidor EJB
Proveedor del contenedor de EJB
Ingredientes de un EJB
•
•
•
•
•
Interfaces Home
– Ayudan a crear, encontrar, remover componentes EJB
Interfaces de Componente
– Define métodos de negocio
Enterprise Bean Class
– Implementa métodos definidos en las interfaces home y del componente
– Proporciona métodos de retorno de llamadas invocados por el contenedor
de EJB
Clase de llave Primaria
– Define un tipo de dato para identificar el bean( entity beans )
Deployment descriptor
– Determina como el contenedor EJB maneja los componentes EJB
Lenguaje XML y EJB
Deployment Descriptors
• Los EJB deployment descriptor son
definidos en XML.
• Regularmente un EJB deployment
descriptor esta generado por dos archivos
XML
– Estándar. Contiene información definida en el
estándar EJB
– Especifico del Vendedor.
EJB Archivos jar
• Todos los ingredientes de un componente
EJB son empacados en un archivo JAR
– Un archivo JAR puede contener código de
varios EJBs.
– Hay un descriptor de despliegue para todos los
EJBs en un archivo JAR.
• Los archivos JAR son desplegados usando
herramientas para el contenedor EJB/
servidor proveedor.
Elementos de Código Generado
• Clases stub y skeleton
– Generados durante la compilación o el
despliegue
• Clases EJB Home y EJB Object
– Para interceptar las llamadas de las interfaces
de los componentes Home remote y remote
– Generados durante el despliegue
Ejemplo de EJBs en acción:
registro y lookup
Ejemplo de EJBs en Acción,
creación de un nuevo EJB
Ejemplo de EJBs en acción:
llamadas a métodos de negocio
Interfaces Remote y Acceso
local
•
•
Los EJBs pueden ser llamados:
– Remotamente: desde otro proceso( Aplicaciones Java, applets, etc)
– Localmente: desde otros componentes EJB o componentes Web
desplegados en la misma Maquina Virtual de Java
Las interfaces Remote Home e Interfaz de componente proporcionan
transparencia local.
– Pueden ser usadas para accesar a ambos EJBs localmente y
remotamente
– Los clientes no saben de la ubicación del EJB
– Los datos son pasados por valor( copias caras )
• Incluso si un cliente es local
Interfaces Locales
• Un EJB proporciona interfaces local home y
componente
– Usados por clientes locales
– Todavía, el EJB puede proporcionar interfaces remotas
• Los datos son pasados por referencia( no copias)
• No hay transparencia en la ubicación
– Un cliente remoto no puede llamar a una interfaz local
• Mejora de rendimiento a un precio de perder las
transparencia de la ubicación.
Ejemplo un EJB con interfaces
local y remote
Session Beans
•
•
•
•
Representan procesos de flujo de trabajo, modelan reglas de negocio,
controlan la interacción entre otros beans
No son persistentes
Son agentes que actúan en favor de aplicaciones cliente sobre el lado
del servidor
– Las tareas de los session beans podrían ser implementadas sobre el
lado del cliente
– Los session beans simplifican la vista del cliente del sistema
Pueden mejorar el rendimiento
– Un session bean puede actuar como una encapsulación de otros
beans
– Los clientes llaman al bean encapsulado
– Se reduce el trafico de red
Tipos de session beans
• Session beans sin estado ( stateless )
– No mantienen un estado conversacional
– Son eficientemente administrados por el contenedor
– Ejemplos de servicios que se pueden utilizar:
• Validación de RFC, validación de tarjeta de crédito,
procesamiento por lotes, etc.
• Session bean con estado ( statefull )
– Mantienen un estado conversacional por el contenedor
entre la invocación de métodos
– Ejemplo: un carrito de compras, manejo de sesiones,
etc.
Ejemplo: MultiplicaStateless
session bean
• MultiplicaStateless EJB
– Un sencillo session bean sin estado
– Recibe dos valores enteros y los multiplica
– Regresa el resultado
• Clases e Interfaces a ser escritas:
– MultiplicaStatelessHome ( interfaz home remota )
– MultiplicaStateless ( interfaz remota del componente)
– MultiplicaStatelessBean ( Clase bean )
Interfaz remota home
package sessionbeans;
import javax.ejb.*;
import java.util.*;
import java.rmi.*;
public interface MultiplicaStatelessHome extends javax.ejb.EJBHome {
public MultiplicaStateless create() throws CreateException, RemoteException;
}
Interfaz Remota del Componente
package sessionbeans;
import javax.ejb.*;
import java.util.*;
import java.rmi.*;
public interface MultiplicaStateless extends javax.ejb.EJBObject {
public void multiplicar(int a, int b) throws RemoteException;
public int getResultado() throws RemoteException;
}
Clase Bean Implementación de las llamadas de
retorno y métodos de negocio
package sessionbeans;
import javax.ejb.*;
public class MultiplicaStatelessBean implements SessionBean {
SessionContext sessionContext;
int resultado;
public void ejbCreate() throws CreateException {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sessionContext) {
this.sessionContext = sessionContext;
}
public int getResultado() {
return resultado;
}
public void multiplicar(int a, int b) {
resultado = a * b;
}
}
Herencia Requerida
Deployment Descriptor ejbjar.xml
<ejb-jar>
<enterprise-beans>
<session>
<display-name>MultiplicaStateless</display-name>
<ejb-name>MultiplicaStateless</ejb-name>
<home>sessionbeans.MultiplicaStatelessHome</home>
<remote>sessionbeans.MultiplicaStateless</remote>
<ejb-class>sessionbeans.MultiplicaStatelessBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>MultiplicaStateless</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
Estrategias de administración de
instancias de los bean class
•
•
•
•
•
Los class bean son manejados por un hilo( proceso )
– Los usuarios no tienen que preocuparse por la sincronización y el
manejo de hilos
Para satisfacer peticiones concurrentes el contenedor crea múltiples
instancias
Problema:
– Muchos clientes -> muchas instancias -> exhaustivos recursos
Solución:
– El numero de instancias en memoria debe ser controlado
– Las instancias deben ser reutilizadas lo mas posible
Existen diferentes estrategias de administración para los distintos tipos
de beans
Intercambio de instancias para
session beans sin estado
•
•
Intercambio de instancias
– Posible vencimiento por la falta de un estado conversacional
• Una estancia de un session bean sin estado no esta dedicada a un
cliente
– Una instancia de la clase bean puede ser intercambiada libremente entre
objetos EJB
– Subsecuentemente, llamadas de clientes pueden ser respondidas por
distintas instancias
Es posible una administración eficiente de instancias de bean
– Muchos clientes y objetos EJB pueden usar solamente pocas instancias del
bean
– El intercambio es rápido – no es necesario un estado conversacional para
ser mantenido
– Las instancias del bean que no están ocupadas se mantienen en un pool
Pasivate y Activación de los
session bean con estado
•
•
•
Un session bean con estado mantiene un estado conversacional
relacionado al cliente
– Una instancia del la clase bean es dedicada a un cliente
– Cada llamada a un método desde un cliente es contestada por la
misma instancia del class bean
– No hay intercambio
Los bean class inactivos pueden ser pasivated
– Las instancias de los bean class Son desalojadas de la memoria y
guardadas en un almacén secundario
Como resultado de la siguiente llamada, la instancia puede ser activada
– Regresada del almacenamiento secundario y reasignada en
memoria
Termino del tiempo para los bean
de sesion con estado
• Los beans sin usar pueden ser
permanentemente removidos del contenedor
– El contenedor remueve el bean si el bean a
pasado su tiempo limite de vida
• Un tiempo limite es configurado en el
descriptor de despliegue para cada tipo de
bean
– 0 significa que el bean nunca se le termina su
tiempo
Ejemplo aplicación usando
Session Bens sin estado y con
estado
Entity Beans
• Representan datos almacenados en un
almacenamiento persistente, tal como una base de
datos
• Describe ambos, el estado y el comportamiento
del objeto
• Su intención es ser usados concurrentemente por
múltiples clientes
– Opuestos a los session beans los cuales son dedicados
para un cliente en particular
Tipos de persistencia
•
•
•
El estado de un entity bean debe ser sincronizado con datos en la base de datos
Persistencia se refiere a el protocolo para coordinar el estado de una instancia
del entity bean y la base de datos
Existen dos tipos de persistencia en los entity beans:
– Bean Maneja Persistencia( BMP )
• El desarrollador del bean debe escribir código para manipular la base
de datos
– Contenedor Maneja Persistencia( CMP )
• Los beans tienen su persistencia que es automáticamente manejada
por el contenedor EJB
– Bean Maneja Persistencia( BMP )
• El desarrollador del bean debe escribir código para manipular la base
de datos
Características CMP
• Ventajas
– Simplicidad: no es necesario código para acceder a la
DB
– Portabilidad: el código no depende de una DB
– Flexibilidad: fácil mapeo a otra DB
– Poderosa y potente funcionabilidad
• Muchas optimizaciones implementadas dentro del motor CMP
de cualquier Servidor de Aplicaciones
• Desventajas
– Características especificas de un DBMS no pueden ser
usadas
– Algunas situaciones pueden estar mas allá de las
capacidades del motor de CMP
Características BMP
• Ventajas
– Soporta cualquier mecanismo de persistencia (
incluyendo legacy systems )
– Posibles optimizaciones en DBMS o aplicaciones
especificas
• Desventajas
–
–
–
–
Complejidad: es necesario código para acceder a la DB
Dependencia a una DB
Mapeo fijo, es determinado en el código fuente
Puede ser menos eficiente que un CMP
• No hay optimizaciones disponibles en CMP
El modelo de persistencia que se
recomienda
• Generalmente, CMP es recomendado
excepto cuando:
– Sea requerido un mecanismo de
almacenamiento persistente en un sistema
legacy que no soporte CMP
– Optimizaciones significantes en Aplicaciones o
DBMS específicos puedan ser mejoradas
usando BMP
Ingredientes de un Entity Bean
•
•
•
•
Interfaces Home( remote y/o local )
Interfaces de componente( remote y/o local )
Clase de llave primaria ( opcional )
Clase del bean
Acceso local a entity beans
• Los entity beans a menudo muestran interfaces
locales
• Razones para usar interfaces locales en entity
beans:
– En una aplicación bien diseñada los entity beans son
accedidos solo localmente desde session beans
• Las interfaces locales mejoran el rendimiento de llamadas
locales
– Interfaces locales son necesarias para implementar
relaciones entre entity beans
Ejemplo de una interfaz local
home
package entitybeans;
import javax.ejb.*;
import java.util.*;
public interface PersonaHome extends javax.ejb.EJBLocalHome {
public Persona create(String codigo, String nombre) throws CreateException;
public Collection findAll() throws FinderException;
public Persona findByPrimaryKey(String codigo) throws FinderException;
}
Ejemplo de una interfaz de
componente local
package entitybeans;
import javax.ejb.*;
import java.util.*;
public interface Persona extends javax.ejb.EJBLocalObject {
public String getCodigo();
public void setCodigo(String codigo);
public void setNombre(String nombre);
public String getNombre();
}
Ejemplo un Entity Class Bean
import javax.ejb.*;
abstract public class PersonaBean implements EntityBean {
EntityContext entityContext;
public java.lang.String ejbCreate(java.lang.String codigo, java.lang.String nombre)
throws CreateException {
setCodigo(codigo);
setNombre(nombre);
return null;
}
public void ejbPostCreate(java.lang.String codigo, java.lang.String nombre)
throws CreateException {
}
public void unsetEntityContext() {
this.entityContext = null;
}
...
Ejemplo un Entity Class Bean (2)
...
public void ejbRemove() throws RemoveException {}
public void ejbLoad() {}
public void ejbStore() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setEntityContext(EntityContext entityContext) {
this.entityContext = entityContext;
}
public abstract void setCodigo(java.lang.String codigo);
public abstract void setNombre(java.lang.String nombre);
public abstract java.lang.String getCodigo();
public abstract java.lang.String getNombre();
}
Conexiones a recursos de facto
J2EE
• Son un mecanismo uniforme para establecer
conexiones backends corporativos:
– Bases de Datos
– Interceptores de mensajes
– Legacy Systems
• Los DataSource son un tipo de conexiones a
recursos por de facto que nos sirven para conectar
aplicaciones J2EE a Bases de Datos
Deployment Descriptor
especifico del Vendedor
• Propiedades de los recursos y sus
conexiones
– Database URL, db driver, etc
• Interfaces Home y del Componente
• Especifica un nombre JNDI de una
conexión a recursos de facto( data source )
Ejemplo de un Deployment
<jndi-definitions>
Descriptor
<visitransact-datasource>
<jndi-name>serial://datasources/dbdemos</jndi-name>
<driver-datasource-jndiname>serial://datasources/driverdbdemos
</driver-datasource-jndiname>
<property>
<prop-name>connectionType</prop-name>
<prop-type>Enumerated</prop-type>
<prop-value>Direct</prop-value>
</property>
</visitransact-datasource>
<driver-datasource>
<jndi-name>serial://datasources/driverdbdemos</jndi-name>
<datasource-class-name>com.inprise.visitransact.jdbc1w2.InpriseConnectionPoolDataSource
</datasource-class-name>
<property>
<prop-name>user</prop-name>
<prop-type>String</prop-type>
<prop-value />
</property>
Ejemplo de un Deployment
Descriptor ( 2 )
<property>
<prop-name>password</prop-name>
<prop-type>String</prop-type>
<prop-value />
</property>
<property>
<prop-name>url</prop-name>
<prop-type>String</prop-type>
<prop-value />
</property>
<property>
<prop-name>driverClassName</prop-name>
<prop-type>String</prop-type>
<prop-value />
</property>
</driver-datasource>
</jndi-definitions>
EJB QL ( Lenguaje de Consulta)
• Simple lenguaje de consulta como SQL
• Usado para definir consultas para métodos
finder y select
• Portabilidad e independencia a la DB y al
contenedor
• Una consulta EJB QL es automáticamente
convertida a SQL cuando llama a la DB
Ejemplo de EJB QL
<abstract-schema-name>PersonaSchema</abstract-schema-name>
<cmp-field>
<field-name>codigo</field-name>
</cmp-field>
<cmp-field>
<field-name>nombre</field-name>
</cmp-field>
<primkey-field>codigo</primkey-field>
<query>
<query-method>
<method-name>findAll</method-name>
<method-params />
</query-method>
<ejb-ql>SELECT OBJECT( o ) FROM PersonaSchema AS o</ejb-ql>
</query>
Manejo de instancias de entity
bean class
• Múltiples clientes pueden interactuar con el
mismo entity bean
• El contenedor asigna una instancia por cada
cliente
• El contenedor y/o la DB preservan la
integridad de los datos
Pool de instancias
• El contenedor de EJB mantiene un pool de
instancias de entity bean clase por cada tipo
de entity bean.
• Una instancia de una clase bean puede
representar diferentes entity beans durante
su tiempo de vida.
Ejemplo Aplicación usando
Entity Beans
Session Stateful Bean
Entity Bean