TESIS QUE PRESENTAN LOS ALUMNOS

Transcripción

1 UNIDAD IZTAPALAPA DIVISION DE CIENCIAS BASICAS E INGENIERIA TESIS QUE PRESENTAN LOS ALUMNOS GALICIA ORTEGA ROSALBA MATRICULA MUJICA MOTA CARLOS MATRICULA PARA LA OBTENCION DEL GRADO DE LICENCIADO EN COMPUTACION PROYECTO: Estudio del Balance de Carga en la Herramienta Middleware EJB. Este Proyecto fue realizado como parte de las actividades del Proyecto CONACYT Infraestructura para el Desarrollo de Aplicaciones Distribuidas, No. Referencia: A ASESOR DRA. GRACIELA ROMAN ALONSO TRIMESTRE: 01 - O Y 02 - I AGOSTO DEL 2002

2 INDICE TEMA Pag. Introducción. 3 Capitulo I Middleware 1. Que es Middleware Definición Ventajas Campos de Aplicación Migración de los Sistemas Host. Reingeniería de Aplicaciones Interconectividad Arquitectura orientada a objetos distribuidos Arquitectura cliente/servidor 9 Capitulo II Aspectos Generales de Enterprise JavaBeans 1. Introducción a los EJB s Componentes de la arquitectura Interfaces Interfaz EJB Object o Remote Interfaz EJB Home Tipos de EJB s Beans de Sesión Beans de Entidad Persistencia Seguridad Designación Modelo de comunicación Gestión Transaccional Gestión de carga de trabajo Llamadas Remotas RMI Arquitectura Ventajas y Desventajas IIOP IDL... 21

3 . continuación índice. TEMA Pag Capitulo III Balance de Carga y Tolerancia a Fallas en EJB 1 Balance de Carga Tolerancia a Fallas Balance de Carga y Tolerancia a Fallas en Clusters EJB Arquitectura Servicios Interfaz EJBObject Interfaz EJBHome EJB s de Sesión sin Estado EJB s de Sesión con Estado EJB s de Entidad Lectura-Escritura EJB's de Entidad.. 32 Capitulo IV Estructura e Implementación de un Programa EJB 1 Estructura de un Programa Creación de Interfaces Interfaz Objeto o Remota Interfaz Home Aplicación Bean Descriptores de Despliegue ejb-jar.xml weblogic-ejb-jar.xml Aplicación Cliente Compilación Ejecución.. 40 Conclusiones Anexo I Instalación del Servidor Weblogic 1. Instalación del Servidor 47 Anexo II Programa de Ejemplo 1. Aplicación PetStore.. 55 Glosario Bibliografía... 61

4 Introduccion

5 Introducción INTRODUCCION La utilización de middleware permite desarrollar aplicaciones en arquitectura cliente-servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. Ya que el desarrollo de aplicaciones distribuidas ha tomado gran importancia en los últimos años y además la Web ha transformado la forma de trabajar de las empresas con sus clientes, es necesario contar con herramientas que nos permitan acceder a aplicaciones remotos robustas como bases de datos o aplicaciones distribuidas las cuales son accedidas por una gran cantidad de usuarios concurrentemente. Al principio, era suficiente con disponer de una página de presentación de la Web. Después las empresas empezaron a desplegar sitios Web activos que permitían a los clientes solicitar productos y servicios. Actualmente, las empresas no solo necesitan utilizar la Web para todas estas finalidades, sino que además deben integrar sus sistemas basados en Web con los demás sistemas de negocio. La tecnología EJB (Enterpise JavaBeans), proporciona el modelo y las herramientas necesarias para llevar a cabo dicha integración. El modelo de componentes de servidor EJB define una arquitectura estándar para servidores de aplicación Java, un entorno robusto que soporta sistemas de aplicación de misión critica altamente distribuidos. Este proyecto de investigación tiene como objetivo principal realizar un trabajo de investigación en el área de los sistemas distribuidos mediante un estudio detallado de la tecnología Middleware, en particular la plataforma EJB. Para esto es necesario conocer en la práctica los conceptos y técnicas para el desarrollo de una aplicación basada en esta plataforma, y estar en posibilidad de estudiar las características de balance de carga y tolerancia a fallas. Para lograr los objetivos anteriores es necesario a prender a instalar y configurar adecuadamente los componentes en un servidor de aplicaciones con soporte EJB. Este reporte se encuentra organizado de la siguiente manera: En el primer capitulo se define el concepto Midddleware, y porque este nos permitir conectar entre sí a una variedad de productos procedentes de diferentes proveedores, ya que es una tecnología que permite que dos o mas sistemas trabajen juntos aunque no estén creados para ello. En el segundo capitulo se define el concepto de EJB; los tres tipos de EJB: beans de sesion sin estado, beans de sesion con estado y beans de entidad; los componentes de su arquitectura: el servidor de EJB y el contenedor EJB; las interfaces con las que el contenedor EJB permite que el cliente interactué con un Enterprise Java Bean: Interfaz 3

6 Introducción EJB Home e Interfaz EJB Object o Remotey las características que permiten que EJB satisfaga sus objetivos: Persistencia, Seguridad, Designación, Modelo de comunicación, Gestión Transaccional, Gestión de Carga de Trabajo, Llamadas Remotas. El tercer capitulo, esta enfocado al Balance de Carga y Tolerancia a Fallas, características importantes en el estudio de los EJB's, para esto se tiene que hablar de Clusters, su arquitectura y de manera más detallada la forma como soluciona el servidor Weblogic los problemas de balance de carga y tolerancia a fallas al prestar(proporcionar) un servicio al cluster. En el Anexo 1, se describe de manera detallada la instalación del Servidor Weblogic, así como la estructura de un programa, desde la creación de las interfaces, la aplicación del bean, los descriptores de despliegue, la aplicación cliente, su compilación y ejecución. De igual forma se muestra la instalación de una pequeña aplicación llamada Pet Store que fue tomada de los ejemplos al ser instalado el Servidor Weblogic. En la parte final se encuentran las conclusiones a las que se llegaron después de haber realizado este proyecto, así como la bibliografía utilizada para el mismo fin. 4

