TALLER DE DESARROLLO CLIENTE/SERVIDOR

Transcripción

1 TALLER DE DESARROLLO CLIENTE/SERVIDOR Documentación Técnica GRUPO Leonardo Rodríguez Andrés Vignaga Felipe Zipitría

2 INDICE Instalación del Software Instalación y configuración 3 Instalaciones 3 Prototipos iniciales 6 Interoperabilidad.NET / J2EE Introducción 10 Interoperabilidad basada en Web Services 10 J2EE Connector Architecture 15 Interoperabilidad basada en Ja.NET 18 Interoperabilidad basada en ActiveX Bridge 19 Solución a utilizar 19 Arquitectura del Sistema Introducción 21 Arquitectura de las aplicaciones 21 Arquitectura del SID en.net 26 Arquitectura del SGAD en J2EE 28 Experiencias del Desarrollo Introducción 33 Experiencia en Desarrollo Aplicativo.NET 33 Experiencia en Desarrollo Aplicativo J2EE 33 Referencias Apéndice I: Proceso de creación de componentes COM Apéndice II: Configuración de Oracle para la interacción con el DTC.. 39 Introducción 39 Configuración 39

3 Instalación y Configuración INSTALACIÓN DEL SOFTWARE Los objetivos del prototipo a construir eran la experimentación en el desarrollo de un aplicativo distribuído que abarque tanto la plataforma.net como la plataforma J2EE, así como estudiar y analizar los diferentes mecanismos existentes para lograr la integración de aplicaciones en ambas plataformas. Esto requirió la instalación y configuración de una infraestructura de software que incluiría los componentes necesarios para permitir el funcionamiento de ambas plataformas. También apuntando a aproximarse aún más a situaciones reales, las instalaciones se hicieron sobre dos sistemas operativos distintos y trabajando sobre dos motores de base de datos distintos. La arquitectura de base se distribuyó físicamente en dos equipos servidores, los cuales tienen la siguiente configuración: Servidor Win2k Servidor Linux Windows 2000 Advanced Server IBM UDB2 7.2 Microsoft.NET Beta 2 Internet Information Server 5.0 Linux RedHat 7.1 * Oracle Enterprise Edition IBM Web Sphere IBM HTTP Server IBM WSTK 3.1 * Las versiones manejadas inicialmente fueron diferentes a las finales. Referirse a las instalaciones particulares por detalles. Figura 1: Configuración En el servidor Linux se optó por instalar el RDBMS Oracle para experimentar la configuración de IBM WebSphere usando Oracle como repositorio de objetos del sistema, la cual difería de la estándar, dado que las herramientas provistas por la instalación de WebSphere requieren completar algunas actividades extras no así con la instalación usando IBM UDB2. Luego de comenzar a trabajar con esta versión y de configurar exitosamente el servidor de aplicaciones sobre Oracle, la versión 4 del producto cambió el formato de utilización del repositorio del sistema y ya no requería como necesaria para su funcionamiento básico, sino que se podía instalar opcionalmente para soporte a los desarrolladores. Para cada una de las máquinas fue necesario la instalación de componentes extras necesarios frecuentemente para el correcto funcionamiento del software a instalar, los cuales serán detallados en las descripciones de las instalaciones particulares. Instalaciones Instalación Servidor Win2k Instalación del SO: Windows 2000 Advanced Server La instalación del servidor Windows 2000 Advanced Server se hizo en la forma estándar. Además, éste servidor ya cuenta con el servidor Web IIS, así como el MTS como servidor de aplicaciones de componentes COM. La instalación no requirió de software adicional para la configuración de hardware, es decir, los drivers se encontraron ya en los CDs de la versión del software de Microsoft, y todo quedó funcionando correctamente. El servidor se instaló como Standalone. TDCS 2001 / Grupo 1 3

4 Instalación BD: UDB2 La base de datos UDB2 tuvo algunos problemas en principio, dado que la versión instalada inicialmente, la 7.0, no funcionaba con el ODBC de Microsoft teniendo problemas para funcionar, por este motivo, con el MTS. Se bajó e instaló la nueva versión (7.2), la cual decía corregir estos problemas, lo cual fue efectivamente comprobado. No se instalaron servicios y software adicional, por ejemplo, para Data Mining. Instalación de Microsoft.NET (Framework y Visual Studio.NET) Se hizo la instalación por defecto, la cual no presentó mayores dificultades. Instalaciones Extras Lo único que se le agregó a este sistema fue el WinZip para extraer archivos comprimidos, el JDK 1.3.1, y luego el software Ja.NET. Instalación Servidor Linux Instalación de SO: Linux RedHat 7.1 La instalación de RedHat Linux recomendda a priori por IBM era de RedHat 6.2. Esta instalación, la cual se intentó hacer en un principio, tuvo innumerables problemas algunos de los cuales se detallan a continuación: la tarjeta de red no estaba soportada nativamente, por lo que hubo que agregarle luego de instalado de forma básica los fuentes de los módulos que soportaban esta tarjeta y compilarlos. Luego de ésto si se pudo hacer funcionar la red. el servidor X-Windows no soportaba la tarjeta de vídeo Intel810, con lo cual se debería bajar una nueva versión del servidor Xfree86 y sus aplicaciones de soporte. conflictos con dispositivos USB. Cabe recalcar que el hardware de las máquinas de IBM era de punta en ese momento. Por estos motivos, se decidió instalar la versión 7.1 de RedHat, recientemente salida en ésas fechas. Esta instalación sí pudo hacerse de una forma muy simple, dado que el hardware que tenían en ese momento las máquinas IBM NetVista no estaba completamente soportado por el RedHat 6.2, pero sí por el RedHat 7.1 [22]. Al disponer de espacio en disco, se instaló el RedHat 7.1 en otra partición del disco, en caso de que por algún problema de compatibilidad con las aplicaciones a instalar tuviera que optarse por la instalación más dificil, pero recomendada por IBM como base de sus aplicaciones. Luego cayó en desuso el RedHat 6.2, dado que el 7.1 no planteó problema alguno en la instalación, configuración y ejecución de éstas. Instalación de DB: Oracle Enterprise Edition El procedimiento que se llevo a cabo en la instalación de Oracle sobre Redhat Linux 7.1 varía del descrito en el manual de instalación de Oracle. Esto es algo común en las instalaciones de Oracle sobre Linux, debido a la gran número de distribuciones y versiones distintas de este sistema operativo. Normalmente al instalar Oracle sobre una determinada distribución de Linux es conveniente previamente verificar en el sitio de dicha distribución, en Metalink [1] o en Technet [2] por instrucciones adicionales para realizar la instalación. TDCS 2001 / Grupo 1 4

