Informe de Proyecto de grado

Estudio e implementación de Web Services

1INTRODUCCIÓN..................................................................................................................................................................4 1.1EL PROYECTO.......................................................................................................................................................................4 1.2OBJETIVO..............................................................................................................................................................................4 1.3ORGANIZACIÓN DEL INFORME ................................................................................................................................................4 2WEB SERVICES....................................................................................................................................................................6 2.1 INTRODUCCIÓN.....................................................................................................................................................................6 2.1.1RPC............................................................................................................................................................................6 2.1.2Comparando protocolos XML.................................................................................................................................6 2.2EVOLUCIÓN DE LOS WEB SERVICES........................................................................................................................................8 2.2.1Historia de la computación distribuida..................................................................................................................8 2.2.2Conectando Aplicaciones en la Web.......................................................................................................................8 2.3ARQUITECTURA DE LOS WS...................................................................................................................................................9 2.3.1Invocación ..............................................................................................................................................................10 2.3.2Descripción ............................................................................................................................................................11 2.3.3Discovery.................................................................................................................................................................12 2.4WSDL : WEB SERVICES DEFINITION LANGUAGE.................................................................................................................13 2.5UDDI : UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION.........................................................................................13 2.6OTRAS TECNOLOGÍAS 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.1INTRODUCCIÓN....................................................................................................................................................................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.1Separación de mensaje y transporte.....................................................................................................................19 3.3.2HTTP.......................................................................................................................................................................20 3.3.3SOAPAction Header...............................................................................................................................................21 3.3.4Status Code..............................................................................................................................................................21 4CASOS DE APLICACIÓN................................................................................................................................................22 4.1INTRODUCCIÓN....................................................................................................................................................................22 4.2PRESENTACIÓN DEL PROBLEMA.............................................................................................................................................22 4.2.1Transacciones.........................................................................................................................................................22

1

Informe de Proyecto de grado

Estudio e implementación de Web Services

4.2.2Publicación de Cursores........................................................................................................................................23 4.2.3Perfil del producto .................................................................................................................................................23 4.2.4XForms ...................................................................................................................................................................24 4.2.5Plataforma y herramientas ...................................................................................................................................25 5DISEÑO.................................................................................................................................................................................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 comunicación sobre SSL.....................................................................................................................33 6.4.2Soporte de firma Digital.........................................................................................................................................35 6.4.3Secuencia de Ejecución 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.2Implementación Básica de un Cursor...................................................................................................................48 6.5.3Implementación de un Cursor con Caché...........................................................................................................49 6.5.4Publicación de un Cursor como Web Service......................................................................................................51 6.5.5Implementación 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.3Ejecución y Presentación de los resultados.........................................................................................................57 7.2CURSORES..........................................................................................................................................................................58 7.2.1Objetivo...................................................................................................................................................................58

2

Informe de Proyecto de grado

Estudio e implementación de Web Services

7.2.2Escenario.................................................................................................................................................................59 7.2.3Ejecución ................................................................................................................................................................59 7.2.4Presentación de los Resultados.............................................................................................................................60 8CONCLUSIONES................................................................................................................................................................63 8.1SOBRE LA TECNOLOGÍA .......................................................................................................................................................63 8.2SOBRE LA APLICACIÓN 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

3

2 Objetivo El objetivo de este proyecto es evaluar el estado del arte de la tecnología de Web Services y probar su aplicación a casos concretos. Para ello. se presenta el marco tecnológico y funcional de IdeaSoft. un racconto de la evolución tecnológica que condujo al surgimiento de WS y una información general de la arquitectura de los WS. El caso de aplicación para las transacciones consiste en estudiar la viabilidad de realizar transacciones comerciales mediante Web Services. evitar el repudio. los protocolos y especificaciones asociadas. En particular se trabajó en el marco tecnológico del producto EDF de la empresa IdeaSoft [1]. En él capitulo titulado Web Services se proporciona una base teórica. etc. su arquitectura. medir su desempeño frente a otras alternativas y fijar una frontera para la utilidad de ésta tecnología. y se realizó una evaluación de algunas implementaciones y herramientas disponibles.1 El Proyecto Recientemente.3 Organización del Informe El informe se organiza de la siguiente manera: primero se da una detallada descripción de la tecnología. ha surgido el concepto de WebServices (WS). a continuación se expone la implementación del prototipo y los benchmarks realizados y por último. Luego. Un objetivo de este proyecto es probar su viabilidad. Como un objetivo de este proyecto se presenta el implementar esta funcionalidad. de su aplicación en los Web Services. Este proyecto se basa en el estudio de esta tecnología y su aplicación a casos concretos. accedido mediante Web Services. demostrando su viabilidad a través de la implementación de un prototipo. se enumeran las conclusiones recogidas durante la realización del proyecto.Informe de Proyecto de grado Estudio e implementación de Web Services 1 Introducción 1. sus componentes. se estudió el concepto de cursor genérico. brindando la infraestructura necesaria para realizar transacciones y manejar cursores. Otro problema que puede atacarse utilizando Web Services es el de recorrer catálogos o colecciones de datos. En una primera instancia se estudió ésta tecnología. de la representación de los datos. resolviendo problemas tales como: asegurar la confidencialidad de la transacción. se da una descripción básica del protocolo. 1. 1. ventajas y desventajas. 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. Los casos de aplicación se eligieron de forma que fueran representativos de los problemas típicos que pueden intentar resolverse con Web Services. En el capítulo denominado Caso de Aplicación se describen los diferentes contextos en que se 4 . y de la forma de transporte entre un punto y otro. de su sintaxis. Más adelante se hace una descripción de los conceptos WSDL y UDDI y de cómo éstos trabajan en conjunto. En el capítulo SOAP.

SSL.Informe de Proyecto de grado Estudio e implementación de Web Services realiza este proyecto y los requerimientos dados para la ejecución de transacciones y el manejo de cursores usando Web Services. se arriba a las conclusiones sobre el proyecto junto con las características que presenta esta tecnología.) y en las consideraciones de performance. En el capítulo Prototipo. Por último se publican mediciones para los distintos entornos de ejecución. se presenta la solución a los requerimientos del proyecto. haciendo hincapié en los requisitos de seguridad que trae aparejados (firma digital. Finalmente. comparando tiempos de respuestas de mensajes firmados y no firmados y los benchmark de los Web Services contra la arquitectura RMI. En el capítulo Diseño. qué herramientas se usaron como software de base para realizarlo y las clases implementadas. en el último capítulo. etc. se describe el entorno de desarrollo del proyecto. 5 .

que pueden ser utilizados sin preocuparse de como fueron implementados.1. Una vasta área de uso de XML viene dada por la necesidad de interoperabilidad. lo cual permite rudimentarias aplicaciones distribuidas sobre la red. La llamada de RPC es idéntica a la sintaxis de una función local.el cliente y el servidor pueden ser implementados con independencia de lenguajes de programación 2. 2.Servidor.Servidor. publicada. El cliente en este caso es la función o método que hace la llamada. e invocada a través de una red. Los requerimientos a la hora de desarrollar o consumir un WS son: una forma estándar de representar los datos: XML un formato común y extensible de mensaje: SOAP un lenguaje común y extensible para describir los servicios: WSDL (basado en XML).1 Introducción Un Web Services (WS) es una aplicación que puede ser descripta. permitiendo a las aplicaciones comunicarse unas con otras de una forma estándar. En efecto XML se ha vuelto la pieza común y de mejor entendimiento de la comunidad de diseñadores de software. Es un mecanismo a nivel de capa de aplicación. que comunica una aplicación con otra. La función toma la forma de interacción Cliente . De aquí en adelante nos referiremos a la comunicación Cliente . Los WS son a los efectos del consumidor componentes que se encuentran dentro de una caja negra.Informe de Proyecto de grado Estudio e implementación de Web Services 2 Web Services 2. localizada.no hay contexto de objeto.requiere un seteo para el retorno de una llamada en ambos servidores . generalmente retornará un valor como resultado de su proceso. generalmente sobre HTTP.1. RMI logra esto naturalmente . una forma de descubrir los servicios en Internet: UDDI (basado en XML). del requerimiento cliente.2 Comparando protocolos XML 6 . el cual requiere ejecutar algún proceso en el servidor. un proveedor y ocasionalmente un corredor (broker) y relacionados con estos agentes está las operaciones de publish (publicar). generalmente Internet. pero se diferencia en que: . find (encontrar) y bind (enlazar).1 RPC RPC permite a los desarrolladores de software hacer funciones o llamadas a métodos a través de la red. RPC actúa con el mismo espíritu Java RMI. Funciones remotas son llamadas a través de la red como una API remota. La arquitectura básica del modelo de WS describe un consumidor. y ser accedidos utilizando XML (SOAP). El proceso servidor.

Una conexión debe abrirse para cada nuevo canal.1 XMLRPC .Liviano.Las especificaciones son muy fáciles de entender . no tiene la habilidad de pasarse a otros protocolos .2.Solamente un servidor sirviendo a un cliente.No existe una seguridad de autentificación especificada .HTTP tunneling es integrante de este protocolo .Es muy fácil de programar.1 La habilidad de host a otros protocolos no se aplica directamente Seguridad y autentificación no están directamente especificadas.El trafico del protocolo es leíble y entendible. Envelope. request y response son documentos XML.Informe de Proyecto de grado Estudio e implementación de Web Services 2. binding para protocolos y otras para HTTP que no están especificadas No es muy fácil de programar en el actual estado de desarrollo No se necesita de una especificación para descifrar el trafico no encriptado El generar protocolos eficientes no fue un criterio de diseño Multi-channels y multiplexing no están actualmente soportadas Se menciona la posibilidad de multi-agent. rápido y fácil para la implementación de invocaciones remotas de funcionalidad a través de HTTP tunneling .Es una instancia de protocolo fija. y un operador podrá descifrar el tráfico no encriptado .Request y response son ambos documentos XML 2. no soporta descentralización .2.Operaciones sin conexión no están actualmente disponibles . sin embargo no están las especificaciones en la versión 1. fue la meta del diseño original .2 SOAP Es el protocolo clave para la nueva infraestructura de interacción entre aplicaciones Soporta HTTP tunneling. como un transport binding Soporta manejo de RPC Soporta operaciones de desconexión No es fácil entender las especificaciones. pero si son flexibles a la hora de implementar. 7 . es un complejo esquema de codificación. procesing path.1.1. no es posible multiplexar canales .

8 . y usando los estándares de Internet. Son aplicaciones modulares. de tal manera que COM puede solamente llamar a COM.2.2 Conectando Aplicaciones en la Web Los Web Services manejan la interoperabilidad mediante el protocolo estándar de XML. basadas en los estándares abiertos de Internet. De tal manera que un viajero puede al mismo tiempo hacer una reserva de un vuelo. que se autodescriben. Sin embargo estos modelos no son fácilmente interoperables. pueden ser publicadas. El modelo de WS potencia el desarrollo de aplicaciones distribuidas. Mas tarde Sun Microsystems lanzo al mercado RMI (Remote Method Invocation). era suficiente. Conectar una maquina a otra se transformó en una prioridad cuando las redes locales se generalizaron. Esto es un buen candidato para un protocolo de comunicación universal.2 Evolución de los Web Services. localizadas. Por ejemplo una compañía de alquiler de coches puede asociar su sistema de reservas on-line con el sistema de aerolíneas y los hoteles. e invocadas desde cualquier lugar de la WEB o dentro de una Intranet. Con estos protocolos se pueden llamar componentes que se encuentren en otras computadoras a través de la red. Estas llamadas se realizan bajo la forma de RPC (Remote Procedure Call). El concepto central de Web Services: computación orientada a los servicios. Fue entonces que OMG estableció IIOP (Internet Inter-ORB Protocol) como el protocolo de comunicación para CORBA. localizadas e invocadas o usadas desde cualquier parte en la Web o dentro de cualquier red local. En los 1980 los protocolos de comunicación no era objeto de interés de los desarrolladores. Estos son componentes que pueden ser fácilmente llamados desde cualquier aplicación que soporte COM o CORBA. Web Services son aplicaciones modulares que se autodescriben. Realizar aplicaciones que dentro de una misma máquina se comunicaran entre sí. 2. que pueden ser publicadas. una habitación de hotel y un coche de alquiler. En general. 2.1 Historia de la computación distribuida. COM y CORBA son modelos para escribir y encapsular código binario. La solución esta disponible para tener comunicación aplicación a aplicación desde cualquier máquina a cualquier otra sin importar el sistema operativo.2. Es necesario aclarar que estos protocolos no son interoperables. entorno de lenguajes. modelos de objetos distribuidos.Informe de Proyecto de grado Estudio e implementación de Web Services 2. La necesidad de pensar en el Web site como en una función. y lo mismo ocurre con CORBA. Microsoft creo DCOM (Distributed COM). Esta evolución tecnológica y de una búsqueda de soluciones a la computación distribuida no es un problema reciente. que determinan un nuevo paradigma de procesos de creación de aplicaciones altamente distribuidas. 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).