7 CAPITULO I. Middleware

8 Capitulo 1. Middleware 1. MIDDLEWARE La existencia de nuevas arquitecturas, nuevos sistemas y plataformas más potentes a la vez que más económicas hace que muchas organizaciones se planteen el traslado de sus aplicaciones corporativas que residen en servidores centrales o mainframes hacia nuevas plataformas. Sin embargo, debido a los rápidos cambios de las tecnologías, es necesario garantizar de cierta forma la inversión que se realiza en el proyecto de rediseño de la aplicación. La estrategia que se utiliza incluye el concepto de middleware. 1.1 DEFINICION El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con varias fuentes de información que se encuentran conectadas por una red. Desde un punto de vista amplio una solución basada en productos de middleware debe permitir conectar entre sí a una variedad de productos procedentes de diferentes proveedores. De esta forma se puede separar la estrategia de sistemas de información de soluciones propietarias de un sólo proveedor. El concepto de middleware no es un concepto nuevo. Los primeros monitores de teleproceso de los grandes sistemas basados en tecnología cliente servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos que el concepto de middleware toma su máxima importancia. Las categorías del middleware podríamos definirlas de la siguiente forma: Monitores de proceso de transacciones distribuidos (DTPM's Distributed Transaction Processing Monitors). Herederos de la tecnología mainframe, son ampliamente demandados para intercomunicar distintos sistemas en distintos entornos. Llamadas a procedimientos remotos (RPC's Remote procedure Call). Diseñado como servicios síncronos para permitir gestión remota de redes. Middleware orientado a mensajes (MOM Messaging Oriented Middleware). Diseñado para servicios de mensajes con tecnología asíncrona. 7

9 Capitulo 1. Middleware (ORB Objects Request Broker). Middleware para tecnologías orientadas a objetos. Objetos piden servicios de objetos que se encuentran en la red. El estándar más conocido de esta tecnología es CORBA Common Object Request Broker Arquitecture. Middleware de acceso a Bases de Datos (Data Base Access Middleware). Para acceso estándar a bases de datos. Permite desarrollar sistemas independizándolo de la base de datos que lo soporte. En la actualidad representa el 50% del mercado del middleware. 1.2 VENTAJAS Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios. Permite la interconectividad de los Sistemas de Información del Organismo. Proporciona mayor control del negocio al poder contar con información procedente de distintas plataformas sobre el mismo soporte. Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas. Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria para que puedan funcionar. 1.3 CAMPOS DE APLICACIÓN Migración de los Sistemas Host. Reingeniería de Aplicaciones La aplicación debería diseñarse en base a módulos intermedios middleware encargados de la comunicación entre el ordenador personal y el host. Esto permite desarrollar hoy la aplicación, sin tener en cuenta los futuros cambios tecnológicos que puedan sufrir los sistemas host. Si el sistema host cambia, o las aplicaciones de host se migran a plataformas de ordenadores personales, todo lo que se necesita es un nuevo módulo middleware. La interfaz de usuario, la lógica y el código interno permanecen sin cambios. Por ejemplo, si el equipo lógico del sistema host se traslada desde el mainframe a una base de datos de plataforma PC ejecutándose en un servidor de ficheros, sólo hay que sustituir el módulo de middleware de forma que realice llamadas SQL. 8

10 Capitulo 1. Middleware Interconectividad Uno e los usos más importantes de las herramientas de middleware es la de facilitar la interconectividad de los diferentes sistemas de un organismo integrando las diferentes islas de información departamentales Arquitectura orientada a objetos distribuidos El concepto de middleware permite también independizar los servicios proporcionados por diferentes objetos que se encuentran en una red proporcionando una red de objetos independientes e interconectados entre sí Arquitectura cliente/servidor La utilización de middleware permite desarrollar aplicaciones en arquitectura cliente servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. 9

11 CAPITULO II. Aspectos Generales de Enterprise JavaBeans

12 Capitulo II. Aspectos Generales de Enterprise JavaBeans 1. INTRODUCCION A LOS EJB Enterprise Java Beans (EJB) corresponde a una tecnología Java que permite definir un modelo para el desarrollo y despliegue de componentes servidor reusables. EJB soporta el desarrollo de aplicaciones basadas en una arquitectura de objetos distribuidos, en múltiples capas y en donde la mayor parte de la lógica de la aplicación se mueve desde el cliente hasta el servidor. EJB extiende el modelo de componentes que definieron los Java Beans. Un "Java Bean" es un componente utilizado en Java que permite agrupar funcionalidades para formar parte de una aplicación. Un "Enterprise Java Bean" también agrupa funcionalidades para una aplicación, sin embargo, implica que existe un ambiente de ejecución ("deployable component"), "EJB (Enterprise Java Bean) Container. Un "Java Bean" requiere ser integrado con otros componentes para que éste sea funcional, mientras un "Enterprise Java Bean" a través de un "EJB Container" puede ser activado ("deployed"). 2. COMPONENTES DE LA ARQUITECTURA Con respecto a la arquitectura EJB, si realizamos un completo análisis de ella se pueden encontrar los siguientes componentes que la estructuran: Servidor de Enterprise Java Beans (Enterprise Java Beans Server): El servidor EJB proporciona el ambiente o entorno necesario para soportar la ejecución de aplicaciones que han sido desarrolladas utilizando la tecnología de EJB. Este servidor administra y coordina la ubicación de los recursos para que sean utilizados por las aplicaciones. EJB Container: Un servidor EJB debe ser capaz de proveer uno o más contenedores EJB. El concepto de container es análogo al concepto de hogar esto queda mas claro al constatar que es el EJB container quien administra a los beans contenidos en el. Por cada EJB, el contenedor es responsable de registrarlo, de proporcionar una interfaz remota para él, de crear o destruir instancias del objeto, realizar chequeos de seguridad para el objeto, manejar su estado activo y coordinar transacciones distribuidas. Como una funcionalidad opcional, el EJB container puede incluso llegar a manejar toda la información persistente dentro del objeto. 2.1 INTERFACES 13