5 Principalmente hubo tres puntos a destacar durante la instalación: No todos los prerrequisitos se pudieron satisfacer para la instalación. Más concretamente los cambios en los parámetros del Kernel que son exigidos para la instalación plantearon un problema dado que al reiniciar el equipo con el nuevo Kernel presentaba problemas. Este no fue un factor de mayor importancia dado que los recursos necesarios para las bases de datos que se iban a utilizar no planteaban grandes exigencias, las cuales eran ampliamente satisfechas por los valores actuales. Fue necesario instalar las librerías Glibc 2.1: El software provisto en los CD s de instalación está compilado utilizando esta versión de las librerías, la cual por defecto se encuentra en la versión 6.2 de la distribución de RedHat pero que en las versiones posteriores es sustituida por versiones posteriores de la misma. Dado que la versión instalada fue RedHat Linux 7.1 fue necesaria su instalación. Se necesitaron las librerías de compatibilidad hacia atrás disponibles en los CD s de Linux. Instalación de Servidor Aplicaciones: IBM WebSphere 4.0 El servidor que se configuró e instaló en principio fue el IBM WebSphere 3.5.3, haciéndosele varios upgrades hasta la versión Cabe recalcar que a cada versión de software que salía, se notaba más estable para el trabajo. De todas formas la instalación, la cual se hizo sobre la base de datos Oracle de soporte a las tablas de sistema no fue tan simple. Si bien la BD estaba soportada al hacer la instalación, es decir, estaba entre las opciones de configuración, no funcionó por defecto. Hubo que crear a mano las tablas en la base de datos Oracle (WAS), además de modificar varios scripts de inicialización que por defecto suponían que el soporte del servidor era dado por una base UDB2. Al salir la versión 4.0, prometía una cierta cantidad de beneficios sobre la 3.5 por lo cual se optó por instalarla. La herramienta de instalación de la versión 4 tenía además la posibilidad de migrar lo instalado en versiones anteriores, con lo cual en breves instantes teníamos el servidor 4.0 funcionando con la misma configuración que el y con las aplicaciones que habíamos desarrollado migradas al nuevo servidor. Instalaciones Extras Como Web Server se utilizó el IBM HTTP Server (versión modificada del Apache Web Server), porque hay un módulo de conexión entre el servidor de aplicaciones y el Web Server que no funcionó con el Apache que viene en el RedHat Linux por no estar compilado con soporte para EAPI (Extended API de los módulos). Se instaló para trabajar luego con el servidor IBM WebSphere 4.0, el IBM WebSphere Application Developer Studio 4.0 preview for Linux, el cual fué el entorno de desarrollo utilizado posteriormente para las aplicaciones sobre Linux. También se requirió del IBM WebServices Toolkit 2.3, posteriormente actualizado a la versión 3.1 para trabajar en el desarrollo de Web Services. Estas aplicaciones son muy simples de instalar, dado que vienen para RedHat Linux en el formato estándar de instalación de paquetes, el formato RPM, y no requirieron de instalaciones adicionales. TDCS 2001 / Grupo 1 5

6 Prototipos Iniciales Introducción Proyectos como éste, en el cual se trabaja con las últimas tecnologías disponibles en el mercado, introducen un riesgo extra por la poca madurez de dichas tecnologías. Un riesgo de estas características puede tener una gran influencia en el éxito del proyecto, afectando a todas las etapas del mismo. Todas las decisiones que se tomen principalmente durante la etapa de diseño de la arquitectura de la solución van a basarse en el correcto funcionamiento de estas tecnologías y en el supuesto de que se pueda lograr la interoperabilidad entre ellas sin mayores problemas. Por esto, en una etapa temprana del proyecto, se debe disminuir el impacto que puede tener cada uno de estos riesgos sobre el proyecto en sí. Una forma de lograrlo es mediante la construcción de prototipos que evalúen el correcto funcionamiento de las tecnologías, así como la interoperabilidad entre ellas. Estos prototipos no sólo tienen el objetivo anteriormente descrito, sino que también sirven para evaluar varias alternativas al resolver un determinado problema, permitiendo determinar cuál es la que se adapta más al mismo. Estos van a proporcionar la información necesaria que luego, en la definición de la arquitectura de la solución, servirán para tomar las decisiones más convenientes para nuestro proyecto. Web Services.NET Este prototipo tiene el objetivo de realizar una primer aproximación a la utilización de Web Services en la plataforma.net. Se construyeron aplicativos simples exponiendo Web Services y aplicativos que permitan consumir estos Web Services. El lenguaje utilizado para la construcción de los Web Services fue C# y se desarrollaron utilizando el entorno de Visual Studio.NET. La creación de Web Services simples demostró ser una tarea extremadamente simple utilizando Visual Studio.NET. El exponer un servicio a través de la Web se resume a colocar un atributo ante cada uno de los métodos que se quieran acceder. El proceso de utilización o consumición de Web Services también demostró ser muy simple y muy similar al uso de cualquier otro componente implementado como una librería dinámica o componente COM. En vez de trabajar con referencias normales se trabajan con referencias Web y pueden ser utilizados como simples objetos nativos del lenguaje que ofrecen determinados servicios. El desarrollador no se debe preocupar de la creación de proxies para el acceso, todo esto es realizado automáticamente por la plataforma. Las pruebas fueron realizadas utilizando C# pero esto fue una decisión arbitraria, se podría haber utilizado cualquiera de los otros lenguajes provistos por la plataforma e inclusive diferentes lenguajes para el servidor y el consumidor de los servicios. Interfaz Gráfica basada en.net El objetivo de este prototipo fue estudiar las nuevas características de los Web Forms provistos por el framework. Primeramente, a diferencia del modelo interpretado de ASP, ASP.NET introduce un modelo compilado. Esto es, las páginas son compiladas y el código HTML es generado como consecuencia de la ejecución de métodos de una clase creada automáticamente. TDCS 2001 / Grupo 1 6