2. y son un paquete en la forma de módulos. y no 9 . tales como HTTP y SMTP. Estos conceptos contienen el protocolo SOAP con varias extensiones. así como el consumidor y desde su punto de vista es una “caja negra”. Luego el consumidor tendrá que aprender acerca del Web Service o su descripción.. SAP AG. el cual consiste de un protocolo de transporte. sin preocuparnos acerca de cómo el servicio esta implementado.Informe de Proyecto de grado Estudio e implementación de Web Services Ellos combinan los mejores aspectos de los componentes de programación. Son accesibles vía los protocolos de Internet como HTTP y SMTP. que pueden ser reutilizados. por W3C [2]. en la versión 1. Esto es un buen signo de la industria para aceptar e implementar estándares basados en protocolo interoperables. IBM Corp.. se da a conocer SOAP. o modelos de componentes fueron usados para crearlos. y basados en XML. describir e invocar. DevelopMentor Inc. o aún en que lenguaje. Finalmente podría disponer o tener la necesidad de invocarlo. Actualmente este protocolo esta siendo desarrollado por el XML Protocol Working Group de la W3C. y programación Web.. 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 tecnología que puede ser usada para implementar WS. SOAP (Simple Object Access Protocol) es un protocolo de mensajes entre computadoras. Las empresas que se juntaron para presentar a la W3C las especificaciones del protocolo fueron : Ariba Inc. sistema operativo.3 Arquitectura de los WS Hay 3 conceptos básicos que son : descubrir. En Mayo del 2000.. SOAP especifica el formato de mensaje que accede e invoca a los objetos. Hewlett-Packard Co. XML y SOAP son la base tecnológica de la arquitectura de los Web Services. Routing/ I ntermediaries Reliable Messaging Context/ Privacy Transactions Attachments Security Process Flow QoS and Pattern Description ( Workflow. IONA Technologies PLC. Lotus Development Corp. y Userland Software Inc. Desde el punto de vista del consumidor... situado en el tope de la capa de transporte. El Message building block.. 2. Commerce One Inc. suministrando los elementos de entrada y recibiendo los elementos de salida del mismo. Compaq Computer Corp. tendrá primero que encontrarlo o descubrirlo. mas que un objeto en particular. Microsoft Corp.

todas las veces. 10 . No tiene un modelo de objetos pero habilita a las aplicaciones al uso de varios modelos de objetos y lenguajes. SOAP es extensible. SOAP trabaja con la infraestructura de Internet. tal como Java en Linux o Visual Basic y Vicual C++ en Windows. y WS Framework pueden ser implementados en cualquier lenguaje de programación.1 SOAP Soportando SOAP.3. saltando los aspectos de seguridad.NET Platform and Framework. Significa que puede ser implementado con varias tecnologías. Varios proveedores y organizaciones han soportado la implementación de SOAP. por el uso de XML. se puede tener un SOAP object request broker (ORB). SOAP no reemplaza a CORBA. un parseador XML. XML. 2. Un ORB es un servicio que asiste en la invocación objetos. mecanismos de RPC. y un servidor HTTP. Esto se amolda a las situaciones de las empresas. y HTTP y SMTP definen los mecanismos de transporte para los mensajes. IBM Dynamic e-Business.[3]).Informe de Proyecto de grado Estudio e implementación de Web Services limita a los desarrolladores a un producto particular de un vendedor. por lo tanto se ha convertido en otro estándar de Internet. proxy servers. y luego con los bloques de Describir y Descubrir. Microsoft . manejando el tiempo de vida. si por ejemplo solo se quiere crear una comunicación de aplicación a aplicación. También establece un framework para enviar mensajes o conducir comunicaciones del tipo RPC. 2.3. Algunos proveedores : HP y e-Speak . realizando pooling. Usando HTTP se vuelve muy fácil de desarrollar. pueden acceder programáticamente a otras computadoras. No hay que hacer configuraciones especiales en routers. firewall. XML es usado para definir el formato del mensaje.1 Invocación Aquí SOAP. para que SOAP trabaje. sin la necesidad de los otros componentes. tales como HTML. HTTP y SMTP (ver [2]. Ningún otro protocolo garantiza que pueda se usado en todas las situaciones. envelope. y ninguna organización o un simple proveedor tendrá el control sobre SOAP. Con pocas líneas de código. sin necesidad de intervención humana y anexarlo como servicio en sus propias aplicaciones. DCOM o RMI. la primera interacción es con el bloque de Invocación. Sun Microsystems and Sun ONE Desde el proveedor.1. W3C ha definido a SOAP como una especificación. es el componente clave para la arquitectura. los Web site. SOAP es un protocolo simple. Es un protocolo de formato de mensaje extensible y se puede colocar en el tope de los protocolos de HTTP y SMTP. manejando performance y demás. solo alcanza con usar SOAP.

La posibilidad de enviar documentos de fax. 11 . (para una información completa ver Apéndice . si el mensaje fue alterado en la ruta.Informe de Proyecto de grado Estudio e implementación de Web Services 2.3. encoding. Este enfoque permite a los desarrolladores usar los módulos y funcionalidad que ellos necesitan.2 Descripción - - - - La descripción de un WS.La posibilidad de incluir un documento no XML. body: es el contenido del mensaje. cuanto tiempo espera por la respuesta? ¿Que puede pasar si dos o más veces el mismo mensaje es enviado? Security – Dar un marco de seguridad a la comunicación. (Platform for Privacy and Preferences (P3P)). un concepto similar puede manejarse para a los Web Services. pueden ser hechas adicionando módulos de funcionalidad. header y body. es la descripción de los mensajes que se pueden aceptar y generar. XML Signature nos ayuda a responder: quien envía el mensaje. a través del direccionamiento. SOAP message consiste de 3 secciones: envelope. firma digital. En pocas palabras el protocolo puede ser extensible. desde un “emisor” (cliente) hacia un “receptor” (servidor).Referencia a guardar el contexto y privacidad. imágenes de medicina. y atributos. o cualquier otro tipo de imágenes. Todos los mensajes son documentos XML con su propio esquema. Esto es una manera de hacer a los WS escalables. que incluye sus propios namespaces. 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 SOAP Message Los mensajes son fundamentalmente en una dirección. elementos. Algunos de los aspectos podrían ser aplicar SSL. incluso hacia múltiples servidores Reliable Messaging – ¿Cuando un servidor envía un mensaje.3. dibujos de ingeniería. codificadas en Base64 Routing/Intermediaries – Relacionadas al proceso de rutear mensajes SOAP a través de intermediarios. del entorno de los usuarios. legales. etc.XML Signature). Context/Privacy . SOAP define 2 namespaces: envelope. Quality of Services – QoS es una medida que puede ser comparada con el número o calificación dada a los ASP o ISP. header: información de identificación del contenido. Algunas de las extensiones que pueden ser deseables en los proveedores : Attachments . y las comunicaciones son del tipo request/response. sin la necesidad de tener que implementar la totalidad de estos. que mide la calidad del servicio.SOAP Message) Extensiones al protocolo.1. 2. o archivo binario. envelope : elemento raíz del mensaje. (ver detalles en Apendice . Esto ofrece la posibilidad de agregar varios WS y ofrecerlos como parte de nuestro paquete. No puede tener DTD asociados.

tales como descripción. a través de categoría.Informe de Proyecto de grado Estudio e implementación de Web Services fundamentalmente realizada por el WSDL (Web Services Description Language).WSDL) 2. a lo más complejo como arrays. desde lo más simple como integer o string. y otros definidos por el usuario. El siguiente nivel es la descripción del servicio en formato XML. se necesita una manera de permitir a otros encontrarlo.3 Discovery Una vez conocida la forma de invocar un WS y su descripción. UDDI (Universal Description. HTTP. contrato. Discovery and Integration) describe como un proveedor puede anunciar la existencia de un WS.3.s El siguiente paso es ver los detalles. La definición de la estructura comienza con un XML Schema. que describe los servicios de red. que provee una manera de especificar tipos de datos. (a la fecha no esta completamente especificado por la W3C. Un consumidor puede encontrar la existencia de un WS. La actual especificacion contiene bindings a SOAP. y MIME. Web Service Requester Socio de negocios u otro sistema FI ND Encontrar Web Service 2 SOAP Request UDDI Service firewall 3 BI ND Recuperar Definición 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 . proceso. el cual define ciertos XML Schemas y namespaces. ver Apendice .

La razón para ebXML fue desarrollar especificaciones XML para el intercambio comercial y crear un simple mercado electrónico donde las empresas de cualquier tamaño y ubicación geográfica podrían encontrar y conducir negocios a través de mensajes basados en documentos XML. independientemente de los formatos de los mensajes o protocolos de red utilizados para comunicarse. Microsoft e IBM.4 WSDL : Web Services Definition Language WSDL es usado para describir servicios Web por parte de las empresas. siendo las referencias del servicio intercambiadas y enlazadas en tiempo de ejecución.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).WSDL.0. Para una especificación completa de WSDL ver Apéndice . Este último factor es clave para la negociación de enlaces en tiempo de ejecución y la captura del comportamiento de servicios de referencia y de intermediarios. La idea es una registración en el registro de empresas UDDI. Un framework completo que describa tales reglas debe incluir medios para componer servicios y medios para expresar el comportamiento de los servicios. WSDL es un formato XML que describe los servicios de red como un conjunto de endpoints que procesan mensajes contenedores de información orientada tanto a documentos como a procedimientos. Discovery and Integration UDDI es un proyecto propuesto por Ariba. muestra como accederlos y el formato que deben tener los mensajes. 2. 2. Para una especificación del funcionamiento de WSDL con UDDI ver Apéndice – WSDL y UDDI. un servicio centralizado y replicado a distintos nodos en forma regular. lo que permite la descripción de endpoints de red y sus mensajes. quedando disponible para ser descubierta por otras empresas. Esta versión del lenguaje WSDL es un primer paso que no incluye un framework para describir las reglas de composición y organización de los endpoints. Los autores de la especificación 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. Los endpoints concretos relacionados se combinan en endpoints abstractos (servicios). 13 .6 Otras tecnologías relacionadas 2. WSDL es extensible. de tal forma que los clientes puedan acceder a ellos y utilizarlos. Es un estándar para registrar y descubrir los WS. EbXML antecede a UDDI.UDDI. Las operaciones y los mensajes se describen de forma abstracta y después se enlazan a un protocolo de red y a un formato de mensaje concreto para definir un endpoint de red. Para una especificación completa de UDDI ver Apéndice . es decir.5 UDDI : Universal Description.6. La composición de servicios debe ser de escritura segura pero también debe permitir pasar referencias. reglas de ordenación para enviar y recibir mensajes. Provee información de los distintos métodos que el WS brinda.Informe de Proyecto de grado Estudio e implementación de Web Services 2.