13 Capitulo II. Aspectos Generales de Enterprise JavaBeans El contenedor EJB permite que el cliente interactúe con un Enterprise Java Bean a través de dos interfaces wrapper: Interfaz EJB Object o Remote. Proporciona el acceso a los métodos dentro del bean. Un objeto EJB representa la visión del usuario del bean. El objeto EJB revela todas las interfaces de la aplicación vinculadas al objeto, pero no aquellas interfaces que permiten al contenedor administrar y controlar al objeto. El wrapper de objeto EJB permite que el contenedor EJB intercepte todas las operaciones que se hagan sobre el bean. Dicho, de otra forma, cada vez que el cliente invoca un método sobre un objeto EJB, la petición pasa por el EJB container antes de ser traspasada al bean. El contenedor implementa la administración de estados, el control de transacciones, seguridad y servicios de persistencia en forma transparente tanto para el cliente como para el bean Interfaz EJB Home. Esta interfaz proporciona el acceso a los servicios del ciclo de vida del EJB. Los clientes pueden usar esta interfaz para crear o destruir instancias del bean en materia de servicios. El modelo EJB provee soporte para un determinado número de servicios implícitos. Servicios Ciclo de vida: Por si solos, los EJB no necesitan manejar en forma explicita las hebras (o hilos), la administración de procesos ni la activación o destrucción de un objeto, ya que estas tareas recaen sobre el contenedor EJB. Manejo de estados: Los EJB no requieren guardar o recuperar en forma explicita los estados del objeto entre llamado y llamado de los métodos, debido a que el contenedor EJB se encarga de llevar a cabo estas tareas en beneficio del mismo bean. Seguridad: Todas las tareas involucradas con este punto (chequeos de seguridad), como por ejemplo, la autenticación de usuarios o el chequeo de niveles de autorización, quedan en manos del container del bean. Transacciones: Los Beans no necesitan explicitar individualmente el código de demarcación transaccional para poder participar en transacciones distribuidas. Es el EJB container quien se encarga de manejar la partida, el enroollment, el compromiso y el rollback de transacciones. Persistencia: Un bean no necesita retirar o almacenar objetos de datos persistentes desde una base de datos, ya que el EJB container se encarga de manejar datos persistentes. 3. TIPOS DE EJB S 14

14 Capitulo II. Aspectos Generales de Enterprise JavaBeans 3.1 BEANS DE SESIÓN Un Bean de Sesión permite realizar cierta lógica solicitada por un cliente ya sea un JSP servlet, Applet e inclusive otro EJB. Existen dos tipos de Beans de Sesión: Beans de Sesión sin Estado (Stateless Session EJB s): Este tipo de EJB como su nombre lo indica no mantiene estado ("Stateless") en el "EJB Container. Estos EJB's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente. Dado que este tipo de bean no mantiene estado, los beans de sesión no están ligados a un cliente particular, de manera que cualquier instancia de un bean de esta clase puede usarse para dar servicio a un cliente. Algunos EJB's de este tipo son: operaciones matemáticas complejas, búsquedas generales, etc. Cualquier información de estado, en caso de que fuera necesario, se mantiene por el cliente. Dado que este tipo de bean no mantiene estado, los beans de sesión no están ligados a ningún cliente particular, de manera que cualquier instancia de un bean de esta clase puede usarse para dar servicio a un cliente. Beans de Sesión con Estado (Statefull Session EJB s): Permiten mantener la sesión del cliente en el "EJB Container", de esta manera el cliente puede trabajar con cierto juego de datos específico administrado por el "EJB Container". Dado que el estado se mantiene en este tipo de EJB, el servidor de aplicación maneja pares cliente-bean. Cada instancia de una cierta EJB se crea bajo petición de un cliente concreto, y en principio es un recurso privado para ese cliente (aunque puede compartirse entre clientes, usando el handle del bean). En esencia, una bean con estado actúa como una extensión del cliente, con la salvedad de que cierta carga del cliente se distribuye en el servidor de aplicaciones. Los datos de estado no sobreviven a una caída del servidor, salvo que la implementación particular soporte persistencia frente a caídas del servidor. Los beans con estado pueden acceder a recursos persistentes (como bases de datos o ficheros) pero, a diferencia de los beans de entidad, no representan datos. 3.2 BEANS DE ENTIDAD Objetos persistentes, que representan una vista de objeto de una determinada fuente de datos. Esto permite que el EJB manipule información residente en sistemas ajenos al "EJB Container. En otras palabras, un "Entity EJB" manipula una copia reflejo de información que reside en otro sistema. Cada instancia de una bean de identidad se identifica a través de una única clave primaria. Las beans de entidad pueden crearse bien creando un objeto (Create()) o insertando directamente datos en la fuente de datos. Dado que el estado de la bean se mantiene en la fuente de datos, este tipo de beans pueden recuperarse ante una caída del sistema. Un bean de entidad a diferencia de un bean de sesión trabaja en conjunción con un depósito de información (generalmente una base de datos), esto permite que el EJB manipule la información residente en sistemas ajenos al EJB Container. 15