7 En ASP.NET, el código HTML y el código de lógica de interfaz (en ASP era VBScript por ejemplo) se encuentra separado. Existen dos variantes básicas a esto: una, donde dicho código se encuentra en secciones especiales de la propia página; u otra donde el código se encuentra en un archivo separado pero asociado a la página. Esta última variante se denomina code behind. El code behind permite realizar una real separación entre lo que es código de gráficos de lo que es código de control. En lo referente a la porción de código HTML que conforma a una página ASP.NET, se introducen los Server Controls. Estos controles son piezas de lógica prefabricada que el diseñador coloca en una página y que manejan entrada y salida, tal como sucede con los forms de aplicaciones de Windows. Estos controles abstraen los detalles del manejo del código HTML y permiten la personalización del control (que se convertirá en código HTML) programáticamente, en forma idéntica a como se desarrollaba una interfaz en VB6. Por ejemplo, en lugar de escribir el código HTML de una lista desplegable (junto con todos sus valores) en la página ASP.NET, es posible utilizar un designer para incluir en la página una DropDownList y desde el code behind setear los valores deseados sin escribir código HTML. Notar que la clase compilada a partir de esa página está preparada para generar el código HTML necesario para crear en el cliente la lista desplegable deseada. ASP.NET puede utilizarse en forma idéntica a ASP tradicional, pero introduce una serie de modificaciones a dicho modelo. Estas modificaciones, dificultan el desarrollo a los novatos por ser un modelo más complicado, por ejemplo en el propio ciclo de vida de las páginas. Por otra parte, una vez comprendido el modelo, las modificaciones otorgan una elegancia antes inexistente (separación real de la lógica y la presentación), y por sobre todo una mayor potencia dada por los Server Controls que ahorran una gran cantidad de código en tareas frecuentes, y el uso de lenguajes como C# en contraposición al VBScript del modelo ASP. Utilización de ADO.NET El objetivo de este prototipo fue estudiar el uso del framework para acceso a bases de datos provisto por.net, así como analizar las diferencias existentes con las propuestas anteriores de Microsoft como eran ADO y DAO. Las pruebas se realizaron con una base de datos Oracle sobre Windows 2000 y se utilizó como lenguaje nuevamente C#. El prototipo apuntó a probar la apertura de la conexión, Data Adapters, Data Readers, Data Sets y ejecución de comandos como (INSERT, DELETE, UPDATE). El manejo de la conexión así como la ejecución de comandos no plantea mayores diferencias a lo que existía en ADO. En cambio el manejo de conjuntos de datos cambio completamente, el concepto de recordset deja de existir para ser remplazado por nuevas estructuras como los Data Readers, Data Sets. ADO.NET está orientado al manejo de la información desconectado, y a su posterior actualización en la base de datos. Los DataSets proveen un mecanismo para disponer de una base de datos relacional en memoria la cual puede ser poblada con datos de una base de datos y ahí manipularlos. Luego permite impactar los cambios realizados sobre la base de datos. Una de las grandes utilidades de los DataSets es de combinárlos con los Web Services, permitiendo situaciones como el siguiente ejemplo: la invocación de un Web Service resulta en la creación de un Data Set y posterior población del mismos con determinados datos. Este Data Set es retornado al cliente el cual lo modifica y luego lo retorna para que los cambios sean impactados a la base de datos. Todo esto es posible gracias a la completa desconexión del Data Set. Esta utilidad tiene la contra que la base puede actualizarse mientras se hace la actualizacion y luego al actualizar se sobreescribirían datos viejos. Cuando se trata del acceso directo de los datos en la base de datos, ADO.NET no permite tanta libertad como lo permitía ADO, ahora solo se dispone de un solo tipo de cursor (forward only) para abrir y recorrer una tabla a través de los DataReaders. TDCS 2001 / Grupo 1 7

8 Creación de Componentes COM+ El servidor de componentes provisto por Microsoft es el MTS (Microsoft Transaction Server), el cual aloja componentes que cumplan con el modelo de COM+. El MTS está incluido nativamente en Windows 2000 y es también el servidor de aplicaciones utilizado por la plataforma.net..net provee un conjunto de librerías que constituyen un framework para la creación de componentes COM+ desde cualquiera de los lenguajes de la plataforma. Estas librerías están accesibles a través del espacio de nombres System.EnterpriseServices. El proceso de creación de un componente COM es simple, solamente se necesita que la clase que desea exportar sus funcionalidades como un componente COM extienda la clase ServicedComponent, así como fijar un conjunto de atributos a nivel de código para especificar los parámetros de creación del componente. Una explicación más detallada de éstas etapas así como su configuración y registro se puede ver en el Apéndice I. Transacciones Distribuidas con COM+ Una vez conocido el mecanismo para crear componentes COM+ y para utilizar ADO.NET para el acceso a bases de datos, el siguiente paso lógico a dar es intentar utilizar MTS a través del DTC (Distributed Transaction Coordinator) para que realice el control de las transacciones, de manera de estar listos para realizar transacciones distribuidas dentro de plataformas Microsoft. Los componentes generados pueden utilizar los servicios que ofrece COM+ para transacciones distribuidas: sincronización, pool de componentes, etc..net permite especificar la voluntad de utilizar estos servicios de una forma declarativa mediante atributos colocados en el código. Por ejemplo, para especificar que las transacciones van a ser coordinadas por el DTC (Distributed Transaction Coordinator) se utiliza el siguiente atributo a nivel de la clase. [Transaction(TransactionOption.Required)] Este atributo a nivel de clase y con el valor Required especifica que ésa clase va a requerir que sus métodos estén dentro de una transacción. Existen varios posibles valores u opciones para especificar el comportamiento del componente frente a las transacciones, pero no vamos a entrar en detalle en este momento. Aparte de declarar que se requieren transacciones para la clase o componente que se está desarrollando, también es posible refinar esa declaración a nivel de método. Además a nivel de método también es necesario establecer el mecanismo por el cual se va a realizar el commit o rollback. Por ejemplo: [AutoComplete] public int deletetest() En este caso AutoComplete especifica que si el método termina exitosamente, (sin tener excepciones no manejadas) al final del método se realiza un commit de la transacción. En cambio, si se levanta una excepción que no es manejada por defecto, se realiza un rollback de la transacción en curso. Otro mecanismo posible para realizar esto es a través de la clase System.EnterpriseServices.ContextUtil que ofrece dos métodos SetComplete y SetAbort para realizar el commit o rollback respectivamente. Dentro del cuerpo del método se trabaja en forma muy similar a como si estuviéramos trabajando directamente con la base de datos. Se debe establecer una conexión con la base de TDCS 2001 / Grupo 1 8

