Web Services

Informe de Proyecto de grado
Estudio e implementacin de Web Services
1INTRODUCCIN..................................................................................................................................................................4 1.1EL PROYECTO.......................................................................................................................................................................4 1.2OBJETIVO..............................................................................................................................................................................4 1.3ORGANIZACIN DEL INFORME ................................................................................................................................................4 2WEB SERVICES....................................................................................................................................................................6 2.1 INTRODUCCIN.....................................................................................................................................................................6 2.1.1RPC............................................................................................................................................................................6 2.1.2Comparando protocolos XML.................................................................................................................................6 2.2EVOLUCIN DE LOS WEB SERVICES........................................................................................................................................8 2.2.1Historia de la computacin distribuida..................................................................................................................8 2.2.2Conectando Aplicaciones en la Web.......................................................................................................................8 2.3ARQUITECTURA DE LOS WS...................................................................................................................................................9 2.3.1Invocacin ..............................................................................................................................................................10 2.3.2Descripcin ............................................................................................................................................................11 2.3.3Discovery.................................................................................................................................................................12 2.4WSDL : WEB SERVICES DEFINITION LANGUAGE.................................................................................................................13 2.5UDDI : UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION.........................................................................................13 2.6OTRAS TECNOLOGAS RELACIONADAS....................................................................................................................................13 2.7IMPLEMENTACIONES Y HERRAMIENTAS..................................................................................................................................14 2.7.1Microsoft SOAP Toolkit 2.0...................................................................................................................................14 2.7.2IBM Web Services Toolkit......................................................................................................................................15 2.7.3 Otras implementaciones de SOAP.......................................................................................................................16 3SOAP : SIMPLE OBJECT ACCESS PROTOCOL......................................................................................................16 3.1INTRODUCCIN....................................................................................................................................................................16 3.2SOAP Y WEB SERVICES.....................................................................................................................................................16 3.2.1SOAP Message Exchange Model..........................................................................................................................16 3.2.2SOAP y HTTP.........................................................................................................................................................18 3.2.3SOAP Message .......................................................................................................................................................18 3.3TRANSPORTE.......................................................................................................................................................................19 3.3.1Separacin de mensaje y transporte.....................................................................................................................19 3.3.2HTTP.......................................................................................................................................................................20 3.3.3SOAPAction Header...............................................................................................................................................21 3.3.4Status Code..............................................................................................................................................................21 4CASOS DE APLICACIN................................................................................................................................................22 4.1INTRODUCCIN....................................................................................................................................................................22 4.2PRESENTACIN DEL PROBLEMA.............................................................................................................................................22 4.2.1Transacciones.........................................................................................................................................................22
4.2.2Publicacin de Cursores........................................................................................................................................23 4.2.3Perfil del producto .................................................................................................................................................23 4.2.4XForms ...................................................................................................................................................................24 4.2.5Plataforma y herramientas ...................................................................................................................................25 5DISEO.................................................................................................................................................................................26 5.1TRANSACCIONES..................................................................................................................................................................26 5.1.1Firma Digital..........................................................................................................................................................26 5.1.2SSL ..........................................................................................................................................................................27 5.1.3Manejo de tickets....................................................................................................................................................27 5.2CURSORES..........................................................................................................................................................................27 5.2.1Manejo de sesiones por parte del servidor...........................................................................................................28 5.2.2Benchmarks.............................................................................................................................................................28 6PROTOTIPO........................................................................................................................................................................29 6.1ESTUDIO DE PLATAFORMA....................................................................................................................................................29 6.2MODELO DE TRABAJO DE APACHE SOAP SOBRE TOMCAT.....................................................................................................29 6.3MECANISMO DE MANTENIMIENTO DE SESIONES (WEB SERVICES STATEFUL)..............................................................................32 6.4 TRANSACCIONES.................................................................................................................................................................33 6.4.1Soporte de comunicacin sobre SSL.....................................................................................................................33 6.4.2Soporte de firma Digital.........................................................................................................................................35 6.4.3Secuencia de Ejecucin de Transacciones...........................................................................................................41 6.4.4Tratamiento de Errores..........................................................................................................................................46 6.4.5Objetos de Intercambio (ValueObjects)................................................................................................................46 6.5 CURSORES.........................................................................................................................................................................47 6.5.1Cursor Abstracto....................................................................................................................................................47 6.5.2Implementacin Bsica de un Cursor...................................................................................................................48 6.5.3Implementacin de un Cursor con Cach...........................................................................................................49 6.5.4Publicacin de un Cursor como Web Service......................................................................................................51 6.5.5Implementacin de un Cliente...............................................................................................................................54 6.5.6RMI..........................................................................................................................................................................55 6.5.7Objetos de Intercambio (ValueObjects)................................................................................................................56 7BENCHMARKS...................................................................................................................................................................57 7.1TRANSACCIONES..................................................................................................................................................................57 7.1.1Objetivo...................................................................................................................................................................57 7.1.2Escenario.................................................................................................................................................................57 7.1.3Ejecucin y Presentacin de los resultados.........................................................................................................57 7.2CURSORES..........................................................................................................................................................................58 7.2.1Objetivo...................................................................................................................................................................58
7.2.2Escenario.................................................................................................................................................................59 7.2.3Ejecucin ................................................................................................................................................................59 7.2.4Presentacin de los Resultados.............................................................................................................................60 8CONCLUSIONES................................................................................................................................................................63 8.1SOBRE LA TECNOLOGA .......................................................................................................................................................63 8.2SOBRE LA APLICACIN A ESTOS CASOS...................................................................................................................................63 8.2.1Transacciones.........................................................................................................................................................63 8.2.2Cursores..................................................................................................................................................................64 8.3SOBRE LA ALTERNATIVA UTILIZADA.......................................................................................................................................68 8.4SOBRE EL FUTURO ..............................................................................................................................................................69 8.5POSIBLES EXTENSIONES AL PROYECTO....................................................................................................................................69
1 Introduccin
1.1 El Proyecto
Recientemente, ha surgido el concepto de WebServices (WS), y los expertos consideran que el mismo cambiar la forma de programar las aplicaciones orientadas a Internet y la conducir hacia una arquitectura orientada a servicios. Este proyecto se basa en el estudio de esta tecnologa y su aplicacin a casos concretos, demostrando su viabilidad a travs de la implementacin de un prototipo.
1.2 Objetivo
El objetivo de este proyecto es evaluar el estado del arte de la tecnologa de Web Services y probar su aplicacin a casos concretos. En una primera instancia se estudi sta tecnologa, los protocolos y especificaciones asociadas, y se realiz una evaluacin de algunas implementaciones y herramientas disponibles. Los casos de aplicacin se eligieron de forma que fueran representativos de los problemas tpicos que pueden intentar resolverse con Web Services. En particular se trabaj en el marco tecnolgico del producto EDF de la empresa IdeaSoft [1], brindando la infraestructura necesaria para realizar transacciones y manejar cursores. El caso de aplicacin para las transacciones consiste en estudiar la viabilidad de realizar transacciones comerciales mediante Web Services. Como un objetivo de este proyecto se presenta el implementar esta funcionalidad, resolviendo problemas tales como: asegurar la confidencialidad de la transaccin, evitar el repudio, etc. Otro problema que puede atacarse utilizando Web Services es el de recorrer catlogos o colecciones de datos. Para ello, se estudi el concepto de cursor genrico, accedido mediante Web Services. Un objetivo de este proyecto es probar su viabilidad, medir su desempeo frente a otras alternativas y fijar una frontera para la utilidad de sta tecnologa.
1.3 Organizacin del Informe

El informe se organiza de la siguiente manera: primero se da una detallada descripcin de la tecnologa, su arquitectura, sus componentes, ventajas y desventajas. Luego, se presenta el marco tecnolgico y funcional de IdeaSoft, a continuacin se expone la implementacin del prototipo y los benchmarks realizados y por ltimo, se enumeran las conclusiones recogidas durante la realizacin del proyecto. En l capitulo titulado Web Services se proporciona una base terica, un racconto de la evolucin tecnolgica que condujo al surgimiento de WS y una informacin general de la arquitectura de los WS. Ms adelante se hace una descripcin de los conceptos WSDL y UDDI y de cmo stos trabajan en conjunto. En el captulo SOAP, se da una descripcin bsica del protocolo, de su aplicacin en los Web Services, de su sintaxis, de la representacin de los datos, y de la forma de transporte entre un punto y otro. En el captulo denominado Caso de Aplicacin se describen los diferentes contextos en que se 4
realiza este proyecto y los requerimientos dados para la ejecucin de transacciones y el manejo de cursores usando Web Services. En el captulo Diseo, se presenta la solucin a los requerimientos del proyecto, haciendo hincapi en los requisitos de seguridad que trae aparejados (firma digital, SSL, etc.) y en las consideraciones de performance. En el captulo Prototipo, se describe el entorno de desarrollo del proyecto, qu herramientas se usaron como software de base para realizarlo y las clases implementadas. Por ltimo se publican mediciones para los distintos entornos de ejecucin, comparando tiempos de respuestas de mensajes firmados y no firmados y los benchmark de los Web Services contra la arquitectura RMI. Finalmente, en el ltimo captulo, se arriba a las conclusiones sobre el proyecto junto con las caractersticas que presenta esta tecnologa.
2 Web Services
2.1 Introduccin
Un Web Services (WS) es una aplicacin que puede ser descripta, publicada, localizada, e invocada a travs de una red, generalmente Internet. Los WS son a los efectos del consumidor componentes que se encuentran dentro de una caja negra, que pueden ser utilizados sin preocuparse de como fueron implementados, y ser accedidos utilizando XML (SOAP), generalmente sobre HTTP. La arquitectura bsica del modelo de WS describe un consumidor, un proveedor y ocasionalmente un corredor (broker) y relacionados con estos agentes est las operaciones de publish (publicar), find (encontrar) y bind (enlazar). Los requerimientos a la hora de desarrollar o consumir un WS son: una forma estndar de representar los datos: XML un formato comn y extensible de mensaje: SOAP un lenguaje comn y extensible para describir los servicios: WSDL (basado en XML). una forma de descubrir los servicios en Internet: UDDI (basado en XML).
Una vasta rea de uso de XML viene dada por la necesidad de interoperabilidad, permitiendo a las aplicaciones comunicarse unas con otras de una forma estndar. En efecto XML se ha vuelto la pieza comn y de mejor entendimiento de la comunidad de diseadores de software. De aqu en adelante nos referiremos a la comunicacin Cliente - Servidor. El proceso servidor, del requerimiento cliente, generalmente retornar un valor como resultado de su proceso. El cliente en este caso es la funcin o mtodo que hace la llamada, el cual requiere ejecutar algn proceso en el servidor. 2.1.1 RPC
RPC permite a los desarrolladores de software hacer funciones o llamadas a mtodos a travs de la red, lo cual permite rudimentarias aplicaciones distribuidas sobre la red. Es un mecanismo a nivel de capa de aplicacin, que comunica una aplicacin con otra. La llamada de RPC es idntica a la sintaxis de una funcin local. La funcin toma la forma de interaccin Cliente - Servidor. RPC acta con el mismo espritu Java RMI, pero se diferencia en que: - no hay contexto de objeto. Funciones remotas son llamadas a travs de la red como una API remota. RMI logra esto naturalmente - requiere un seteo para el retorno de una llamada en ambos servidores - el cliente y el servidor pueden ser implementados con independencia de lenguajes de programacin 2.1.2 Comparando protocolos XML
2.1.2.1 XMLRPC - Liviano, rpido y fcil para la implementacin de invocaciones remotas de funcionalidad a travs de HTTP tunneling - HTTP tunneling es integrante de este protocolo - Operaciones sin conexin no estn actualmente disponibles - Las especificaciones son muy fciles de entender - Es muy fcil de programar, fue la meta del diseo original - El trafico del protocolo es leble y entendible, y un operador podr descifrar el trfico no encriptado - Una conexin debe abrirse para cada nuevo canal, no es posible multiplexar canales - Solamente un servidor sirviendo a un cliente, no soporta descentralizacin - Es una instancia de protocolo fija, no tiene la habilidad de pasarse a otros protocolos - No existe una seguridad de autentificacin especificada - Request y response son ambos documentos XML 2.1.2.2 SOAP Es el protocolo clave para la nueva infraestructura de interaccin entre aplicaciones Soporta HTTP tunneling, como un transport binding Soporta manejo de RPC Soporta operaciones de desconexin No es fcil entender las especificaciones, es un complejo esquema de codificacin, binding para protocolos y otras para HTTP que no estn especificadas No es muy fcil de programar en el actual estado de desarrollo No se necesita de una especificacin para descifrar el trafico no encriptado El generar protocolos eficientes no fue un criterio de diseo Multi-channels y multiplexing no estn actualmente soportadas Se menciona la posibilidad de multi-agent, procesing path, sin embargo no estn las especificaciones en la versin 1.1 La habilidad de host a otros protocolos no se aplica directamente Seguridad y autentificacin no estn directamente especificadas, pero si son flexibles a la hora de implementar. Envelope, request y response son documentos XML.
2.2 Evolucin de los Web Services.