org/jsr/detail/093. provee una API para acceder a XML basados en registros distribuidos. Bajo nivel: objetos que acceden directamente al transporte y la estructura del mensaje SOAP.com/xml/xml_jarx.0. 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 . basados profundamente en el meta data de XML.Informe de Proyecto de grado Estudio e implementación de Web Services Para más información ver www. Utiliza la API de bajo nivel para hacer este trabajo. el cual es usado frecuentemente junto con la API de alto nivel. divididas en: Alto nivel: objetos que simplifican el RPC SOAP a través de proxies y stubs.0 consiste actualmente de tres APIs COM.org 2. sin basarse en el meta data de XML. Pese a ser una tecnología emergente.jsp 2.NET. se enumeran algunas de las mas importantes y sus principales características. 2. SMTP) Para más información ver www. Esta información es representada en un documento XML y define un esquema en el cual establece directorios para publicar información que puede ser compartida vía un protocolo estándar (HTTP. como por ejemplo: WSDL Generator: un wizard para generar el meta data XML derivado de un objeto COM. A continuación. El Microsoft SOAP Toolkit 2.7.3 DSML Directory Services Markup Language.ebXML.6.org 2.1 Microsoft SOAP Toolkit 2.0.0 La apuesta de Microsoft a esta tecnología ha quedado clara al presentar su nueva plataforma .6.2 JAXR JARX o Java API for XML Registries. y forma parte de la API JAXM (Java API for XML Messaging). el cual define una API para mensajes basados en XML. es un marco para describir la estructura y contenido de información de servicio de directorio. existen actualmente un variado y creciente número de implementaciones y herramientas disponibles. Para más información ver java. hay numerosas herramientas y utilidades que proveen una gran comodidad para el desarrollo.dsml.7 Implementaciones y Herramientas. SMO (Simple Messaging Object): objetos que vuelven fácil de usar mensajes SOAP que contienen XML.html o jcp.sun. en lugar de tener el overhead del RPC Adicionalmente a las APIs. Esta respaldada por Sun y fue originalmente para acceder a ebXML. la cual soporta fuertemente XML y SOAP.

WSDL. demos y ejemplos para ayudar en el diseño y ejecución de aplicaciones basadas en Web Services que pueden automáticamente encontrarse unas a otras y colaborar en transacciones de negocios sin programación adicional o intervención humana.Informe de Proyecto de grado Estudio e implementación de Web Services La plataforma . basado en el Internet Information Server y ASP. Sin embargo.NET 2.7. SOAP. así como demostraciones de cómo pueden trabajar juntas las tecnologías emergentes estándar. publicación y discovering de aplicaciones basadas en Web Services que soportan UDDI. testeo. construcción. la generación de archivos WSDL sólo es posible a 15 . tales como SOAP. un entorno de desarrollo de alto nivel para Web Services existe: IBM's WebSphere Studio Application Developer permite la creación. WSTK exhibe la tecnología emergente en Web Services y es una buena forma de comprender una de las especificaciones mas recientemente anunciadas por IBM. y XML. Provee ejemplos simples de Web Services.NET provee un servidor de Web Services.2 IBM Web Services Toolkit El IBM Web Services ToolKit (WSTK) es un kit de desarrollo de software que incluye un runtime. Por ejemplo. A modo de comentario de la utilización de ésta herramienta se ha comprobado que algunas características básicas son limitadas. WSDL y UDDI.

sin que por ello tengan menos componentes. DevelopMentor y UserLand. 2. Por mas información sobre WSTK. 3. tales como arrays. C++. operando simplemente sobre HTTP GET. con la contribución de IBM y Lotus. Phyton y PHP.1. Estos pueden ser usados a través de XML-RPC.1 XML Documentos como Mensajes El concepto fundamental es el uso de documentos XML como mensajes. La idea detrás de SOAP es la misma que RPC. y UserLand Software el 8 de Mayo de 2000.no se asocia fuertemente con HTTP . sin embargo SOAP incluye : .SOAP especifica información adicional incluida en el documento XML. Puede ser compuestos y leídos por desarrolladores con editores de 16 . ver [4]. que describe el contenido y como podría ser procesada. . [7] y [8].3 Otras implementaciones de SOAP Si bien no fueron evaluadas para éste proyecto. Por mas información. tal como en el caso de SOAP. Esto provee varias ventajas. Pero SOAP ha sido aceptado por proveedores y desarrolladores independientes como un estándar.Informe de Proyecto de grado Estudio e implementación de Web Services partir de Java Beans.1 Introducción SOAP esta descripto en una nota a la W3C.2. el cual es mejorado todo el tiempo. IBM.define la especificación de algunas estructuras en XML.. Para ver una completa lista de implementaciones ver [9] 3. esto significa que puede ser procesado por varios intermediarios .1 SOAP Message Exchange Model Define un modelo para el intercambio de mensajes. SOAP 1. etc. existen actualmente implementaciones de SOAP para Perl. La nota describe la versión 1.tiene características especificas para operaciones clásicas de RPC con parámetros in/out. en el cual intervienen los siguientes conceptos : 3. La primera versión fue liberada en 1999 y fue un resultado de desarrolladores de Microsoft. presentado por Microsoft. [6].el modelo es descentralizado.2 SOAP y Web Services SOAP no es el único protocolo para el uso de WS.1 del protocolo. ver [5].7. 3 SOAP : Simple Object Access Protocol 3.. como una Note por la W3C.2. .1 fue liberada el 8 de Mayo del 2000. También define un protocolo para llamadas a métodos remotos.

3. que describe un evento del sistema y lo difunde a otro servidor en la red.3 Message Chains El intercambio de mensajes puede ser realizado como una cadena de entidades lógicas que pueden procesar los mensajes. no importa que ruta toma un mensaje o como muchos endpoints puede procesarlos. hacer el proceso de depuración más simple. Esto significa que todos los siguientes escenarios son aceptados y permitidos por la especificación de SOAP : Un aplicación desktop compone un mensaje SOAP que requiere una cantidad de stock y lo envía como el body de un HTTP POST. y trabaja en las mayoría de las plataformas. Este es el método SOAP usado con HTTP y/o RPC.5 Diseño Modular SOAP es abierto y extensible. procesa el mensaje y retorna un mensaje SOAP en el HTTP response. 3. Todos los enpoints deben de manejar mensajes en cierta manera.2. Un proceso en el server compone un mensaje SOAP. Esta operación es la construcción básica de bloques de SOAP y es la unidad mas pequeña de trabajo. Los requerimientos más comunes son el intercambio de mensajes en pares request/response. Hay 3 pasos que un endpoint debe tomar para conformar la especificación: 1) Examina el mensaje.2.1. Un endpoint pueden funcionar tanto como receptor o emisor.2. Requerimientos complejos de intercambio se componen construyendo cadenas de mensajes. entonces elimina todas las partes identificadas en el primer paso antes de enviar el mensaje al siguiente endpoint. Un WS recibe el POST. que envía un mensaje como un e-mail attachment (parecido a ser un mensaje en one-way) - 17 .1.4 Endpoints en Funcionamiento Pensando el SOAP en términos de endpoints. La responsabilidad de un endpoint es examinar un mensaje y remover la parte que fue direccionada hacia ese endpoint para proceso. 3) Si este endpoint es un intermediario. 3.Informe de Proyecto de grado Estudio e implementación de Web Services textos.1. el cual actúa como receptor de mensajes. Un desarrollador de software. pasando mensajes a otros receptores (intermediarios). Si el endpoint puede manejarla o rechazarla.2 Emisor y Receptor En el intercambio de mensajes hay dos partes involucradas: emisor y receptor. 2) Determinar cuales de las partes direccionadas hacia este endpoint son obligatorias.1.2. ayuda a comprender la flexibilidad de los mensajes SOAP. Este concepto de una entidad lógica que realiza algún proceso de un mensaje SOAP es referida como un endpoint. 3. para ver si contiene cualquier información direccionada hacia el. el intercambio básico one-way.

según el modelo requestresponse. Las especificaciones. pero cualquier protocolo o método puede sustituir a HTTP.HTTP POST es solamente para el tipo request . De otra manera se introducirían potenciales riesgos al tener que habilitar otros puertos en los firewalls. La habilidad de crear protocolos que se colocan en el tope del protocolo estándar HTTP se hace mas importante que nunca.Informe de Proyecto de grado Estudio e implementación de Web Services SOAP soporta tan diferentes escenarios gracias a un diseño modular.SOAPAction en el HTTP header es requerida para indicar el intento de request . Provee un método para serialización de datos. pero las aplicaciones pueden definir sus propias reglas. SOAP muestra como podrían ser intercambiados sobre HTTP.un error es respondido con el codigo de status 500 y el mensaje Internal Server Error. 18 . Hay una diferencia entre los datos y su propósito o finalidad. Purpose – SOAP no define que es lo que hay dentro del mensaje.2. básicamente un tunneling. El elemento raíz es siempre el <Envelope>. 3. 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. los cuales permiten HTTP tunneling. permitiendo cualquier protocolo con base en HTTP. 3.2.un request SOAP exitoso es indicado por un response con status HTTP y codigo 2nn siendo nn un número entre 00 y 99 . de principio a fin. . Transport – No define como son transportados los mensajes durante el intercambio.el Content-Type del header de HTTP debe especificar “application/soap” .3 SOAP Message Un mensaje SOAP consiste de un documento XML. conteniendo el Fault element. Esto a su vez potencia la seguridad de las redes a través de los firewall. El HTTP tunneling se refiere a un wrapper del protocolo de comunicación HTTP.2 SOAP y HTTP SOAP especifica el binding sobre HTTP. La mayoría de las redes comerciales optimizan el trafico del protocolo HTTP. son dejadas abiertas para futuras extensiones del protocolo.

Carrier Pigeon. y especificado en un atributo encodingStyle que indica su uso. 3.Informe de Proyecto de grado Estudio e implementación de Web Services El elemento <Envelope> puede contener un elemento opcional <Header>.3 Transporte Hasta ahora se detalló el contenido del paquete SOAP. SMTP. llamado body entries. Raw sockets. El elemento <Body> le sigue al <Header> y es obligatorio. Este mecanismo se llama transporte. Es el contenido del mensaje. Esta es una lista de posibles transportes para el mensaje SOAP. 19 . Cada uno de estos es independientemente codificado. el cual debe ser el primer hijo inmediato. Anticipa el camino del mensaje SOAP como valor agregado a lo largo del proceso. Named Pipes. con lo necesario para consumir el servicio. llamado <Fault>. Files. Body y Header ir al Apéndice SOAP Message 3. que ocurre solo una vez dentro del <Body> y se utiliza para indicar errores o excepciones.3. algunos mas probables que otros: HTTP. Todo esto se basa en un modelo de mensajes request/response como una forma de invocar un método y pasarle parámetros. a continuación se describirá como se envía un mensaje desde el emisor al receptor. SOAP define solo un tipo de body entries. Puede contener sus propios elementos hijos. El elemento <Header> puede tener múltiples header entries. Para mas detalles acerca de como son los componentes Envelope. MQSeries.1 Separación de mensaje y transporte Una decisión acertada hecha por los autores de SOAP consiste en la separación de la definición del mensaje y de su transporte. La mayoría de los desarrolladores se enfocarán en HTTP como el protocolo estándar de transporte para los mensajes SOAP. El potencial de esto es hacerlo sobre Internet usando HTTP para realizar la comunicación entre aplicaciones.

