Estudios de Doctorado Avances en Informtica Curso Objetos Distribuidos: Nuevos Avances y Plataformas Universidad de Oviedo

Aplicacin de Objetos Distribuidos para la construccin de Aplicaciones Web basadas en Tecnologa Java

Daniel Fernndez Lanvin 20217190Y dflanvin@hotmail.com

Tabla de Contenidos

Introduccin.................................................................................................................. 3 Aplicaciones WEB........................................................................................................ 3 Evolucin.................................................................................................................. 3 Modelo 1............................................................................................................... 3 Modelo 1.5............................................................................................................ 3 Modelo 2............................................................................................................... 3 Modelo 2X............................................................................................................ 4 Definicin de la arquitectura software ........................................................................... 4 Aspectos generales.................................................................................................... 5 Objetos distribuidos java............................................................................................... 9 Enterprise JavaBeans ................................................................................................ 9 EJBs de tipo Entidad ........................................................................................... 10 EJBs de tipo Sesin............................................................................................. 10 Message Driven Beans ........................................................................................ 11 RMI ........................................................................................................................ 11 Web Services .......................................................................................................... 12 Aplicacin de Objetos distribuidos a aplicaciones Web............................................... 13 Separacin lgico-fsica de capas con objetos distribuidos ...................................... 13 Separacin fsica de las capas.............................................................................. 13 Persistencia de entidades con EJBs entidad. Beneficios y problemas ....................... 17 Descomposicin funcional del sistema. Modelo colaborativo distribuido ................ 18 Descomposicin en microaplicaciones ................................................................ 19 Integracin con Legacy Systems con MessageDrivenBeans con comunicacin asncrona................................................................................................................. 20 Bibliografa................................................................................................................. 22

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Introduccin
El objeto de este documento es considerar las distintas aplicaciones que se dan hoy en da a las tecnologas de objetos distribuidos en el sector del desarrollo web. Las soluciones descritas en este documento estn modeladas en el mbito de las aplicaciones java / j2ee, dado que es la combinacin ms habitual y que ms posibilidades ofrece a nivel arquitectnico y de aplicacin de patrones de diseo. No obstante, la mayor parte de los patrones descritos son perfectamente adaptables a otro tipo de tecnologas de objetos distribuidos, como COM / DCOM o servicios CORBA, o incluso combinables entra ellos, como por ejemplo emplear un cliente de EJBs para atacar un objeto CORBA mediante IIOP.

Aplicaciones WEB
Lo que el mercado demanda actualmente son mayormente aplicaciones web, que permitan a las empresas tradicionales llegar al cliente de a pi sin necesidad de que ste se desplace hasta la ubicacin fsica de la misma. Partiendo de este tipo de productos, adems de la tecnologa empleada para dar solucin al problema, se han ido creando y perfeccionando distintas arquitecturas ms o menos independientes de la tecnologa aplicada. Dentro de esta familia de aplicaciones o herramientas, hay que destacar el papel que el lenguaje JAVA, junto con sus extensiones J2EE y el apoyo del mundo open-source estn jugando.

Evolucin
La evolucin tecnolgica que el sector ha sufrido durante los ltimos aos ha permitido otra evolucin paralela, la de la arquitectura de las aplicaciones web. A medida que aparecan nuevos recursos tcnicos, los patrones de diseo se amoldaban para aprovechar las nuevas caracterstica que ests novedades ofrecan. De esta forma, el modelo arquitectnico de las aplicaciones de Internet ha sufrido dos grandes saltos desde la aparicin de los primeros portales. Los distintos modelos de aplicacin sobre los que ha ido desarrollando se clasifica en:

Modelo 1
Son las ms primitivas. Se identifican con este modelo las clsicas aplicaciones web CGI, basadas en la ejecucin de procesos externos al servidor web, cuya salida por pantalla era el html que el navegador reciba en respuesta a su peticin. Presentacin, negocio y acceso a datos se confundan en un mismo script perl.

Modelo 1.5
Aplicado a la tecnologa java, se da con la aparicin de las pginas ASP de Microsoft, y posteriormente jsps y los servlets. En este modelo, las responsabilidades de presentacin (navegabilidad, visualizacin, etc) recaen en las pginas dinmicas generadas en el servidor, mientras que los componentes incrustados en las mismas (javabeans, ActiveX, etc) son los responsables del modelo de negocio y acceso a datos.

Modelo 2
Como evolucin del modelo 1.5 con la incorporacin del patrn MVC a este tipo de aplicaciones, se define lo que se conoce como Model 2 de la arquitectura web. En el diagrama siguiente se aprecia la incorporacin de un elemento controlador de la

Objetos Distribuidos

Universidad de Oviedo

-3 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

navegacin de la aplicacin. El modelo de negocio queda encapsulado en los componentes que se incrustan en las pginas de servicor, aunque como se ver a lo largo del resto del documento, esta responsabilidad se explota cuando se alcanza el modelo de diseo n-capas[FOW02].

Modelo 2X
El modelo 2X aparece como evolucin del modelo 2, y con objeto de dar respuesta a la necesidad, cada vez ms habitual, de desarrollar aplicaciones multicanal, es decir, aplicaciones web pueden ser atacadas desde distintos tipos de clientes remotos. As, una aplicacin web multicanal podr ejecutarse desde una PDA, desde un terminal de telefona mvil, o desde cualquier navegador html estndar. El medio para lograr publicar la misma aplicacin para distintos dispositivos es emplear plantillas XSL para transformar los datos XML y determinar la plantilla a emplear en base al parmetro user-agent recibido en la request. La aplicacin de esta solucin al modelo 2 de aplicaciones web define lo que se conoce como modelo 2X [STXX][MERC02].

Definicin de la arquitectura software

Para poder comprender las ventajas que aporta la aplicacin de las distintas soluciones distribuidas aqu descritas al desarrollo de aplicaciones web, primer es recomendable realizar una serie de reflexiones acerca de las cualidades que dichos productos deben tener para garantizar unos mnimos de calidad. En este apartado se recogen las cualidades deseables en este tipo de aplicaciones, los aspectos que es
Objetos Distribuidos Universidad de Oviedo

-4 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

necesario tener en cuenta para obtener un producto fiable, escalable y, sobre todo, mantenible.