9 datos, realizar las operaciones que sean necesarias y luego cerrar dicha conexión. Lo que sí, en ningún momento se debería intentar es iniciar o terminar una transacción, ya que hacerlo terminaría produciendo una excepción. Para optimizar la apertura y cierre de las conexiones lo cual puede disminuir mucho la performance, se pueden utilizar un pool de conexiones a la base de datos. Para que el DTC pueda coordinar el Resource Manager de Oracle es necesario llevar a cabo determinados pasos de configuración, los cuales serán explicados con mayor detalle en el Apéndice II. Otro atributo que es posible especificar a nivel de clase es el correspondiente al manejo de pool de objetos. [ObjectPooling(Enabled=true, MinPoolSize=2, MaxPoolSize=10, CreationTimeout=3000)] Al incluir este atributo se está dando a entender que la clase requiere del servicio de pool de objetos. Como se ve en el ejemplo, se requieren un conjunto de parámetros para configurarlo y además se requiere sobrescribir algunos métodos para inicializar el objeto cuando este se activa, limpiar cuando se desactiva, entre otros. Esto excede los objetivos del prototipo por lo cual no se entrará en mayor detalle. TDCS 2001 / Grupo 1 9

10 ESTUDIO DE INTEROPERABILIDAD.NET / J2EE Introducción La dinámica actual de las empresas origina su expansión, fusiones con otras empresas y aperturas a nuevos mercados por distintos medios, plantea exigencias muy altas para las aplicaciones empresariales que existen detrás para soportar semejante estructura. Algunas de las exigencias planteadas son: escalabilidad de la aplicación, la cual a su vez está estrechamente relacionada con su portabilidad a nuevas plataformas de base más performantes. facilidad de expansión y mantenimiento. facilidad de integración con aplicaciones y fuentes de datos existentes. seguridad y confiabilidad son fundamentales. Por estas exigencias, las diferentes ofertas de plataformas de desarrollo que existen en el mercado y la gran diversidad de funcionalidades que cada una de estos productos ofrecen, lleva a que cada vez sea más necesario el combinar distintas plataformas para obtener una aplicación que se adapte lo mejor posible a las necesidades. También debería haber bajos costos en tiempo, recurso y dinero como es de suponer. La solución para un problema como éste, en donde existen un gran número de vendedores de software involucrados, requiere esfuerzos en conjunto de su parte para la producción de estándares de forma de coordinar y facilitar el trabajo de todos. Un ejemplo de este problema se da al tratar de integrar aplicaciones desarrolladas en la plataforma J2EE y aplicaciones desarrolladas en el plataforma.net de Microsoft. Muchos esfuerzos han sido volcados para hacer esta integración posible, dado que son las plataformas más utilizadas en el mercado. Existen tanto propuestas propietarias como estándares que solucionan en buena medida este problema de integración. A continuación se presentan cuatro soluciones que se encuentran actualmente en el mercado. Interoperabilidad basada en Web Services Introducción Los Web Services [12] son una tecnología emergente para permitir exponer servicios a través de la Web. Permite que aplicaciones Web interactúen dinámicamente con otras aplicaciones Web, utilizando para ello estándares abiertos como XML, UDDI y SOAP. Las funciones que pueden ser realizadas por los web services pueden ir desde simples intercambios de información hasta complicados procesos de negocios. Las empresas vendedoras de servicios pueden encapsular su lógica y procesos de negocio mediante web services y exponerlas para que sus clientes las consuman a través de la Web. Aparte de un avance tecnológico los web services plantean un cambio en los modelos de negocios de las empresas vendedoras de servicios, poniendo en jaque a los mecanismos actuales de venta de software y servicios computacionales. Exponiendo los servicios en la Web se tiene acceso a un espectro mucho mayor de clientes potenciales y facilita enormemente el acceso a dichos servicios. Las ideas detrás de los Web Services no son ideas nuevas, ya estaban presentes en tecnologías como RPC (Remote Procedure Call). Los Web Services permiten realizar invocaciones a TDCS 2001 / Grupo 1 10