2 HTTP HTTP es el transporte mas utilizado para SOAP porque es ampliamente aceptado y difundido. Hay un par de reglas básicas para el uso de HTTP como transporte de SOAP. Los mecanismos para enviar un mensaje SOAP sobre HTTP es el estándar HTTP POST método.3. este bloque de datos es el propio mensaje SOAP. Porque el mensaje SOAP es XML. el protocolo de transporte estándar para la Web. y SOAP. este retorna una respuesta HTTP . Un HTTP POST envía un bloque de datos a una URI particular en un servidor Web. el candidato para el formato de mensaje estándar. : 20 . constituye una poderosa herramienta. Si hay una respuesta al mensaje. La combinación de HTTP.Informe de Proyecto de grado Estudio e implementación de Web Services 3. HTTP hace que sea el gran transporte para SOAP. En este caso el mensaje SOAP. que los autores aseguran que las reglas para su uso como transporte son parte de las especificaciones de SOAP.Ej. el cabezal Content-Type del HTTP POST debe ser “application/soap”.

y la URI indica el lugar del endpoint.com/timeserver/'> <w:country>Uruguay</w:country> </w:GetLocalTime> </soap:Body> </soap:Envelope> Las primeras 4 líneas de este ejemplo están relacionas al HTTP transport. El mensaje por si sólo no cambia porque esta siendo transportado por HTTP. que indica un Internal Server Error.com/timeserver.mysoap.org/soap/envelope/' soap:encodingStyle='http://schemas.3 SOAPAction Header La especificación SOAP define un cabezal adicional a ser usado cuando el mensaje SOAP es transportado sobre HTTP. cualquiera en el rango 200-299 indica éxito. y el valor del cabezal es la URI que indica las intenciones del mensaje SOAP.mysoap. La primer línea contiene el método HTTP. 21 .xmlsoap. Todos los mensajes SOAP deben usar application/soap.com</h:from> </soap:Header> <soap:Body> <w:GetLocalTime xmlns:w='http://www. La primer línea también indica la versión 1. Content-Type indica el tipo MIME del contenido del POST. y están seccionados dentro de clases de 100 elementos. Esto le permite al firewall y otros servidores realizar procesos condicionales basados en la presencia del SOAPAction Header. es específico de SOAP.com/Header'>SoapGuy@mysoap.org/soap/encoding/'> <soap:Header> <h:from xmlns:h='http://www. SOAP coloca un requerimiento sobre el transporte de HTTP cuando este es usado para intercambiar mensajes. Estos son enteros. Esto es un indicio al servidor que un particular HTTP POST contiene un mensaje SOAP. Por ejemplo. 3.1 de HTTP usada en este request. Este ejemplo representa un mensaje SOAP request enviado a la URL http://www. El último cabezal. 3.mysoap. entonces el código de status debe ser 500.3. La necesidad de SOAPAction depende de cómo nuestro endpoint está implementado.4 Status Code HTTP retorna un código de status. y este cabezal es el SOAPAction Header. SOAPAction. SOAPAction header no cambia porque está enviando un mensaje SOAP. Content-Length dice el tamaño en bytes del contenido.1 Content-Type: application/soap Content-Length: ### SOAPaction: “urn:mysoaptime” Estudio e implementación de Web Services <soap:Envelope xmlns:soap='http://schemas.3.Informe de Proyecto de grado POST /timeserver HTTP/1. Si la respuesta contiene una falla. Las 2 primeras son estándares de HTTP.xmlsoap. Las siguientes 3 líneas son el cabezal HTTP.

2. 22 . Como ejemplos se pueden plantear un cursor de Base de Datos. 4. por el cliente (para brindar garantías al servidor). Los casos a implementar son los siguientes: Transacciones: Se trata de implementar una típica transacción comercial con fuertes requerimientos de seguridad. Cursores: Se trata de recorrer en forma remota (sobre una LAN e Internet) una colección de datos mediante un cursor. por un agente externo que interceptó y modificó la misma o por errores en la transmisión.2 Asegurar la integridad Es necesario asegurar que la información transmitida no pueda ser modificada. Desde la perspectiva del que envía en mensaje (sender).1 Transacciones El objetivo es probar esta tecnología en escenarios en donde los servicios tienen un alto grado de seguridad. significa asegurar la identidad del que recibe el mensaje autenticado Desde la perspectiva del que recibe el mensaje (recipient). la cual es llamada autentificación del mensaje.1. ya sea por el servidor (para brindar garantías al cliente). tales como los encontrados en el contexto de transacciones comerciales (por ejemplo.2. o realizar un pedido de compra). 4. Para esto se deben contemplar las siguientes requisitos de Seguridad: 4.1. La otra es la autentificación de la identidad de quién envía y de quién recibe el mensaje.1 Introducción A los efectos de probar esta tecnología se presentarán 2 casos puntuales de aplicación. por lo que el contenido de la comunicación no puede ser entendible por una tercera persona que la pudiera interceptar.1 Confidencialidad de la transmisión La transacción puede contener información confidencial.Informe de Proyecto de grado Estudio e implementación de Web Services 4 Casos de Aplicación 4.2 Presentación del Problema A continuación se presentara de forma detallada los problemas existentes en los casos a resolver. 4.3 Autentificación Involucra dos clases de requerimientos de seguridad : Una es la identidad del creador del mensaje. significa asegurar la identidad del que envía del mensaje y el contenido del mensaje autenticado. 4. servicios en donde se permite transferir dinero de una cuenta bancaria a otra. la cual es llamada sender/recipient authentication.1. las paginas de un reporte o los ítems de un catalogo.2.2.

3 Perfil del producto Este proyecto se desarrolla en el marco del producto EDF (Enterprise Development Framework).1.4 Asegurar el no repudio Debe garantizarse que ninguno de los participantes en la comunicación pueda negar parte en la misma.2. Entre las técnicas se encuentran: ambientes cliente-servidor de múltiples capas.2. formularios electrónicos. A tal fin.1 Mantenimiento de Estados Para recorrer un cursor se debe mantener en el servidor la posición en la que se encuentra el mismo. y lo que sucede si esta tercera parte reclama que ha recibido la transacción del emisor.Informe de Proyecto de grado Estudio e implementación de Web Services 4. 4.2. push/publish/subscribe.2. Con esto se desea evitar el caso en que un receptor trata fraudulentamente de reenviar una transacción a otro receptor.2. workflow.2. Los objetivos de este caso a implementar son los de recorrer un cursor de forma remota y cuidando los siguientes detalles: 4.6 Evitar el reenvío de transacciones (forward) Es necesario evitar que la transacción sea reenviada a un destinatario que no sea el deseado.2. 4.2. 23 . como por ejemplo en el caso de recorrer un reporte o cargar un combo. 4. puede considerarse esto como un caso particular del recorrido de un cursor.2. por ejemplo los cursores de un RDBMS. y una copia de la misma transacción.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. haya sido reenviada por error o por una tercera parte con fines fraudulentos. el cual consiste en un ambiente de interoperabilidad entre un conjunto de técnicas y productos que permiten el desarrollo de una nueva generación de aplicaciones realmente centradas en la red. 4.1.1. 4. CIM (Customer Interaction Management). OLAP.5 Evitar copias de transacciones como válidas (replay) Se debe poder distinguir entre una transacción enviada por el cliente.2 Publicación de Cursores Una de los requerimientos del proyecto consiste en recuperar colecciones de datos a través de WS.

24 . puede considerarse como una transacción electrónica. haciendo hincapié en la separación de la presentación del formulario y su contenido. 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.Informe de Proyecto de grado Estudio e implementación de Web Services 4.2. Para el caso de transacciones. Actualmente. Uno de los objetivos de este proyecto consiste en proveer infraestructura para permitir la ejecución de formularios mediante Web Services. existe una propuesta de definición en este sentido llamada XForms [10].4 XForms Dentro de la capa de presentación. un motor de ejecución de formularios. De igual manera. Ideasoft implementa esta propuesta en JForms. Últimamente se han remitido propuestas a la W3C para estandarizar el modelo de formularios. un formulario que contenga información de transferencia de dinero entre cuentas bancarias. una forma habitual de interacción con el usuario es a través de formularios.

Para mas detalles. Asimismo. tales como Tomcat. y actualmente se encuentra disponible la versión 1.5 Plataforma y herramientas Ideasoft utiliza fuertemente la plataforma Java. ver Apéndice – Plataforma y Herramientas 25 . junto con todas las herramientas relacionadas a ella. Apache SOAP. La única excepción admitida fue la utilización de la XML Security Suite de IBM. un producto para firmas digitales de archivos XML. la cual no fue utilizada porque al momento de comenzar la fase de implementación no había sido liberada.0.Informe de Proyecto de grado Estudio e implementación de Web Services 4. La primera versión corresponde a febrero de 2002.3.2. Hoy en día una alternativa open source es el ApacheXML-Security-J. etc. se le dio prioridad a la utilización de herramientas open source.