15 Capitulo II. Aspectos Generales de Enterprise JavaBeans 4. PERSISTENCIA Una de las características claves del modelo EJB es la persistencia, que puede implantarse a nivel de bean de entidad o a nivel de contenedor. En el primer caso, el desarrollador sobrecarga los métodos de carga y almacenamiento, para guardar la información residente en los atributos del bean de entidad en una fuente de datos por ejemplo, JDBC. Este mecanismo es el más flexible (pues el desarrollador define cómo se almacenan los datos) pero liga a nivel de código la bean con el almacén de datos. Algunos proveedores están empezando a proporcionar herramientas de traducción objeto-relacional. Otra alternativa son las vistas de base de datos, sitien muchas bases de datos no permiten la actualización de múltiples tablas desde una vista. Si la persistencia la proporciona el contenedor EJB, en general el proveedor incorpora una herramienta de traducción objeto-relacional para enlazar atributos del bean con campos del almacén de datos. 5. SEGURIDAD EJB usa la clase java.security.identity para describir a los usuarios y roles. Es responsabilidad del servidor de aplicaciones (o del contenedor EJB) efectuar la traducción con una identidad real (por ejemplo, el DN de un certificado X.509 usado para autenticar a un usuario). Esta información la obtiene la instancia de la bean a través de los métodos getcalleridentity e iscallerinrole(identity ident) de la clase javax.ejb.ejbcontext. EJB usa para la autorización el modelo de listas de control de accesos (ACLs) en el descriptor de despliegue. 6. DESIGNACION Se utiliza JNDI para enmascarar el servicio de denominación real y proporcionar una interfaz común para el servicio de denominación. JNDI ofrece las funciones de directorios y de denominación para las aplicaciones de Java. Pero la API es independiente de cualquier implementación específica de un servicio de directorios y de denominación. Esta independencia de implementación garantiza que se puedan utilizar servicios de directorios y de denominación diferentes accediendo a ellos a través de la API JNDI. Las aplicaciones de Java pueden utilizar numerosos servicios de directorios y de denominación existentes como, por ejemplo: 16

16 Capitulo II. Aspectos Generales de Enterprise JavaBeans LDAP (Lightweight Directory Access Protocol), DNS (Servicio de denominación de dominios) o CDS (Servicio de directorio de célula) de DCE. JNDI se ha diseñado para aplicaciones de Java utilizando el modelo de objeto de Java. Usando JNDI, las aplicaciones de Java pueden almacenar y recuperar objetos denominados de cualquier tipo de objeto Java. JNDI también proporciona métodos para ejecutar operaciones estándar de directorios. 7. MODELO DE COMUNICACIÓN La especificación JB define RMI (Remote Method Invocation) y el protocolo asociado (JRMP) como protocolo por defecto para invocación remota de métodos de objetos Java. EJB proporciona también CORBA/IIOP, de manera que clientes CORBA pueden invocar enterprise beans, esencialmente esto se logra mediante ficheros IDL proporcionados por las clases e interfaces estándar de EJB, combinados con ficheros IDL ligados a enterprise. 8. GESTION TRANSACCIONAL EJB soporta transacciones planas, basadas en la especificación CORBA OTS (Object Transaction Service) 1.1. Con esta facilidad, el desarrollador queda liberado de definir los detalles de la transacción, tema especialmente complejo si se habla de transacciones distribuidas, two-phase commit, etc. Las transacciones en un entorno EJB pueden mantenerse de dos maneras. En la primera, el desarrollador puede controlar por programa el alcance de la transacción usando el interfaz javax.jts.usertransaction, en el cliente o en el bean. En la segunda posibilidad, el servidor de aplicaciones gestiona los límites de la transacción usando atributos de transacción durante el despliegue. Notamos que la segunda posibilidad es mas flexible, si bien la primera puede ser necesaria para aquellas transacciones complejas que no puedan modelarse mediante las facilidades del servidor de aplicaciones. Los valores del atributo de transacción definidos en EJB y que tiene lugar cuando se invoca. 17

17 Capitulo II. Aspectos Generales de Enterprise JavaBeans 9. GESTION DE CARGA DE TRABAJO El servicio de gestión de carga de trabajo mejora la escalabilidad del entorno de servidor EJB agrupando varios servidores EJB en grupos de servidores. Los clientes pueden acceder a estos grupos de servidores como si se tratara de un único servidor EJB, y el servicio de gestión de carga de trabajo garantiza que la carga de trabajo se distribuye uniformemente a través de los servidores EJB de los grupos de servidores. Un servidor EJB sólo puede pertenecer a un grupo de servidores. La creación de grupos de servidores es una tarea administrativa que se maneja desde la Consola administrativa de el entorno de servidor EJB y desde la Interfaz de usuario final de Gestión de sistemas en el servidor EJB. 10. LLAMADAS REMOTAS 10.1 RMI RMI es un modelo de objetos distribuidos desarrollado por JavaSoft y esta basado en la misma filosofía de un modelo RPC, con la ventaja de permitir el paso directo de objetos como parámetros en los métodos remotos. Esta diseñado específicamente para el lenguaje Java y presupone que los programas cliente y servidor están escritos en este lenguaje. Es una de la especificaciones que forma parte del proyecto JavaBeans, ya presentado con anterioridad en este mismo documento Arquitectura 18

18 Capitulo II. Aspectos Generales de Enterprise JavaBeans El modelo RMI dispone de una arquitectura de tres niveles, sobre los cuales las aplicaciones se apoya lógicamente. Aplication Client Server RMI System Stubs Skeletons Remote Reference Layer Transport ARQUITECTURA DE 3 NIVELES Las responsabilidades de cada una de estas se detalla a continuación: Stub/Squeleton: Cuando un cliente invoca un método de un objeto remoto, en realidad utiliza un stub o representante (proxy), que es una implementación de las interfaces remotas del objeto remoto. Dicho stub se encarga de enviar sus solicitudes de invocación a los métodos a través dela interfaz de referencia remota. Referencia Remota: Se encarga de la semántica de la invocación y de la referencia al servidor. Transporte: Responsable del establecimiento de la conexión, su gestión y mantenimiento. Envía la llamada remota solicitada por la capa de referencia del cliente a ala capa de referencia del servidor, para que esta la entrega a la capa de squeleton, quien se encarga de realizar la llamada al procedimiento. 1.2 Ventajas y Desventajas Orientación a objetos: RMI puede incluir puede incluir objetos completos en sus argumentos y valores de retorno Comportamiento móvil: El comportamiento de objetos viaja junto con los atributos a utilizar objetos como parámetros o valores de retorno de unmetodo remoto. De esta forma, la implememtacion de las interfaz ( clase ) solo debe de ser actualizada para la invocación local de metodos en objetos raidos desde el servidor. 19