El concepto central de Web Services: computacin orientada a los servicios, que determinan un nuevo paradigma de procesos de creacin de aplicaciones altamente distribuidas. Son aplicaciones modulares, que se autodescriben, pueden ser publicadas, localizadas, e invocadas desde cualquier lugar de la WEB o dentro de una Intranet. El modelo de WS potencia el desarrollo de aplicaciones distribuidas. Por ejemplo una compaa de alquiler de coches puede asociar su sistema de reservas on-line con el sistema de aerolneas y los hoteles. De tal manera que un viajero puede al mismo tiempo hacer una reserva de un vuelo, una habitacin de hotel y un coche de alquiler. 2.2.1 Historia de la computacin distribuida.
Esta evolucin tecnolgica y de una bsqueda de soluciones a la computacin distribuida no es un problema reciente. En los 1980 los protocolos de comunicacin no era objeto de inters de los desarrolladores. Realizar aplicaciones que dentro de una misma mquina se comunicaran entre s, era suficiente. En los 1990 alcanzaron popularidad objetos como COM (Componet Object Model) introducido por Microsoft y CORBA (Common Object Request Broker Architecture) introducido por OMG (Object Management Group). En general, COM y CORBA son modelos para escribir y encapsular cdigo binario. Estos son componentes que pueden ser fcilmente llamados desde cualquier aplicacin que soporte COM o CORBA. Sin embargo estos modelos no son fcilmente interoperables, de tal manera que COM puede solamente llamar a COM, y lo mismo ocurre con CORBA. Conectar una maquina a otra se transform en una prioridad cuando las redes locales se generalizaron. Fue entonces que OMG estableci IIOP (Internet Inter-ORB Protocol) como el protocolo de comunicacin para CORBA. Microsoft creo DCOM (Distributed COM). Mas tarde Sun Microsystems lanzo al mercado RMI (Remote Method Invocation). Con estos protocolos se pueden llamar componentes que se encuentren en otras computadoras a travs de la red. Estas llamadas se realizan bajo la forma de RPC (Remote Procedure Call). Es necesario aclarar que estos protocolos no son interoperables. La solucin esta disponible para tener comunicacin aplicacin a aplicacin desde cualquier mquina a cualquier otra sin importar el sistema operativo, entorno de lenguajes, modelos de objetos distribuidos, y usando los estndares de Internet. Esto es un buen candidato para un protocolo de comunicacin universal. 2.2.2 Conectando Aplicaciones en la Web
Los Web Services manejan la interoperabilidad mediante el protocolo estndar de XML. La necesidad de pensar en el Web site como en una funcin. Web Services son aplicaciones modulares que se autodescriben, que pueden ser publicadas, localizadas e invocadas o usadas desde cualquier parte en la Web o dentro de cualquier red local, basadas en los estndares abiertos de Internet. 8
Ellos combinan los mejores aspectos de los componentes de programacin, y programacin Web, y son un paquete en la forma de mdulos, que pueden ser reutilizados, sin preocuparnos acerca de cmo el servicio esta implementado, o an en que lenguaje, sistema operativo, o modelos de componentes fueron usados para crearlos, as como el consumidor y desde su punto de vista es una caja negra. Son accesibles va los protocolos de Internet como HTTP y SMTP, y basados en XML. XML y SOAP son la base tecnolgica de la arquitectura de los Web Services. SOAP (Simple Object Access Protocol) es un protocolo de mensajes entre computadoras. SOAP especifica el formato de mensaje que accede e invoca a los objetos, mas que un objeto en particular. En Mayo del 2000, se da a conocer SOAP, por W3C [2]. Las empresas que se juntaron para presentar a la W3C las especificaciones del protocolo fueron : Ariba Inc., Commerce One Inc., Compaq Computer Corp, DevelopMentor Inc, Hewlett-Packard Co., IBM Corp., IONA Technologies PLC, Lotus Development Corp., Microsoft Corp., SAP AG, y Userland Software Inc.. Esto es un buen signo de la industria para aceptar e implementar estndares basados en protocolo interoperables. Actualmente este protocolo esta siendo desarrollado por el XML Protocol Working Group de la W3C, en la versin 1.2.
2.3 Arquitectura de los WS

Hay 3 conceptos bsicos que son : descubrir, describir e invocar. Desde el punto de vista del consumidor, tendr primero que encontrarlo o descubrirlo. Luego el consumidor tendr que aprender acerca del Web Service o su descripcin. Finalmente podra disponer o tener la necesidad de invocarlo, suministrando los elementos de entrada y recibiendo los elementos de salida del mismo. Estos conceptos contienen el protocolo SOAP con varias extensiones. El Message building block, situado en el tope de la capa de transporte, el cual consiste de un protocolo de transporte, tales como HTTP y SMTP.
Routing/ I ntermediaries
Reliable Messaging
Context/ Privacy
Transactions
Attachments
Security
Process Flow
QoS
and Pattern Description ( Workflow, Orchestration)
RDF ( meta data)

Semantic Web
SOAP XML
Message / Wire ( I nvocation)
WSDL
Structure XML
Description
UDDI
I nspection
Discovery
Este marco no es muy restrictivo a la tecnologa que puede ser usada para implementar WS, y no 9
limita a los desarrolladores a un producto particular de un vendedor. Significa que puede ser implementado con varias tecnologas, tal como Java en Linux o Visual Basic y Vicual C++ en Windows. Esto se amolda a las situaciones de las empresas, si por ejemplo solo se quiere crear una comunicacin de aplicacin a aplicacin, solo alcanza con usar SOAP, sin la necesidad de los otros componentes, y WS Framework pueden ser implementados en cualquier lenguaje de programacin. Algunos proveedores : HP y e-Speak , IBM Dynamic e-Business, Microsoft .NET Platform and Framework, Sun Microsystems and Sun ONE Desde el proveedor, la primera interaccin es con el bloque de Invocacin, y luego con los bloques de Describir y Descubrir. 2.3.1 Invocacin
Aqu SOAP, es el componente clave para la arquitectura. Es un protocolo de formato de mensaje extensible y se puede colocar en el tope de los protocolos de HTTP y SMTP. 2.3.1.1 SOAP Soportando SOAP, los Web site, pueden acceder programticamente a otras computadoras, sin necesidad de intervencin humana y anexarlo como servicio en sus propias aplicaciones. XML es usado para definir el formato del mensaje, envelope, mecanismos de RPC, y HTTP y SMTP definen los mecanismos de transporte para los mensajes. SOAP es un protocolo simple. Con pocas lneas de cdigo, un parseador XML, y un servidor HTTP, se puede tener un SOAP object request broker (ORB). Un ORB es un servicio que asiste en la invocacin objetos, manejando el tiempo de vida, realizando pooling, manejando performance y dems. SOAP es extensible, por el uso de XML. Ningn otro protocolo garantiza que pueda se usado en todas las situaciones, todas las veces. Tambin establece un framework para enviar mensajes o conducir comunicaciones del tipo RPC. SOAP trabaja con la infraestructura de Internet. No hay que hacer configuraciones especiales en routers, firewall, proxy servers, para que SOAP trabaje. Usando HTTP se vuelve muy fcil de desarrollar, saltando los aspectos de seguridad. Varios proveedores y organizaciones han soportado la implementacin de SOAP. W3C ha definido a SOAP como una especificacin, y ninguna organizacin o un simple proveedor tendr el control sobre SOAP, por lo tanto se ha convertido en otro estndar de Internet, tales como HTML, XML, HTTP y SMTP (ver [2],[3]). SOAP no reemplaza a CORBA, DCOM o RMI. No tiene un modelo de objetos pero habilita a las aplicaciones al uso de varios modelos de objetos y lenguajes.
10
2.3.1.2 SOAP Message Los mensajes son fundamentalmente en una direccin, desde un emisor (cliente) hacia un receptor (servidor), y las comunicaciones son del tipo request/response. Todos los mensajes son documentos XML con su propio esquema, que incluye sus propios namespaces, elementos, y atributos. SOAP define 2 namespaces: envelope, encoding. No puede tener DTD asociados. SOAP message consiste de 3 secciones: envelope, header y body. envelope : elemento raz del mensaje. header: informacin de identificacin del contenido. body: es el contenido del mensaje. (para una informacin completa ver Apndice - SOAP Message) Extensiones al protocolo, pueden ser hechas adicionando mdulos de funcionalidad. Este enfoque permite a los desarrolladores usar los mdulos y funcionalidad que ellos necesitan, sin la necesidad de tener que implementar la totalidad de estos. En pocas palabras el protocolo puede ser extensible. Algunas de las extensiones que pueden ser deseables en los proveedores : Attachments - La posibilidad de incluir un documento no XML, o archivo binario. La posibilidad de enviar documentos de fax, legales, imgenes de medicina, dibujos de ingeniera, o cualquier otro tipo de imgenes, codificadas en Base64 Routing/Intermediaries Relacionadas al proceso de rutear mensajes SOAP a travs de intermediarios. Esto ofrece la posibilidad de agregar varios WS y ofrecerlos como parte de nuestro paquete. Esto es una manera de hacer a los WS escalables, a travs del direccionamiento, incluso hacia mltiples servidores Reliable Messaging Cuando un servidor enva un mensaje, cuanto tiempo espera por la respuesta? Que puede pasar si dos o ms veces el mismo mensaje es enviado? Security Dar un marco de seguridad a la comunicacin. Algunos de los aspectos podran ser aplicar SSL, firma digital, etc. XML Signature nos ayuda a responder: quien enva el mensaje, si el mensaje fue alterado en la ruta. (ver detalles en Apendice - XML Signature). Quality of Services QoS es una medida que puede ser comparada con el nmero o calificacin dada a los ASP o ISP, que mide la calidad del servicio, un concepto similar puede manejarse para a los Web Services. Context/Privacy - Referencia a guardar el contexto y privacidad, del entorno de los usuarios. (Platform for Privacy and Preferences (P3P)). Transaction Support Permitir que un grupo de operaciones o acciones se comporten como si fueran una simple unidad (o todo falla o todo es un xito). 2.3.2 Descripcin
La descripcin de un WS, es la descripcin de los mensajes que se pueden aceptar y generar, 11
fundamentalmente realizada por el WSDL (Web Services Description Language), el cual define ciertos XML Schemas y namespaces. La definicin de la estructura comienza con un XML Schema, que provee una manera de especificar tipos de datos, desde lo ms simple como integer o string, a lo ms complejo como arrays, y otros definidos por el usuario. El siguiente nivel es la descripcin del servicio en formato XML, que describe los servicios de red. La actual especificacion contiene bindings a SOAP, HTTP, y MIME. (a la fecha no esta completamente especificado por la W3C, ver Apendice - WSDL) 2.3.3 Discovery
Una vez conocida la forma de invocar un WS y su descripcin, se necesita una manera de permitir a otros encontrarlo. UDDI (Universal Description, Discovery and Integration) describe como un proveedor puede anunciar la existencia de un WS. Un consumidor puede encontrar la existencia de un WS, a travs de categora.s El siguiente paso es ver los detalles, tales como descripcin, proceso, contrato.
Web Service Requester Socio de negocios u otro sistema
FI ND
Encontrar Web Service
SOAP Request
UDDI Service
firewall
3 BI ND
Recuperar Definicin en WSDL
4
I nvocar Web Service
SOAP Request
1 PUBLI SH
Registrar Web Service (en tiempo de desarrollo)
SOAP Request
Servlets
JAXR
SOAP Request
Documento WSDL
Web Service Provider
Conceptos publish find bind en los Web Services
12
2.4 WSDL : Web Services Definition Language

WSDL es usado para describir servicios Web por parte de las empresas, de tal forma que los clientes puedan acceder a ellos y utilizarlos. Provee informacin de los distintos mtodos que el WS brinda, muestra como accederlos y el formato que deben tener los mensajes. WSDL es un formato XML que describe los servicios de red como un conjunto de endpoints que procesan mensajes contenedores de informacin orientada tanto a documentos como a procedimientos. Las operaciones y los mensajes se describen de forma abstracta y despus se enlazan a un protocolo de red y a un formato de mensaje concreto para definir un endpoint de red. Los endpoints concretos relacionados se combinan en endpoints abstractos (servicios). WSDL es extensible, lo que permite la descripcin de endpoints de red y sus mensajes, independientemente de los formatos de los mensajes o protocolos de red utilizados para comunicarse. Esta versin del lenguaje WSDL es un primer paso que no incluye un framework para describir las reglas de composicin y organizacin de los endpoints. Un framework completo que describa tales reglas debe incluir medios para componer servicios y medios para expresar el comportamiento de los servicios, es decir, reglas de ordenacin para enviar y recibir mensajes. La composicin de servicios debe ser de escritura segura pero tambin debe permitir pasar referencias, siendo las referencias del servicio intercambiadas y enlazadas en tiempo de ejecucin. Este ltimo factor es clave para la negociacin de enlaces en tiempo de ejecucin y la captura del comportamiento de servicios de referencia y de intermediarios. Los autores de la especificacin WSDL desean publicar versiones revisadas de WSDL y/o documentos adicionales que incluyan un framework para componer servicios y un framework para describir el comportamiento de los servicios. Para una especificacin completa de WSDL ver Apndice - WSDL.
2.5 UDDI : Universal Description, Discovery and Integration

UDDI es un proyecto propuesto por Ariba, Microsoft e IBM. Es un estndar para registrar y descubrir los WS. La idea es una registracin en el registro de empresas UDDI, un servicio centralizado y replicado a distintos nodos en forma regular, quedando disponible para ser descubierta por otras empresas. Para una especificacin completa de UDDI ver Apndice - UDDI. Para una especificacin del funcionamiento de WSDL con UDDI ver Apndice WSDL y UDDI.
2.6 Otras tecnologas relacionadas

2.6.0.1 EbXML Es una iniciativa establecida por UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business) y OASIS (Organitatio for the Advancement of Structured Information Standards). EbXML antecede a UDDI. La razn para ebXML fue desarrollar especificaciones XML para el intercambio comercial y crear un simple mercado electrnico donde las empresas de cualquier tamao y ubicacin geogrfica podran encontrar y conducir negocios a travs de mensajes basados en documentos XML. 13
Para ms informacin ver www.ebXML.org 2.6.0.2 JAXR JARX o Java API for XML Registries, provee una API para acceder a XML basados en registros distribuidos. Esta respaldada por Sun y fue originalmente para acceder a ebXML, y forma parte de la API JAXM (Java API for XML Messaging), el cual define una API para mensajes basados en XML. Para ms informacin ver java.sun.com/xml/xml_jarx.html o jcp.org/jsr/detail/093.jsp 2.6.0.3 DSML Directory Services Markup Language, es un marco para describir la estructura y contenido de informacin de servicio de directorio. Esta informacin es representada en un documento XML y define un esquema en el cual establece directorios para publicar informacin que puede ser compartida va un protocolo estndar (HTTP, SMTP) Para ms informacin ver www.dsml.org
2.7 Implementaciones y Herramientas.