Aspectos generales
A la hora de abordar el desarrollo de un proyecto web, hay una serie de consideraciones acerca del mismo que hay que tener muy presentes, dado que son claves en que tipo de diseo y metodologas de desarrollo aplicar. Separacin de responsabilidades o incumbencias entre los distintos elementos del sistema. Esta premisa supone la base de la separacin en capas del sistema. Distintas responsabilidades no deben ser delegadas en la misma clase, y llevado esto algo ms all, en el mismo conjunto de clases. En la actualidad, la tendencia ms aceptada es la aplicacin de patrones de diseo de arquitectura que dividen la responsabilidad en distintas capas (separacin de incumbencias) que interaccionan unas con otras a travs de sus interfaces. Se trata de los sistemas denominados multicapa o n-capas [JURI00]. Aplicados a los proyectos web, el modelo ms bsico es el de aplicaciones 3 capas: 1. Presentacin Como su nombre indica, se limita a la navegabilidad y a gestionar todos aquellos aspectos relacionados con la lgica de presentacin de la aplicacin, como comprobacin de datos de entrada, formatos de salida, internacionalizacin de la aplicacin, etc. 2. Negocio o dominio El resultado del anlisis funcional de la aplicacin viene a ser la identificacin del conjunto de reglas de negocio que abstraen el problema real a tratar. Ests son las que realmente suponen el motor del sistema, dado que se basan en el funcionamiento del modelo real. En un caso hipottico de un programa de gestin cualquiera, estaramos hablando, por ejemplo, del conjunto de operaciones que dan el servicio de negocio emisin de factura. 3. Acceso a datos Esta capa es la encargada de persistir las entidades que se manejan en negocio, el acceso a los datos almacenados, la actualizacin, etc, aunque puede ofrecer servicios relacionados con la persistencia o recuperacin de informacin ms complejos.

Objetos Distribuidos

Universidad de Oviedo

-5 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Tomando como base este modelo, distintos patrones arquitectnicos han ido apareciendo como evolucin del mismo (Modelo Brown [FOWL02], los patrones de Sun, etc.), casi todos insertando ms capas que habitualmente estn orientadas a conseguir una mayor independencia entre las tres anteriormente descritas.

La separacin en capas de las distintas clases que, en base a su actuacin sobre las entidades, se responsabilizan de tareas distintas, choca de plano con el principio bsico de la orientacin a objetos. Si atendiramos a este principio complemente, cada entidad del sistema debiera ser capaz y responsable de autopersistirse y representarse a si misma. As, una misma entidad acaparara funcionalidad de las distintas capas aqu identificadas. La identificacin de las responsabilidades de la capas como servicios del sistema invita a retirar parte de la lgica de la entidad (como la persistencia) de la clase que la modela y delegarla en otras clases especializadas en ello. Esta variacin del paradigma permite el desarrollo de aplicaciones ms fciles de mantener, dado que se agrupa en un mismo conjunto de clases toda la lgica comn. Escalabilidad Una de las caractersticas principales de las aplicaciones publicadas en la Web es que el nmero de usuarios de la misma puede verse incrementado de forma vertiginosa en un periodo de tiempo relativamente corto. El xito o el fracaso de un sitio web orientado al usuario comn determinarn, entre otros aspectos, el dimensionamiento del sistema sobre el que se instala y soporta el software que sustenta dicho sitio. En consecuencia, una de los requisitos fundamentales de una aplicacin web es que sea completamente escalable sin que un aumento de los recursos dedicados a la misma suponga modificacin alguna en su comportamiento o capacidades. La escalabilidad de un sistema web puede ser: Horizontal: cuando literalmente clonamos el sistema en otra mquina (u otras mquinas) de caractersticas similares y balanceamos la carga de trabajo mediante un dispositivo externo. El balanceador de carga puede ser: Balanceador Software Por ejemplo, habitualmente encontramos un servidor web apache junto con el mdulo mod_jk que permite redireccin las peticiones http que a tal efecto sean configuradas entre las distintas mquinas que forman la granja de servidores.
Objetos Distribuidos Universidad de Oviedo

-6 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Este tipo de balanceadores examinan el paquete http e identifican la sesin1 del usuario, guardando registro de cual de las mquinas de la granja se est encargado de servir a dicha sesin. Este aspecto es importante, dado que nos permite trabajar (de cara al diseo de la aplicacin) apoyndonos en el objeto session propio del usuario y almacenando en ella informacin relativa a la sesin del mismo, puesto que tenemos la garanta de que todas las peticiones de una misma sesin http van a ser redireccionadas hacia la misma mquina. Balanceador hardware Se trata de dispositivos que, respondiendo nicamente a algoritmos de reparto de carga (Round Robin, LRU, etc.), redireccionan una peticin http del usuario a la mquina que, segn dicho algoritmo, convenga que se haga cargo de la peticin. Son mucho ms rpidos de los anteriores, dado que se basan en conmutacin de circuitos y no examinan ni interpretan el paquete http. Sin embargo, el no garantizar el mantenimiento de la misma sesin de usuario en la misma mquina, condiciona seriamente el diseo, dado que fuerza a que la informacin relativa a la sesin del usuario sea almacenada por el implementador del mismo, bien en cookies o bien en base de datos2. Balanceador hardware http- Se trata de dispositivos hardware pero que si que examinan el paquete http y mantienen la relacin usuario mquina servidora. Mucho ms rpidos que los balanceadores software, pero algo menos que los hardware, suponen hoy en da una de las soluciones ms aceptadas en el mercado. Vertical: Habitualmente, la separacin lgica en capas se implementa de tal forma que se permita una separacin fsica de las mismas. Interponiendo elementos conectores que acten de middlewares (por ejemplo, EJBs [ROMA01] o servicios CORBA), es posible distribuir la aplicacin de forma vertical (una mquina por cada capa del sistema), e incluso si esto no fuera suficiente, distribuyendo los elementos de una misma capa entre distintas mquinas servidoras, lo cual implica una distribucin horizontal selectiva dentro de cada una de las capas. Cluster: Con la aparicin de los servidores de aplicaciones en cluster se abre una nueva capacidad de escalabilidad que, dependiendo de cmo se aplique, podra clasificarse como vertical u horizontal. Un cluster de servidores de aplicaciones permite el despliegue de una aplicacin web corriente de forma que su carga de trabajo vaya a ser distribuida entre la granja de servidores que forman el cluster, de modo transparente al usuario y al administrador. El cluster, mediante el mecanismo de