19 Capitulo II. Aspectos Generales de Enterprise JavaBeans Patrones de diseño: La posibilidad e incluir objetos en la invocación de metodos permite una implementacion fiel a los patrones de diseño de software orientado a objetos. Seguridad: RMI esta por sobre la maquina virtual de Java. Por esto, las aplicaciones deben someterse por completo a la administración de seguridad que impone esta maquina virtual, tal como l haria una aplicación normal o un applet. Fácil de programar: La integración con Java requiere de muy pocas lineasd e código, ademas de utilizar el sistema de herencia de interfaces clasico para declarar clases remotas. Conexión con sistemas existentes: A traves de JNI (Java Native Method Interface) se pueden escribir partes del sistema en Java y seguir utilizando el resto en lenguaje nativo. Ademas, RMI puede hacer uso de JDBC para comunicarse con bases de datos relacionales sin modificar otros subsistemas que utilicen estas bases de datos y que no estn escritas en Java. Código portable: El codigo RMI es 100% portable a cualquier maquina virtual de Java (desde el JDK 1.1 en adelante). Recolección de basura distribuida: Recoleccion automatica de objetos remotos que no son referenciados por ningun cliente. Computación paralela: RMI soporta el modelo de multiples hebras de Java, permiendo la explotacion de procesamiento concurrente de peticiones de los clientes Los protocolos de comunicación son públicos: De esta forma todos los sistemas de Java pueden comunicarse en forma directa, sin necesidad de protocolos de traducción que produzcan overhead. RMI presenta un serio problema de interoperabilidad con otros lenguajes. Utiliza un protocolo de comu-nicación no estándar. No tiene la posibilidad de comunicarse con objetos CORBA 10.2 IIOP IIOP (Internet Inter-ORB Protocol) es el protocolo de comunicación de CORBA. Define la forma en que los datos deben ser trasmitidos entre clientes y servidores CORBA. Las interfaces a objetos remotos están descritas en un lenguaje de definición de interfaces independiente a la plataforma (IDL). Antes de RMI-IIOP, los desarrolladores Java debían elegir entre RMI y CORA/IIOP (javaidl) para generar soluciones distribuidas. RMI-IIOP permite que, agregando una serie de restricciones, los objetos RMI puedan utilizar el protocolo IIOP y comunicarse con objetos CORBA, aprovechando la interoperabilidad de CORBA entre multiples lenguajes en forma independiente Al utilizar RMI sobre IIOP se descarta la necesisdad d einteractuar con lenguajes de definición de interfaces externos (IDL), los cuales serán tratados en el siguiente punto. 20

20 Capitulo II. Aspectos Generales de Enterprise JavaBeans RMI-IIOP combina las mejores características de RMI y CORBA Al igual que RMI... o RMI-IIOP permite la serialización directa de objetos para ser utilizados como parámetros de métodos. AL igual que CORBA... o RMI-IIOP esta basado en estándares abiertos definidos en conjunto por cientos de proveedores y usuarios en la OMG o Utiliza IIOP como protocolo de comunicación. Con RMI-IIOP, un desarrollador puede escribir interfaces remotas en Java e implementarlas utilizando tecnologías Java y las APIs de RMI. Estas interfaces también pueden ser implementadas en cualquier otro lenguaje que sea soportado por la OMG. Al utilizar RMI-IIOP, los objetos pueden ser pasados como parámetros por referencia y por valor sobre IIOP IDL El IDL de Java es una tecnología para objetos distribuidos, esto es, objetos interactuando en diferentes plataformas a traves de la red. El IDL de Java posibilita a los objetos para interactuar si preocuparse de si fueron escritos en java u otro lenguaje. Esto es posible porque está basado en CORBA definido por el OMG (Object Management Group). Una parte de CORBA es IDL, un lenguaje neutral de definición de interfaces. Cada lenguaje que soporta CORBA tiene su propio mapeo de IDL, y como el nombre lo dice, Java IDL es el mapeo de IDL para Java. Para soportar la interacción entre objetos en programas distintos, el IDL de Java provee un ORB (Object Request Broker). El ORB es una biblioteca de clases que permite la comunicación entre las aplicaciones Java IDL y otras aplicaciones CORBA. El modelo de programación IDL, conocido como JAVA IDL, comprende el ORB de Java para CORBA y el compilador idlj que mapea el estandar IDl, de la OMG, a Java, que utiliza el ORB de Java para CORBA. El IDL dela OMG en lenguaje puramente declarativo diseñado para especificar interfaces operacionales, independientemente del lenguaje de programación,para aplicaciones distribuidas. OMG define un mapeo de IDL a diferentes lenguajes deprogramcion incluyendo C, C++, Lisp, Pitón, Smaltalk, COBOL, Ada y Java. 21

21 CAPITULO III. Balance de Carga y Tolerancia a fallas en EJB

22 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB 1. BALANCE DE CARGA El servicio de gestión de carga de trabajo mejora la escalabilidad del entorno de servidor EJB agrupando varios servidores EJB en grupos de servidores. Los clientes pueden acceder a estos grupos de servidores como si se tratara de un único servidor EJB, y el servicio de gestión de carga de trabajo garantiza que la carga de trabajo se distribuye uniformemente a través de los servidores EJB de los grupos de servidores. Un servidor EJB sólo puede pertenecer a un grupo de servidores. El Servidor Weblogic provee la propiedad de desarrollo home-load-algorithm y stateless-bean-load-algorithm en el descriptor de despliegue weblogic-ejb-jar.xml, donde se establece el tipo de balance que se desea, existen tres tipos: Round Robin Weight. Random. 2. TOLERANCIA A FALLAS Decimos que un sistema falla cuando no cumple su especificación. Como las computadoras y los sistemas distribuidos se utilizan cada vez mas en misiones donde la seguridad es crítica, la necesidad de evitar las fallas es cada vez mayor. 2.1 FALLA DE COMPONENTES Los sistemas de computo pueden fallar debido a una falla en algún componente, como el procesador, la memoria, un dispositivo de E/S, un cable o el software. Una falla es un desperfecto, causado tal vez por un error de diseño, un error de fabricación, un error de programación, un daño físico, el deterioro con el curso de tiempo, condiciones ambientales adversas, entradas inesperadas, un error del operador, etc. No todo esto conduce (de inmediato) a fallas del sistema, pero algunas de estas cosas sí. 25