Pese a ser una tecnologa emergente, existen actualmente un variado y creciente nmero de implementaciones y herramientas disponibles. A continuacin, se enumeran algunas de las mas importantes y sus principales caractersticas. 2.7.1 Microsoft SOAP Toolkit 2.0 La apuesta de Microsoft a esta tecnologa ha quedado clara al presentar su nueva plataforma .NET, la cual soporta fuertemente XML y SOAP. El Microsoft SOAP Toolkit 2.0 consiste actualmente de tres APIs COM, divididas en: Alto nivel: objetos que simplifican el RPC SOAP a travs de proxies y stubs, basados profundamente en el meta data de XML. Utiliza la API de bajo nivel para hacer este trabajo. Bajo nivel: objetos que acceden directamente al transporte y la estructura del mensaje SOAP, sin basarse en el meta data de XML. SMO (Simple Messaging Object): objetos que vuelven fcil de usar mensajes SOAP que contienen XML, en lugar de tener el overhead del RPC
Adicionalmente a las APIs, hay numerosas herramientas y utilidades que proveen una gran comodidad para el desarrollo, como por ejemplo: WSDL Generator: un wizard para generar el meta data XML derivado de un objeto COM, el cual es usado frecuentemente junto con la API de alto nivel. WSDL and WSML API : una API adicional para la lectura y escritura de meta data XML MSSOAPT: un utilitario para debuggear y tracear el progreso de los request y response del SOAP 14
La plataforma .NET provee un servidor de Web Services, basado en el Internet Information Server y ASP.NET 2.7.2 IBM Web Services Toolkit
El IBM Web Services ToolKit (WSTK) es un kit de desarrollo de software que incluye un runtime, demos y ejemplos para ayudar en el diseo y ejecucin de aplicaciones basadas en Web Services que pueden automticamente encontrarse unas a otras y colaborar en transacciones de negocios sin programacin adicional o intervencin humana. Provee ejemplos simples de Web Services, as como demostraciones de cmo pueden trabajar juntas las tecnologas emergentes estndar, tales como SOAP, WSDL y UDDI. WSTK exhibe la tecnologa emergente en Web Services y es una buena forma de comprender una de las especificaciones mas recientemente anunciadas por IBM. Sin embargo, un entorno de desarrollo de alto nivel para Web Services existe: IBM's WebSphere Studio Application Developer permite la creacin, construccin, testeo, publicacin y discovering de aplicaciones basadas en Web Services que soportan UDDI, SOAP, WSDL, y XML.
A modo de comentario de la utilizacin de sta herramienta se ha comprobado que algunas caractersticas bsicas son limitadas. Por ejemplo, la generacin de archivos WSDL slo es posible a 15
partir de Java Beans. Por mas informacin sobre WSTK., ver [4]. 2.7.3 Otras implementaciones de SOAP
Si bien no fueron evaluadas para ste proyecto, existen actualmente implementaciones de SOAP para Perl, C++, Phyton y PHP. Por mas informacin, ver [5], [6], [7] y [8].
3 SOAP : Simple Object Access Protocol

3.1 Introduccin
SOAP esta descripto en una nota a la W3C., presentado por Microsoft, IBM, y UserLand Software el 8 de Mayo de 2000. La nota describe la versin 1.1 del protocolo. La idea detrs de SOAP es la misma que RPC. Tambin define un protocolo para llamadas a mtodos remotos, sin embargo SOAP incluye : - SOAP especifica informacin adicional incluida en el documento XML, que describe el contenido y como podra ser procesada. - no se asocia fuertemente con HTTP - define la especificacin de algunas estructuras en XML, tales como arrays. - el modelo es descentralizado, esto significa que puede ser procesado por varios intermediarios - tiene caractersticas especificas para operaciones clsicas de RPC con parmetros in/out, etc.
3.2 SOAP y Web Services

SOAP no es el nico protocolo para el uso de WS. Estos pueden ser usados a travs de XML-RPC, operando simplemente sobre HTTP GET, sin que por ello tengan menos componentes. Pero SOAP ha sido aceptado por proveedores y desarrolladores independientes como un estndar, el cual es mejorado todo el tiempo. La primera versin fue liberada en 1999 y fue un resultado de desarrolladores de Microsoft, DevelopMentor y UserLand. SOAP 1.1 fue liberada el 8 de Mayo del 2000, como una Note por la W3C, con la contribucin de IBM y Lotus. Para ver una completa lista de implementaciones ver [9] 3.2.1 SOAP Message Exchange Model
Define un modelo para el intercambio de mensajes, en el cual intervienen los siguientes conceptos : 3.2.1.1 XML Documentos como Mensajes El concepto fundamental es el uso de documentos XML como mensajes, tal como en el caso de SOAP. Esto provee varias ventajas. Puede ser compuestos y ledos por desarrolladores con editores de 16
textos, hacer el proceso de depuracin ms simple, y trabaja en las mayora de las plataformas. 3.2.1.2 Emisor y Receptor En el intercambio de mensajes hay dos partes involucradas: emisor y receptor. Esta operacin es la construccin bsica de bloques de SOAP y es la unidad mas pequea de trabajo. Los requerimientos ms comunes son el intercambio de mensajes en pares request/response. Este es el mtodo SOAP usado con HTTP y/o RPC, el intercambio bsico one-way. Requerimientos complejos de intercambio se componen construyendo cadenas de mensajes. 3.2.1.3 Message Chains El intercambio de mensajes puede ser realizado como una cadena de entidades lgicas que pueden procesar los mensajes. Este concepto de una entidad lgica que realiza algn proceso de un mensaje SOAP es referida como un endpoint, el cual acta como receptor de mensajes. La responsabilidad de un endpoint es examinar un mensaje y remover la parte que fue direccionada hacia ese endpoint para proceso. Un endpoint pueden funcionar tanto como receptor o emisor, pasando mensajes a otros receptores (intermediarios). 3.2.1.4 Endpoints en Funcionamiento Pensando el SOAP en trminos de endpoints, ayuda a comprender la flexibilidad de los mensajes SOAP. Todos los enpoints deben de manejar mensajes en cierta manera, no importa que ruta toma un mensaje o como muchos endpoints puede procesarlos. Hay 3 pasos que un endpoint debe tomar para conformar la especificacin: 1) Examina el mensaje, para ver si contiene cualquier informacin direccionada hacia el. 2) Determinar cuales de las partes direccionadas hacia este endpoint son obligatorias. Si el endpoint puede manejarla o rechazarla. 3) Si este endpoint es un intermediario, entonces elimina todas las partes identificadas en el primer paso antes de enviar el mensaje al siguiente endpoint. 3.2.1.5 Diseo Modular SOAP es abierto y extensible. Esto significa que todos los siguientes escenarios son aceptados y permitidos por la especificacin de SOAP : Un aplicacin desktop compone un mensaje SOAP que requiere una cantidad de stock y lo enva como el body de un HTTP POST. Un WS recibe el POST, procesa el mensaje y retorna un mensaje SOAP en el HTTP response. Un proceso en el server compone un mensaje SOAP, que describe un evento del sistema y lo difunde a otro servidor en la red. Un desarrollador de software, que enva un mensaje como un e-mail attachment (parecido a ser un mensaje en one-way)
17
SOAP soporta tan diferentes escenarios gracias a un diseo modular. Las especificaciones, de principio a fin, son dejadas abiertas para futuras extensiones del protocolo. SOAP es extensible en las siguientes reas: Message Syntax el formato tiene un rea aparte para extensiones que sean adicionadas Data SOAP puede contener cualquier tipo de datos. Provee un mtodo para serializacin de datos, pero las aplicaciones pueden definir sus propias reglas. Transport No define como son transportados los mensajes durante el intercambio. SOAP muestra como podran ser intercambiados sobre HTTP, pero cualquier protocolo o mtodo puede sustituir a HTTP. Purpose SOAP no define que es lo que hay dentro del mensaje. Hay una diferencia entre los datos y su propsito o finalidad. 3.2.2 SOAP y HTTP
SOAP especifica el binding sobre HTTP, bsicamente un tunneling, segn el modelo requestresponse. El HTTP tunneling se refiere a un wrapper del protocolo de comunicacin HTTP. La habilidad de crear protocolos que se colocan en el tope del protocolo estndar HTTP se hace mas importante que nunca. La mayora de las redes comerciales optimizan el trafico del protocolo HTTP, permitiendo cualquier protocolo con base en HTTP. Esto a su vez potencia la seguridad de las redes a travs de los firewall, los cuales permiten HTTP tunneling. De otra manera se introduciran potenciales riesgos al tener que habilitar otros puertos en los firewalls. - el Content-Type del header de HTTP debe especificar application/soap - HTTP POST es solamente para el tipo request - SOAPAction en el HTTP header es requerida para indicar el intento de request - un request SOAP exitoso es indicado por un response con status HTTP y codigo 2nn siendo nn un nmero entre 00 y 99 - un error es respondido con el codigo de status 500 y el mensaje Internal Server Error, conteniendo el Fault element. 3.2.3 SOAP Message
Un mensaje SOAP consiste de un documento XML. El elemento raz es siempre el <Envelope>.
18
El elemento <Envelope> puede contener un elemento opcional <Header>, el cual debe ser el primer hijo inmediato. El elemento <Header> puede tener mltiples header entries. Anticipa el camino del mensaje SOAP como valor agregado a lo largo del proceso. El elemento <Body> le sigue al <Header> y es obligatorio. Es el contenido del mensaje, con lo necesario para consumir el servicio. Puede contener sus propios elementos hijos, llamado body entries. Cada uno de estos es independientemente codificado, y especificado en un atributo encodingStyle que indica su uso. SOAP define solo un tipo de body entries, llamado <Fault>, que ocurre solo una vez dentro del <Body> y se utiliza para indicar errores o excepciones. Todo esto se basa en un modelo de mensajes request/response como una forma de invocar un mtodo y pasarle parmetros. El potencial de esto es hacerlo sobre Internet usando HTTP para realizar la comunicacin entre aplicaciones. Para mas detalles acerca de como son los componentes Envelope, Body y Header ir al Apndice SOAP Message
3.3 Transporte
Hasta ahora se detall el contenido del paquete SOAP, a continuacin se describir como se enva un mensaje desde el emisor al receptor. Este mecanismo se llama transporte. 3.3.1 Separacin de mensaje y transporte
Una decisin acertada hecha por los autores de SOAP consiste en la separacin de la definicin del mensaje y de su transporte. Esta es una lista de posibles transportes para el mensaje SOAP, algunos mas probables que otros: HTTP, SMTP, MQSeries, Raw sockets, Files, Named Pipes, Carrier Pigeon. La mayora de los desarrolladores se enfocarn en HTTP como el protocolo estndar de transporte para los mensajes SOAP.
19
3.3.2
HTTP
HTTP es el transporte mas utilizado para SOAP porque es ampliamente aceptado y difundido. La combinacin de HTTP, el protocolo de transporte estndar para la Web, y SOAP, el candidato para el formato de mensaje estndar, constituye una poderosa herramienta. HTTP hace que sea el gran transporte para SOAP, que los autores aseguran que las reglas para su uso como transporte son parte de las especificaciones de SOAP. Hay un par de reglas bsicas para el uso de HTTP como transporte de SOAP. Los mecanismos para enviar un mensaje SOAP sobre HTTP es el estndar HTTP POST mtodo. Un HTTP POST enva un bloque de datos a una URI particular en un servidor Web. En este caso el mensaje SOAP, este bloque de datos es el propio mensaje SOAP. Porque el mensaje SOAP es XML, el cabezal Content-Type del HTTP POST debe ser application/soap. Si hay una respuesta al mensaje, este retorna una respuesta HTTP .Ej. :
20
Informe de Proyecto de grado POST /timeserver HTTP/1.1 Content-Type: application/soap Content-Length: ### SOAPaction: urn:mysoaptime
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> <soap:Header> <h:from xmlns:h='http://www.mysoap.com/Header'>SoapGuy@mysoap.com</h:from> </soap:Header> <soap:Body> <w:GetLocalTime xmlns:w='http://www.mysoap.com/timeserver/'> <w:country>Uruguay</w:country> </w:GetLocalTime> </soap:Body> </soap:Envelope>
Las primeras 4 lneas de este ejemplo estn relacionas al HTTP transport. La primer lnea contiene el mtodo HTTP, y la URI indica el lugar del endpoint. Este ejemplo representa un mensaje SOAP request enviado a la URL http://www.mysoap.com/timeserver. La primer lnea tambin indica la versin 1.1 de HTTP usada en este request. Las siguientes 3 lneas son el cabezal HTTP. Las 2 primeras son estndares de HTTP. Content-Type indica el tipo MIME del contenido del POST. Todos los mensajes SOAP deben usar application/soap. Content-Length dice el tamao en bytes del contenido. El ltimo cabezal, SOAPAction, es especfico de SOAP. El mensaje por si slo no cambia porque esta siendo transportado por HTTP, SOAPAction header no cambia porque est enviando un mensaje SOAP. 3.3.3 SOAPAction Header
La especificacin SOAP define un cabezal adicional a ser usado cuando el mensaje SOAP es transportado sobre HTTP, y este cabezal es el SOAPAction Header. Esto es un indicio al servidor que un particular HTTP POST contiene un mensaje SOAP, y el valor del cabezal es la URI que indica las intenciones del mensaje SOAP. Esto le permite al firewall y otros servidores realizar procesos condicionales basados en la presencia del SOAPAction Header. La necesidad de SOAPAction depende de cmo nuestro endpoint est implementado. 3.3.4 Status Code
HTTP retorna un cdigo de status. Estos son enteros, y estn seccionados dentro de clases de 100 elementos. Por ejemplo, cualquiera en el rango 200-299 indica xito. SOAP coloca un requerimiento sobre el transporte de HTTP cuando este es usado para intercambiar mensajes. Si la respuesta contiene una falla, entonces el cdigo de status debe ser 500, que indica un Internal Server Error.
21
4 Casos de Aplicacin
4.1 Introduccin
A los efectos de probar esta tecnologa se presentarn 2 casos puntuales de aplicacin. Los casos a implementar son los siguientes: Transacciones: Se trata de implementar una tpica transaccin comercial con fuertes requerimientos de seguridad. Cursores: Se trata de recorrer en forma remota (sobre una LAN e Internet) una coleccin de datos mediante un cursor. Como ejemplos se pueden plantear un cursor de Base de Datos, las paginas de un reporte o los tems de un catalogo.
4.2 Presentacin del Problema