Se define la sesin del usuario como la secuencia de eventos que ha provocado desde que el usuario comienza su ejecucin de la aplicacin. 2 Al mantener la informacin de sesin en base de datos, es accesible desde cualquiera de las instancias de la aplicacin. No obstante, es necesario controlar la caducidad de la misma para evitar un crecimiento desmesurado del repositorio. Objetos Distribuidos Universidad de Oviedo

-7 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

replicacin de sesin, garantiza que sea cual sea la mquina que sirva la peticin http tendr acceso a la sesin del usuario (objeto HttpSession en java). Este tipo de sistemas, debido precisamente a la replicacin de sesin, suele presentar problemas de rendimiento. Pese a que hace un tiempo la tendencia de diseo era contraria al empleo de la sesin (objeto session) como soporte de apoyo en el desarrollo del sistema, sobre todo debido a problemas de rendimiento y a la abundancia de balanceadores hardware comunes, hoy en da es habitual el empleo de la misma. No obstante, es un recurso delicado, dado que un abuso de est tcnica acarrea problemas de rendimiento por un excesivo uso de memoria. Hay que tener en cuenta a la hora de hacer el diseo de una aplicacin web java que, hasta que la sesin no caduque, todos los objetos contenidos en la misma que no hayan sido eliminados explcitamente persisten en la memoria del servidor, puesto que no estn disponibles para el recolector de basura. Portabilidad En la medida de lo posible, una aplicacin web debe poder adaptarse a las distintas posibles arquitecturas fsicas susceptibles de ser empleadas para el despliegue del paquete, limitndose en la medida de lo posible el impacto de tal adaptacin a tareas de configuracin, y evitndose as la necesidad de modificar el cdigo de la misma ante dichas situaciones. Un ejemplo que se da habitualmente, es el encontrar un cliente reacio al empleo de tecnologas J2EE por los consabidos costes de rendimiento (o simplemente econmicos) que acarrean. Dado que el modelo de separacin fsica de capas mediante Enterprise javabeans de tipo sesin implementando el patrn de diseo Faade [GOF94][JURI00] es algo habitual y recomendado desde muchos mbitos acadmicos, surge la necesidad de modificar el cdigo del producto para eliminar las capas intermedias, puesto que no se cuenta con un contenedor el EJBs para la implantacin. Componentizacin de servicios de infraestructura En todas las aplicaciones, incluidas las aplicaciones web, aparecen una serie de servicios que podramos denominar de infraestructura, y que han de estar disponibles desde distintas partes del sistema. As, esta necesidad rompe aparentemente la separacin vertical de capas, dando lugar a una capa de infraestructura que sirve funcionalmente a todas las dems. Casos habituales de servicios de esta naturaleza son: Servicio de log Pool de conexiones JDBC (o de cualquier otro sistema de persistencia) Sistema de configuracin Gestor de accesos/permisos de usuario. Etc.

La arquitectura propuesta pretende tratar este conjunto de servicios como componentes, servicios de la capa de infraestructura, de forma que:

Objetos Distribuidos

Universidad de Oviedo

-8 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

1. 2.

Puedan ser sustituidos por nuevas versiones sin necesidad de parada del sistema ni recompilacin y/o repaquetizacin del mismo Puedan ser reutilizados por futuros proyectos o distintas partes del mismo, evitando que en un mismo sistema coexistan n distintos gestores de permisos, n distintos proveedores de conexiones a bases de datos, gestores de logs, etc. Sean accesibles desde todas las capas del sistema sin romper la independencia entre las mismas.

3.

Gestin de la sesin de usuario, cacheado de entidades Con objeto de limitar en la medida de lo posible los accesos innecesarios a memoria secundaria (bases de datos, ficheros externos de configuracin, etc) se propone un sistema que se apoya en parte en el empleo de la sesin HTTP(s) para cachear ciertos datos referentes a la sesin del usuario, o bien comunes a todas las sesiones de usuario. Obviamente, la cantidad y naturaleza de las entidades susceptibles de ser cacheadas ser determinada teniendo muy presentes aspectos de rendimiento del producto, dado que un empleo abusivo de esta tcnica puede y suele llevar a un consumo excesivo de los recursos del sistema (memoria).

Aplicacin de patrones de diseo El empleo y aplicacin de patrones de diseo [GOF94] facilita el entendimiento del cdigo y, por tanto, reduce considerablemente el coste de mantenimiento, dado que adems de aportar soluciones eficientes para problemas comunes, son muy interesantes como medio de entendimiento entre diseadores e implementadores.

Objetos distribuidos java

Aunque el objeto principal de este documento no es describir en profundidad todas las tecnologas de objetos distribuidos java existentes en el mercado, sino su aportacin y posibles aplicaciones al sector de desarrollo de productos web, si se describirn someramente las soluciones distribuidas de las que se hablar posteriormente, a la hora de aplicarlas para alcanzar los distintos aspectos deseables descritos en el apartado anterior.

Enterprise JavaBeans
La especificacin de JavaBeans Enterprise (EJB) define una arquitectura para el desarrollo y despliegue de aplicaciones basadas en objetos distribuidos transaccionales, software de componentes del lado del servidor. Las organizaciones pueden construir sus propios componentes o comprarlos a vendedores de terceras partes. Estos componentes del lado del servidor, llamados beans enterprise, son objetos distribuidos que estn localizados en contenedores de JavaBean Enterprise y proporcionan servicios remotos para clientes distribuidos a lo largo de la red. Los interfaces remoto y home son tipos de interface "Java RMI Remote" . El interface java.rmi.Remote se usa con objetos distribuidos para representar el bean en un espacio de direccionamiento diferente (proceso o mquina). Un bean enterprise es un objeto distribuido, esto significa que la

Objetos Distribuidos

Universidad de Oviedo

-9 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

clase bean es ejemplarizada y vive en un contenedor pero puede ser accedida por aplicaciones que viven en otros espacios de direccionamiento. Internamente, los EJBs pueden emplear tanto RMI como IIOP (protocolo definido por CORBA), aunque esto es totalmente transparente al usuario del objeto remoto, dado que ni siquiera se percatar de si el objeto se encuentra en su misma mquina o en otra a miles de kilmetros de distancia.

EJBs de tipo Entidad