23 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB Las fallas se clasifican por lo general como transitorias, intermitentes o permanentes. Las fallas transitorias ocurren una vez y después desaparecen. Si la operación se repite la falla ya no se presenta. Falla intermitente, esta desaparece, reaparece, etcétera. Un mal contacto de un conector causa con frecuencia una falla intermitente, las cuales son graves por su difícil diagnostico. Lo usual es que cuando aparece el doctor, el sistema funcione de manera perfecta. Una falla permanente es aquella que continua existiendo hasta reparar el componente con el desperfecto. Los circuitos quemados, los errores del software y el rompimiento de la cabeza del disco provocan con frecuencia fallas permanentes. El objetivo del diseño y construcción de sistemas tolerantes de fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en la presencia de fallas. Este propósito es muy diferente al de garantizar que las componentes individuales sean muy confiables, pues permite(e incluso espera) que el sistema falle si alguno de los componentes lo hace. 2.2 FALLA DE SISTEMA En un sistema distribuido critico, con frecuencia nos interesa que el sistema pueda sobrevivir a las fallas de los componentes (en particular, del procesador), en vez de hacer que las fallas sean poco probables. La confiabilidad de un sistema es en particular importante en un sistema distribuido, debido a la gran cantidad de componentes; de ahí la mayor posibilidad de que falle uno de ellos. Se pueden distinguir dos tipos de fallas del procesador: 1. Fallas silentes 2. Fallas bizantinas Con las fallas silentes, un procesador que falla solo se detiene y no responde a las entradas subsecuentes ni produce mas entradas, excepto que puede anunciar que ya no esta funcionando. También se llaman fallas de detención. Con las fallas bizantinas, un procesador que falla continua su ejecución, proporcionando respuestas incorrectas a las preguntas y posiblemente trabajando de manera maliciosa junto con otros procesadores que han fallado, para dar la impresión de que todos funcionan de manera correcta aunque no sea así. Los errores no detectados en el software exhiben con frecuencia fallas bizantinas. 26

24 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB 2.3 SISTEMAS SINCRONOS VS ASINCRONOS Como acabamos de ver, las fallas de los componentes pueden ser transitorias, intermitentes o permanentes, mientras que las fallas del sistema pueden ser silentes o bizantinas. Un tercer eje ortogonal trata del desempeño en un sentido abstracto. Supongamos que tenemos un sistema en el cual, si un procesador envía un mensaje a otro, se garantiza que obtiene una respuesta dentro de un tiempo T conocido de antemano. Si no se obtiene una respuesta, esto significa que el sistema receptor ha fallado. El tiempo T incluye el tiempo suficiente para considerar la perdida de mensajes (enviándolos hasta n veces). En el contexto de la investigación relativa a la tolerancia de fallas, un sistema que tiene la propiedad de responder siempre a un mensaje dentro de un limite finito conocido, si esta funcionando, es síncrono. Un sistema que no tiene esta propiedad es asíncrono. Aunque esta terminología es desafortunada, ya que entra en conflicto con usos más tradicionales de los términos, se utiliza con amplitud entre las personas que trabajan con la tolerancia de fallas. 2.4 USO DE REDUNDANCIA El método general para la tolerancia de fallas consiste en el uso de redundancia. Existen tres tipos posibles: 1. Redundancia de la información 2. Redundancia del tiempo 3. Redundancia física Con la redundancia de la información, se agregan algunos bits para poder recuperar los bits revueltos. Por ejemplo, se puede agregar un código Hamming para transmitir los datos y recuperarse del ruido en la línea de transmisión. Con la redundancia del tiempo, se realiza una acción, y entonces, en caso necesario, se vuelve a realizar. Si una transacción aborta, puede volverse a realizar otro sin daño alguno. La redundancia de tiempo es de particular utilidad cuando las fallas son transitorias o intermitentes. Con la redundancia física, se agrega un equipo adicional para permitir que el sistema como un todo tolere la perdida o el mal funcionamiento de algunos componentes. Por ejemplo se pueden agregar mas procesadores, de modo que si unos pocos de ellos fallan, el sistema pueda seguir funcionando de manera correcta. 27

25 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB Hay dos formas de organizar estos procesadores adicionales: 1. La replica activa 2. El respaldo primario Consideremos el caso de un servidor. Si se utiliza la replica activa todos los procesadores se utilizan todo el tiempo como servidores(en paralelo) para ocultar las fallas por completo. Por el contrario, el esquema de respaldo primario solo utiliza un procesador como servidor, reemplazándolo con un respaldo si falla. Analizaremos estas dos estrategias mas adelante. Pero en ambas, los aspectos a considerar son: 1. El grado de replica requerido. 2. El desempeño en el caso promedio y en el peor caso, en ausencia de fallas. 3. El desempeño en el caso promedio y en el peor caso, cuando ocurre una falla. 2.5 TOLERANCIA DE FALLAS MEDIANTE REPLICA ACTIVA La replica activa es una técnica muy conocida para proporcionar la tolerancia de fallas mediante la redundancia física. En muchos sistemas los servidores actúan como grandes maquinas de estado finito: aceptan solicitudes y producen respuestas. La lectura de solicitudes no altera el estado del servidor, pero la escritura de solicitudes si lo hace. Si cada solicitud cliente se envia a cada servidor y todas son recibidas y procesadas en el mismo orden, después de procesar cada una, todos los servidores que no han fallado tendrán con exactitud el mismo estado y darán las mismas respuestas. El cliente puede combinar todos lo resultados para enmascarar las fallas. 2.6 TOLERANCIA DE FALLAS MEDIANTE RESPALDO PRIMARIO La idea esencial del método de respaldo primario es que en cualquier instante, un servidor es el primario y realiza todo el trabajo. Si el primario falla, el respaldo ocupa su lugar. En forma ideal, el remplazo debe ocurrir de manera limpia, y ser notado únicamente por el sistema operativo cliente, no por los programas de aplicación. Como la replica activa, este esquema se utiliza con amplitud en el mundo. La tolerancia de fallas con respaldo primario tiene dos ventajas principales sobre la replica activa: En primer lugar, es más sencilla durante la operación normal puesto que los mensajes van a un solo servidor y no a todo un grupo. Los problemas asociados con el ordenamiento de estos mensajes también desaparecen. 28