11 procedimientos remotos, tanto en redes de porte pequeño como puede ser una Intranet empresarial como en redes de gran porte como Internet. Esto es posible porque están basados en un protocolo simple y liviano para realizar las invocaciones. El protocolo que permite realizar las invocaciones es SOAP (Simple Object Access Protocol). SOAP es un protocolo estándar creado por la W3C, basado en XML. SOAP está compuesto por cuatro componentes fundamentales: un envoltorio que define un framework para describir los mensajes y cómo estos deben ser procesados, un conjunto de reglas para codificar (o serializar) instancias de tipos de datos definidos por las aplicaciones, una convención de cómo representar invocaciones remotas y sus respuestas, y una convención para vincular el intercambio de mensajes con un protocolo de transporte. El protocolo de transporte que normalmente se utiliza con SOAP y el utilizado por los Web Services es HTTP. El utilizar como protocolo HTTP para las invocaciones facilita el uso de la infraestructura Web ya existente en prácticamente toda empresa en la actualidad, para el intercambio de información o publicación de servicios de la empresa. Asimismo, este intercambio es posible realizarlo sin tener que agregar más protocolos a los ya existentes en los Firewalls corporativos para permitir estos flujos de información, lo cual sería necesario si se utilizara algún otro protocolo. Los Web Services son mucho más que simplemente SOAP, este sólo define el protocolo de invocación remota de los métodos, pero aparte de éste también incorporan al WSDL (Web Service Description Language) como un lenguaje también basado en XML que permite describir los contratos de cada servicio. Este lenguaje fue desarrollado conjuntamente por Microsoft e IBM y sometido para su aprobación como un estándar. También se incluye un protocolo para el descubrimiento de Web Services (Disco) el cual define el formato de un documento XML con la información de descubrimiento y un protocolo para que un usuario pueda recibir este documento, permitiendo descubrir los servicios de una URL conocida. Para los casos en que el usuario no conoce la URL, también incluye un mecanismos UDDI (Universal Descriptor, Discovery and Integrator) estándares para que los proveedores de servicios publiquen sus servicios y los consumidores los encuentren. Al estar basados en estándares abiertos, no están restringidos a ninguna plataforma o lenguaje en particular, y por ello ofrecen un framework ideal para la integración de aplicaciones. Existen otras tecnologías que permiten la integración de aplicaciones o componentes distribuidos; CORBA ó DCOM son un ejemplo de ellas. Estas tecnologías normalmente son muy complejas (difíciles de implementar) y requieren de una gran cantidad de recursos para funcionar correctamente. Esto plantea requerimientos importantes de hardware tanto para el servidor como para el cliente y también sobre la infraestructura de la red de soporte. Por las razones mencionadas anteriormente, estas tecnologías son solo viables en redes privadas pequeñas y no es posible utilizarlas con componentes de bajos recursos como por ejemplo PDA o celulares. La ventaja que plantean los Web Services es que el protocolo que utilizan para realizar las invocaciones es un protocolo liviano y simple, lo que lo hace propicio para correr en redes de gran porte como Internet y pueden ser utilizados desde cualquier dispositivo. Actualmente las plataformas.net y J2EE son las principales plataformas que incluyen soporte de Web Services en forma nativa. TDCS 2001 / Grupo 1 11

12 Transacciones La aparición de los Web Services promete tener un gran impacto en la forma en que los grandes sistemas empresariales se comunican y colaboran. Los procesos de negocio ya no estarán restringidos a una sola empresa, estos pasarán a ser grandes procesos que implicarán la colaboración de varias empresas. La tecnología que permita realizar esta integración debe disponer de mecanismos de seguridad y transaccionalidad apropiados, para asegurar la confiabilidad y confidencialidad de la información por ellos manejada. Actualmente la propuesta de Web Services no incluye soporte para transacciones. Numerosos esfuerzos se están llevando a cabo en esa dirección para lograr aumentar la confiabilidad de esta tecnología. IBM está llevando adelante un proyecto llamado Web Services Transactions Project, [15][13][14] el cual intenta brindar un solución al problema. Apuntan a resolverlo utilizando un framework de coordinación de propósito general como es el J2EE Activity Service [16], dada la gran variedad de modelos transaccionales que existen en la actualidad. La idea es que este framework sea lo suficientemente flexible como para permitir coordinar a todos los participantes con diferentes modelos transaccionales, utilice protocolos estándares como SOAP y no comprometa la autonomía de ninguno de los participantes. Otra propuesta actualmente disponible en el mercado es la de Versata Inc., la cual dispone de una extensión [17] para servidores de aplicaciones J2EE llamada Versata Logic Server para el manejo de lógica de negocio. Soporta servidores de aplicaciones como IBM WebSphere o BEA WebLogic. Esta extensión también permite el manejo de transacciones en forma declarativa sobre los Web Services. Asimismo existe una propuesta de un modelo transaccional basado en SOAP llamada SOAP- CTX [18], con el objetivo de ejecutar transacciones ACID sobre conexiones no confiables. Este fue especialmente diseñado pensando en protocolos como HTTP o SMTP. Integración J2EE y.net Claramente los Web Services presentan una propuesta muy interesante para la integración de aplicaciones en diferentes plataformas y diferentes lenguajes. Dado que los Web Services aún son una tecnología emergente, la cual no está completamente estable, los ideales de interoperabilidad entre plataformas no se cumplen en un 100% por lo cual es necesario complementar con determinadas herramientas para poder resolver estos problemas de interoperabilidad. Para la integración de plataformas como.net y J2EE, existen una gran variedad de herramientas que permiten llevarla a cabo. Algunas de estas herramientas son: IBM Web Service Toolkit (WSTK): Provee de un runtime environment (tanto del lado del cliente como del servidor), demos, ejemplos y algunas herramientas adicionales para diseñar y ejecutar aplicaciones basadas en Web Services [20]. El objetivo del producto es facilitar el desarrollo de aplicaciones basadas en Web Services. Trabaja como un plug-in para servidores de aplicaciones J2EE y actualmente en la versión 3.0 los servidores soportados son: IBM WebSphere y Web Sphere MicroEdition, Jakarta Tomcat 4.0. Estos servidores ya tienen soporte para Web Services, pero el WSTK le agrega algunas funcionalidades nuevas y aplicaciones ejemplo. Aparte de incluir todos los estándares como SOAP, WSDL, UDDI; el WSTK provee un conjunto de utilidades extras que ofrecen entre otras cosas servicios de identificación, notificación, medición TDCS 2001 / Grupo 1 12