El bean de entidad es uno de los tres tipos de beans primarios. El bean de entidad es usado para representar datos en un base de datos. Proporciona un interface orientado a objeto a los datos que normalmente seran accedidos mediante el JDBC u otro API. Ms que eso, los beans de entidad proporcionan un modelo de componentes que permite a los desarrolladores de beans enfocar su atencin en la lgica de negocio del bean, mientras el contenedor tiene cuidado de manejar la persistencia, las transacciones, y el control de accesos. Hay dos tipos de beans de entidad: Persistencia Manejada por el Contenedor (CMP) y Persistencia Manejada por el Bean (BMP). Con CMP, el contenedor maneja la persistencia del bean de entidad. Las herramientas de los vendedores se usan para mapear los campos de entidad a la base de datos y no se escribe ningn cdigo de acceso a las bases de datos en la clase del bean. Con BMP, el bean de entidad contiene cdigo de acceso a la base de datos (normalmente JDBC) y es responsable de leer y escribir en la base de datos su propio estado. Las entidades BMP tienen mucha ayuda ya que el contenedor alertar al bean siempre que sea necesario hacer una actualizacin o leer su estado desde la base de datos. El contenedor tambin puede manejar cualquier bloqueo o transaccin, para que la base de datos se mantenga ntegra.

EJBs de tipo Sesin

Loes EJBs de tipo sesin son objetos distribuidos puros, cuya implementacin no ha de estar ligada a ningn sistema de persistencia de entidades, como en el caso anterior. Responden exactamente al modelo de objetos de CORBA, con la salvedad de que en su creacin fuerzan la aplicacin del modelo factora3. Desde el punto de vista del usuario del bean, contar con una clase cuyos mtodos podr invocar de forma habitual, sin conocer si la ejecucin del mtodo se realiza en la misma mquina o en otra distinta. Dentro de los EJBS de sesin se distinguen dos tipos. Con estado El objeto remoto es capaz de garantizar que su estado va a mantenerse para el mismo usuario del objeto entre distintas invocaciones. As, si en la invocacin 1 se cambia el valor de uno de los atributos del objeto, en la siguiente invocacin desde la misma clase, el valor nuevo del atributo se conservar. El mantenimiento de este estado implica la serializacin del estado del bean cuando el objeto remoto es compartido (en un pool, habitualmente) por varios clientes remotos, lo cual supone un coste importante que pone en duda el posible rendimiento de este tipo de solucin.
3

Sin estado

Tambin aplicable a objetos CORBA Universidad de Oviedo

Objetos Distribuidos

-10 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Los EJBs de sesin sin estado no garantizan el mantenimiento del estado del objeto remoto entre dos invocaciones sucesivas del mismo cliente. Esto sujeta al diseador del sistema a mantener el estado de la sesin en la parte del sistema que est por encima de la capa delimitada por los objetos distribuidos. No obstante, pese a este inconveniente, se facilita la reutilizacin de objetos en pools, y se evitan los posibles problemas de rendimiento derivados de la serializacin contnua del estado de los beans.

Message Driven Beans

Los Message Driven Beans (MDBs) se incorporarn a la especificacin de EJBs, en la versin 2.0 de la misma. Rompiendo parcialmente la filosofa de sus hermanos de entidad y sesin, los MDBs funcionan con invocaciones asncronas, como clientes de colas de mensajes. Una mensaje emitido desde un objeto a otro se denomina asncrono cuando el flujo de ejecucin no se detiene esperando el retorno del mtodo invocado, tal y como sucede en una invocacin corriente desde una clase a otra. As, este tipo de objetos son una mezcla entre cliente JMS4 y beans Enterprise de sesin sin estado, dado que cuentan con la flexibilidad del primero, y las caractersticas que le confiere el estar gestionado por un contenedor de EJBs de los segundos (seguridad, gestin de transacciones distribuidas, concurrencia, etc). Esta forma de actuar resulta ideal para la integracin de sistemas nuevos con los ya existentes5 en el entorno de despliegue, como se ver ms adelante.

RMI
Remote Method Invocation (RMI) deriva del obligado salto a la orientacin a objetos de las clsicas RPCs. Las RPCs permitan la invocacin remota y transparente de funciones cuya ejecucin poda realizarse bien en local o bien en una mquina
4

Java Messaging service, especificacin J2EE para el tratamiento de mensajera asncrona por medio del paso de mensajes, colas, etc. 5 Legacy Systems Objetos Distribuidos Universidad de Oviedo

-11 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

distante sin que el proceso invocante fuera consciente de ello, ni el programador supeditado a esta circunstancia. Una funcin RPC se invoca como cualquier otra funcin del programa. Las RMIs son invocaciones de mtodos de objetos remotos. Mediante el mismo mecanismo que las RPCs, es decir, con un stub de cliente y otro de servidor, las tareas de localizacin del servicio remoto, empaquetamiento, encriptacin e invocacin son realizadas por los stubs, de forma que la clase invocante se limita a invocar un mtodo y recibir el resultado. De esta forma, se permite crear aplicaciones java distribuidas, que repartan la carga de procesamiento entre los distintos elementos fsicos que forman el sistema distribuido. Sobre RMI si soportan las invocaciones remotas que permiten a los EJBs ejecutar mtodos de objetos remotos.