26 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB En segundo lugar, en la practica se requieren menos maquinas puesto que en cualquier instante se necesitan un primario y un respaldo. Como desventaja, trabaja mal en presencia de fallas bizantinas, en las que el primario afirma erróneamente que funciona de manera perfecta Además, la recuperación de una falla del primario puede ser compleja y consumir mucho tiempo. 2.7 TOLERANCIA DE FALLAS EN EJB Otra característica importante que se presenta en los EJB, es el poder ser tolerante a fallas, y algunas de las características que se presentan gracias a esto son las siguientes: Un cluster WebLogic aísla a los clientes de los incidentes. Usa la redundancia de servidores múltiples. Si un servidor falla, otro puede asumir el control. Esto aumenta la disponibilidad de la aplicación a los clientes. Pero para poder entender mejor de cómo es que funciona el balance de carga y la tolerancia a fallas, tenemos que hablar también de los clusters, lo cual se hará en el siguiente apartado. Esto será explicado con base al Servidor WebLogic para EJB, el cual se utilizo para este estudio. 3. BALANCE DE CARGA Y TOLERANCIA A FALLAS EN CLUSTERS EJB Como sabemos un cluster es un arreglo de computadoras conectadas entre si, por medio de una red, con el fin de realizar tareas que requieren grandes recurso y capacidad, utilizando obviamente todos los recursos de dichas computadoras, para estas tareas. 3.1 ARQUITECTURA Un Cluster WebLogic consta de un número de servidores WebLogic desplegados en una red, coordinada con una combinación de Domain Name Service (DNS), replicación de 29

27 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB árboles de nombrado JNDI, la réplica de los datos de la sesión, y WebLogic RMI. Los servidores proxy entre los clientes Web y el Cluster WebLogic coordinan los servicios de clustering para los servlets y las páginas JSP. Los servidores proxy pueden ser servidores WebLogic, o servidores de terceras partes; Netscape, Microsoft, o Apache, usados con un plug-in proporcionado por el servidor WebLogic. Los clientes Web conectan con un cluster WebLogic dirigiendo peticiones a un servidor proxy. Los clientes Java basados en RMI conectan con un cluster WebLogic usando una dirección del cluster definida en la red. El código del lado del Servidor también se beneficia del balance de carga y los servicios de control de fallos proporcionados por un cluster WebLogic. En aplicaciones J2EE, la mayoría del código de la aplicación se ejecuta en la capa media y puede utilizar los servicios distribuidos entre varios servidores WebLogic. Por ejemplo, un servlet que se ejecuta en el servidor A WebLogic podría utilizar un bean enterprise en el servidor B WebLogic y leer los mensajes de una cola JMS en el servidor C. 3.2 SERVICIOS La mayoría de los servicios de WebLogic Server pueden ponerse en un cluster; es decir, pueden ser desplegados en un número ilimitado de servidores del cluster. El cluster selecciona el servidor WebLogic que proporcionará un servicio. En las siguientes secciones se indica como es que se implementan los servicios de Balance de Carga y Tolerancia a Fallas en los Clusters EJB Interfaz EJBObject Una vez que se haya seleccionado ese servidor y hayan sido ejemplarizados los objetos con estado en el servidor, fijan al cliente a ése servidor WebLogic hasta que hayan acabado con el servicio. Si un servidor WebLogic que recibe un objeto fijado falla, el cliente debe detectar el incidente y crear otro ejemplar en otro servidor del cluster. Para proporcionar un control de fallos más resistente, un cluster WebLogic evita fijar un objeto a un servidor a menos que absolutamente sea necesario. En algunos casos el cluster replica el estado del objeto en otro servidor de reserva para permitir el control de fallos para el servicio Interfaz EJBHome En un servidor cluster WebLogic, el lado del servidor la representación del objeto Home puede ser remplazada por un cluster-aware "stub". El cluster-aware stub tiene el conocimiento de todos los objetos Home EJB del Servidor WebLogic en el cluster. El 30

28 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB cluster-aware stub provee balance de carga distribuyendo las peticiones del EJB a los servidores disponibles. Estos pueden también proveer tolerancia a fallos para las peticiones, ya que esto rutea dichas peticiones a servidores disponibles cuando otros servidores tienen fallas EJB's de Sesión sin Estado Los EJB's de sesión sin estado pueden tener a ambos un cluster-aware home stub y un replica-aware EJBObject stub. Por default, el servidor WebLogic provee servicios para tolerancia a fallas para la llamada a métodos EJB, pero solo si una falla ocurre entre la llamada a métodos. Por ejemplo, la tolerancia a fallas es automáticamente soportada si una falla ocurre después de que un método se completa, o si el método falla al conectar al servidor. Cuando ocurren fallas mientras un método EJB esta en progreso, el servicio de tolerancia a fallos del Servidor WebLogic no es automático de un servidor a otro. Este comportamiento asegura que la actualización de la base de datos dentro de un método EJB no sea duplicada un escenario con fallas. Por ejemplo, si un cliente llama un método que incrementa un valor en un dato almacenado y el Servidor WebLogic fallido salta a otro servidor antes que el método se complete, el dato almacenado podría ser actualizado dos veces para una llamada a método simple de un cliente. Si los métodos son escritos de forma tal que repetidas llamadas al mismo método no cause duplicación de actualizaciones, el método es llamado "idempotente". Para métodos idempotentes, el Servidor WebLogic provee la propiedad de desarrollo statelessbean-methods-are-idempotent. Si usted pone la propiedad a verdadero en weblogic-ejbjar.xml el servidor WebLogic asume que el método es idempotente y proveerá servicio de tolerancia a fallas para el método EJB, cada que una falla ocurra durante una llamada a método EJB's de Sesión con Estado Para habilitar EJB's de sesión con estado para usar cluster-aware home stubs, se pone home-is-clusterable a "verdadero". Esto provee tolerancia a fallas y balance de carga para EJB con estado. Los EJB's de sesión con estado configurados de esta manera usan replica-aware EJBObjects EJB's de Entidad Como todos los tipos de EJB, los EJB's de entidad pueden utilizar cluster-aware home stubs una vez que se ponga home-is-clusterable a "verdadero". El comportamiento de el EJBObject stub depende de el elemento cache-strategy descrito en el weblogic-ejb- 31