13 de uso de Web Services y contratación de Web Services y servicios de acceso a datos similares a JDBC basado en Web Services [21]. GLUE: Provee una plataforma tanto para desarrollar como para consumir Web Services para la plataforma Java. El mismo soporta y es completamente compatible con los estándares XML, SOAP, WSDL y UDDI. Incorpora una API muy completa que disminuye la complejidad del desarrollo y publicación de Web Services. Este producto es desarrollado por la empresa The Mind Electric. Se destaca por su facilidad de uso (lo cual fue confirmado al implementar un prototipo para consumir Web Services de.net desde Java), su confiabilidad y robustez. Java XML Pack: Es un paquete provisto por Sun que incorpora un conjunto de APIs para XML y APIs estándar para manejo de Web Services. Las APIs provistas soportan SOAP, XMLP (XML protocol) el cual es una especificación provista por W3C para la interacción entre objetos remotos basada en XML (está aún en construcción y se espera que finalmente sea basada en SOAP) y también soporte para WSDL y UDDI. El paquete está compuesto por cuatro APIs, JAXM para mensajería en general, basada en SOAP, JAXP para procesamiento de datos en formato XML, JAXR para registro de servicios (soporta UDDI) y JAX-RPC que permite realizar invocaciones a Web Services (basada en SOAP y con soporte WSDL). Prototipos Para probar la interoperabilidad entre Java y.net, se intento realizar pruebas con el IBM Web Services Toolkit y con GLUE. Para el caso de IBM WSTK hubieron algunos problemas con su instalación, los cuales impidieron que se llegara a completar las pruebas. Estas pruebas se hicieron instalándolo sobre el servidor de aplicaciones IBM Web Sphere 4.0 sobre Windows 2000 Professional Edition. En cambio para el caso de GLUE [19], las pruebas fueron realizadas con éxito y sin enfrentar mayores problemas. En las pruebas realizadas se utilizó GLUE 2.0 y fueron realizadas sobre Windows 2000 Professional Edition. Inicialmente se creo un Web Service utilizando Visual Studio.NET, que por un lado dispone de un método que retorna el string tradicional Hello World!! y otro Web Service que dado dos números realiza su suma y retorna el resultado. Esos servicios se publicaron y quedaron prontos para ser utilizados. Luego desde Java y utilizando GLUE se creo una aplicación que permite invocar estos Web Services y mostrar los resultados en pantalla. GLUE no requiere la creación de Stubs previo a la invocación de los métodos, estos son creados dinámicamente por el al momento de realizar las invocaciones. Esto permite disminuir y simplificar el trabajo necesario por los desarrolladores. Lo único que se debe crear previamente es una interfaz que corresponda a los métodos de los Web Services que se van a invocar, esta luego se le pasa como parámetro a GLUE para que éste pueda devolver un proxy que implemente dicha interfaz. El resultado de esto es que prácticamente de forma transparente, desde Java se puede obtener una referencia a un objeto que representa al objeto modelado por los Web Services del lado del servidor. Dicha interfaz puede ser generada en forma automática utilizando la herramienta wsdl2java partiendo del documento que describe al Web Service. En la Figura 1 se puede ver la implementación del ambos Web Services en C#. Para marcar a un método como accesible desde la Web lo único que se necesita es poner el atributo [WebMethod] que así lo diga. En la Figura 2 se puede ver el código necesario para realizar la invocación a los Web Services usando GLUE. El mecanismo es muy simple, basta simplemente realizar el binding a la URL en donde está localizado el documento WSDL que describe los servicios disponibles y así ya obtener una referencia a un proxy generado dinámicamente. TDCS 2001 / Grupo 1 13