Web Services
Podemos definir un servicio web como un compendio de tres mecanismos complementarias: 1. Publicacin de servicios mediante los directorios UDDI. 2. Localizacin de servicios. 3. Invocacin de servicios sirvindose del protocolo SOAP. De los tres mecanismo, el ms interesante es el que nos permite realizar invocaciones remotas mediante el protocolo SOAP. SOAP es un protocolo de mensajera XML extensible que forma la base de los Servicios Web. Proporciona un mecanismo simple y consistente que permite a una aplicacin enviar mensajes XML a otra aplicacin. Un mensaje SOAP es una transmisin de una va desde un emisor SOAP a un receptor SOAP, y cualquier aplicacin puede participar en este intercambio como emisor o receptor. Los mensajes SOAP se pueden combinar para soportar muchos comportamientos de comunicacin, incluyendo, solicitud/respuesta, respuesta solicitada, mensajera asncrona de una va, o incluso notificacin. SOAP es un protocolo de alto nivel que slo define la estructura del mensaje6 y unas pocas reglas para su procesamiento. Es completamente independiente del protocolo de transporte subyacente, por eso los mensajes SOAP se pueden intercambiar sobre HTTP, JMS o protocolos de transporte de e-mail. Actualmente el protocolo HTTP es el ms utilizado para los mensajes HTTP. En esta ltima cualidad radica el aspecto ms interesante de los servicios web, dado que la posibilidad de trabajar sobre HTTP evita la limitacin que presentan todas las tecnologas anteriormente citadas. Los protocolos RMI e IIOP se soportan sobre invocaciones binarias. Este tipo de comunicaciones, debido a razones de seguridad, suelen estar cerradas en los proxies que delimitan el acceso a las intranets desde el exterior. Debido a ello, los sistemas distribuidos basados en RMI e IIOP estan limitados al mbito de la Intranet, lo que reduce su capacidad de integracin y delegacin de tareas en terceros sistemas. Sin embargo, el protocolo SOAP trabaja con XML sobre http. Sus paquetes son cadenas de texto plano que acceden a la Intranet a travs del puerto 80, siendo perfectamente comprensibles y sencillos de filtrar y examinar. Lgicamente, esta caracterstica obliga a delegar ciertas tareas de seguridad en otros procesos, dado que esta es una de las principales cualidades de RMI e IIOP.

Lo que se denomina envelope (sobre) SOAP Universidad de Oviedo

Objetos Distribuidos

-12 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Aplicacin de Objetos distribuidos a aplicaciones Web

En esta apartado se trata de discurrir como, mediante las tecnologas de objetos distribuidos, se consigue cumplir o alcanzar algunos de los objetivos base marcados en los apartados anteriores.

Separacin lgico-fsica de capas con objetos distribuidos

A la hora de plantear el diseo de una aplicacin web, el primer paso es conseguir separar conceptualmente las tareas que el sistema debe desempear entre las distintas capas lgicas y en base a la naturaleza de tales tareas. Se ha de partir de la separacin inicial en tres capas, diferenciando que proceso de los que hay que modelar responde a tareas de presentacin, cual a negocio y cual a acceso a datos. En caso de identificar algn proceso lgico que abarque responsabilidades adjudicadas a dos o ms capas distintas, es probable que dicho proceso deba ser explotado en subprocesos iterativamente, hasta alcanzar el punto en el que no exista ninguno que abarque ms de una capa lgica. No es objeto de este estudio el analizar la coleccin de responsabilidades achacables a cada capa ms all de lo ya introducido en la descripcin de los aspectos generales de una aplicacin web. Si lo es, sin embargo, analizar la separacin fsica de las mismas, el pos de obtener una aplicacin escalable verticalmente, entendiendo la escalabilidad vertical tal y como se defini anteriormente.

Separacin fsica de las capas

La evolucin del modelo 3-capas al modelo n-capas pasa por la incorporacin de las capas intermedias que permiten desacoplar las primitivas y distribuirlas por medio de algn tipo de middleware. As, cada una de las capas deber ser vista como un conjunto de servicios desde la capa superior, encapsulando la lgica que implementen, y ser accedidas por medio de una capa intermedia de integracin que oculte a la capa superior los detalles de acceso a la inferior. Es labor de esta capa intermedia el servir de puente entre ambas capas. Como consecuencia de estar trabajando en un entorno orientado a objetos, las distintas soluciones tcnicas que podemos adoptar para la implementacin de estas capas son principalmente las basadas en las tecnologas citadas anteriormente en el documento:
Objetos Distribuidos Universidad de Oviedo

-13 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

1. Servicios RMI. Como se vio anteriormente, un servicio RMI permite la invocacin de mtodos de objetos remotos, situados en espacios de memoria distintos y, probablemente, mquinas tambin distintas. Es posible entonces emplear esta solucin tecnolgica para unir dos capas adyacentes de una aplicacin web. Para independizar a la capa superior del middleware empleado para unirla con la inferior, se encapsula toda la lgica dependiente de dicho middleware dentro de una clase Helper [GOF94], de forma que futuras sustituciones en el mtodo de unin entre capas se limiten a la modificacin de una clase. As, el helper se ocupara de las tareas de configuracin, localizacin e invocacin del servicio. Las clases de la capa superior veran en el helper la interfaz de la capa inferior, dado que se deber implementar en el helper un mtodo por cada uno de los servicios ofrecidos por la capa inferior. Distribuida con la capa inferior, tendremos la implementacin de los servicios RMI, que se limitaran a invocar a las clases de la capa que implementen los servicios solicitados desde la capa superior. Esta solucin nos permite distribuir la aplicacin entre distintas mquinas, pudiendo desgranar cada capa en servicios, y colocar un servicio en cada mquina disponible. 2. Servicios WEB Al igual que se puede emplear un servicio RMI para distribuir las distintas capas del sistema, es posible tambin construir las capas intermedias basndose en el empleo de servicios Web. La ventaja principal que obtendramos con esta variacin es la ya descrita anteriormente: superar la barrera que delimita la Intranet del exterior a travs del puerto 80 del firewall. No obstante, el tratamiento de XML es ms costoso en cuanto a memoria y tiempo de procesamiento que las invocaciones RMI, lo cual sugiere que a no ser que sea necesario acceder a servicios externos a la Intranet, es preferible de cara al rendimiento del sistema la solucin anterior. 3. EJBs de tipo Sesin Las dos soluciones anteriores, aunque perfectamente vlidas, tienen una seria limitacin para el desarrollo de aplicaciones web. El principio de separacin lgica y fsica de capas implica que los procesos de negocio son implementados en una capa superior a la de persistencia. Es habitual, sobre todo en los proyectos de comercio electrnico, la necesidad de realizar operaciones de persistencia de entidades de carcter atmico, en las cuales la ejecucin parcial de las mismas lleva a la base de datos a un estado de inconsistencia. La forma de conseguir que las operaciones de la capa de negocio puedan estar dotadas de este carcter es el empleo de transacciones distribuidas. Tanto los servicios web, como los RMI carecen de control transaccional. En caso de que fuera necesario ejercer tal control, necesitaramos delegarlo en monitores transaccionales externos como TUXEDO. La incorporacin de este tipo de herramientas es cara y dispara el coste del producto, por lo que se emplea slo en proyectos de gran envergadura. Sin embargo, los EJBs estn dotados de esta interesante caracterstica. El contenedor de EJBs que cumpla con la especificacin J2EE

