4° Encuentro Internacional de Computación Aplicada

Arquitectura de Objetos Distribuidos utilizando EJBs

Omar Gómezomar@cuci.udg.mx

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

Software bus

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

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)

IDLstub

IDLskeleton

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-ORBso1 o2

S (o1) S (o2)

IDL IDL

Object Request Broker

o3 o4

S (o3) S (o4)

IDL IDL

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 componentframework( 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 ejb-jar.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 uncliente

– 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 manejadapor 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 Beanimport 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 Descriptor<jndi-definitions>

<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