A continuacin se presentara de forma detallada los problemas existentes en los casos a resolver. 4.2.1 Transacciones
El objetivo es probar esta tecnologa en escenarios en donde los servicios tienen un alto grado de seguridad, tales como los encontrados en el contexto de transacciones comerciales (por ejemplo, servicios en donde se permite transferir dinero de una cuenta bancaria a otra, o realizar un pedido de compra). Para esto se deben contemplar las siguientes requisitos de Seguridad: 4.2.1.1 Confidencialidad de la transmisin La transaccin puede contener informacin confidencial, por lo que el contenido de la comunicacin no puede ser entendible por una tercera persona que la pudiera interceptar. 4.2.1.2 Asegurar la integridad Es necesario asegurar que la informacin transmitida no pueda ser modificada, ya sea por el servidor (para brindar garantas al cliente), por el cliente (para brindar garantas al servidor), por un agente externo que intercept y modific la misma o por errores en la transmisin. 4.2.1.3 Autentificacin Involucra dos clases de requerimientos de seguridad : Una es la identidad del creador del mensaje, la cual es llamada autentificacin del mensaje. La otra es la autentificacin de la identidad de quin enva y de quin recibe el mensaje, la cual es llamada sender/recipient authentication. Desde la perspectiva del que enva en mensaje (sender), significa asegurar la identidad del que recibe el mensaje autenticado Desde la perspectiva del que recibe el mensaje (recipient), significa asegurar la identidad del que enva del mensaje y el contenido del mensaje autenticado. 22
4.2.1.4 Asegurar el no repudio Debe garantizarse que ninguno de los participantes en la comunicacin pueda negar parte en la misma. 4.2.1.5 Evitar copias de transacciones como vlidas (replay) Se debe poder distinguir entre una transaccin enviada por el cliente, y una copia de la misma transaccin, haya sido reenviada por error o por una tercera parte con fines fraudulentos. 4.2.1.6 Evitar el reenvo de transacciones (forward) Es necesario evitar que la transaccin sea reenviada a un destinatario que no sea el deseado. Con esto se desea evitar el caso en que un receptor trata fraudulentamente de reenviar una transaccin a otro receptor, y lo que sucede si esta tercera parte reclama que ha recibido la transaccin del emisor. 4.2.2 Publicacin de Cursores
Una de los requerimientos del proyecto consiste en recuperar colecciones de datos a travs de WS, como por ejemplo en el caso de recorrer un reporte o cargar un combo. A tal fin, puede considerarse esto como un caso particular del recorrido de un cursor, por ejemplo los cursores de un RDBMS. Los objetivos de este caso a implementar son los de recorrer un cursor de forma remota y cuidando los siguientes detalles: 4.2.2.1 Mantenimiento de Estados Para recorrer un cursor se debe mantener en el servidor la posicin en la que se encuentra el mismo. 4.2.2.2 Consideraciones de Performance En el caso de recorrer grandes cantidades de datos ser importante que la respuesta del sistema en cuanto a performance sea aceptable. 4.2.3 Perfil del producto
Este proyecto se desarrolla en el marco del producto EDF (Enterprise Development Framework), el cual consiste en un ambiente de interoperabilidad entre un conjunto de tcnicas y productos que permiten el desarrollo de una nueva generacin de aplicaciones realmente centradas en la red. Entre las tcnicas se encuentran: ambientes cliente-servidor de mltiples capas, workflow, push/publish/subscribe, CIM (Customer Interaction Management), formularios electrnicos, OLAP.
23
4.2.4
XForms
Dentro de la capa de presentacin, una forma habitual de interaccin con el usuario es a travs de formularios. ltimamente se han remitido propuestas a la W3C para estandarizar el modelo de formularios, haciendo hincapi en la separacin de la presentacin del formulario y su contenido. Actualmente, existe una propuesta de definicin en este sentido llamada XForms [10].
Ideasoft implementa esta propuesta en JForms, un motor de ejecucin de formularios. Uno de los objetivos de este proyecto consiste en proveer infraestructura para permitir la ejecucin de formularios mediante Web Services. Para el caso de transacciones, un formulario que contenga informacin de transferencia de dinero entre cuentas bancarias, puede considerarse como una transaccin electrnica. De igual manera, por ejemplo el llenado de valores de un combo en un formulario o el paginado de un reporte puede verse como la recorrida de un cursor.
24
4.2.5
Plataforma y herramientas
Ideasoft utiliza fuertemente la plataforma Java, junto con todas las herramientas relacionadas a ella. Asimismo, se le dio prioridad a la utilizacin de herramientas open source, tales como Tomcat, Apache SOAP, etc. La nica excepcin admitida fue la utilizacin de la XML Security Suite de IBM, un producto para firmas digitales de archivos XML. Hoy en da una alternativa open source es el ApacheXML-Security-J, la cual no fue utilizada porque al momento de comenzar la fase de implementacin no haba sido liberada. La primera versin corresponde a febrero de 2002, y actualmente se encuentra disponible la versin 1.0.3. Para mas detalles, ver Apndice Plataforma y Herramientas
25
5 Diseo
En esta seccin se presentaran distintas propuestas tecnolgicas, detallando los requerimientos que satisfacen.
5.1 Transacciones
5.1.1 Firma Digital
La firma digital (SOAP-DSIG) define la sintaxis y procedimientos para firmar digitalmente mensajes SOAP y validar su firma. La firma digital permite que los mensajes sean autenticados contra un usuario. Esta tecnologa ha sido implementada en productos comerciales por IBM, Microsoft y otros. Una transaccin del tipo comercial requiere del no repudio. SOAP-DSIG tiene este propsito. Especficamente SOAP-DSIG define un formato de datos para calcular y agregar la firma digital a un documento XML. Una firma digital se basa en una criptografa de clave pblica, y generalmente toma mucho ms tiempo computar una firma en lugar de un hash o un MAC (Message Authentication Code) de clave simtrica. El emisor y receptor no necesitan compartir una clave secreta, el servidor puede identificar al creador del mensaje, lo cual constituye una garanta de que la firma es del creador. La firma digital de un documento XML se representa por el elemento Signature, el cual tiene la siguiente estructura ("?" denota cero o una ocurrencia; "+" denota uno o mas ocurrencia y "*" denota cero o mas ocurrencias): <Signature> <SignedInfo> (CanonicalizationMethod) (SignatureMethod) (<Reference (URI=)? > (Transforms)? (DigestMethod) (DigestValue) </Reference>)+ </SignedInfo> (SignatureValue) (KeyInfo)? (Object)* </Signature> En un mensaje SOAP el elemento <Body> contiene los datos de la transaccin. Estos son firmados, a partir de su firma se genera el elemento <Signature>, el cual es incluido en el header de SOAP. La clave usada para firmar el mensaje es identificada por el elemento <KeyInfo> la cual garantiza la 26
identificacin del usuario que creo el mensaje. Finalmente el mensaje SOAP firmado es enviado al servidor. Para mas detalles, ver Apendice - XML Signature La firma digital permite solucionar el problema del posible repudio de una transaccin, y asegura la integridad de los datos transmitidos. Para satisfacer los requerimientos de no repudio es necesario tener simultneamente la autentificacin del mensaje mediante el uso de firma digital y cumplir con los requerimientos de autentificacin del emisor. Esto ltimo se consigue mediante SSL. 5.1.2 SSL
SSL es un protocolo ampliamente usado para transmitir documentos HTML desde un sitio seguro, y asegura al usuario una comunicacin encriptada con el sitio. Es normalmente utilizado en aplicaciones B2C (business-to-costumer). La negociacin del SSL se puede resumir a grandes rasgos en estos pasos: Tanto el cliente como el servidor intercambian los certificados X.509 para probar su identidad. Los certificados son verificados comprobando la validez de las fechas y la firma digital de una Autoridad de Certificados (organizacin que emite certificados) conocida. El cliente genera aleatoriamente un conjunto de claves que sern usados para la encriptacin. Las claves son encriptadas usando la clave pblica del servidor y son enviadas al servidor de forma segura. Se usan claves diferentes en la comunicacin cliente - servidor que en la del servidor al cliente, con un total de cuatro claves. Se acuerda un algoritmo de encriptacin (para mantener la privacidad de la comunicacin). Para mas detalles, ver [11] SSL asegura la confidencialidad de la comunicacin y la autentificacin del servidor frente a los clientes y (opcionalmente) de los clientes frente al servidor. Por otra parte cabe destacar que fue desechada la alternativa de utilizar XML encriptado [12], pues al momento de escoger una solucin, la especificacin se encontraba en estado de Working Draft, por lo que se opto por una tecnologa madura y estndar. 5.1.3 Manejo de tickets
Para asegurar que todos los mensajes vlidos sean distintos, se introduce el concepto de ticket. Un ticket consta bsicamente de un nmero de secuencia, el cual sirve para numerar los mensajes, un timestamp, que indica el momento en que es enviado el mensaje, y un identificador del destinatario (Identity Recipient). El nmero de secuencia y el identificador del destinatario son gestionados por el servidor y luego manejados por el cliente, mientras que el timestamp es directamente agregado por el cliente. Estos datos son mantenidos para cada sesin. Al manejar tickets se evita el replay de mensajes, ya que cada mensaje tendr numeros de secuencia y timestamps distintos, y el forward de mensajes, ya que cada ticket identifica al destinatario en el que se puede ejecutar el formulario
5.2 Cursores
Para el caso puntual de recorrer cursores en forma remota, se presentan distintas alternativas y los requerimientos que satisfacen.
27
5.2.1
Manejo de sesiones por parte del servidor
Los WS son stateless por definicin, por lo que el mantener el estado a travs de los distintos request es un problema no cubierto por la especificacin. Para resolver este caso, se enuncian al menos dos posibles opciones: Provista por la infraestructura de Web Service: Usar implementaciones propietarias que resuelvan el problema, brindando WS stateful de forma transparente, tales como las provistas por Apache SOAP 2.2 o .NET Construir aplicaciones cliente/servidor de forma que intercambien un identificador de sesin o similar entre los distintos request, y manejar en las aplicaciones la administracin correspondiente a las sesiones.
Implementada dentro de la Aplicacin: -
En este caso se opt por la primera opcin por varias razones: Esta funcionalidad al ser brindada por la infraestructura evita la necesidad de programar una lgica de manejo de sesiones, lo cual no se encuentra dentro de los objetivos de este proyecto. Al permitir que la infraestructura realice el manejo de sesiones, el sistema se vuelve mas escalable y performante. Por ultimo se apuesta a que esta caracterstica sea parte del estndar en futuras versiones, pues el manejo de sesiones es algo altamente utilizado y bsico en aplicaciones no triviales. Benchmarks
5.2.2
Una duda implcita en cualquier aplicacin que utilice Web Service radica en como ser su desempeo al momento de su puesta en marcha. En este caso por tratarse de recorrer grandes cantidades de datos este punto es crucial. Por esto se decidi realizar un estudio comparativo de esta tecnologa frente a otras alternativas propietarias (aunque posiblemente mas performantes) como ser Java RMI. El objetivo de este benchmark es confrontar Web Services contra RMI en el caso puntual de tener que recorrer una coleccin de datos en forma remota. Se eligi RMI por ser una alternativa conocida y se puede utilizar exactamente el mismo cdigo del cursor. Se espera que sea mas performante pues no involucra parseo de XML y el overhead de empaquetado y transporte de datos es menor. En particular se desea comparar : El recorrer los datos solicitndolos de a uno por vez. El recorrer los datos solicitndolos de a rfagas (cache en el cliente). El desempeo en funcin del tamao de las tuplas a transferir. La performance en una LAN y en Internet
28
6 Prototipo
A continuacin se presenta la implementacin realizada en base al diseo descrito en el punto anterior. Primero se describir la plataforma y el entorno en el que se realiz el sistema. Luego se detallarn las clases implementadas para el caso de las transacciones, y por ltimo se presentarn las clases implementadas para el manejo de cursores.
6.1 Estudio de Plataforma

Todas las clases fueron implementadas en el lenguaje Java, versin 1.3 [13]. Como servidor y contenedor de servlets se utiliz el Jakarta Tomcat versin 3.2.1 [14]. La implementacin de SOAP utilizada fue el Apache SOAP 2.2 [15]. Para el manejo de las firmas digitales de XML se utiliz el IBM XML Security Suite [16]. Como parser de archivos XML se utiliz el Xerces v. 1.2.3. [17] y como procesador de XSLT se utiliz el Xalan 2.1.0 [18]. Tambin es necesario para el correcto funcionamiento de este producto la instalacin del JavaMail 1.2 [19] y el JavaBeans Activation Framework 1.0.1 [20]. Para la instalacin de estos componentes es necesario un orden predefinido en el classpath, configurar archivos de Tomcat y del SOAP de apache. Tambin se deben generar certificados con el keytool para que luego puedan ser tomados por el XMLSS y por el Tomcat para el SSL. Por mas detalles de instalacin y configuracin Apendice Instalacin y Configuracin
6.2 Modelo de trabajo de Apache SOAP sobre Tomcat