Objetos Distribuidos

Universidad de Oviedo

-14 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

controla las transacciones distribuidas en las que participan los componentes que gestiona. Se deduce as como la ms recomendable de las tres la solucin basada en el empleo de EJBs de sesin como implementacin de las capas intermedias. Bajo este prisma, los EJBs actan como objetos tontos, carentes de lgica alguna, cuyo cometido nico es hacer de puente entre la capa superior y la inferior, ocultando la lgica que ejecutan los mtodos que publica. Este funcionamiento responde al del patrn de diseo Faade[GOF94].

El modelo recomendado y en boga a da de hoy es pues el que se sirve de EJBs de tipo sesin mostrando a la capa superior el conjunto de servicios que ofrece la capa inferior, al mismo tiempo que posibilita la invocacin remota de los mismos de forma transparente al usuario del servicio. De esta forma la separacin lgica entre capas pasa a ser tambin fsica, y se consigue dotar a la aplicacin de escalabilidad vertical. No obstante, este tipo de arquitectura presenta an un problema importante. Cuando la aplicacin no est distribuida verticalmente, porque quiz no sea necesario an (pocos usuarios), y se encuentra desplegada en una sola mquina, se estn realizando invocaciones RMI o IIOP al localhost por cada solicitud de servicio que se realice de una capa a otra. Esto, lgicamente, presenta un coste innecesario que puede provocar un descenso de rendimiento importante en el sistema, puesto que el proceso de realizar una invocacin remota por RMI (o IIOP7) resulta bastante pesado. En respuesta a esta problemtica, Sun Microsystems decidi extender la especificacin de EJBs aprovechando la publicacin de la versin 2.0 de la misma con la incorporacin de los interfaces locales. Con ellos, el desarrollador conserva la separacin de responsabilidades, dado que sigue trabajando con el mismo interfaz del servicio, pero con la salvedad de que lo que se est realizado por debajo no es una llamada remota, sino una simple invocacin local de la clase que implementa el interfaz. Se soluciona de este modo el problema del rendimiento, pero la aplicacin sigue dependiendo de la presencia de un contenedor de EJBs, pese a que su aportacin al sistema no es necesaria en absoluto, dado que, al menos en lo que a la distribucin de las capas se refiere8, no se realizan invocaciones remotas. Esto incide negativamente en
Protocolo de comunicacin de CORBA que pueden emplear los Enterprise javabeans. Es importante tener en cuenta que estamos partiendo de la suposicin de que no se estn empleando EJBs de tipo entidad para el acceso a base de datos o cualquier otra funcin, sino simplemente EJBs de tipo sesin para la separacin entre capas.
8 7

Objetos Distribuidos

Universidad de Oviedo

-15 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

la portabilidad del producto, dado que es posible que se imponga la implantacin del mismo sobre una arquitectura fsica basada en un servidor web y un motor de jsps y servlets. En el caso habitual de que la aplicacin slo empleara EJBs a modo de middleware entre capas, estaramos limitando la portabilidad de la misma por un aspecto ajeno a su funcionalidad principal, o imponiendo al cliente la incorporacin a su sistema de un contenedor de EJBs. Dado que esto no es factible, se ha de optar por una solucin alternativa que, limitndose a tareas de configuracin del producto, permita ser desplegado tanto en sistemas no escalables verticalmente (es decir, careciendo de la separacin fsica de las capas por medio de EJBs) como en los que si cuentan con un contenedor de EJBs y permiten dicha escalabilidad. El siguiente patrn ofrece una solucin acorde con estas premisas, apoyndose en la capa de infraestructura concebida tal y como se describe en este documento. En el diagrama se muestra un ejemplo de cmo aplicar dicho patrn a la separacin entre la capa de presentacin y la capa de negocio. En l se muestran las relaciones existentes entre las clase necesarias para un escenario bien sin distribucin vertical, o bien con ella empleando EJBs de tipo sesin sin estado a modo de fachadas.

Objetos Distribuidos

Universidad de Oviedo

-16 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

El patrn de diseo que define este tipo de solucin es el Business Delegate[GOF94]. La funcin de los distintos elementos del diagrama ser: xxxServiceHelper El service helper funciona como elemento encapsulador del puente entre el servlet de presentacin y el business bean en negocio. Simplifica la resolucin del medio para llegar a la clase de negocio. Por medio del ServiceLocator (servicio de la capa de infraestructura), recupera la clase que implementa la interfaz del servicio de negocio, en base a la configuracin actual de la capa de infraestructura. Esta puede ser bien una clase normal que simplemente invoque lo mtodos del bean de negocio (modelo sin distribuir), bien un Enterprise JavaBean de tipo Session (modelo distribuido), o incluso un cliente RMI, cliente SOAP, etc. En el caso de un modelo sin distribucin vertical, se tratar de una clase normal, permitindose as el despliegue del producto en una arquitectura fsica desprovista de contenedores de EJBs. ServiceLocator A esta clase se le pide que resuelva cual es el componente que, en base a un fichero XML de configuracin de la capa de infraestructura, debe instanciar en un momento para la interfaz que se le solicita. Ser esta la que le sirva al helper el bridge a la clase de negocio. Habitualmente, se tratar de un singleton. Al estar configurada por medio de un fichero externo, el administrador del sistema puede establecer el bridge a usar (es decir, la clase que debe implementar la interfaz del servicio en cada ejecucin) editando un fichero xml plano, y permitiendo as adaptar el sistema a distintos entornos sin necesidad de recodificar o repaquetizar el producto. xxxServiceLocator Cuando el puente sea una clase simple, el ServiceLocator retornar una instancia de esta clase, que se limita a llamar a los mtodos del bean de negocio cuando se invoquen los correspondientes a travs del interfaz. En el diagrama esta clase aparece como xxxSimpleServiceLocator. En caso de una distribucin basada en EJBs, se retornara el stub de cliente, el cual invocara a bean de implementacin del EJB, que a su vez invocara el bean de negocio. De esta forma, es transparente al implementador de la capa de presentacin la forma con la que se invoca la capa de negocio.

Persistencia de entidades con EJBs entidad. Beneficios y problemas