29 Capitulo III. Balance de Carga y Tolerancia a Fallas en EJB jar.xml Lectura-Escritura EJB's de Entidad La lectura-escritura en un EJB de entidad en un cluster se comporta similarmente a un EJB de entidad en un sistema de no clúster, de hecho: Múltiples clientes pueden usar el bean en transacciones. ejbload () es siempre llamado al principio de cada transacción (porque el parámetro db-is-shared no puede ser puesto a "falso" en un cluster). El comportamiento de ejbstore () esta sujeto a las mismas reglas descritas para ejbload y ebjstore para EJB's de Entidad. Desafortunadamente, por falta de tiempo no se logró correr alguna aplicación dentro del cluster y elaborar pruebas de balance de carga y tolerancia a fallas, pero se espera que esto se reporte en la siguiente fase de esta investigación. 32

30 CAPITULO IV. Estructura e implementacion de un programa EJB

31 Capitulo IV. Estructura e Implementación de un Programa EJB 1. ESTRUCTURA DE UN PROGRAMA En esta sección describiremos paso a paso como crear una sencilla aplicación EJB, la cual, se encarga de hacer la conversión de pulgadas a centímetros, en donde la aplicación del cliente desea convertir pasa por parámetro 100 al bean que se encuentra instalado en nuestro Servidor WebLogic, por medio de una interfaz Objeto, devolviendo el valor en centímetros correspondiente. 1.1 CREACION DE INTERFACES Interfaz Objeto o Remota //Conversor.java package examples.ejb.basic.pastaconversor; import javax.ejb.ejbobject; import java.rmi.remoteexception; public interface Conversor extends EJBObject { public double polcent(double pols) throws RemoteException; } Interfaz Home //ConversorHome.java package examples.ejb.basic.pastaconversor; import java.io.serializable; import java.rmi.remoteexception; import javax.ejb.createexception; import javax.ejb.ejbhome; public interface ConversorHome extends EJBHome { Conversor create() throws RemoteException, CreateException; } 35

32 Capitulo IV. Estructura e Implementación de un Programa EJB 1.2 APLICACIÓN BEAN //ConversorBean.java package examples.ejb.basic.pastaconversor; import java.rmi.remoteexception; import javax.ejb.sessionbean; import javax.ejb.sessioncontext; public class ConversorBean implements SessionBean { public double polcent(double pols) { return pols * 2.54; } public ConversorBean() {} public void ejbcreate() {} public void ejbremove() {} public void ejbactivate() {} public void ejbpassivate() {} public void setsessioncontext(sessioncontext sc) {} } 1.3 DESCRIPTORES DE DESPLIEGUE ejb-jar.xml <?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' ' <ejb-jar> <enterprise-beans> <session> <ejb-name>ejb</ejb-name> <home>examples.ejb.basic.pastaconversor.conversorhome</home> <remote>examples.ejb.basic.pastaconversor.conversor</remote> <ejb-class> examples.ejb.basic.pastaconversor.conversorbean </ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> 36

33 Capitulo IV. Estructura e Implementación de un Programa EJB <method> <ejb-name>ejb</ejb-name> <method-intf>remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> weblogic-ejb-jar.xml <?xml version="1.0"?> <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic EJB//EN' ' <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>ejb</ejb-name> <caching-descriptor> <max-beans-in-free-pool>100</max-beans-in-free-pool> <max-beans-in-cache>100</max-beans-in-cache> <idle-timeout-seconds>5</idle-timeout-seconds> </caching-descriptor> <clustering-descriptor> <home-is-clusterable>false</home-is-clusterable> <home-load-algorithm>round-robin</home-load-algorithm> <stateless-bean-is-clusterable>false</stateless-bean-is-clusterable> <stateless-bean-load-algorithm> round-robin </stateless-bean-load-algorithm> <stateless-bean-methods-are-idempotent> False </stateless-bean-methods-are-idempotent> </clustering-descriptor> <jndi-name>pastaconversor.conversorhome</jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar> 1.4 APLICACIÓN CLIENTE //ConversorCli.java 37

34 Capitulo IV. Estructura e Implementación de un Programa EJB package examples.ejb.basic.pastaconversor; import javax.naming.context; import javax.naming.initialcontext; import javax.rmi.portableremoteobject; import javax.ejb.*; import javax.naming.*; import java.rmi.remoteexception; import java.util.*; public class ConversorCli { static String url = "t3://paci:7001"; static String user = null; static String password = null; public static void main(string[] args) { System.out.println("Iniciando\n"); if ((args == null) (args.length == 0)){} //Checar argumentos, en caso que existan else for (int i = 0; i < args.length; i++) { switch(i) { case 0: url = args[i]; break; case 1: user = args[i]; break; case 2: password = args[i]; break; default: } } System.out.println("Crear un objeto de componente\n"); try { } Context ctx = getinitialcontext(); //crea la interfaz home ConversorHome cvh = (ConversorHome) ctx.lookup ("pastaconversor.conversorhome"); Conversor oconv = cvh.create(); //Crea el bean por medio de la int. home //Llama al metodo que convierte de pulgadas a centimetros. double valorcent = oconv.polcent(100.00); System.out.println("Valor para 100: "); System.out.println(String.valueOf(valorcent)); oconv.remove(); } catch (Exception ex) { System.err.println("Error!"); ex.printstacktrace(); } //Verifica la autentificacion del cliente static public Context getinitialcontext() throws Exception { 38