Apache SOAP provee un manejo bsico de visualizacin, deploy y ejecucin de Web Services sobre Tomcat. El acceso al SOAP en Tomcat es a travs de , en esto punto se presentan tres acciones posibles a realizar, las cuales son: List: Lista los WebServices disponibles.
29
Deploy: Agregar un Web Service a la lista.
Un-Deploy: Borrar un Web Services de la lista de disponibles.
Para mas detalles, ver Apndice Administracion de Web Services con Apache SOAP 30
El modelo de trabajo del Soap sobre Tomcat es el siguiente:
Aplicacin Cliente
Apache SOAP
Parser de XML
SOAP
Registro remoto de Servicios Apache SOAP Listener ( RPCRouterServlet) Apache SOAP
Web Application Server
Parser de XML
Aplicacin Servidor
Este diagrama define el funcionamiento bsico de una invocacin a un Web Service utilizando Apache SOAP, el cual es el siguiente: La Aplicacin cliente a travs del Apache SOAP Library crea y enva un request SOAP al servidor (). En el servidor Web es recibido este request por parte de un servlet (rpcrouter mapeado a la clase RPCRouterServlet). Busca en la Remote Services Registry la clase asociada al mtodo, la instancia y por ultimo ejecuta el mtodo solicitado por el cliente.
Algunas extensiones al framework de Apache SOAP necesitan la capacidad de interactuar con el 31
mensaje SOAP al momento de recibirlo o enviarlo. Para facilitar este tipo de interacciones Apache SOAP provee la interface EnvelopeEditor, la cual consta de los mtodos: public void editIncoming(Reader in, Writer out) throws SOAPException; public void editOutgoing(Reader in, Writer out) throws SOAPException;
Estos mtodos sern invocados despus de enviar un mensaje y antes de recibirlo:
Aplicacin Cliente
Apache SOAP
Parser de XML
EnvelopeEditors
Registro remoto de Servicios Apache SOAP Listener ( RPCRouterServlet) Apache SOAP
Web Application Server
Parser de XML
Aplicacin Servidor
6.3 Mecanismo de mantenimiento de sesiones (Web Services stateful)