14 Luego basta con invocar a los métodos del proxy devuelto para realizar las invocaciones a los Web Services correspondientes. using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Diagnostics; using System.Web; using System.Web.Services; namespace WSHelloWorld { public class Service1 : System.Web.Services.WebService { public Service1() { InitializeComponent(); } #region Component Designer generated code private void InitializeComponent(){} #endregion protected override void Dispose( bool disposing ){} // [WebMethod] public string HelloWorld() { return "Hello World"; } } } // [WebMethod] public int add(int a, int b) { return a+b; } Figura 1: Web Services implementados con de.net // Prototipo.- Consumo de Web Services publicados por la plataforma //.NET desde Java utilizando GLUE. import electric.registry.registry; public class TestIt{ public static void main( String[] args ) throws Exception { // Realizando el bind con el correspondiente archivo WSDL. // El archivo WSDL se encuentra publicado en la dirección // abajo mencionada String url = " IWSHelloWorld Hello = (IWSHelloWorld) Registry.bind( url, IWSHelloWorld.class ); // Invocación al Web Service como si fuera un objeto // Java local String str = Hello.HelloWorld(); System.out.println("Prueba del Test Hello World"); System.out.println(""); System.out.println("Resultado: " + str); } } // Invocación al Web Service como si fuera un objeto // Java local int res = Hello.add(10, 10); System.out.println("Prueba de la suma, con "); System.out.println(""); System.out.println("Resultado: " + res); Figura 2: Invocación de Web Services mediante GLUE TDCS 2001 / Grupo 1 14

15 J2EE Connector Architecture Introducción J2EE Connector Architecture (JCA) [3][6] es un estándar desarrollado por el Java Community Process apostando a solucionar el problema de integración entre servidores de aplicaciones y Enterprise Information Servers (EIS) existentes. Antes de la existencia de la JCA los vendedores de servidores de aplicaciones debían extender sus productos mediante mecanismos propietarios para permitir la interoperabilidad con determinados tipos de EIS. Los EJB desarrollados utilizando estos mecanismos propietarios perdían automáticamente la portabilidad hacia el resto de los servidores de aplicaciones J2EE disponibles en el mercado, y con esto las características fundamentales a la cual apunta la tecnología Java. Por otro lado con la introducción de JCA, los EJBs desarrollados pueden acceder potencialmente a cualquier EIS mediante mecanismos homogéneos y bien definidos por la especificación JCA [3], logrando así no comprometer la portabilidad de los EJB desarrollados. Como ejemplo de EISs podemos considerar a Enterprise Resource Planning (ERP), procesamiento de transacciones en mainframes, bases de datos, aplicaciones legadas implementadas en lenguajes distintos a Java y otras plataformas para desarrollo de aplicaciones empresariales (como puede ser.net). Actualmente se encuentra disponible la especificación 1.0 de JCA, la cual se incorporó a la plataforma J2EE a partir de la versión 1.3. La idea fundamental detrás de JCA es que los vendedores de servidores de aplicaciones extiendan sus productos para soportar la especificación JCA y los vendedores de EIS proveer de los llamados resource adapters (una suerte de drivers, se entrará en mayor detalle en las siguientes secciones) para cada uno de sus EIS. Estos resource adapter se registran en el servidor de aplicaciones, quedando disponibles para ser utilizados por los componentes que residen en el mismo. Para acceder a los EIS la especificación define un mecanismo homogéneo mediante un API (llamada Common Client Interface o CCI). La especificación establece una serie de contratos que debe cumplir tanto los servidores de aplicaciones que implementen la JCA, como los resource adapters de cada EIS para definir mecanismos de escalabilidad, seguridad y permitir manejos transaccionales entre los mismos. La Arquitectura Para eliminar las heterogeneidades existentes entre los distintos EIS, la especificación define una serie de contratos a nivel del sistema que deben cumplir tanto el servidor de aplicaciones como los EIS. Al decir a nivel del sistema significa que van a ser coordinados entre ambos sistemas (servidor de aplicaciones y EIS) siendo completamente transparentes para las aplicaciones que corren en el servidor de aplicaciones. Se establecen tres tipos de contratos: Manejo de conexiones: Con el objetivo de permitir el manejo homogéneo de las conexiones, proveer una interfaz común para el manejo de las conexiones y de un pool de conexiones a los efectos de permitir escalabilidad en las soluciones. También permitir un mecanismo genérico para que el servidor de aplicaciones pueda proveer distintas Quality of Service (QoS). Seguridad: Extiende los contratos de manejo de conexiones con detalles específicos a la seguridad, como puede ser permitir pasar las credenciales desde el servidor de aplicaciones al resource adapter. TDCS 2001 / Grupo 1 15

16 Manejo de transacciones: Permitir establecer un ambiente transaccional al trabajar con diferentes EIS de una forma completamente transparente. La arquitectura de la JCA está basada en la existencia de los llamados resource adapters específicos de cada EIS, los cuales son componentes de software que implementan los contratos por el lado de los EIS, sirven de intermediarios entre el servidor de aplicaciones y los EIS. Ver Figura 3. El servidor de aplicaciones por su lado, debe de extenderse para soportar la JCA, implementando los contratos. Figura 3: Arquitectura de la JCA Múltiples resource adapters se pueden registrar a un servidor a aplicaciones y también es posible que un resource adapter se registre en varios servidores de aplicaciones. Para la comunicación entre los componentes y los resources adapters la especificación permite dos mecanismos: A través de la Common Client Interface (CCI). Interfaz especialmente diseñada para permitir un acceso uniforme a todos los EIS. A través de APIs específicas de cada resource adapter. Se recomienda el uso del primer mecanismo. JCA y.net La J2EE Connector Architecture ofrece una solución interesante al problema de interoperabilidad existentes entre EJB de la plataforma J2EE y componentes COM de la plataforma Microsoft [5]. En la actualidad en el framework provisto por EJB y por COM las transacciones distribuidas son manejadas mediante la implementación del Distributed Transaction Processing (DTP) definido por los estándares X/Open. En este estándar existe el llamado Transaction Manager (TM) que es el encargado de crear y coordinar a todos los recursos participantes de las transacciones distribuidas. Cada uno de los repositorios de información tiene un representante llamado Resource Manager (RM) que dialoga con el TM (utilizando el protocolo XA) de forma de coordinar la transacción para ese repositorio en particular. Llegado el momento, el TM realizará el commit o el rollback de todos los participantes de la transacción simultáneamente. TDCS 2001 / Grupo 1 16

17 Los servidores de aplicaciones J2EE ofrecen el servicio DTP a través del Java Transaction Service (JTS), de forma análoga del lado de Microsoft existe el Distributed Transaction Coordinator (DTC). A pesar de utilizar ambos el DTP, no es posible que el JTS se comunique directamente con un RM de COM, lo cual imposibilita el tener transacciones que abarquen componentes EJB y COM simultáneamente. Como fue presentado anteriormente, JCA fue diseñado especialmente para resolver problemas como éste, por lo cual utilizando JCA sería posible implementar un resource adapter específico para COM que junto a un servidor J2EE con soporte para JCA permita realizar transacciones distribuidas combinando componentes EJB y COM. Actualmente JCA ha tenido una amplia aceptación en el mercado y existen varios servidores de aplicaciones J2EE con soporte para JCA. También existen gran cantidad de empresas abocadas al desarrollo de JCA Connectors o resource adapters. Algunas empresas como INTRINSYC [9] y Javector Software [5] han desarrollado resource adapters específicos para COM, permitiendo el manejo de transacciones, seguridad y pool de conexiones para COM. Mediante el uso de los JCA es posible acceder a componentes COM desde cualquier plataforma, y de cualquier servidor de aplicaciones que soporte la especificación JCA. El connector desarrollado por INTRINSYC, no requiere la instalación de ningún software en especial del lado del servidor Microsoft, este dialoga directamente utilizando el protocolo DCOM. En la Figura 4 se puede ver la arquitectura de la solución de INTRINSYC. Figura 4: JCA Connector de INTRINSYC Dispone de la librería J-Integra Pure Java Runtime que permite tanto el acceso a COM a través del resource adapter, como de programas Java normales. Servidores de Aplicaciones con soporte JCA En la actualidad existen varios servidores de aplicaciones J2EE con soporte para J2EE Connector Architecture. En la Figura 5 se puede ver una lista de ellos. También existe una considerable cantidad de resource adapter disponibles en el mercado. Por más información ver [4]. TDCS 2001 / Grupo 1 17

18 Vendedor / Producto Versión BEA WebLogic Preview Borland Enterprise Server IBM WebSphere Technology for Developers 1.0 Macromedia JRun Server Technology Preview 1.0 Pramati Server SilverStream extend App Server 4.0 Beta 1.0 Sybase EAServer Trifork Application Server Figura 5: Servidores de aplicaciones con soporte JCA IBM WebSphere incluye soporte para JCA desde la versión 4.0, pero en modalidad BETA. A partir de la versión 4.1 de WebSphere el soporte de JCA ya es una de las funcionalidades finales incluidas por el producto. Interoperabilidad basada en Ja.NET Introducción Ja.NET es un producto ofrecido por la empresa Intrinsyc Software Inc. que provee un bridge entre el mundo Java y el mundo Microsoft.NET [7][8]. Permite el acceso a EJBs desde cualquier lenguaje provisto por.net y también permite el acceso a componentes.net desde cualquier aplicación Java, inclusive EJBs. Esto lo logra haciendo uso de.net remoting, el nuevo protocolo para objetos distribuidos ofrecido por Microsoft..NET remoting fue diseñado para ser utilizado en ambientes Intranets donde el hay un alto acoplamiento entre los distintos componentes o también sobre ambientes Internets en donde existe un bajo acoplamiento entre los componentes..net remoting es usado dentro de la plataforma.net para permitir la comunicación de managed componentes (o componentes CLR) que estén en diferentes dominios de aplicación. Al hacer uso de.net remoting Ja.NET permite que los componentes Java aparezcan como componentes CLR y que los componentes CLR aparezcan como componentes Java. La versión actual de Ja.Net (1.0) no soporta transacciones distribuidas ni niveles de seguridad, pero promete que para futuras versiones estas funcionalidades van estar integradas. Por las carencias que tiene esta propuesta a primera vista no tiene mayores ventajas sobre lo que se podría realizar utilizando Web Services. Pero en realidad si las tiene: Soporta múltiples protocolos de transporte. Por ejemplo permite transferencias binarias de alta velocidad sobre TCP. Permite activación y control de tiempo de vida de los objetos por parte del cliente. Soporta eventos y callback. Permite mapeo entre la jerarquía de clases y tipos. Soporte Ja.Net incluye soporte para los servidores de aplicaciones BEA WebLogic, IBM WebSphere, Oracle 9i, iplanet, Borland Enterprise server y JBoss. TDCS 2001 / Grupo 1 18

19 Interoperabilidad basada en ActiveX Bridge ActiveX bridge [10] es una tecnología agregada al servidor de aplicaciones IBM WebSphere a partir de la versión 4.0 [11] que permite que aplicaciones COM accedan a componentes EJB y otros servicios disponibles de la plataforma J2EE que se encuentren disponibles en el servidor WebSphere. Esto se logra teniendo una JVM corriendo dentro del proceso ActiveX la cual es la que efectivamente se comunica con el servidor, y el componente COM a través del ActiveX bridge realiza las invocaciones correspondientes a esta JVM [10]. En la Figura 6 se ve reflejada la arquitectura propuesta. Figura 6: Arquitectura del ActiveX Bridge El bridge además del acceso a componentes EJB permite el acceso a las APIs de Java, como pueden ser Java Naming and Directory Interface (JNDI), Java Database Connectivity (JDBC), Java Messaging Service (JMS), etc. El bridge soporta manejo de control de cargas y seguridad, pero no soporta transacciones distribuidas que involucren ambos ambientes. Otra carencia es que la comunicación es unidireccional, solo es posible invocar servicios o componentes Java desde COM, pero no es posible hacerlo en el otro sentido. La documentación establece que el ActiveX bridge está soportado para ejecutar sobre Visual Basic, VBScript, ASP sobre plataformas NT o Windows Pero debería poder hacerlo en todo lenguaje con soporte COM. Solución a Utilizar Como se vió existen varias posibles soluciones al problema de interoperabilidad entre ambas plataformas. Para la implementación del prototipo es necesario optar por una de las soluciones, la que mejor se adapte a las necesidades del problema y a los tiempos existentes para llevar a cabo el desarrollo. TDCS 2001 / Grupo 1 19

20 Antes de optar por una de las soluciones hagamos un resumen de las principales ventajas y desventajas de las opciones. Los Web Services tienen la ventaja de que son soportados en forma nativa por ambas plataformas, también los prototipos construidos demostraron que es posible realizar esta integración y de una forma muy simple. Por otro lado los Web Services plantean la desventaja de que no permiten manejar transacciones entre ambas plataformas, lo cual lleva a que la integración sea factible sólo para consultar información, no para la actualización. Los Web Services, al estar basados en estándares, plantean la ventaja de que al exponer los servicios luego es posible integrarlos a otra plataforma si es necesario sin tener la necesidad de realizar ningún cambio o tener especial consideración. Por otro lado la solución propuesta por JCA promete ser la más completa, ofrece una solución elegante a todo el problema de integración de ambas plataformas. Al permitir realizar transacciones que se extiendan en ambas plataformas permite realizar una integración completa. Se debe considerar que esta tecnología es relativamente nueva y que el servidor de aplicaciones J2EE (IBM WebSphere) que se va a utilizar, en su versión 4.0 soporta la J2EE Connector Architecture en una versión Beta. Las otras dos propuestas Ja.Net y ActiveX bridge plantean una solución particular y propietaria la cual genera una dependencia fuerte con un producto en particular. El uso de ActiveX bridge restringe completamente la portabilidad de los EJB que hagan uso de esta tecnología. Las funcionalidades ofrecidas por Ja.Net y ActiveX bridge no plantean ventajas sobre los que es posible lograr mediante el uso de Web Services, para este problema en particular. De los puntos antes mencionados se desprende que las dos opciones más fuertes para solucionar este problema en particular serían mediante Web Services o usando JCA. Todo parece indicar que el uso de JCA es la mejor solución para este problema, pero por las restricciones de tiempo existentes para la culminación del proyecto se optó por el uso de los Web Services, tecnología para la cual ya se habían realizado prototipos que demostraban la factibilidad de su uso. TDCS 2001 / Grupo 1 20