y generalmente toma mucho más tiempo computar una firma en lugar de un hash o un MAC (Message Authentication Code) de clave simétrica.Informe de Proyecto de grado Estudio e implementación de Web Services 5 Diseño En esta sección se presentaran distintas propuestas tecnológicas. La firma digital permite que los mensajes sean autenticados contra un usuario. el cual es incluido en el header de SOAP. El emisor y receptor no necesitan compartir una clave secreta. el servidor puede identificar al creador del mensaje. Microsoft y otros. La firma digital de un documento XML se representa por el elemento Signature. Específicamente SOAP-DSIG define un formato de datos para calcular y agregar la firma digital a un documento XML. SOAP-DSIG tiene este propósito. Estos son firmados. lo cual constituye una garantía de que la firma es del creador. detallando los requerimientos que satisfacen. La clave usada para firmar el mensaje es identificada por el elemento <KeyInfo> la cual garantiza la 26 .1. a partir de su firma se genera el elemento <Signature>. Una firma digital se basa en una criptografía de clave pública. 5. Esta tecnología ha sido implementada en productos comerciales por IBM. "+" 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 transacción.1 Transacciones 5. Una transacción del tipo comercial requiere del no repudio.1 Firma Digital La firma digital (SOAP-DSIG) define la sintaxis y procedimientos para firmar digitalmente mensajes SOAP y validar su firma. el cual tiene la siguiente estructura ("?" denota cero o una ocurrencia.

Para mas detalles. y el forward de mensajes. un timestamp. ya que cada ticket identifica al destinatario en el que se puede ejecutar el formulario 5. el cual sirve para numerar los mensajes. Un ticket consta básicamente de un número de secuencia.Informe de Proyecto de grado Estudio e implementación de Web Services identificación del usuario que creo el mensaje. pues al momento de escoger una solución.1. El número de secuencia y el identificador del destinatario son gestionados por el servidor y luego manejados por el cliente. ver Apendice . El cliente genera aleatoriamente un conjunto de claves que serán usados para la encriptación. con un total de cuatro claves. ya que cada mensaje tendrá numeros de secuencia y timestamps distintos. Las claves son encriptadas usando la clave pública del servidor y son enviadas al servidor de forma segura. Se acuerda un algoritmo de encriptación (para mantener la privacidad de la comunicación). Es normalmente utilizado en aplicaciones B2C (business-to-costumer). Estos datos son mantenidos para cada sesión. La negociación del SSL se puede resumir a grandes rasgos en estos pasos: Tanto el cliente como el servidor intercambian los certificados X. 27 . se presentan distintas alternativas y los requerimientos que satisfacen. 5. mientras que el timestamp es directamente agregado por el cliente. Los certificados son verificados comprobando la validez de las fechas y la firma digital de una Autoridad de Certificados (organización que emite certificados) conocida. Al manejar tickets se evita el replay de mensajes. se introduce el concepto de ticket.servidor que en la del servidor al cliente. Para mas detalles. y un identificador del destinatario (Identity Recipient). Por otra parte cabe destacar que fue desechada la alternativa de utilizar XML encriptado [12]. ver [11] SSL asegura la confidencialidad de la comunicación y la autentificación del servidor frente a los clientes y (opcionalmente) de los clientes frente al servidor. y asegura la integridad de los datos transmitidos.2 SSL SSL es un protocolo ampliamente usado para transmitir documentos HTML desde un sitio seguro. 5.2 Cursores Para el caso puntual de recorrer cursores en forma remota.1. la especificación se encontraba en estado de Working Draft. Se usan claves diferentes en la comunicación cliente . Esto último se consigue mediante SSL. que indica el momento en que es enviado el mensaje.XML Signature La firma digital permite solucionar el problema del posible repudio de una transacción. Para satisfacer los requerimientos de no repudio es necesario tener simultáneamente la autentificación del mensaje mediante el uso de firma digital y cumplir con los requerimientos de autentificación del emisor. Finalmente el mensaje SOAP firmado es enviado al servidor.3 Manejo de tickets Para asegurar que todos los mensajes válidos sean distintos.509 para probar su identidad. y asegura al usuario una comunicación encriptada con el sitio. por lo que se opto por una tecnología madura y estándar.

Al permitir que la infraestructura realice el manejo de sesiones. Benchmarks 5.Informe de Proyecto de grado Estudio e implementación de Web Services 5. En este caso por tratarse de recorrer grandes cantidades de datos este punto es crucial. El objetivo de este benchmark es confrontar Web Services contra RMI en el caso puntual de tener que recorrer una colección de datos en forma remota. El recorrer los datos solicitándolos de a ráfagas (cache en el cliente). Se eligió RMI por ser una alternativa conocida y se puede utilizar exactamente el mismo código del cursor.2. lo cual no se encuentra dentro de los objetivos de este proyecto. Por ultimo se apuesta a que esta característica sea parte del estándar en futuras versiones. Se espera que sea mas performante pues no involucra parseo de XML y el overhead de empaquetado y transporte de datos es menor.2 Una duda implícita en cualquier aplicación que utilice Web Service radica en como será su desempeño al momento de su puesta en marcha. El desempeño en función del tamaño de las tuplas a transferir. En particular se desea comparar : El recorrer los datos solicitándolos de a uno por vez. brindando WS stateful de forma transparente.1 Manejo de sesiones por parte del servidor Los WS son stateless por definición. el sistema se vuelve mas escalable y performante.NET Construir aplicaciones cliente/servidor de forma que intercambien un identificador de sesión o similar entre los distintos request. y manejar en las aplicaciones la administración correspondiente a las sesiones. Implementada dentro de la Aplicación: - En este caso se optó por la primera opción por varias razones: Esta funcionalidad al ser brindada por la infraestructura evita la necesidad de programar una lógica de manejo de sesiones.2. pues el manejo de sesiones es algo altamente utilizado y básico en aplicaciones no triviales. se enuncian al menos dos posibles opciones: Provista por la infraestructura de Web Service: Usar implementaciones propietarias que resuelvan el problema. tales como las provistas por Apache SOAP 2. Para resolver este caso.2 o . por lo que el mantener el estado a través de los distintos request es un problema no cubierto por la especificación. Por esto se decidió realizar un estudio comparativo de esta tecnología frente a otras alternativas propietarias (aunque posiblemente mas performantes) como ser Java – RMI. La performance en una LAN y en Internet 28 .

3. en esto punto se presentan tres acciones posibles a realizar.2 [19] y el JavaBeans Activation Framework 1. Como servidor y contenedor de servlets se utilizó el Jakarta Tomcat versión 3.Informe de Proyecto de grado Estudio e implementación de Web Services 6 Prototipo A continuación se presenta la implementación realizada en base al diseño descrito en el punto anterior. También se deben generar certificados con el keytool para que luego puedan ser tomados por el XMLSS y por el Tomcat para el SSL.2.2 Modelo de trabajo de Apache SOAP sobre Tomcat Apache SOAP provee un manejo básico de visualización. Por mas detalles de instalación y configuración Apendice – Instalación y Configuración 6.0 [18]. Para el manejo de las firmas digitales de XML se utilizó el IBM XML Security Suite [16]. [17] y como procesador de XSLT se utilizó el Xalan 2. configurar archivos de Tomcat y del SOAP de apache.1 [14]. deploy y ejecución de Web Services sobre Tomcat. También es necesario para el correcto funcionamiento de este producto la instalación del JavaMail 1. Para la instalación de estos componentes es necesario un orden predefinido en el classpath. Primero se describirá la plataforma y el entorno en el que se realizó el sistema.1 Estudio de Plataforma Todas las clases fueron implementadas en el lenguaje Java.1. El acceso al SOAP en Tomcat es a través de . Como parser de archivos XML se utilizó el Xerces v.2 [15].2. versión 1.0. y por último se presentarán las clases implementadas para el manejo de cursores. La implementación de SOAP utilizada fue el Apache SOAP 2. 1. 6. 29 .1 [20]. las cuales son: List: Lista los WebServices disponibles.3 [13]. Luego se detallarán las clases implementadas para el caso de las transacciones.

Informe de Proyecto de grado Estudio e implementación de Web Services - Deploy: Agregar un Web Service a la lista. ver Apéndice – Administracion de Web Services con Apache SOAP 30 . Para mas detalles. - Un-Deploy: Borrar un Web Services de la lista de disponibles.

- - Algunas extensiones al framework de Apache SOAP necesitan la capacidad de interactuar con el 31 .Informe de Proyecto de grado Estudio e implementación de Web Services El modelo de trabajo del Soap sobre Tomcat es el siguiente: Aplicación Cliente Apache SOAP Parser de XML SOAP Registro remoto de Servicios Apache SOAP Listener ( RPCRouterServlet) Apache SOAP Web Application Server Parser de XML Aplicación Servidor Este diagrama define el funcionamiento básico de una invocación a un Web Service utilizando Apache SOAP. En el servidor Web es recibido este request por parte de un servlet (rpcrouter mapeado a la clase RPCRouterServlet). el cual es el siguiente: La Aplicación cliente a través del Apache SOAP Library crea y envía un request SOAP al servidor (). Busca en la Remote Services Registry la clase asociada al método. la instancia y por ultimo ejecuta el método solicitado por el cliente.

Writer out) throws SOAPException. Estas son copiadas y almacenadas en el objeto org. manteniendo la sesión.Informe de Proyecto de grado Estudio e implementación de Web Services mensaje SOAP al momento de recibirlo o enviarlo. Para esto. esa cookie es devuelta al servidor. Si otra llamada es realizando usando el mismo objeto Call. Estos métodos serán invocados después de enviar un mensaje y antes de recibirlo: Aplicación Cliente Apache SOAP Parser de XML EnvelopeEditors Registro remoto de Servicios Apache SOAP Listener ( RPCRouterServlet) Apache SOAP Web Application Server Parser de XML Aplicación Servidor 6. la cual consta de los métodos: public void editIncoming(Reader in.Call usado para invocar el servicio.RPCMessage.soap.apache. Para facilitar este tipo de interacciones Apache SOAP provee la interface EnvelopeEditor.3 Mecanismo de mantenimiento de sesiones (Web Services stateful) El mantenimiento de las sesiones se consigue haciendo que el servicio que se está comunicando vía HTTP setee cookies apropiadas para mantener la sesión. public void editOutgoing(Reader in.rpc. es necesario configurar el cliente de la siguiente manera: 32 . Writer out) throws SOAPException.

ver HIPERVÍNCULO "Apendice XXXX. call.3.1 Deploy del Web Services para el mantenimiento de sesiones Para que el Web Service mantenga la sesión.1 Transacciones Soporte de comunicación sobre SSL Para asegurar la confidencialidad de la información. debe ser realizado su deploy con la opción Scope en “Session”. shc. se habilita la comunicación cliente/servidor mediante SSL [11]. 6.4 6. A continuación.doc" Apéndice – Administracion de Web Services con Apache SOAP 6.1. se efectúa el siguiente cambio en la configuración.0.4.setMaintainSession (false).4. éste establecerá una nueva conexión con el servidor y la información de la sesión se perderá. 33 . Cabe destacar que el objeto SOAPHTTPConnection debe ser el mismo a lo largo de toda la sesión. Si se realiza un nuevo “shc = new SOAPHTTPConnection ()”.Informe de Proyecto de grado Estudio e implementación de Web Services Call call = new Call (). 6.setSOAPTransport (shc). se mencionan los pasos seguidos para configurar la comunicación por SSL entre el servidor y el cliente.1 Configuración del servidor Para usar HTTP con el conector SSL en Tomcat. en lugar de “Request” Por mas información sobre el deploy de un Web Service. SOAPHTTPConnection shc = new SOAPHTTPConnection ().

Ejemplo: System.Provider Por defecto. Tomcat utilizará el certificado que tiene alias “tomcat” en el keystore.2 [21].protocol").pkgs: Indica la implementación del URL handler para el protocolo HTTPS.2=com.service.net.internal.net.xml: <Connector className="org.net.protocol. por ejemplo con la siguiente línea: 34 .handler.provider.internal. Los jars de jsse deben estar en el CLASSPATH y en $JAVA_HOME/jre/lib/ext (JAVA > 1.http.sun.ssl.sun. debe instalarse la Java Secure Socket Extension o JSSE 1.security y añadir la linea security.tomcat.service.4.2 Configuración del cliente Para la configuración del cliente será necesario setearle al cliente 2 properties.PoolTcpConnector"> <Parameter name="handler" value="org. java." keystore_path\keystore_name").ssl.setProperty("javax. La password del keystore es changeit.0.apache. se especifica que los clientes se deben autentificar y que el puerto utilizado para la comunicación segura será el 8443.tomcat.ssl. las cuales son: javax.1. Para la creación de un certificado con esas características se utiliza el siguiente comando: keytool -genkey -alias tomcat -keyalg RSA 6.protocol.net.Informe de Proyecto de grado Estudio e implementación de Web Services en el archivo server. System.trustStore".setProperty("java. Adicionalmente debe agregarse como proveedor de seguridad la clase que implementa el HTTPS.ssl. Para que el Tomcat utilize sockets seguros.pkgs".apache.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.trustStore: Indica el camino y nombre del keystore que contiene los certificados confiables para el cliente.www.2).ssl.net.apache.handler."com. Parte de la configuración consiste en editar el archivo $JAVA_HOME/jre/lib/security/java.tomcat.HttpConnectionHandler"/> <Parameter name="port" value="8443"/> <Parameter name="socketFactory" value="org.

El firmado de los paquetes SOAP en el cliente y la verificación de la firma digital en el servidor se realiza mediante los llamados EnvelopeEditors.sun.Informe de Proyecto de grado Estudio e implementación de Web Services Security.addProvider(new com. mencionados en el punto 6.1. Por mas información acerca de las implementaciones disponibles ver [22].ssl. 6. Este producto fue elegido debido que al momento de comenzar el proyecto. Al día de hoy se ha ampliado notoriamente la cantidad de opciones posibles.2 Soporte de firma Digital El soporte para firma digital de archivos XML se brinda a través de la API IBM XML Security Suite.4. Las clases implementadas pueden verse en el siguiente diagrama (en fondo claro se encuentran las clases implementadas por terceros.Provider()).internal. se debe ingresar el certificado del servidor en el keystore del cliente y el certificado del cliente en el keystore del servidor.ssl. fue el que presentó menos problemas al realizarle test básicos.net. Por ultimo y como sustitución al intercambio de certificados del handshake de SSL.2. y en fondo oscuro las clases implementadas para este proyecto): 35 .

En caso afirmativo. se comporta de igual forma que ClientEnvelopeEditor. Para el caso de recibir la respuesta del servidor. ejecuta el método. Del lado del servidor. La clase ClientEnvelopeEditor se encarga de enviar un mensaje SOAP sin modificarlo. Cabe mencionar que la implementación “por defecto” (dejando el cuerpo del método en blanco) causaría un mal funcionamiento de la aplicación. la clase ServerEnvelopeEditor se encarga de verificar si la firma digital del mensaje SOAP recibido es correcta. bloqueando el flujo de información. y enviarlo al cliente si la firma digital es correcta. y de recibir un mensaje SOAP firmado digitalmente por el servidor. agregando como parámetros los datos necesarios para almacenar y verificar a posteriori la firma digital. 36 . siguiendo el patrón Adapter [23]. para brindar una implementación básica de los métodos editIncoming y editOutgoing . o en caso contrario levantar una excepción. ya que hereda el método editIncoming. La clase ClientSignedEnvelopeEditor se encarga de firmar digitalmente el mensaje SOAP que recibe y enviarlo posteriormente. si éste contiene alguna.Informe de Proyecto de grado Estudio e implementación de Web Services 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.

se retorna una excepción. y una llamada Signature que es utilizada por ClientSignedEnvelopeEditor y ServerEnvelopeEditor para firmar digitalmente los mensajes SOAP. se ejecuta el método. Para obtener los certificados digitales necesarios al momento de firmar y verificar las firmas. pero es fácilmente modificable. De lo contrario. Esta clase también se encarga de firmar digitalmente las respuestas provenientes de la ejecución de los métodos. se implementó una aplicación que realiza la verificación: 37 . o archivo en formato JKS (Java Key Store). 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 comprobación a posteriori de la firma digital. Si no la requiere. Se implementaron dos clases utilitarias para trabajar con las firmas digitales: una llamada Verifier. se implementó una clase utilitaria llamada KeyStoreUtil. que se encarga de proporcionar una instancia de un certificado. a partir de un identificador. para dar garantías al cliente acerca del resultado de las transacciones.Informe de Proyecto de grado Estudio e implementación de Web Services Estos datos pueden ser almacenados en una base de datos o similar. como ser un servidor LDAP o una base de datos. si el mensaje no contiene firma digital y el método la requiere. para evitar un posible repudio del cliente. que es utilizada por las clases ClientEnvelopeEditor y ServerEnvelopeEditor para verificar la firma digital. La implementación actual los obtiene a partir de un keystore. De esta forma queda abierto el sistema para que en un futuro puedan ser tomados de otras fuentes.

Informe de Proyecto de grado Estudio e implementación de Web Services La relación entre las clases puede verse en el siguiente diagrama: 38 .

implementado en la clase VerifierWS: 39 . se publicó como Web Service un método que permite realizar la verificación en forma remota.Informe de Proyecto de grado Estudio e implementación de Web Services 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 implementación en donde la aplicación GUI que interactúa con el usuario instancia localmente la clase que realiza la verificación. A su vez.

NS_URI_SOAP_ENC).apache. setEncodingStyleURI: Identifica el Encoding org.Constants. Estos son los mapeos entre los objetos Java y su correspondiente representación en XML.soap. e invocan a los Web Services a través de sus métodos: 40 . a utilizar (por defecto es - Preparar y setear el vector correspondiente a los parámetros de cada método a ejecutar. setTargetObjectURI: Identificador del Web Service a utilizar. Los clientes la instancian. De esta manera es transparente para el usuario final la serialización de objetos java a XML y viceversa. Esta clase se llama XFormsProxy. setMethodName: Identificador del método a ejecutar. Estas llamadas manejan y resuelven los siguientes problemas: Configurar los “mapType”. se implementó una clase que encapsula la mayor parte de la complejidad inherente a la configuración de la llamada a Web Services.Informe de Proyecto de grado Estudio e implementación de Web Services 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 ejecución de los Web Services a través de clientes Java. Setear el número de secuencia correspondiente a cada ejecución. e implementa el patrón Proxy. descrito en [23].

4. y las clases involucradas. A continuación se detalla el ciclo de la ejecución de una transacción. 41 .3 Secuencia de Ejecución de Transacciones.Informe de Proyecto de grado Estudio e implementación de Web Services 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.

y brinda la implementación para los métodos publicados como Web Services. que implementa la interfaces WebServiceTransaction encapsula la lógica de la ejecución de la transacción. La clase WebServiceTransactionImp.2) para la firma y la verificación. En la ejecución de la transacción participan los EnvelopeEditors (descritos en la sección 6. 42 . tal como se menciona en el punto 6. Básicamente.5.Informe de Proyecto de grado Estudio e implementación de Web Services En este diagrama se muestra el ciclo de vida de una transacción.1. siguiendo la idea del patrón Facade [23].1. consta de un inicio de sesión (mediante el método login) y la ejecución de la transacción (mediante el método execute).

Informe de Proyecto de grado Estudio e implementación de Web Services WebService Transaction (from server) execute() execute() login() WebServiceTransactionImp (from server) WebServiceTransactionImp() login() execute() execute() ControlUser (from server) checkUser() ControlUserImp (from server) ControlUserImp() checkUser() 43 .

Informe de Proyecto de grado Estudio e implementación de Web Services 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 unívocamente al Web Service para los clientes. Comunmente se utiliza el formato urn:UniqueServiceID 44 .

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 . dicho objeto maneja los siguientes datos: transactionOk: Status de la ejecución del Web Service. se utiliza y se desecha Session: La instancia del objeto es única durante toda la sesión Application: Sólo una instancia del objeto es creada durante todo el tiempo de vida del SOAP servlet Methods: Define los nombres de los métodos que pueden ser invocados en este objeto Provider Class: Indica la clase que brinda la implementación del Web Service. se crea una instancia del objeto. errors: Vector de errores asociado a la ejecución de la transacción y no a aspectos concernientes a la ejecución del Web Service. Existen principalmente tres valores posibles: Request: Por cada request. Esta clase debe estar accesible (en el classpath) por el web container Type mappings: En esta sección se describe la relación de los objetos utilizados y las clases que los serializan. Para una mejor descripción de todos los campos relacionados con el deploy. El resultado de la transacción es representado por el objeto TransactionResult. Message: Mensaje asociado a la respuesta.Informe de Proyecto de grado Estudio e implementación de Web Services Scope: Define el tiempo de vida del objeto que responde al request. ver [24].

estos son errores de ejecución (descriptos anteriormente) y errores de seguridad.4. con el código y el mensaje correspondientes. Recipient no válido: Se intentó ejecutar la transacción en un recipient distinto al indicado.4 Tratamiento de Errores Básicamente se distinguen dos clases de errores. implementando varios JavaBeans. 6.4. 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 .5 Objetos de Intercambio (ValueObjects) Para realizar el intercambio de información entre los distintos componentes del sistema.Informe de Proyecto de grado Estudio e implementación de Web Services 6. Ante cualquiera de éstos errores se lanza una SOAPException. A continuación se detallaran los diferentes tipos de errores de seguridad: Error en el login: Usuario o password no válidos Número de secuencia incorrecto: El número enviado por el cliente no es el esperado Timestamp no válido: La hora indicada por la transacción está fuera de rango Firma digital no válida: La firma digital del paquete SOAP no verifica. se siguió el patrón ValueObjects.

En particular. A continuación se presenta la API Cursor. 47 . (benchmarks). estos objetos son genéricos y la implementación es totalmente independiente al tipo de datos de los mismos.1 Cursor Abstracto La idea de un cursor abstracto es básicamente la acción de recorrer una lista de objetos.5 Cursores En esta sección se comentarán los detalles de implementación del caso de aplicación referido a los cursores. Los resultados de esta comparación se presentan en el capítulo 7.Informe de Proyecto de grado Estudio e implementación de Web Services 6. y por otro las construidas para comparar los Web Services contra RMI. proporcionada por la empresa Ideasoft. se comentarán por un lado las clases construidas para demostrar la viabilidad de esta tecnología aplicada a esta caso puntual.5. 6.

Informe de Proyecto de grado Estudio e implementación de Web Services 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. y devuelve una instancia de la clase DBCursorImp que puede ser utilizada para recorrer el resultado de la consulta. 48 .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.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.5. La clase DBCursorFactoryImp recibe un DBCursorSpecImp que contiene la consulta a la base de datos. diseñado para acceder a una base de datos mediante JDBC.2 Implementación Básica de un Cursor Se realizó una implementación concreta de un cursor.

La arquitectura se ilustra en la siguiente figura: CacheCursor Ráfagas DBCursor Peticiones simples Base de Datos Las clases implementadas se presentan en el siguiente diagrama: 49 . El mismo implementa la idea básica de un cache. publicando la interface de un cursor.Informe de Proyecto de grado Estudio e implementación de Web Services 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. se penso en un cursor con cacheo.5. pidiendo de a ráfagas los objetos a un cursor básico y almacenando una copia de los últimos.3 Implementación de un Cursor con Caché Para realizar una implementación mas inteligentes sobre un cursor.

ya que un ResultSet no es una clase contenedora. Por lo tanto se encapsuló la información en este conjunto de clases: 50 . Junto con estas implementaciones también se construyeron clases utilitarias para poder representar en memoria los objetos del cursor. loadSize: Establece la cantidad de elementos que se cargan cuando se requiere un elemento que no se encuentra en memoria.Informe de Proyecto de grado Estudio e implementación de Web Services 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() DBCursorImp() DBCursorImp() getId() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close() * 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. sino un apuntador a la base de datos.

ResultSet 6. que cumple con la interface Cursor y sirve como fachada de un CacheCursor.4 Publicación de un Cursor como Web Service El fin principal de este caso de aplicación es realizar la publicación de un cursor mediante Web Services.sql. se implementó la clase WebServicesCursor. También agrega métodos para brindar ráfagas de objetos y así proporcionar soporte para caché en el cliente. La arquitectura se muestra en la siguiente figura: 51 .5.Informe de Proyecto de grado Estudio e implementación de Web Services DataAccess (from api) ResultSetWrapper (from util) DBCursorImp (from cursor) DBCursorImp() DBCursorImp() getId() moreThan() search() next() previous() first() last() beforeFirst() afterLast() absolute() relative() getRow() getObjectAccess() getRecordAccess() getDataAccess() getCursorCapabilities() close() 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. Para esto.

Informe de Proyecto de grado Estudio e implementación de Web Services WebServiceCursor Ráfagas CacheCursor Ráfagas 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 .

soapenc.Informe de Proyecto de grado Estudio e implementación de Web Services Con el fin de poder serializar la clase ResultSetWrapper (que no es un JavaBean. se implementó una clase que realiza la serialización a y desde XML. y por lo tanto no se puede utilizar el org.encoding.BeanSerializer). llamada ResultSetWrapperSerializer Deserializer (from xml) Serializer (from xml) ResultSetWrapperSerializer (from util) ResultSetWrapperSerializer() marshall() unmarshall() getPropertyDescriptors() getWriteMethod() instantiateBean() class$() java.ResultSet ResultSetWrapper (from util) 53 .sql.soap.apache.

El mismo sigue la idea de solicitar al servidor ráfagas de elementos. A continuación se describe la arquitectura mediante un diagrama: Cliente Gráfico Ráfagas WebServiceCursor Ráfagas CacheCursor Ráfagas DBCursor Peticiones simples Base de Datos 54 . mediante un mecanismo de cache del lado del cliente.Informe de Proyecto de grado Estudio e implementación de Web Services 6.5. y mantener una copia de los mismos en el cliente (ráfaga). se implementó un cliente gráfico que recorre un cursor a través de Web Services.5 Implementación de un Cliente Para probar la utilidad de esta tecnología.

A través del mismo se puede crear un cursor a partir de una consulta y recorrer su resultado gráficamente. 55 . Los mismos tienen una lógica similar al cliente para Web Services y fueron construidos para realizar los Benchmarks correspondientes. la cual indica la cantidad de elementos a traer desde el servidor cada vez que se solicita un nuevo elemento.5.Informe de Proyecto de grado Estudio e implementación de Web Services 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) Gráficamente. En el mismo se agrega la noción de “Ráfaga”. 6.6 RMI También fue implementado un cliente RMI y su correspondiente servidor. el resultado puede verse en el siguiente “screenshot”.

implementando varios JavaBeans. se siguió el patrón ValueObjects.5.7 Objetos de Intercambio (ValueObjects) Para realizar el intercambio de información entre los distintos componentes del sistema. 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 .Informe de Proyecto de grado Estudio e implementación de Web Services 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.

1. RAM.1.4.1 Transacciones 7. tarjeta de red 10 Mb   Software : W2000. Apache Soap 2. En cada caso primero se menciona el objetivo del estudio.3 Ejecución y Presentación de los resultados Para la ejecución se trabajó con un paquete de 88 Kb. uno para el caso de transacciones. tarjeta de red 10 Mb. 7. tales como la encriptación del canal (SSL [11]) y el firmado digital de los paquetes SOAP. RAM. 256 Mb. 7. Nota : Las pruebas se realizaron en condiciones de tráfico relativamente bajo y todos los servidores dedicados para estas pruebas. variando los niveles de seguridad y otro sobre la performance de cursores frente a otra tecnología. Los aspectos a considerar están referidos al costo que tienen en la performance los requisitos de seguridad. JRE 1.1. modem 56 Kb. Este tamaño de paquete se considera un ejemplo válido de una transacción de 57 . como por ejemplo distintas redes o una variada granularidad en la información solicitada.6 Kb. se detallan los pormenores de la ejecución y por último se enumeran los resultados asociados a cada caso.1.1 Objetivo Este Benchmark tiene como objetivo medir el desempeño del prototipo implementado para el caso de aplicación de las transacciones descrito en el punto 6.Informe de Proyecto de grado Estudio e implementación de Web Services 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.   Escenario Software : W98.2 Cliente Hardware : Pentium II. Internet : las pruebas se realizaron con una conexión a 33. 7. estudiados sobre distintas redes (LAN e Internet).3. Presentaremos dos diferentes benchmarks. 64 Mb.2   LAN : cliente y servidor conectados a un Switch 100 Mb. Apache Soap 2. luego se presenta el escenario en el que fueron realizadas las pruebas. sin tomar en cuenta el overhead del mensaje SOAP y el HTTP.3.2   Servidor Hardware : Pentium IV. JRE 1.2. Tomcat 3.

Informe de Proyecto de grado

Estudio e implementación de Web Services

mediana complejidad. Las consultas se realizan en un formato de tiempo "no think" (sin pensar) donde los pedidos se realizan continuamente. Esto representa una situación irreal, por lo que cada flujo de consultas representa la carga de trabajo de una gran cantidad de usuarios simultáneos en el mundo real. En este punto se probaron los siguientes 8 casos. Se realizaron 5 consultas por caso, tomándose el promedio como valor representativo, por mas detalles ver Apendice - Resultados Benchmark.xls Transporte Tecnología Tamaño 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 Duración (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 duración total de la transacción 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), prácticamente despreciable. Desde otro punto de vista, puede verse que la encriptación 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 tecnología 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 continuación se presenta una tabla de [26] que ilustra el overhead de utilizar RMI:

Para realizar el estudio, se definieron cuatro dimensiones que representan las características mas 58

Informe de Proyecto de grado

Estudio e implementación de Web Services

interesantes a comparar: Tecnología: Java RMI contra Web Services. Red: Internet contra LAN. Tamaño de los paquetes: Se evaluaron distintos tamaños de las respuestas. Tamaño de la ráfaga: 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 conexión a 33.6 Kb. Nota : Las pruebas se realizaron en condiciones de tráfico relativamente bajo y todos los servidores dedicados para estas pruebas. 7.2.3 Ejecución

En este punto se probó los siguientes 12 casos : Para la ejecución se trabajó con 3 tamaños distintos de registros : Pequeños : tuplas de aproximadamente 56 bytes.
     

Medianos : tuplas de aproximadamente 336 bytes. Grandes : tuplas de aproximadamente 616 bytes.

59

Informe de Proyecto de grado

Estudio e implementación de Web Services

Las consultas se realizan en un formato de tiempo "no think" (sin pensar) donde los pedidos se realizan continuamente. Esto representa una situación irreal, por lo que cada flujo de consultas representa la carga de trabajo de una gran cantidad de usuarios simultáneos en el mundo real. Para el caso de presentación de los datos se agruparan por tablas para ráfagas de tamaño 1 a 200 en intervalos de 20. Transporte Lan Tecnología Web Services RMI Internet Web Services RMI Tamaño Dato Pequeños Medianos Grandes Pequeños Medianos Grandes Pequeños Medianos Grandes Pequeños 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

Presentación de los Resultados

Las tablas con los valores obtenidos de las pruebas realizadas se encuentran en el Apéndice Resultados Benchmark.xls A continuación se presentan algunas gráficas, resaltando los aspectos más significativos de las pruebas.

60

Tecnología para el caso de una red local (LAN) Tamaño de ráfaga/Tamaño de mensaje. Tecnología para el caso de Internet 61 .Informe de Proyecto de grado Estudio e implementación de Web Services Tamaño de ráfaga/Tamaño de mensaje.

en donde ha sido ocultado este valor. Tecnología para el caso de Internet. Tamaño de ráfaga/Tamaño de mensaje. Tecnología para el caso de una red local (LAN) Tamaño de ráfaga/Tamaño de mensaje. 62 . se presentan gráficas de los mismos casos.Informe de Proyecto de grado Estudio e implementación de Web Services Ya que el caso de tamaño de paquete = 1 marca una gran diferencia.

Prácticamente todas las grandes empresas de software están incorporando a sus productos el concepto de interactuar a través de Web Services. el número de implementaciones. Asimismo. Mediante SSL se consiguió alcanzar el nivel estándar de seguridad en cuanto a la confidencialidad de la transmisión.1. consiste en que ciertos aspectos de los Web Services que todavía no han sido estandarizados. 8. la cual consiste en permitir la interoperabilidad de sistemas heterogéneos en forma transparente. sin embargo. Por último. estaría en contra de una de las principales característica de los Web Services. La implementación de utilitarios que permiten verificar la 63 .1 Sobre la tecnología Es evidente la fuerza que han tomado los Web Services en la industria.2 Sobre la aplicación a estos casos Algo que se hizo evidente a poco de empezar este proyecto. toolkits y frameworks de desarrollo disponibles está creciendo en forma acelerada. 8. WSDL y UDDI permiten convertir las aplicaciones corporativas en Web Services y así conseguir un alto nivel de interoperabilidad entre ellas. Un detalle a destacar. lo que restringe fuertemente el tipo de clases que pueden ser publicadas en forma automática como Web Services con esta herramienta) y la documentación en muchas casos es escasa o nula (por ejemplo el Apache SOAP 2. lo que permite suponer que el número de desarrolladores que se vuelque a trabajar con Web Services también crezca rápidamente.1 Transacciones Una conclusión importante sobre este caso radica en que fue posible implementar en forma exitosa un soporte para transacciones electrónicas basado en Web Services. 8. Por último. que incluye un generador de archivos WSDL.2. están siendo resueltos por las implementaciones. conclusiones sobre las alternativas posibles. y no ilustran problemas complejos. se mencionarán posibles trabajos a desarrollar como continuaciones de este proyecto. La mayoría tiene un número reducido de funcionalidades (por ejemplo. Si bien este problema es común en las aplicaciones de hoy en día.2. a través del manejo de tickets se evita la posibilidad de que mensajes duplicados sean procesados como mensajes válidos.Informe de Proyecto de grado Estudio e implementación de Web Services 8 Conclusiones Las conclusiones de este proyecto se dividirán en cuatro secciones: conclusiones sobre la tecnología y su estado actual. Un claro ejemplo se brindará en el punto 8. Incorporando la firma digital se obtuvieron garantías de integridad y no repudio tanto para el servidor como para el cliente. Las demos y ejemplos que acompañan al software normalmente son básicas.1 o la IBM SOAPEnvelopeApi). al tratar el tema de los Web Services stateful. es la falta de madurez de las herramientas disponibles. SOAP.2. El uso de estándares y protocolos abiertos tales como HTTP. el IBM WSTK 3. XML. cuando éste aparezca) y a un bajo nivel de interoperabilidad entre sistemas basados en implementaciones de distinto origen. sólo permite generarlos a partir de un JavaBean que utilice tipos básicos. Esto puede llevar a problemas de mantenimiento (será necesario adaptar el código existente al estándar. conclusiones sobre el trabajo realizado para cumplir con los casos de aplicación y conclusiones sobre el futuro de los Web Services. y que puede generalizarse al estado actual de la tecnología de Web Services.

fue posible implementar el mecanismo de recorrido de cursores mediante Web Services.1. por lo cual puede llegar a ser innecesario el uso de SSL y de esta manera mejorar de 2. tomando como base la duración de una transacción de paquetes sin firmar y sin SSL. Como era de esperar. Esto significa además que cumplir con los requisitos máximos de seguridad ocasionan una caída significativa en la performance del sistema (casi dos veces y media mas lento). se observa un incremento de 1.Informe de Proyecto de grado Estudio e implementación de Web Services firma digital a posteriori cierra el circulo en cuanto a asegurar la intencionalidad de la transacción. De esto puede concluirse que la diferencia entre el firmar o no firmar un paquete es mínima y no incidirá en la performance del sistema.01 para el caso de una transmisión sobre SSL. Para el caso de la LAN. todavía no lo es aplicada a SOAP. de 1. y no los paquetes que puedan generarse para el llenado del formulario). En el caso de Internet y tomando nuevamente el tiempo en procesar una transacción basada en un paquete sin firmar y sin SSL. es necesario realizar programación del lado del cliente. En este caso el costo de utilizar SSL afecta notoriamente la performance (casi cuatro veces y media mas lento) pero por tratarse de una conexión sobre Internet (un medio no seguro) es prácticamente imprescindible su utilización. Por ejemplo. Esto plantea una contradicción con la filosofía de los Web Services. la cual propone su invocación como un simple RPC. Para el mantenimiento de los tickets. ya que tanto la clase que publica los métodos del Web Services como la clase que maneja el cache del lado del cliente implementan la interface Cursor. Si se flexibilizan algunos requerimientos (que el cliente elija el timestamp. También se observa que el firmado del paquete afecta en 1.8 la perdida de performance del sistema. si bien se apega al estado actual de la especificación. altos niveles de seguridad afectan en forma negativa a la performance del sistema.64 para paquetes sin firmar y con SSL y de 2. el estado de la especificación de ésta para SOAP es de NOTE [27] por lo que no puede asegurarse que la implementación actual termine cumpliendo el estándar.41 para paquetes firmados y sobre SSL. Las conclusiones extraíbles a partir de los resultados expuestos en el punto 7. que pueda realizar una transacción sin el consentimiento del servidor y que el recipient se indique como un parámetro más) no es necesario el mantenimiento de tickets. Sin embargo para algunas LAN es posible pensar en alternativas de seguridad a otros niveles. Por lo tanto una recomendación que surge de esto consiste en evitar el firmado de paquetes no “sensibles” (por ejemplo. Un aspecto problemático del estado actual de la tecnología consiste en que las implementaciones avanzan más rápido que los estándares. El diseño escogido permite utilizar el cursor basado en Web Services como cualquier otro cursor.2 Cursores Al igual que en el caso de las transacciones.2. sobre LAN y sobre Internet. se observa un incremento de 1. Cabe señalar un aspecto del estado del arte en este campo: Si bien la firma digital de XML es estándar.06 para el caso de paquete firmado sin SSL.37 para paquetes firmados y sobre SSL. 8. programación que debe ser repetida para cada cliente o lenguaje que consuma el Web Service. Los tickets sirven para que el servidor indique cual transacción acepta (con el sequence number) y cuando se realizó (con el timestamp). considerando la transacción como un formulario.8 para el caso de paquete firmado sin SSL.41 a 1. Para esto se 64 .3 pueden dividirse en dos grupos fundamentales.42 para paquetes sin firmar y con SSL y de 4. se detectó un tema delicado al tener que resolver el problema del mantenimiento de las sesiones. Tanto el timestamp como el sequence number son válidos para evitar los paquetes duplicados. para utilizar Web Services stateful. de 4. firmar sólo el “submit” de la transacción. tales como la restricción de acceso físico a las líneas de transmisión.

[29]) resuelven este problema también de forma propietaria. A continuación se muestra la variación de la relación entre Web Services y RMI. lo que corresponde a una mejora de mas del 55%.Informe de Proyecto de grado Estudio e implementación de Web Services estudiaron dos posibles soluciones. Esto implica que si se desea acceder a ese servicio desde clientes implementados en lenguajes distintos. Estas alternativas se contraponen a algunas de las bases del modelo de los Web Services.4 y 4.2. La solución adoptada (utilizar el mecanismo de mantenimiento de sesión provisto por la implementación de SOAP) no forma parte de la especificación actual. Se observa una pérdida de performance de 4.2 veces mas lento para el caso Internet. es necesario reprogramar la lógica de cacheo en cada lenguaje. lo cual va contra el modelo.1.4 y 84. ya que si bien no alcanza a ser tan performante como RMI. si bien se mantiene una mayor interoperabilidad. dejando como principal argumento favorable el apoyo en la interoperabilidad del sistema. pérdida que disminuye a menos de 1. ya que presenta una solución que apoya la interoperabilidad con un costo en la performance en muchos casos aceptable. Esto. Considerando el caso en que no fue necesario modificar la interface Cursor (o sea. y de hecho otras implementaciones ([28].23 veces si se utilizan ráfagas de tamaño 1. la alternativa de los Web Services es muy razonable. Asimismo. implica que se deba reprogramar la lógica de cacheo para cada cliente o lenguaje que consuma el Web Service. detalladas en el punto 5. a medida que se aumenta el tamaño de la ráfaga de datos: En el caso Internet. o utilizar clientes propietarios. unido a que en este contexto la presencia de firewalls es extremadamente frecuente. para obtener una performance “aceptable”. De esto puede concluirse que la diferencia de rendimiento prácticamente descarta la alternativa basada en Web Services para el caso LAN. las diferencias son menos dramáticas. Como puede apreciarse en el estudio de Benchmarks.09 veces mas lento a 8.74 veces mas lento para el caso LAN. y entre 4. la información es transmitida en ráfagas de tamaño 1) el sistema se comportó entre 118. Otro ítem a tener en cuenta es el relacionado con la optimización de la performance. 65 . fue necesario establecer un mecanismo de solicitud por ráfagas e implementar lógica de cacheo del lado del cliente. una de las características 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. De esta forma. mejora la pérdida de performance en mas de un 90% (Web Services pasa de ser 99.6 veces) para ráfagas de mas de 100 elementos. Una observación inmediata y esperable a partir de los Benchmarks consiste en que los Web Services presentan actualmente una performance muy baja con relación a una alternativa propietaria como RMI. La alternativa propuesta (modificar la interface Cursor para que soporte pedidos en ráfagas e implementar lógica de cacheo en el cliente) brinda una solución intermedia. si bien RMI continúa siendo mas performante que los Web Services. Esto puede traer problemas de mantenimiento e interoperabilidad.8 veces si se consideran ráfagas de mas de 100 elementos.

con requisitos similares al caso de cursores. Puede verse que ante un aumento del tamaño de los datos transmitidos (ya sea por un incremento en el tamaño de la ráfaga o por un incremento en el tamaño de los paquetes) la velocidad de transmisión aumenta. In 66 . lo cual era esperable. y por otro RMI es una alternativa cerrada. Otra conclusión que surge del análisis de los benchmarks corresponde a la relación entre el tamaño de los datos intercambiados y el tiempo empleado en transmitirlos. para LAN e Internet. aunque por lo ya expuesto. y los Web Services pueden interactuar directamente con la capa de negocios o con la capa RMI. sólo es posible acceder a la capa de Web Services. te rn et WEB SERVI CES LA N RMI Capa de Negocios La capa de negocios es publicada en la LAN a través de RMI. tanto para el caso Web Services como para el caso RMI. que requiere de configuraciones especiales en los firewalls para comunicarse a través de Internet. Cabe destacar que los Web Services son utilizables también a través de la LAN. La siguiente figura propone una arquitectura que ejemplifica estos conceptos. la interface con la capa de negocios no debería basarse exclusivamente en una de las dos tecnologías. Por un lado. Desde Internet.Informe de Proyecto de grado Estudio e implementación de Web Services A modo de resumen. los Web Services presentan serios problemas de performance en ambientes LAN. no se aconseja. A continuación se presentan las gráficas de velocidades en función del tamaño de la ráfaga. puede concluirse que para un sistema que tenga como escenarios de interacción tanto Internet como LAN.

50 3.00 1 20 40 60 80 100 120 140 160 180 200 0.00 0.00 400000.00 200000.00 2. Por ejemplo.00 80.00 0. supóngase el caso de una aplicación GUI que maneja un combo para 67 .00 bytes/seg bytes/seg Chicos 6000.00 1 20 40 60 80 100 T a ma ñ o R á f a g a 0.00 8000. sino en ráfagas) constituye una alternativa efectiva.00 1 20 40 60 80 100 Tamaño Ráfag a 120 140 160 180 200 0.00 3.00 5.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. en donde la diferencia de velocidades se reduce a valores entre 2 y 1.00 G randes 2000.50 Chic os Medianos Gr andes 40.50 0.00 0.00 Medianos Grandes 3000.00 600000.00 1. para ráfagas mayores a 140 valores.00 70000. o en caso de hacerlo.00 500000.Informe de Proyecto de grado Estudio e implementación de Web Services Velocidad Web Ser vices (Internet) 8000.00 20000.6.00 30000.00 Velocidad Web Services (LAN) 7000.00 100000.00 5000.00 Velocidad RMI (LAN) 10000.50 120.00 6000. como se presenta en las siguientes gráficas.00 4. puede observarse que para el caso LAN.50 1.00 50000.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. Relación entre v elocidades (LAN) Relación entre v elocidades (Internet) 140.00 Medianos Grandes 4000. Esto demuestra que la solución propuesta (no traer datos en forma unitaria. traerlos junto con datos asociados o que tengan una alta probabilidad de ser requeridos a continuación.00 Chicos Medianos Grandes 1000.00 60000.00 700000.00 Chicos Medianos 300000. el utilizar ráfagas disminuye la diferencia entre las velocidades.00 1 20 40 60 80 100 T amañ o Ráfaga 120 140 160 180 200 Analizando la variación de la velocidad de una tecnología contra la otra.00 2000.00 Chicos Medianos Gr andes 60. llevándolas a valores entre 16-14 y 8-7.00 4.00 40000.00 10000.00 2. una buena estrategia a seguir consiste en no realizar pequeños pedidos de datos.00 Chicos 4000. Para el caso Internet se da un fenómeno similar.00 100.00 20.

y luego. 8. 68 . etc. Un detalle a mencionar es que debido a la falta de estándares en aspectos antes mencionados (por ejemplo en el caso stateful). debido en muchos casos a conflictos entre versiones y a una documentación pobre en tamaño y calidad.NET). y otro combo que le permite seleccionar localidades en función del departamento. Una mejor solución consiste en solicitar las localidades junto con los departamentos. la utilización del IBM XML Security Suite [16] se basó en que fue la que presentó menos problemas de instalación y configuración. y ya que para muchos casos el tiempo de realizar la transacción no es crítico (por ejemplo en el caso de ejecutar un formulario el usuario pasa la mayor parte del tiempo llenándolo. para que de esta manera se genere un único pedido de mayor tamaño.3 Sobre la alternativa utilizada El software base a utilizar (Tomcat. se plantean las siguientes recomendaciones en función de las posibles aplicaciones de esta tecnología: para el caso de las transacciones. Por último. o no respetando estrictamente el protocolo SOAP. Apache SOAP.Informe de Proyecto de grado Estudio e implementación de Web Services permitirle al usuario seleccionar departamentos. Durante la elección de la herramienta a utilizar para la generación de firmas digitales en XML. y se desea que los combos sean cargados a partir de Web Services. lo que posiblemente lleve a una baja performance. los Web Services no son aplicables en su forma básica. como el caso del cacheo antes mencionado. en el caso de un protocolo de interacción “fina” con el usuario). Esta estrategia plantea muchos pedidos de pequeño tamaño. Claramente. y prácticamente imposible acceder desde clientes basados en otra plataforma (por ejemplo . cada vez que se cambie de departamento. se invoque a un Web Services para cargar las localidades del nuevo departamento seleccionado. Xerces. es compleja su utilización sin los utilitarios provistos del lado del cliente. Sobre los cursores pueden diferenciarse dos casos: uno en donde los pedidos sean de gran tamaño 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 pequeños y es necesario una rápida respuesta (por ejemplo. 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. open source y basado en el lenguaje Java. Se puede mejorar la performance de los Web Services con alternativas que se alejen del modelo. El mayor problema radica en que todavía no están completamente definidos algunos estándares sobre el tema. se consultaron y evaluaron algunas de las implementaciones listadas en [22].2. Como se menciona en la sección 6. se demostró que es posible su utilización bajo todas las garantías requeridas.4. Para el primer caso. aunque fue problemática la configuración e instalación de los mismos. además de cumplir el requerimiento de funcionar sobre la plataforma Java. es viable una solución basada en Web Services. Otra conclusión que se puede obtener de esto es que para aplicaciones en donde el rendimiento es crítico. el encoding style de SOAP establece que cada propiedad de un objeto se mapee con un elemento XML. tampoco es recomendable llevar está práctica al extremo. 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. Una posible estrategia radica en utilizar un Web Services para cargar el combo de departamentos. Por ejemplo.) surgió naturalmente a partir de los requerimientos de la empresa Ideasoft: software libre. De la utilización de estas herramientas se puede concluir que la implementación de los objetivos es factible. mientras que en el otro es muy difícil que la performance sea aceptable.

y realizar pruebas completas de la ejecución de formularios XForms. una API alternativa open source para el firmado de archivos XML. Un objetivo más ambicioso que el propuesto para este proyecto consiste en la implementación de un framework que permita la publicación de lógica de negocios en forma transparente como Web Services seguros.5 Posibles extensiones al proyecto Mostrar la interoperabilidad del sistema implementando un cliente en un lenguaje diferente a Java. la presencia de los Web Services en la industria es cada vez mas fuerte.5. etc. En la medida que se estandarizen algunos de los aspectos problemáticos antes mencionados. Si bien se demostró la viabilidad de la infraestructura provista y el diseño realizado es independiente de la lógica a publicar. No se utilizó para este proyecto debido a lo expuesto en el punto 4. que promete un mejor desempeño que la implementación de SOAP utilizada en este proyecto. Su finalidad consistiría en que el usuario del framework provea su Web Services e indicando detalles de infraestructura (repositorio de certificados. 69 . los Web Services se convertirán en la base de la integración de sistemas en el futuro. 8.NET         Evaluar otras implementaciones. La base en los estándares de la W3C fomentan la interoperabilidad sin problemas inherentes a implementaciones propietarias.4 Sobre el futuro Como se mencionó. base para el almacenamiento de firmas digitales. las implementaciones brinden una performance aceptable y las herramientas mejoren su calidad. se encuentra disponible (en versión beta) una nueva implementación de SOAP por parte de Apache. Asimismo. llamada Axis. como Delphi o algún lenguaje de la plataforma . En particular la XML Security J de Apache.Informe de Proyecto de grado Estudio e implementación de Web Services 8.) consiga su publicación con los niveles de seguridad conseguidos en este proyecto. un punto interesante consiste en probar su integración con EDF.2. Posiblemente sean la alternativa para comunicar sistemas heterogéneos mas utilizada en el corto y mediano plazo.

Sign up to vote on this title
UsefulNot useful