Los EJBs de entidad estn pensados para ofrecer una visin orientada a objetos de una base de datos relacional. Una vez que se localiza la entidad en el repositorio por medio de los mtodos find del ejb, el objeto distribuido mapea una tupla de la tabla que representa, siendo las actualizaciones que se realicen sobre sus atributos reflejados en la base de datos en el momento en el que el contenedor de EJBs lo considere necesario. Esta visin del mapeo objeto relacional es acadmicamente purista, y libera al
Objetos Distribuidos Universidad de Oviedo

-17 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

programador del sistema de la labor de desarrollar sentencias SQL, as como lo independiza de la base de datos que se encuentre tras el EJB, dado que es posible desplegarlo contra distintos repositorios de informacin sin necesidad de tocar ni una lnea del cdigo de las clases que lo utilizan. Sin embargo, presenta serios problemas de rendimiento, dado que los mtodos de bsqueda aportados hasta la versin 1.2 de la especificacin no contemplaban la posibilidad de realizar bsquedas cruzadas entre entidades (JOINS en SQL), lo cual obligaba a traspasar operaciones habitualmente resueltas eficientemente por el motor de base de datos al cdigo, realizando tareas tediosas de programar y con muy bajo rendimiento debido al excesivo uso de memoria. As mismo, la posibilidad de una solucin hbrida entre el empleo de EJBs de entidad para el manejo de entidades individuales, y sentencias SQL para el procesado masivo de informacin del repositorio es inviable, dado que para que un EJB de entidad funcione adecuadamente, ha de garantizarse que todos los accesos a la tabla que mapea se realizan a travs del propio EJB. Esto se debe al retardo en la sincronizacin con el repositorio que se aprovecha para aumentar el rendimiento del contenedor a modo de cach.

En la versin 2.0 de la especificacin se ha tratado de poner solucin a este inconveniente, permitiendo el establecimiento de relaciones maestro-esclavo entre EJBs, extendiendo el lenguaje EJB-QL e incorporando a la edicin J2EE de la api JDO. No obstante, an no es posible alcanzar la potencia de ejecucin que aporta el empleo del lenguaje SQL nativo de la base de datos objeto. La solucin para la capa de persistencia ms aceptada hoy en da es aquella que combina EJBs de tipo sesin sin estado a modo de fachadas carentes de lgica, con los DBBeans que atacan con sentencias SQL a la base de datos relacional sobre la que habitualmente se soporta el sistema de informacin.

Descomposicin funcional del sistema. Modelo colaborativo distribuido

Uno de los objetivos ms claros e importantes en el proceso de desarrollo de software ha de ser la reutilizacin de cdigo. Este principio hay que contemplarlo desde
Objetos Distribuidos Universidad de Oviedo

-18 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

dos perspectivas distintas: no desarrollar elementos o componentes que ya existan y estn probados, y desarrollar pensando en que puede que maana el cdigo que se est implementando pueda ser reutilizado en distintos proyectos. El factor de reutilizacin de un paquete de cdigo viene determinado por la independencia que exista entre los componentes del sistema. Si una clase realiza varias invocaciones directas a otra distinta, no ser portable a otro proyecto a no ser que no llevemos la segunda tambin. A un nivel ms alto de abstraccin se debe tambin procurar desarrollar mdulos lo ms independientes posible del resto de la aplicacin.

Descomposicin en microaplicaciones
Si se aplica este principio a nivel de proyecto entero, y procuramos descomponer el producto identificando funcionalidades, obtendramos una aplicacin final formada por una agrupacin de lo que podramos denominar mdulos o microaplicaciones. Pongmonos, por ejemplo, en el caso del desarrollo de una intranet web, proyecto muy comn por otra parte. Servicios habituales del la intranet son la gestin de usuarios, la publicacin de noticias, foros, etc. Afinando ms, la gestin de usuarios, por ejemplo, se puede separar entre la de personas, la de perfiles, la de grupos, etc. Surge en este contexto el problema de la colaboracin intrnseca entre estas microaplicaciones (dado que en caso contrario, no seran tales, sino aplicaciones completas), puesto que procesos asociados a una microaplicacin requerirn de otros procesos o datos localizados en microaplicaciones distintas. Un error de diseo frecuente en este tipo de contextos es permitir que una microaplicacin recupere informacin directamente del repositorio de datos mantenido por otra. Esto genera productos fuertemente acoplados, y dificulta mucho las labores de mantenimiento, dado que un cambio leve en el modelo de datos de un servicio cualquiera puede conllevar efectos laterales importantes. Se pierde el control sobre la gestin de las entidades de la base de datos, adems de dificultar la depuracin de errores. Colaboracin entre microaplicaciones Cuando surge la necesidad de colaborar con ciertos procesos desde una micro aplicacin a otra, la primera cuestin a resolver es a que nivel de la arquitectura se debe hacer esto, manteniendo siempre el principio de separacin de responsabilidades y de mxima independencia entre los distintos mdulos de la aplicacin. Como se ha dicho antes, se ha de evitar el acceso directo al repositorio de informacin. Si por el contrario, se accediera a nivel de la capa de acceso a datos, a travs de sus faades, se evitara el problema antes descrito. Sin embargo, limita la posible evolucin de la microaplicacin fuente de datos, puesto que se esta forzando a que mantenga la misma interfaz en su capa de acceso a datos en un futuro. El punto adecuado para comunicar dos microaplicaciones es pues la capa de negocio, dado que adems es en esta capa donde se comprueba la potestad del usuario para invocar a los procesos en ella implementados. As, ser necesario que la microaplicacin que requiere del servicio se autentifique en la segunda, para evitar que terceros sistemas invoquen procesos de negocio inadecuadamente. Esto puede obligar a elevar servicios de persistencia al nivel de la capa de negocio, incluso cuando no sea necesario implementar reglas de negocio, pero as se mantiene centralizado el control de acceso en una misma capa. Para mantener la independencia entre microaplicaciones, debe sustituirse el modelo habitual de colaboracin entre mdulos, es decir, la invocacin directa de sus

Objetos Distribuidos

Universidad de Oviedo

-19 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