El mantenimiento de las sesiones se consigue haciendo que el servicio que se est comunicando va HTTP setee cookies apropiadas para mantener la sesin. Estas son copiadas y almacenadas en el objeto org.apache.soap.rpc.RPCMessage.Call usado para invocar el servicio. Si otra llamada es realizando usando el mismo objeto Call, esa cookie es devuelta al servidor, manteniendo la sesin. Para esto, es necesario configurar el cliente de la siguiente manera: 32
Call call = new Call (); SOAPHTTPConnection shc = new SOAPHTTPConnection (); shc.setMaintainSession (false); call.setSOAPTransport (shc);
Cabe destacar que el objeto SOAPHTTPConnection debe ser el mismo a lo largo de toda la sesin. Si se realiza un nuevo shc = new SOAPHTTPConnection (), ste establecer una nueva conexin con el servidor y la informacin de la sesin se perder. 6.3.0.1 Deploy del Web Services para el mantenimiento de sesiones Para que el Web Service mantenga la sesin, debe ser realizado su deploy con la opcin Scope en Session, en lugar de Request
Por mas informacin sobre el deploy de un Web Service, ver HIPERVNCULO "Apendice XXXX.doc" Apndice Administracion de Web Services con Apache SOAP
6.4
6.4.1
Transacciones
Soporte de comunicacin sobre SSL
Para asegurar la confidencialidad de la informacin, se habilita la comunicacin cliente/servidor mediante SSL [11]. A continuacin, se mencionan los pasos seguidos para configurar la comunicacin por SSL entre el servidor y el cliente. 6.4.1.1 Configuracin del servidor Para usar HTTP con el conector SSL en Tomcat, se efecta el siguiente cambio en la configuracin, 33
en el archivo server.xml:
<Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/> <Parameter name="port" value="8443"/> <Parameter name="socketFactory" value="org.apache.tomcat.net.SSLSocketFactory"/> <Parameter name="keystore" value="/var/tomcat/conf/keystore" /> <Parameter name="keypass" value="changeit"/> <Parameter name="clientAuth" value="true"/> </Connector>
Aqu se indica que el keystore es el fichero /var/tomcat/conf/keystore. La password del keystore es changeit, se especifica que los clientes se deben autentificar y que el puerto utilizado para la comunicacin segura ser el 8443. Para que el Tomcat utilize sockets seguros, debe instalarse la Java Secure Socket Extension o JSSE 1.0.2 [21]. Los jars de jsse deben estar en el CLASSPATH y en $JAVA_HOME/jre/lib/ext (JAVA > 1.2). Parte de la configuracin consiste en editar el archivo $JAVA_HOME/jre/lib/security/java.security y aadir la linea security.provider.2=com.sun.net.ssl.internal.ssl.Provider Por defecto, Tomcat utilizar el certificado que tiene alias tomcat en el keystore. Para la creacin de un certificado con esas caractersticas se utiliza el siguiente comando: keytool -genkey -alias tomcat -keyalg RSA 6.4.1.2 Configuracin del cliente Para la configuracin del cliente ser necesario setearle al cliente 2 properties, las cuales son: javax.net.ssl.trustStore: Indica el camino y nombre del keystore que contiene los certificados confiables para el cliente. java.protocol.handler.pkgs: Indica la implementacin del URL handler para el protocolo HTTPS.
Ejemplo: System.setProperty("javax.net.ssl.trustStore"," keystore_path\keystore_name"); System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol"); Adicionalmente debe agregarse como proveedor de seguridad la clase que implementa el HTTPS, por ejemplo con la siguiente lnea: 34
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); Por ultimo y como sustitucin al intercambio de certificados del handshake de SSL, se debe ingresar el certificado del servidor en el keystore del cliente y el certificado del cliente en el keystore del servidor. 6.4.2 Soporte de firma Digital
El soporte para firma digital de archivos XML se brinda a travs de la API IBM XML Security Suite. Este producto fue elegido debido que al momento de comenzar el proyecto, fue el que present menos problemas al realizarle test bsicos. Al da de hoy se ha ampliado notoriamente la cantidad de opciones posibles. Por mas informacin acerca de las implementaciones disponibles ver [22]. El firmado de los paquetes SOAP en el cliente y la verificacin de la firma digital en el servidor se realiza mediante los llamados EnvelopeEditors, mencionados en el punto 6.1.2. Las clases implementadas pueden verse en el siguiente diagrama (en fondo claro se encuentran las clases implementadas por terceros, y en fondo oscuro las clases implementadas para este proyecto):
35
EnvelopeEditor
(from transport)
editIncoming() editOutgoing()
EnvelopeEditorAdapter
(from transport)
ClientEnvelopeEditor (from client) ClientEnvelopeEditor() editIncoming()
ServerEnvelopeEditor (from server) ServerEnvelopeEditor() editIncoming() editOutgoing()
Verifier
(from util) $ VERIFY_NOTHING : int = 0 $ VERIFY_SIGNATURE : int = 1 $ VERIFY_ALL : int = 2 Verifier() transformMessage() getSignatureElement() hasSignatureElement() verify() getDigestValue() getSignatureValue()
-ivSignature
Signature
(from util) ClientSignedEnvelopeEditor (from client) ClientSignedEnvelopeEditor() editOutgoing() Signature() getInstance() sign() getSignatureElement() verify() getAlias() -ivSignature
La clase EnvelopeEditorAdapter es una clase utilitaria que implementa la interface EnvelopeEditor, siguiendo el patrn Adapter [23], para brindar una implementacin bsica de los mtodos editIncoming y editOutgoing . Cabe mencionar que la implementacin por defecto (dejando el cuerpo del mtodo en blanco) causara un mal funcionamiento de la aplicacin, bloqueando el flujo de informacin. La clase ClientEnvelopeEditor se encarga de enviar un mensaje SOAP sin modificarlo, y de recibir un mensaje SOAP firmado digitalmente por el servidor, y enviarlo al cliente si la firma digital es correcta, o en caso contrario levantar una excepcin. La clase ClientSignedEnvelopeEditor se encarga de firmar digitalmente el mensaje SOAP que recibe y enviarlo posteriormente. Para el caso de recibir la respuesta del servidor, se comporta de igual forma que ClientEnvelopeEditor, ya que hereda el mtodo editIncoming. Del lado del servidor, la clase ServerEnvelopeEditor se encarga de verificar si la firma digital del mensaje SOAP recibido es correcta, si ste contiene alguna. En caso afirmativo, ejecuta el mtodo, agregando como parmetros los datos necesarios para almacenar y verificar a posteriori la firma digital. 36
Estos datos pueden ser almacenados en una base de datos o similar, para evitar un posible repudio del cliente. De lo contrario, si el mensaje no contiene firma digital y el mtodo la requiere, se retorna una excepcin. Si no la requiere, se ejecuta el mtodo. Esta clase tambin se encarga de firmar digitalmente las respuestas provenientes de la ejecucin de los mtodos, para dar garantas al cliente acerca del resultado de las transacciones. Se implementaron dos clases utilitarias para trabajar con las firmas digitales: una llamada Verifier, que es utilizada por las clases ClientEnvelopeEditor y ServerEnvelopeEditor para verificar la firma digital, y una llamada Signature que es utilizada por ClientSignedEnvelopeEditor y ServerEnvelopeEditor para firmar digitalmente los mensajes SOAP. Para obtener los certificados digitales necesarios al momento de firmar y verificar las firmas, se implement una clase utilitaria llamada KeyStoreUtil, que se encarga de proporcionar una instancia de un certificado, a partir de un identificador. La implementacin actual los obtiene a partir de un keystore, o archivo en formato JKS (Java Key Store), pero es fcilmente modificable. De esta forma queda abierto el sistema para que en un futuro puedan ser tomados de otras fuentes, como ser un servidor LDAP o una base de datos.
KeyStoreUtil
(from util)
getCertificate() getKey()
KeyStoreUtilImp (from util) KeyStoreUtilImp() getCertificate() getKey()
Verifier
(from util) $ VERIFY_NOTHING : int = 0 $ VERIFY_SIGNATURE : int = 1 $ VERIFY_ALL : int = 2 Verifier() transformMessage() getSignatureElement() hasSignatureElement() verify() getDigestValue() getSignatureValue()
Signature
(from util) Signature() getInstance() sign() getSignatureElement() verify() getAlias()
Para demostrar que es posible realizar la comprobacin a posteriori de la firma digital, se implement una aplicacin que realiza la verificacin:
37
La relacin entre las clases puede verse en el siguiente diagrama:
38
JFrame
(from swing)
$ EXIT_ON_CLOSE : int = 3 defaultCloseOperation : int rootPaneCheckingEnabled : boolean
VerificadorFrame
(from client)
VerificadorFrame() main() jbInit() actionPerformed() verifyExecute() class$()
Verifier
(from util)
$ VERIFY_NOTHING : int = 0 $ VERIFY_SIGNATURE : int = 1 $ VERIFY_ALL : int = 2 Verifier() transformMessage() getSignatureElement() hasSignatureElement() verify() getDigestValue() getSignatureValue()
Aqu se muestra una implementacin en donde la aplicacin GUI que interacta con el usuario instancia localmente la clase que realiza la verificacin. A su vez, se public como Web Service un mtodo que permite realizar la verificacin en forma remota, implementado en la clase VerifierWS:
39
VerifierWS
(from server)
VerifierWS() verifyExecute()
Verifier
(from util)
$ VERIFY_NOTHING : int = 0 $ VERIFY_SIGNATURE : int = 1 $ VERIFY_ALL : int = 2 Verifier() transformMessage() getSignatureElement() hasSignatureElement() verify() getDigestValue() getSignatureValue()
Para facilitar la ejecucin de los Web Services a travs de clientes Java, se implement una clase que encapsula la mayor parte de la complejidad inherente a la configuracin de la llamada a Web Services. Estas llamadas manejan y resuelven los siguientes problemas: Configurar los mapType. Estos son los mapeos entre los objetos Java y su correspondiente representacin en XML. De esta manera es transparente para el usuario final la serializacin de objetos java a XML y viceversa. setTargetObjectURI: Identificador del Web Service a utilizar. setMethodName: Identificador del mtodo a ejecutar. setEncodingStyleURI: Identifica el Encoding org.apache.soap.Constants.NS_URI_SOAP_ENC). a utilizar (por defecto es
Preparar y setear el vector correspondiente a los parmetros de cada mtodo a ejecutar. Setear el nmero de secuencia correspondiente a cada ejecucin.
Esta clase se llama XFormsProxy, e implementa el patrn Proxy, descrito en [23]. Los clientes la instancian, e invocan a los Web Services a travs de sus mtodos:
40
JFrame
(from swing)
$ EXIT_ON_CLOSE : int = 3 defaultCloseOperation : int rootPaneCheckingEnabled : boolean
TestFrame
(from client)
XFormsProxy
(from client)
$ NORMAL_MODE : int = 0 $ NRO_SEQU_MODE : int = 1 $ DATE_MODE : int = 2 $ APP_NAME_MODE : int = 3 TestFrame() main() jbInit() loginButton_actionPerformed() getStackTraceAsString() ejecutarButton_actionPerformed() setGUIData()
call : EServiceCall XFormsProxy() getTicket() login() execute() prepareExecute() prepareLogin() sendExecute() sendLoginMessage() class$()
-xFormsProxy
6.4.3
Secuencia de Ejecucin de Transacciones.
A continuacin se detalla el ciclo de la ejecucin de una transaccin, y las clases involucradas.
41
En este diagrama se muestra el ciclo de vida de una transaccin. Bsicamente, consta de un inicio de sesin (mediante el mtodo login) y la ejecucin de la transaccin (mediante el mtodo execute). En la ejecucin de la transaccin participan los EnvelopeEditors (descritos en la seccin 6.1.2) para la firma y la verificacin, tal como se menciona en el punto 6.1.5. La clase WebServiceTransactionImp, que implementa la interfaces WebServiceTransaction encapsula la lgica de la ejecucin de la transaccin, y brinda la implementacin para los mtodos publicados como Web Services, siguiendo la idea del patrn Facade [23].
42
WebService Transaction
(from server)
execute() execute() login()
WebServiceTransactionImp
(from server)
WebServiceTransactionImp() login() execute() execute()
ControlUser
(from server)
checkUser()
ControlUserImp
(from server)
ControlUserImp() checkUser()
43
El detalle del deploy como Web Service puede verse en la siguiente figura:
Los campos destacables de la herramienta de deploy son los siguientes: ID: Un URN que identifica unvocamente al Web Service para los clientes. Comunmente se utiliza el formato urn:UniqueServiceID
44
Scope: Define el tiempo de vida del objeto que responde al request. Existen principalmente tres valores posibles: Request: Por cada request, se crea una instancia del objeto, se utiliza y se desecha Session: La instancia del objeto es nica durante toda la sesin Application: Slo una instancia del objeto es creada durante todo el tiempo de vida del SOAP servlet Methods: Define los nombres de los mtodos que pueden ser invocados en este objeto Provider Class: Indica la clase que brinda la implementacin del Web Service. Esta clase debe estar accesible (en el classpath) por el web container Type mappings: En esta seccin se describe la relacin de los objetos utilizados y las clases que los serializan. Para una mejor descripcin de todos los campos relacionados con el deploy, ver [24]. El resultado de la transaccin es representado por el objeto TransactionResult, dicho objeto maneja los siguientes datos: transactionOk: Status de la ejecucin del Web Service. Message: Mensaje asociado a la respuesta. errors: Vector de errores asociado a la ejecucin de la transaccin y no a aspectos concernientes a la ejecucin del Web Service.
XFormResult
(from domain)
XFormResult() getSoapMessage() setSoapMessage() getTransactionResult() setTransactionResult()
-transactionResult
TransactionResult
(from domain)
TransactionError
(from domain)
transactionOk : boolean TransactionResult() isTransactionOk() getTransactionOk() setTransactionOk() getMessage() setMessage() setErrors() getErrors()
global : boolean TransactionError() getMessage() setMessage() isGlobal() setGlobal() getFieldName() setFieldName()
45
6.4.4
Tratamiento de Errores
Bsicamente se distinguen dos clases de errores, estos son errores de ejecucin (descriptos anteriormente) y errores de seguridad. A continuacin se detallaran los diferentes tipos de errores de seguridad: Error en el login: Usuario o password no vlidos Nmero de secuencia incorrecto: El nmero enviado por el cliente no es el esperado Timestamp no vlido: La hora indicada por la transaccin est fuera de rango Firma digital no vlida: La firma digital del paquete SOAP no verifica. Recipient no vlido: Se intent ejecutar la transaccin en un recipient distinto al indicado.
Ante cualquiera de stos errores se lanza una SOAPException, con el cdigo y el mensaje correspondientes. 6.4.5 Objetos de Intercambio (ValueObjects)
Para realizar el intercambio de informacin entre los distintos componentes del sistema, se sigui el patrn ValueObjects, implementando varios JavaBeans, actuando como contenedores de datos:
Ticket
(from domain)
Participant
(from domain)
getSequenceNumber() setSequenceNumber() getIdentityRecipient() setIdentityRecipient() setDate() getDate()
getUser() getPasswd() getDN() setUser() setPasswd() setDN()
TicketImp
(from domain)
ParticipantImp
(from domain)
sequenceNumber : int getIdentityRecipient() setIdentityRecipient() setDate() getDate() TicketImp() getSequenceNumber() setSequenceNumber()
ParticipantImp() getUser() setUser() getPasswd() setPasswd() getDN() setDN()
46
6.5
Cursores
En esta seccin se comentarn los detalles de implementacin del caso de aplicacin referido a los cursores. En particular, se comentarn por un lado las clases construidas para demostrar la viabilidad de esta tecnologa aplicada a esta caso puntual, y por otro las construidas para comparar los Web Services contra RMI. (benchmarks). Los resultados de esta comparacin se presentan en el captulo 7. 6.5.1 Cursor Abstracto La idea de un cursor abstracto es bsicamente la accin de recorrer una lista de objetos, estos objetos son genricos y la implementacin es totalmente independiente al tipo de datos de los mismos. A continuacin se presenta la API Cursor, proporcionada por la empresa Ideasoft.
47
interface CursorContainer
interface CursorSpec +getFamily():String +getType():String +getParameter():Object +getSearchSpec():Object
interface CursorMetadata +getColumnCount():int +isSearchable(par1:int):boolean +getColumnDisplaySize(par1:int):int +getColumnLabel(par1:int):String +getColumnName(par1:int):String +getPrecision(par1:int):int +getScale(par1:int):int +getColumnType(par1:int):int
interface Cursor +getId():String +moreThan(x:int):boolean +search(searchSpec:Object):void +next():boolean +previous():boolean +first():boolean +last():boolean +beforeFirst():void +afterLast():void +absolute(i:int):boolean +relative(i:int):boolean +getRow():int +getObjectAccess():ObjectAccess +getRecordAccess():RecordAccess +getDataAccess():DataAccess +close():void
interface CursorFactory +createCursor(cursorSpec:CursorSpec):Cursor
interface DataAccess +getRow():int +wasNull():boolean +getString(par1:int):String +getBoolean(par1:int):boolean +getByte(par1:int):byte +getShort(par1:int):short +getInt(par1:int):int +getLong(par1:int):long +getFloat(par1:int):float +getDouble(par1:int):double +getBigDecimal(par1:int,par2:int):BigDecimal +getBytes(par1:int):byte[] +getDate(par1:int):Date +getTime(par1:int):Time +getTimestamp(par1:int):Timestamp +getString(par1:String):String +getBoolean(par1:String):boolean +getByte(par1:String):byte +getShort(par1:String):short +getInt(par1:String):int +getLong(par1:String):long +getFloat(par1:String):float +getDouble(par1:String):double +getBigDecimal(par1:String,par2:int):BigDecimal +getBytes(par1:String):byte[] +getDate(par1:String):Date +getTimestamp(par1:String):Timestamp +getTime(par1:String):Time +getMetaData():ResultSetMetaData +getObject(par1:int):Object +getObject(par1:String):Object +findColumn(par1:String):int +getBigDecimal(par1:int):BigDecimal +getBigDecimal(par1:String):BigDecimal
interface ObjectAccess +getObject():Object +getRow():int
interface RecordAccess +getRecord():Record +getRow():int
interface Record +getFieldsCount():int +getFieldAsString(fieldName:String):String +getField(fieldName:String):Object
6.5.2
Implementacin Bsica de un Cursor
Se realiz una implementacin concreta de un cursor, diseado para acceder a una base de datos mediante JDBC. La clase DBCursorFactoryImp recibe un DBCursorSpecImp que contiene la consulta a la base de datos, y devuelve una instancia de la clase DBCursorImp que puede ser utilizada para recorrer el resultado de la consulta.
48
DBCursorImp
(from cursor)
DBCursorSpecImp
(from cursor)
DBCursorSpecImp() getFamily() setFamily() getType() setType() getParameter() setParameter() getSearchSpec() setSearchSpec() DBCursorSpecImp() DBCursorSpecImp()
DBCursorFactoryImp
(from cursor)
DBCursorFactoryImp() createCursor() setSessionContext()
DBCursorImp() DBCursorImp() getId() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close()
CursorFactor y
(from api)
CursorSpec
(from api)
Cursor
(from api)
6.5.3
Implementacin de un Cursor con Cach
Para realizar una implementacin mas inteligentes sobre un cursor, se penso en un cursor con cacheo. El mismo implementa la idea bsica de un cache, publicando la interface de un cursor, pidiendo de a rfagas los objetos a un cursor bsico y almacenando una copia de los ltimos. La arquitectura se ilustra en la siguiente figura:
CacheCursor
Rfagas
DBCursor
Peticiones simples
Base de Datos
Las clases implementadas se presentan en el siguiente diagrama:
49
Cursor
(from api)
CacheCursor
(from cursor)
CacheObjects
(from cursor)
firstCase : boolean relativePosition : int absolutePosition : int hasLast : boolean cacheSize : int loadSize : int getId() CacheCursor() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close()
DBCursorImp
(from cursor)
absolutePosition : int relativePosition : int hasLast : boolean CacheObjects() getAccsesorsObjects() setAccsesorsObjects() getAbsolutePosition() setAbsolutePosition() getRelativePosition() setRelativePosition() isHasLast() setHasLast()
* CommonAccess
(from cursor)
CommonAccess() getDataAccess() setDataAccess() getRecordAccess() setRecordAccess() getObjectAccess() setObjectAccess() remove()
#data
-dataAccess
DataAccess
-objectAccess
(from api)
-recordAccess ObjectAcces s RecordAcce ss

(from api) (from api)
El mecanismo de cacheo puede resumirse en el manejo de las siguientes variables: cacheSize: Esta variable establece la cantidad de elementos que almacena temporalmente el cursor. loadSize: Establece la cantidad de elementos que se cargan cuando se requiere un elemento que no se encuentra en memoria.
Junto con estas implementaciones tambin se construyeron clases utilitarias para poder representar en memoria los objetos del cursor, ya que un ResultSet no es una clase contenedora, sino un apuntador a la base de datos. Por lo tanto se encapsul la informacin en este conjunto de clases:
50
DataAccess
(from api)
ResultSetWrapper
(from util)
DBCursorImp
(from cursor)
setRows() ResultSetWrapper() ResultSetWrapper() close() getRow() getRows() wasNull() getString() getBoolean() getByte() getShort() getInt() getLong() getFloat() getDouble() getBigDecimal() getBytes() getDate() getTime() getTimestamp() getString() getBoolean() getByte() getShort() getInt() getLong() getFloat() getDouble() getBigDecimal() getBytes() getDate() getTimestamp() getTime() getMetaData() getObject() getObject() findColumn() getBigDecimal() getBigDecimal()
java.sql.ResultSet
6.5.4
Publicacin de un Cursor como Web Service
El fin principal de este caso de aplicacin es realizar la publicacin de un cursor mediante Web Services. Para esto, se implement la clase WebServicesCursor, que cumple con la interface Cursor y sirve como fachada de un CacheCursor. Tambin agrega mtodos para brindar rfagas de objetos y as proporcionar soporte para cach en el cliente. La arquitectura se muestra en la siguiente figura:
51
WebServiceCursor
Rfagas
CacheCursor
Rfagas
DBCursor
Peticiones simples
Base de Datos
Las clases mencionadas se ilustran en el siguiente diagrama:
Cursor
-cursor WebServiceCursor
(from server)
(from api)
CacheCursor
(from cursor)
WebServiceCursor() init() init() getId() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getObjectsAccess() getRecordsAccess() getDatasAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close()
firstCase : boolean relativePosition : int absolutePosition : int hasLast : boolean cacheSize : int loadSize : int getId() CacheCursor() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close()
52
Con el fin de poder serializar la clase ResultSetWrapper (que no es un JavaBean, y por lo tanto no se puede utilizar el org.apache.soap.encoding.soapenc.BeanSerializer), se implement una clase que realiza la serializacin a y desde XML, llamada ResultSetWrapperSerializer
Deserializer
(from xml)
Serializer
(from xml)
ResultSetWrapperSerializer (from util) ResultSetWrapperSerializer() marshall() unmarshall() getPropertyDescriptors() getWriteMethod() instantiateBean() class$()
java.sql.ResultSet
ResultSetWrapper (from util)
53
6.5.5
Implementacin de un Cliente
Para probar la utilidad de esta tecnologa, se implement un cliente grfico que recorre un cursor a travs de Web Services, mediante un mecanismo de cache del lado del cliente. El mismo sigue la idea de solicitar al servidor rfagas de elementos, y mantener una copia de los mismos en el cliente (rfaga). A continuacin se describe la arquitectura mediante un diagrama:
Cliente Grfico
Rfagas
WebServiceCursor
Rfagas
CacheCursor
Rfagas
DBCursor
Peticiones simples
Base de Datos
54
Las clases implementadas para esto se presentan en el siguiente diagrama:
CursorFrame
(from client)
position : int CursorFrame() main() jbInit() primeroButton_actionPerformed() previoButton_actionPerformed() siguienteButton_actionPerformed() ultimoButton_actionPerformed() crearCursorButton_actionPerformed()
WebServiceCursor invoke (Web Service)

(from server)
Grficamente, el resultado puede verse en el siguiente screenshot. En el mismo se agrega la nocin de Rfaga, la cual indica la cantidad de elementos a traer desde el servidor cada vez que se solicita un nuevo elemento. A travs del mismo se puede crear un cursor a partir de una consulta y recorrer su resultado grficamente.
6.5.6
RMI
Tambin fue implementado un cliente RMI y su correspondiente servidor. Los mismos tienen una lgica similar al cliente para Web Services y fueron construidos para realizar los Benchmarks correspondientes.
55
Remote
(from rmi)
RMICursor
(from rmi)
RMICursorImp
(from rmi)
Cursor
(from api)
-cursor
CacheCursor
(from cursor)
main() RMICursorImp() init() init() getId() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getObjectsAccess() getRecordsAccess() getDatasAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close()
RMICursorClient
(from rmi)
RMICursorClient() main()
6.5.7
Objetos de Intercambio (ValueObjects)
Para realizar el intercambio de informacin entre los distintos componentes del sistema, se sigui el patrn ValueObjects, implementando varios JavaBeans, actuando como contenedores de datos.
CacheObjects
(from cursor) absolutePosition : int relativePosition : int hasLast : boolean CacheObjects() getAccsesorsObjects() setAccsesorsObjects() getAbsolutePosition() setAbsolutePosition() getRelativePosition() setRelativePosition() isHasLast() setHasLast()
CommonAccess
(from cursor) CommonAccess() getDataAccess() setDataAccess() getRecordAccess() setRecordAccess() getObjectAccess() setObjectAccess() remove()
56
7 Benchmarks
Las pruebas de rendimiento o Benchmarks se definen como una serie de pruebas llevadas a cabo en el software en una gran variedad de circunstancias, como por ejemplo distintas redes o una variada granularidad en la informacin solicitada. Presentaremos dos diferentes benchmarks, uno para el caso de transacciones, variando los niveles de seguridad y otro sobre la performance de cursores frente a otra tecnologa. En cada caso primero se menciona el objetivo del estudio, luego se presenta el escenario en el que fueron realizadas las pruebas, se detallan los pormenores de la ejecucin y por ltimo se enumeran los resultados asociados a cada caso.
7.1 Transacciones
7.1.1 Objetivo Este Benchmark tiene como objetivo medir el desempeo del prototipo implementado para el caso de aplicacin de las transacciones descrito en el punto 6.4. Los aspectos a considerar estn referidos al costo que tienen en la performance los requisitos de seguridad, tales como la encriptacin del canal (SSL [11]) y el firmado digital de los paquetes SOAP, estudiados sobre distintas redes (LAN e Internet). 7.1.2 Cliente Hardware : Pentium II, 64 Mb. RAM, tarjeta de red 10 Mb, modem 56 Kb.
Escenario
Software : W98, JRE 1.3, Apache Soap 2.2
Servidor Hardware : Pentium IV, 256 Mb. RAM, tarjeta de red 10 Mb
Software : W2000, JRE 1.3. Tomcat 3.2.1, Apache Soap 2.2
LAN : cliente y servidor conectados a un Switch 100 Mb. Internet : las pruebas se realizaron con una conexin a 33.6 Kb. Nota : Las pruebas se realizaron en condiciones de trfico relativamente bajo y todos los servidores dedicados para estas pruebas.
7.1.3
Ejecucin y Presentacin de los resultados
Para la ejecucin se trabaj con un paquete de 88 Kb, sin tomar en cuenta el overhead del mensaje SOAP y el HTTP. Este tamao de paquete se considera un ejemplo vlido de una transaccin de 57
mediana complejidad. Las consultas se realizan en un formato de tiempo "no think" (sin pensar) donde los pedidos se realizan continuamente. Esto representa una situacin irreal, por lo que cada flujo de consultas representa la carga de trabajo de una gran cantidad de usuarios simultneos en el mundo real. En este punto se probaron los siguientes 8 casos. Se realizaron 5 consultas por caso, tomndose el promedio como valor representativo, por mas detalles ver Apendice - Resultados Benchmark.xls Transporte Tecnologa Tamao Dato Canal sin Encriptar Paquete sin Firmar Paquete Firmado Canal Encriptado Paquete sin Firmar Paquete Firmado Canal sin Encriptar Paquete sin Firmar Paquete Firmado Canal Encriptado Paquete sin Firmar Paquete Firmado Duracin (ms) 472 846 778 1.142 6.274 6.676 27.736 27.462
Como puede observarse, para el caso de LAN el costo de firmar el paquete incide en la duracin total de la transaccin en un factor de 1,6 veces (1,8 si no se encripta el canal y 1,46 en caso contrario), mientras que ese factor es de 1,03 (1,064 si no se encripta el canal y 1,009 en caso contrario), prcticamente despreciable. Desde otro punto de vista, puede verse que la encriptacin del canal incide en un factor de 1,45 para el caso de una LAN, y en un factor de 4,25 en el caso de Internet.
7.2 Cursores
7.2.1 Objetivo La idea que persigue este Benchmark es comparar Web Services contra una tecnologa propietaria y conocida como RMI, para brindar un punto de referencia a la hora de considerar su uso. El rendimiento de RMI ya ha sido estudiado (ver [25]) y se consider una alternativa razonable para este caso. A continuacin se presenta una tabla de [26] que ilustra el overhead de utilizar RMI:
Para realizar el estudio, se definieron cuatro dimensiones que representan las caractersticas mas 58
interesantes a comparar: Tecnologa: Java RMI contra Web Services. Red: Internet contra LAN. Tamao de los paquetes: Se evaluaron distintos tamaos de las respuestas. Tamao de la rfaga: Variar la cantidad de elementos que el servidor retorna por cada round trip. Escenario
7.2.2 Cliente
Hardware : Pentium II, 64 Mb. RAM, tarjeta de red 10 Mb, modem 56 Kb.
Software : W98, JRE 1.3, Apache Soap 2.2
Servidor Hardware : Pentium IV, 256 Mb. RAM, tarjeta de red 10 Mb
Software : W2000, JRE 1.3. Tomcat 3.2.1, Apache Soap 2.2
Conjunto de datos : Los cursores recorrieron una tabla de aproximadamente 8.000 tuplas contra una base de datos Oracle 8.1.6 sobre un servidor Intel con 2 procesadores, 2 Gb. RAM, Solaris 7.
LAN : cliente y servidor conectados a un Switch 100 Mb. Internet : las pruebas se realizaron con una conexin a 33.6 Kb. Nota : Las pruebas se realizaron en condiciones de trfico relativamente bajo y todos los servidores dedicados para estas pruebas. 7.2.3 Ejecucin
En este punto se prob los siguientes 12 casos : Para la ejecucin se trabaj con 3 tamaos distintos de registros : Pequeos : tuplas de aproximadamente 56 bytes.

Medianos : tuplas de aproximadamente 336 bytes. Grandes : tuplas de aproximadamente 616 bytes.
59
Las consultas se realizan en un formato de tiempo "no think" (sin pensar) donde los pedidos se realizan continuamente. Esto representa una situacin irreal, por lo que cada flujo de consultas representa la carga de trabajo de una gran cantidad de usuarios simultneos en el mundo real. Para el caso de presentacin de los datos se agruparan por tablas para rfagas de tamao 1 a 200 en intervalos de 20. Transporte Lan Tecnologa Web Services RMI Internet Web Services RMI Tamao Dato Pequeos Medianos Grandes Pequeos Medianos Grandes Pequeos Medianos Grandes Pequeos Medianos Grandes N Caso Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 Caso 7 Caso 8 Caso 9 Caso 10 Caso 11 Caso 12
7.2.4
Presentacin de los Resultados
Las tablas con los valores obtenidos de las pruebas realizadas se encuentran en el Apndice Resultados Benchmark.xls A continuacin se presentan algunas grficas, resaltando los aspectos ms significativos de las pruebas.
60
Tamao de rfaga/Tamao de mensaje, Tecnologa para el caso de una red local (LAN)
Tamao de rfaga/Tamao de mensaje, Tecnologa para el caso de Internet
61
Ya que el caso de tamao de paquete = 1 marca una gran diferencia, se presentan grficas de los mismos casos, en donde ha sido ocultado este valor.
Tamao de rfaga/Tamao de mensaje, Tecnologa para el caso de una red local (LAN)
Tamao de rfaga/Tamao de mensaje, Tecnologa para el caso de Internet.
62
8 Conclusiones
Las conclusiones de este proyecto se dividirn en cuatro secciones: conclusiones sobre la tecnologa y su estado actual, conclusiones sobre las alternativas posibles, conclusiones sobre el trabajo realizado para cumplir con los casos de aplicacin y conclusiones sobre el futuro de los Web Services. Por ltimo, se mencionarn posibles trabajos a desarrollar como continuaciones de este proyecto.
8.1 Sobre la tecnologa

Es evidente la fuerza que han tomado los Web Services en la industria. Prcticamente todas las grandes empresas de software estn incorporando a sus productos el concepto de interactuar a travs de Web Services. El uso de estndares y protocolos abiertos tales como HTTP, XML, SOAP, WSDL y UDDI permiten convertir las aplicaciones corporativas en Web Services y as conseguir un alto nivel de interoperabilidad entre ellas. Asimismo, el nmero de implementaciones, toolkits y frameworks de desarrollo disponibles est creciendo en forma acelerada, lo que permite suponer que el nmero de desarrolladores que se vuelque a trabajar con Web Services tambin crezca rpidamente. Un detalle a destacar, sin embargo, consiste en que ciertos aspectos de los Web Services que todava no han sido estandarizados, estn siendo resueltos por las implementaciones. Esto puede llevar a problemas de mantenimiento (ser necesario adaptar el cdigo existente al estndar, cuando ste aparezca) y a un bajo nivel de interoperabilidad entre sistemas basados en implementaciones de distinto origen. Si bien este problema es comn en las aplicaciones de hoy en da, estara en contra de una de las principales caracterstica de los Web Services, la cual consiste en permitir la interoperabilidad de sistemas heterogneos en forma transparente. Un claro ejemplo se brindar en el punto 8.2.2, al tratar el tema de los Web Services stateful.
8.2 Sobre la aplicacin a estos casos

Algo que se hizo evidente a poco de empezar este proyecto, y que puede generalizarse al estado actual de la tecnologa de Web Services, es la falta de madurez de las herramientas disponibles. La mayora tiene un nmero reducido de funcionalidades (por ejemplo, el IBM WSTK 3.1, que incluye un generador de archivos WSDL, slo permite generarlos a partir de un JavaBean que utilice tipos bsicos, lo que restringe fuertemente el tipo de clases que pueden ser publicadas en forma automtica como Web Services con esta herramienta) y la documentacin en muchas casos es escasa o nula (por ejemplo el Apache SOAP 2.1 o la IBM SOAPEnvelopeApi). Las demos y ejemplos que acompaan al software normalmente son bsicas, y no ilustran problemas complejos. 8.2.1 Transacciones
Una conclusin importante sobre este caso radica en que fue posible implementar en forma exitosa un soporte para transacciones electrnicas basado en Web Services. Mediante SSL se consigui alcanzar el nivel estndar de seguridad en cuanto a la confidencialidad de la transmisin. Incorporando la firma digital se obtuvieron garantas de integridad y no repudio tanto para el servidor como para el cliente. Por ltimo, a travs del manejo de tickets se evita la posibilidad de que mensajes duplicados sean procesados como mensajes vlidos. La implementacin de utilitarios que permiten verificar la 63
firma digital a posteriori cierra el circulo en cuanto a asegurar la intencionalidad de la transaccin. Cabe sealar un aspecto del estado del arte en este campo: Si bien la firma digital de XML es estndar, todava no lo es aplicada a SOAP; el estado de la especificacin de sta para SOAP es de NOTE [27] por lo que no puede asegurarse que la implementacin actual termine cumpliendo el estndar, si bien se apega al estado actual de la especificacin. Como era de esperar, altos niveles de seguridad afectan en forma negativa a la performance del sistema. Las conclusiones extrables a partir de los resultados expuestos en el punto 7.1.3 pueden dividirse en dos grupos fundamentales, sobre LAN y sobre Internet. Para el caso de la LAN, tomando como base la duracin de una transaccin de paquetes sin firmar y sin SSL, se observa un incremento de 1,8 para el caso de paquete firmado sin SSL, de 1,64 para paquetes sin firmar y con SSL y de 2,41 para paquetes firmados y sobre SSL. Por lo tanto una recomendacin que surge de esto consiste en evitar el firmado de paquetes no sensibles (por ejemplo, considerando la transaccin como un formulario, firmar slo el submit de la transaccin, y no los paquetes que puedan generarse para el llenado del formulario). Esto significa adems que cumplir con los requisitos mximos de seguridad ocasionan una cada significativa en la performance del sistema (casi dos veces y media mas lento). Sin embargo para algunas LAN es posible pensar en alternativas de seguridad a otros niveles, tales como la restriccin de acceso fsico a las lneas de transmisin, por lo cual puede llegar a ser innecesario el uso de SSL y de esta manera mejorar de 2,41 a 1,8 la perdida de performance del sistema. En el caso de Internet y tomando nuevamente el tiempo en procesar una transaccin basada en un paquete sin firmar y sin SSL, se observa un incremento de 1,06 para el caso de paquete firmado sin SSL, de 4,42 para paquetes sin firmar y con SSL y de 4,37 para paquetes firmados y sobre SSL. Tambin se observa que el firmado del paquete afecta en 1,01 para el caso de una transmisin sobre SSL. De esto puede concluirse que la diferencia entre el firmar o no firmar un paquete es mnima y no incidir en la performance del sistema. En este caso el costo de utilizar SSL afecta notoriamente la performance (casi cuatro veces y media mas lento) pero por tratarse de una conexin sobre Internet (un medio no seguro) es prcticamente imprescindible su utilizacin. Para el mantenimiento de los tickets, es necesario realizar programacin del lado del cliente, programacin que debe ser repetida para cada cliente o lenguaje que consuma el Web Service. Esto plantea una contradiccin con la filosofa de los Web Services, la cual propone su invocacin como un simple RPC. Los tickets sirven para que el servidor indique cual transaccin acepta (con el sequence number) y cuando se realiz (con el timestamp). Si se flexibilizan algunos requerimientos (que el cliente elija el timestamp, que pueda realizar una transaccin sin el consentimiento del servidor y que el recipient se indique como un parmetro ms) no es necesario el mantenimiento de tickets. Tanto el timestamp como el sequence number son vlidos para evitar los paquetes duplicados. 8.2.2 Cursores
Al igual que en el caso de las transacciones, fue posible implementar el mecanismo de recorrido de cursores mediante Web Services. El diseo escogido permite utilizar el cursor basado en Web Services como cualquier otro cursor, ya que tanto la clase que publica los mtodos del Web Services como la clase que maneja el cache del lado del cliente implementan la interface Cursor. Un aspecto problemtico del estado actual de la tecnologa consiste en que las implementaciones avanzan ms rpido que los estndares. Por ejemplo, se detect un tema delicado al tener que resolver el problema del mantenimiento de las sesiones, para utilizar Web Services stateful. Para esto se 64
estudiaron dos posibles soluciones, detalladas en el punto 5.2.1. La solucin adoptada (utilizar el mecanismo de mantenimiento de sesin provisto por la implementacin de SOAP) no forma parte de la especificacin actual, y de hecho otras implementaciones ([28],[29]) resuelven este problema tambin de forma propietaria. Esto puede traer problemas de mantenimiento e interoperabilidad. Otro tem a tener en cuenta es el relacionado con la optimizacin de la performance. Como puede apreciarse en el estudio de Benchmarks, para obtener una performance aceptable, fue necesario establecer un mecanismo de solicitud por rfagas e implementar lgica de cacheo del lado del cliente. Esto implica que si se desea acceder a ese servicio desde clientes implementados en lenguajes distintos, es necesario reprogramar la lgica de cacheo en cada lenguaje, o utilizar clientes propietarios. Estas alternativas se contraponen a algunas de las bases del modelo de los Web Services. Una observacin inmediata y esperable a partir de los Benchmarks consiste en que los Web Services presentan actualmente una performance muy baja con relacin a una alternativa propietaria como RMI. Considerando el caso en que no fue necesario modificar la interface Cursor (o sea, la informacin es transmitida en rfagas de tamao 1) el sistema se comport entre 118,4 y 84,74 veces mas lento para el caso LAN, y entre 4,4 y 4,2 veces mas lento para el caso Internet. De esto puede concluirse que la diferencia de rendimiento prcticamente descarta la alternativa basada en Web Services para el caso LAN, dejando como principal argumento favorable el apoyo en la interoperabilidad del sistema. Asimismo, una de las caractersticas a favor de los Web Services como ser la capacidad de actuar en forma transparente sobre los firewalls muchas veces no es esencial en ambientes controlados como una LAN. La alternativa propuesta (modificar la interface Cursor para que soporte pedidos en rfagas e implementar lgica de cacheo en el cliente) brinda una solucin intermedia, ya que si bien no alcanza a ser tan performante como RMI, mejora la prdida de performance en mas de un 90% (Web Services pasa de ser 99,09 veces mas lento a 8,6 veces) para rfagas de mas de 100 elementos. De esta forma, si bien se mantiene una mayor interoperabilidad, implica que se deba reprogramar la lgica de cacheo para cada cliente o lenguaje que consuma el Web Service, lo cual va contra el modelo. A continuacin se muestra la variacin de la relacin entre Web Services y RMI, a medida que se aumenta el tamao de la rfaga de datos:
En el caso Internet, si bien RMI contina siendo mas performante que los Web Services, las diferencias son menos dramticas. Se observa una prdida de performance de 4,23 veces si se utilizan rfagas de tamao 1, prdida que disminuye a menos de 1,8 veces si se consideran rfagas de mas de 100 elementos, lo que corresponde a una mejora de mas del 55%. Esto, unido a que en este contexto la presencia de firewalls es extremadamente frecuente, la alternativa de los Web Services es muy razonable, ya que presenta una solucin que apoya la interoperabilidad con un costo en la performance en muchos casos aceptable.
65
A modo de resumen, puede concluirse que para un sistema que tenga como escenarios de interaccin tanto Internet como LAN, con requisitos similares al caso de cursores, la interface con la capa de negocios no debera basarse exclusivamente en una de las dos tecnologas. Por un lado, los Web Services presentan serios problemas de performance en ambientes LAN, y por otro RMI es una alternativa cerrada, que requiere de configuraciones especiales en los firewalls para comunicarse a travs de Internet. La siguiente figura propone una arquitectura que ejemplifica estos conceptos.
te rn et
WEB SERVI CES

LA N
RMI
Capa de Negocios
La capa de negocios es publicada en la LAN a travs de RMI, y los Web Services pueden interactuar directamente con la capa de negocios o con la capa RMI. Desde Internet, slo es posible acceder a la capa de Web Services. Cabe destacar que los Web Services son utilizables tambin a travs de la LAN, aunque por lo ya expuesto, no se aconseja. Otra conclusin que surge del anlisis de los benchmarks corresponde a la relacin entre el tamao de los datos intercambiados y el tiempo empleado en transmitirlos. Puede verse que ante un aumento del tamao de los datos transmitidos (ya sea por un incremento en el tamao de la rfaga o por un incremento en el tamao de los paquetes) la velocidad de transmisin aumenta, tanto para el caso Web Services como para el caso RMI, lo cual era esperable. A continuacin se presentan las grficas de velocidades en funcin del tamao de la rfaga, para LAN e Internet.
In
66
Velocidad Web Ser vices (Internet)

8000,00 70000,00
Velocidad Web Services (LAN)
7000,00
60000,00
6000,00
50000,00
5000,00 Chicos 4000,00 Medianos Grandes 3000,00 20000,00 2000,00 10000,00 30000,00 40000,00 Chicos Medianos Grandes
1000,00
0,00 1 20 40 60 80 100 120 140 160 180 200
0,00 1 20 40 60 80 100 120 140 160 180 200
Ta ma o R f a g a
Ta ma o R f a g a
Velocidad RMI (Internet)

12000,00 700000,00
Velocidad RMI (LAN)
10000,00
600000,00
500000,00 8000,00 bytes/seg bytes/seg Chicos 6000,00 Medianos Grandes 4000,00 200000,00 400000,00 Chicos Medianos 300000,00 G randes
2000,00
100000,00
0,00 1 20 40 60 80 100 Tamao Rfag a 120 140 160 180 200
0,00 1 20 40 60 80 100 T ama o Rfaga 120 140 160 180 200
Analizando la variacin de la velocidad de una tecnologa contra la otra, como se presenta en las siguientes grficas, puede observarse que para el caso LAN, el utilizar rfagas disminuye la diferencia entre las velocidades, llevndolas a valores entre 16-14 y 8-7, para rfagas mayores a 140 valores. Para el caso Internet se da un fenmeno similar, en donde la diferencia de velocidades se reduce a valores entre 2 y 1,6. Esto demuestra que la solucin propuesta (no traer datos en forma unitaria, sino en rfagas) constituye una alternativa efectiva.
Relacin entre v elocidades (LAN)
Relacin entre v elocidades (Internet)
140,00
5,00
4,50 120,00 4,00
100,00
3,50
3,00 80,00 Chicos Medianos Gr andes 60,00 2,00 2,50 Chic os Medianos Gr andes
40,00
1,50
1,00 20,00 0,50
0,00 1 20 40 60 80 100
T a ma o R f a g a
0,00 120 140 160 180 200 1 20 40 60 80 100

T a ma o R f a g a
120
140
160
180
200
Por lo tanto, una buena estrategia a seguir consiste en no realizar pequeos pedidos de datos, o en caso de hacerlo, traerlos junto con datos asociados o que tengan una alta probabilidad de ser requeridos a continuacin. Por ejemplo, supngase el caso de una aplicacin GUI que maneja un combo para 67
permitirle al usuario seleccionar departamentos, y otro combo que le permite seleccionar localidades en funcin del departamento, y se desea que los combos sean cargados a partir de Web Services. Una posible estrategia radica en utilizar un Web Services para cargar el combo de departamentos, y luego, cada vez que se cambie de departamento, se invoque a un Web Services para cargar las localidades del nuevo departamento seleccionado. Esta estrategia plantea muchos pedidos de pequeo tamao, lo que posiblemente lleve a una baja performance. Una mejor solucin consiste en solicitar las localidades junto con los departamentos, para que de esta manera se genere un nico pedido de mayor tamao. Claramente, tampoco es recomendable llevar est prctica al extremo. Otra conclusin que se puede obtener de esto es que para aplicaciones en donde el rendimiento es crtico, los Web Services no son aplicables en su forma bsica. Se puede mejorar la performance de los Web Services con alternativas que se alejen del modelo, como el caso del cacheo antes mencionado, o no respetando estrictamente el protocolo SOAP. Por ejemplo, el encoding style de SOAP establece que cada propiedad de un objeto se mapee con un elemento XML, incluso si se trata de tipos simples, cuando se puede obtener una mayor performance al parsear si la propiedad se mapea como un atributo del tipo nombre=valor. Por ltimo, se plantean las siguientes recomendaciones en funcin de las posibles aplicaciones de esta tecnologa: para el caso de las transacciones, se demostr que es posible su utilizacin bajo todas las garantas requeridas, y ya que para muchos casos el tiempo de realizar la transaccin no es crtico (por ejemplo en el caso de ejecutar un formulario el usuario pasa la mayor parte del tiempo llenndolo, y normalmente es aceptable un tiempo de proceso relativamente prolongado) y por lo tanto la performance del round trip del Web Service no constituye un inconveniente insuperable. El mayor problema radica en que todava no estn completamente definidos algunos estndares sobre el tema. Sobre los cursores pueden diferenciarse dos casos: uno en donde los pedidos sean de gran tamao y en donde un tiempo de respuesta sea aceptable (por ejemplo en el caso del paginado de un reporte) y otro para cuando los pedidos son pequeos y es necesario una rpida respuesta (por ejemplo, en el caso de un protocolo de interaccin fina con el usuario). Para el primer caso, es viable una solucin basada en Web Services, mientras que en el otro es muy difcil que la performance sea aceptable.
8.3 Sobre la alternativa utilizada

El software base a utilizar (Tomcat, Apache SOAP, Xerces, etc.) surgi naturalmente a partir de los requerimientos de la empresa Ideasoft: software libre, open source y basado en el lenguaje Java. Durante la eleccin de la herramienta a utilizar para la generacin de firmas digitales en XML, se consultaron y evaluaron algunas de las implementaciones listadas en [22]. Como se menciona en la seccin 6.4.2, la utilizacin del IBM XML Security Suite [16] se bas en que fue la que present menos problemas de instalacin y configuracin, adems de cumplir el requerimiento de funcionar sobre la plataforma Java. De la utilizacin de estas herramientas se puede concluir que la implementacin de los objetivos es factible, aunque fue problemtica la configuracin e instalacin de los mismos, debido en muchos casos a conflictos entre versiones y a una documentacin pobre en tamao y calidad. Un detalle a mencionar es que debido a la falta de estndares en aspectos antes mencionados (por ejemplo en el caso stateful), es compleja su utilizacin sin los utilitarios provistos del lado del cliente, y prcticamente imposible acceder desde clientes basados en otra plataforma (por ejemplo .NET).
68
8.4 Sobre el futuro

Como se mencion, la presencia de los Web Services en la industria es cada vez mas fuerte. Posiblemente sean la alternativa para comunicar sistemas heterogneos mas utilizada en el corto y mediano plazo. La base en los estndares de la W3C fomentan la interoperabilidad sin problemas inherentes a implementaciones propietarias. En la medida que se estandarizen algunos de los aspectos problemticos antes mencionados, las implementaciones brinden una performance aceptable y las herramientas mejoren su calidad, los Web Services se convertirn en la base de la integracin de sistemas en el futuro.
8.5 Posibles extensiones al proyecto

Mostrar la interoperabilidad del sistema implementando un cliente en un lenguaje diferente a Java, como Delphi o algn lenguaje de la plataforma .NET

Evaluar otras implementaciones. En particular la XML Security J de Apache, una API alternativa open source para el firmado de archivos XML. No se utiliz para este proyecto debido a lo expuesto en el punto 4.2.5. Asimismo, se encuentra disponible (en versin beta) una nueva implementacin de SOAP por parte de Apache, llamada Axis, que promete un mejor desempeo que la implementacin de SOAP utilizada en este proyecto. Si bien se demostr la viabilidad de la infraestructura provista y el diseo realizado es independiente de la lgica a publicar, un punto interesante consiste en probar su integracin con EDF, y realizar pruebas completas de la ejecucin de formularios XForms. Un objetivo ms ambicioso que el propuesto para este proyecto consiste en la implementacin de un framework que permita la publicacin de lgica de negocios en forma transparente como Web Services seguros. Su finalidad consistira en que el usuario del framework provea su Web Services e indicando detalles de infraestructura (repositorio de certificados, base para el almacenamiento de firmas digitales, etc.) consiga su publicacin con los niveles de seguridad conseguidos en este proyecto.
69

Web Services

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services

Uploaded by

Copyright:

Available Formats

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

1.3 Organizacin del Informe

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

2.2 Evolucin de los Web Services.

Informe de Proyecto de grado

Estudio e implementacin de Web Services

2.3 Arquitectura de los WS

and Pattern Description ( Workflow, Orchestration)

RDF ( meta data)

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

La descripcin de un WS, es la descripcin de los mensajes que se pueden aceptar y generar, 11

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Web Service Requester Socio de negocios u otro sistema

Web Service Provider

Conceptos publish find bind en los Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

2.4 WSDL : Web Services Definition Language

2.5 UDDI : Universal Description, Discovery and Integration

2.6 Otras tecnologas relacionadas

Informe de Proyecto de grado

Estudio e implementacin de Web Services

2.7 Implementaciones y Herramientas.

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

3 SOAP : Simple Object Access Protocol

3.2 SOAP y Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Un mensaje SOAP consiste de un documento XML. El elemento raz es siempre el <Envelope>.

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services

4.2 Presentacin del Problema

Informe de Proyecto de grado

Estudio e implementacin de Web Services

Informe de Proyecto de grado

Estudio e implementacin de Web Services