clases, por otro que permita un mayor desacoplamiento de los mismos. A este punto se presentan distintas alternativas, de donde se destacan estas dos: 1. Empleo de EJBs de sesin. La invocacin de los servicios de negocio de una microaplicacin desde otra mediante un EJB tiene la gran ventaja de que, al ser habitual el empleo de estos componentes a modo de faade, es posible que no tenga impacto alguno en la microaplicacin fuente de datos. Adems, puede llegar a ser imprescindible si la operacin a realizar se viera implicada en una transaccin, dado que el EJB es capas de gestionar transacciones distribuidas. Por otro lado, la invocacin es costosa (RMI o IIOP), y sobre todo inviable si las microaplicaciones cuentan con un firewall entre ellas. Esto limita la distribucin y/o sustitucin del producto. 2. Servicios WEB Los servicios web cuentan con la ventaja de permitir invocaciones remotas en formato XML y sobre el protocolo (entro otros) http. Esto posibilita la distribucin o colaboracin de las microaplicaciones presentes en distintas redes, o a travs de Internet, dado que no son interceptados por un fierwall. Se debe publicar un servicio web por cada servicio de negocio que se desee compartir con otras microaplicaciones de la misma aplicacin o, porqu no, de otras aplicaciones o sistemas distintos. Esta opcin es ms aconsejable que la anterior, aunque inviable en el caso de las transacciones distribuidas. El empleo de esta alternativa de diseo permite amplias posibilidades de distribucin de un mismo producto, pero adems facilita enormemente algo muy demandado hoy en da en el mercado como la integracin con otros sistemas de la misma compaa. Con esta arquitectura, es relativamente sencillo adaptar, por ejemplo, la gestin de permisos sobre servicios de la aplicacin, a un nuevo entorno con un gestor propio, o centralizar el control de acceso para todas las compaas de un grupo empresarial, cada una con su propia instancia del producto, en un mismo punto de la red. El desarrollo de servicios web es sencillo y est disponible para prcticamente todos los entornos de desarrollo.

Integracin con Legacy Systems con MessageDrivenBeans con comunicacin asncrona

El modelo descrito en el apartado anterior desacopla las distintas partes de un mismo sistema permitiendo una futura sustitucin de alguna de ellas por cualquier otra. Contempla el uso de servicios web como medio de integracin de los mdulos desacoplados, con las ventajas y limitaciones que estos conllevan. Este tipo de solucin es perfectamente vlida cuando trabajamos con sistemas que, como en el ejemplo anterior, estn desarrollados por nosotros mismos, o al menos siguen el mismo flujo de negocio. No obstante, los problemas de integracin no suelen ser tan triviales como una simple adaptacin de las invocaciones. En ocasiones, nos vemos obligados a desarrollar o adaptar un producto que debe integrarse con sistemas antiguos, ya presentes en la empresa, y cuya modificacin es completamente inaceptable o inviable. Son lo que se denominan Legacy Systems, y su presencia obliga al nuevo elemento del sistema a ser l el que se adapta, debido a las dificultades y/o limitaciones de mantenimiento que suelen presentar. Uno de los puntos de incompatibilidad ms frecuentes viene dado por el
Objetos Distribuidos Universidad de Oviedo

-20 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

momento en el que un sistema (por ejemplo, el nuevo) requiere enviar un mensaje al otro, puesto que es posible que en ese instante el segundo sistema no est dispuesto para asumir el mensaje en trmite. Estos problemas de sincronismo a la hora de integrar dos sistemas pueden ser solventados por medio del empleo de un middleware de mensajera asncrona. As, cuando el sistema A requiera el envo de un mensaje al sistema B, no tiene porqu preocuparse de la disponibilidad del segundo, sino que su mensaje quedar pendiente de recepcin hasta que el sistema B est en disposicin de procesarlo. Si trasladamos el problema descrito al mbito de desarrollo en el que se sita este documento, es decir, las aplicaciones Web basadas en tecnologa java / j2ee, la solucin de integracin viene dada por el empleo de EJBs de tipo MDB (Message Driven Beans). Supongamos que una entidad bancaria desea sustituir parcialmente la interfaz por la que los dependientes realizan los movimientos contables de sus clientes por una interfaz web. Lgicamente, ambos dos sistemas deben ser compatibles y seguir funcionando manteniendo la coherencia entre los datos. Al no existir una interfaz java en el sistema antiguo, los datos slo podrn ser cargados en ste mediante procesos batch peridicos, quiz nocturnos. En este caso, cada vez que la aplicacin web realizara un movimiento, deber enviar un mensaje al sistema actual notificando la transaccin. El mensaje quedar recogido en la cola de mensajes, hasta que finalmente sea solicitado por parte del cliente de la cola. Peridicamente, el sistema actual lanzar un proceso batch de carga por el cual recuperar todos los mensajes encolados y los procesar para actualizar su informacin. As mismo, los mensajes desde el sistema antiguo al muevo pueden ser generados por cualquier tipo de proceso batch que acte de emisor para la cola. En este caso, el sistema web contar con un MDB a la escucha, y procesar los mensajes emitidos desde la otra mquina a medida que estos vayan siendo encolados.

Con este tipo de mecanismos se solucionan los problemas de integracin derivados de la falta de sincronismo entre los sistemas a integrar. El hecho de emplear un EJB MDB permite tratar al sistema remoto como otra pieza ms del sistema orientado a objetos, dado que para el sistema web es inapreciable la diferencia entre ambos.

Objetos Distribuidos

Universidad de Oviedo

-21 -

Programa de doctorado Avances en Informtica

Daniel Fernndez Lanvin

Bibliografa
[FOWL02] http://martinfowler.com/apsupp/appfacades.pdf [GOF94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four). Design Patterns. Addison Wesley Professional Computing Series, 1994. ISBN 0-201-63361-2 [JAKA03] http://jakarta.apache.org [JURI00] Matjaz Juric, Nadia Nashi, Craig Berry, Meeraj Kunnumpurath, John Carnell, Sasha Romanosky, J2EE Design Patterns Applied. Wrox Press Inc, 2002. ISBN 1861005288 [MARIN01] Floyd Marinescu, EJB Design Patterns: Advanced Patterns, Processes, and Idioms. John Wiley & Sons, 2001. ISBN 0471208310 [ROA01] E Roman, Scott W. Ambler, Tyler Jewell. Mastering Enterprise JavaBeans, second edition. John Wiley & Sons, 2001. ISBN 0471417114 [STXX] http://stxx.sourceforge.net/ [MERC02] Julien Mercay and Gilbert Bouzeid. Boost Struts With XSLT and XML. Java World, Febrero 2002.

Objetos Distribuidos

Universidad de Oviedo

-22 -