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

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

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

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

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

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

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

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

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

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

Un framework completo que describa tales reglas debe incluir medios para componer servicios y medios para expresar el comportamiento de los servicios. WSDL es extensible. Provee información de los distintos métodos que el WS brinda. quedando disponible para ser descubierta por otras empresas. Los endpoints concretos relacionados se combinan en endpoints abstractos (servicios).6. 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. Para una especificación completa de WSDL ver Apéndice .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). La composición de servicios debe ser de escritura segura pero también debe permitir pasar referencias. 2.4 WSDL : Web Services Definition Language WSDL es usado para describir servicios Web por parte de las empresas. muestra como accederlos y el formato que deben tener los mensajes. 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. 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. 13 . lo que permite la descripción de endpoints de red y sus mensajes. 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.UDDI.Informe de Proyecto de grado Estudio e implementación de Web Services 2.WSDL.5 UDDI : Universal Description. independientemente de los formatos de los mensajes o protocolos de red utilizados para comunicarse. es decir. 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. Microsoft e IBM. 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.6 Otras tecnologías relacionadas 2.0. de tal forma que los clientes puedan acceder a ellos y utilizarlos. un servicio centralizado y replicado a distintos nodos en forma regular. Es un estándar para registrar y descubrir los WS. La idea es una registración en el registro de empresas UDDI. EbXML antecede a UDDI. Para una especificación del funcionamiento de WSDL con UDDI ver Apéndice – WSDL y UDDI. Para una especificación completa de UDDI ver Apéndice . siendo las referencias del servicio intercambiadas y enlazadas en tiempo de ejecución. reglas de ordenación para enviar y recibir mensajes. 2. Discovery and Integration UDDI es un proyecto propuesto por Ariba.

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

y XML. 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. publicación y discovering de aplicaciones basadas en Web Services que soportan UDDI. SOAP. así como demostraciones de cómo pueden trabajar juntas las tecnologías emergentes estándar. WSDL y UDDI. Por ejemplo. un entorno de desarrollo de alto nivel para Web Services existe: IBM's WebSphere Studio Application Developer permite la creación. Provee ejemplos simples de Web Services. basado en el Internet Information Server y ASP.7. Sin embargo.NET 2. A modo de comentario de la utilización de ésta herramienta se ha comprobado que algunas características básicas son limitadas. construcción. 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. testeo.2 IBM Web Services Toolkit El IBM Web Services ToolKit (WSTK) es un kit de desarrollo de software que incluye un runtime. tales como SOAP. la generación de archivos WSDL sólo es posible a 15 .Informe de Proyecto de grado Estudio e implementación de Web Services La plataforma .NET provee un servidor de Web Services.

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

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

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

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

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

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

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

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

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

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

"+" 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. 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. detallando los requerimientos que satisfacen. Una firma digital se basa en una criptografía de clave pública.1 Firma Digital La firma digital (SOAP-DSIG) define la sintaxis y procedimientos para firmar digitalmente mensajes SOAP y validar su firma. el servidor puede identificar al creador del mensaje. Estos son firmados.1. lo cual constituye una garantía de que la firma es del creador. La clave usada para firmar el mensaje es identificada por el elemento <KeyInfo> la cual garantiza la 26 . La firma digital permite que los mensajes sean autenticados contra un usuario. 5. 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. Esta tecnología ha sido implementada en productos comerciales por IBM. Microsoft y otros.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. El emisor y receptor no necesitan compartir una clave secreta. SOAP-DSIG tiene este propósito.1 Transacciones 5. el cual tiene la siguiente estructura ("?" denota cero o una ocurrencia. Una transacción del tipo comercial requiere del no repudio. el cual es incluido en el header de SOAP. a partir de su firma se genera el elemento <Signature>.

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

El desempeño en función del tamaño de las tuplas a transferir. Por ultimo se apuesta a que esta característica sea parte del estándar en futuras versiones. el sistema se vuelve mas escalable y performante.2 o . Se espera que sea mas performante pues no involucra parseo de XML y el overhead de empaquetado y transporte de datos es menor. 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 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. y manejar en las aplicaciones la administración correspondiente a las sesiones.1 Manejo de sesiones por parte del servidor Los WS son stateless por definición. brindando WS stateful de forma transparente. lo cual no se encuentra dentro de los objetivos de este proyecto. Al permitir que la infraestructura realice el manejo de sesiones. El recorrer los datos solicitándolos de a ráfagas (cache en el cliente).NET Construir aplicaciones cliente/servidor de forma que intercambien un identificador de sesión o similar entre los distintos request. Se eligió RMI por ser una alternativa conocida y se puede utilizar exactamente el mismo código del cursor. En particular se desea comparar : El recorrer los datos solicitándolos de a uno por vez. La performance en una LAN y en Internet 28 . Para resolver este caso. se enuncian al menos dos posibles opciones: Provista por la infraestructura de Web Service: Usar implementaciones propietarias que resuelvan el problema. pues el manejo de sesiones es algo altamente utilizado y básico en aplicaciones no triviales. 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. tales como las provistas por Apache SOAP 2. por lo que el mantener el estado a través de los distintos request es un problema no cubierto por la especificación. En este caso por tratarse de recorrer grandes cantidades de datos este punto es crucial. Benchmarks 5.2.Informe de Proyecto de grado Estudio e implementación de Web Services 5.2. 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.

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 Modelo de trabajo de Apache SOAP sobre Tomcat Apache SOAP provee un manejo básico de visualización. y por último se presentarán las clases implementadas para el manejo de cursores. Para el manejo de las firmas digitales de XML se utilizó el IBM XML Security Suite [16]. Como parser de archivos XML se utilizó el Xerces v. 1. las cuales son: List: Lista los WebServices disponibles.1 Estudio de Plataforma Todas las clases fueron implementadas en el lenguaje Java. La implementación de SOAP utilizada fue el Apache SOAP 2.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.2 [19] y el JavaBeans Activation Framework 1.3. Luego se detallarán las clases implementadas para el caso de las transacciones. 6. [17] y como procesador de XSLT se utilizó el Xalan 2. El acceso al SOAP en Tomcat es a través de .0.1 [20].2 [15]. Para la instalación de estos componentes es necesario un orden predefinido en el classpath.1. Como servidor y contenedor de servlets se utilizó el Jakarta Tomcat versión 3. 29 .2. versión 1. en esto punto se presentan tres acciones posibles a realizar.3 [13]. Por mas detalles de instalación y configuración Apendice – Instalación y Configuración 6. deploy y ejecución de Web Services sobre Tomcat.0 [18]. configurar archivos de Tomcat y del SOAP de apache. Primero se describirá la plataforma y el entorno en el que se realizó el sistema.1 [14].2. También es necesario para el correcto funcionamiento de este producto la instalación del JavaMail 1.

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

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. la instancia y por ultimo ejecuta el método solicitado por el cliente. Busca en la Remote Services Registry la clase asociada al método. 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 (). - - Algunas extensiones al framework de Apache SOAP necesitan la capacidad de interactuar con el 31 . En el servidor Web es recibido este request por parte de un servlet (rpcrouter mapeado a la clase RPCRouterServlet).

Estas son copiadas y almacenadas en el objeto org.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.RPCMessage.rpc. Writer out) throws SOAPException. esa cookie es devuelta al servidor. public void editOutgoing(Reader in. Para facilitar este tipo de interacciones Apache SOAP provee la interface EnvelopeEditor.Informe de Proyecto de grado Estudio e implementación de Web Services mensaje SOAP al momento de recibirlo o enviarlo. 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.apache. Writer out) throws SOAPException.Call usado para invocar el servicio. Para esto. es necesario configurar el cliente de la siguiente manera: 32 . Si otra llamada es realizando usando el mismo objeto Call. manteniendo la sesión.soap. la cual consta de los métodos: public void editIncoming(Reader in.

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

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

4. Las clases implementadas pueden verse en el siguiente diagrama (en fondo claro se encuentran las clases implementadas por terceros. y en fondo oscuro las clases implementadas para este proyecto): 35 .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. 6.internal. mencionados en el punto 6.ssl.net. 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. se debe ingresar el certificado del servidor en el keystore del cliente y el certificado del cliente en el keystore del servidor. Por ultimo y como sustitución al intercambio de certificados del handshake de SSL.addProvider(new com. fue el que presentó menos problemas al realizarle test básicos. Por mas información acerca de las implementaciones disponibles ver [22]. Este producto fue elegido debido que al momento de comenzar el proyecto.Informe de Proyecto de grado Estudio e implementación de Web Services Security.2.1. Al día de hoy se ha ampliado notoriamente la cantidad de opciones posibles.sun.Provider()).ssl.

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

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

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 .

se publicó como Web Service un método que permite realizar la verificación en forma remota. A su vez. implementado en la clase VerifierWS: 39 .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.

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

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

2) para la firma y la verificación. La clase WebServiceTransactionImp.1. Básicamente.1. 42 .5. y brinda la implementación para los métodos publicados como Web Services. En la ejecución de la transacción participan los EnvelopeEditors (descritos en la sección 6. siguiendo la idea del patrón Facade [23]. tal como se menciona en el punto 6. 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). que implementa la interfaces WebServiceTransaction encapsula la lógica de la ejecución de la transacción.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.

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 .

Comunmente se utiliza el formato urn:UniqueServiceID 44 .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.

dicho objeto maneja los siguientes datos: transactionOk: Status de la ejecución del Web Service. ver [24]. El resultado de la transacción es representado por el objeto TransactionResult. 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 . 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. 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. 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. 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. se crea una instancia del objeto. Existen principalmente tres valores posibles: Request: Por cada request. Para una mejor descripción de todos los campos relacionados con el deploy.

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.Informe de Proyecto de grado Estudio e implementación de Web Services 6. 6. Ante cualquiera de éstos errores se lanza una SOAPException. con el código y el mensaje correspondientes.4. Recipient no válido: Se intentó ejecutar la transacción en un recipient distinto al indicado. estos son errores de ejecución (descriptos anteriormente) y errores de seguridad. se siguió el patrón ValueObjects. 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 .4. implementando varios JavaBeans.5 Objetos de Intercambio (ValueObjects) Para realizar el intercambio de información entre los distintos componentes del sistema.4 Tratamiento de Errores Básicamente se distinguen dos clases de errores.

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

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. diseñado para acceder a una base de datos mediante JDBC. La clase DBCursorFactoryImp recibe un DBCursorSpecImp que contiene la consulta a la base de datos.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.2 Implementación Básica de un Cursor Se realizó una implementación concreta de un cursor. 48 . y devuelve una instancia de la clase DBCursorImp que puede ser utilizada para recorrer el resultado de la consulta.par2:int):BigDecimal +getBytes(par1:String):byte[] +getDate(par1:String):Date +getTimestamp(par1:String):Timestamp +getTime(par1:String):Time +getMetaData():ResultSetMetaData +getObject(par1:int):Object +getObject(par1:String):Object +findColumn(par1:String):int +getBigDecimal(par1:int):BigDecimal +getBigDecimal(par1:String):BigDecimal interface ObjectAccess +getObject():Object +getRow():int interface RecordAccess +getRecord():Record +getRow():int interface Record +getFieldsCount():int +getFieldAsString(fieldName:String):String +getField(fieldName:String):Object 6.5.

se penso en un cursor con cacheo. El mismo implementa la idea básica de un cache. pidiendo de a ráfagas los objetos a un cursor básico y almacenando una copia de los últimos.5. 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.3 Implementación de un Cursor con Caché Para realizar una implementación mas inteligentes sobre 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 .

loadSize: Establece la cantidad de elementos que se cargan cuando se requiere un elemento que no se encuentra en memoria. 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. sino un apuntador a la base de datos.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. ya que un ResultSet no es una clase contenedora.

La arquitectura se muestra en la siguiente figura: 51 .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.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. que cumple con la interface Cursor y sirve como fachada de un CacheCursor. se implementó la clase WebServicesCursor.sql.ResultSet 6. También agrega métodos para brindar ráfagas de objetos y así proporcionar soporte para caché en el cliente.5. 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 .

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.soapenc. se implementó una clase que realiza la serialización a y desde XML. y por lo tanto no se puede utilizar el org. llamada ResultSetWrapperSerializer Deserializer (from xml) Serializer (from xml) ResultSetWrapperSerializer (from util) ResultSetWrapperSerializer() marshall() unmarshall() getPropertyDescriptors() getWriteMethod() instantiateBean() class$() java.apache.encoding.soap.ResultSet ResultSetWrapper (from util) 53 .sql.BeanSerializer).

El mismo sigue la idea de solicitar al servidor ráfagas de elementos.5 Implementación de un Cliente Para probar la utilidad de esta tecnología.5. y mantener una copia de los mismos en el cliente (ráfaga). 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. se implementó un cliente gráfico que recorre un cursor a través de Web Services.

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

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.5. implementando varios JavaBeans. actuando como contenedores de datos.7 Objetos de Intercambio (ValueObjects) Para realizar el intercambio de información entre los distintos componentes del sistema. 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 . se siguió el patrón ValueObjects.

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

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

Informe de Proyecto de grado Estudio e implementación de Web Services 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. Tecnología para el caso de Internet 61 .

Tecnología para el caso de una red local (LAN) Tamaño de ráfaga/Tamaño de mensaje.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. en donde ha sido ocultado este valor. se presentan gráficas de los mismos casos. Tecnología para el caso de Internet. 62 . Tamaño de ráfaga/Tamaño de mensaje.

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

Por lo tanto una recomendación que surge de esto consiste en evitar el firmado de paquetes no “sensibles” (por ejemplo. de 4.42 para paquetes sin firmar y con SSL y de 4.1. si bien se apega al estado actual de la especificación.41 a 1. 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). 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.8 para el caso de paquete firmado sin SSL. altos niveles de seguridad afectan en forma negativa a la performance del sistema.8 la perdida de performance del sistema. de 1. es necesario realizar programación del lado del cliente. Los tickets sirven para que el servidor indique cual transacción acepta (con el sequence number) y cuando se realizó (con el timestamp). Como era de esperar. firmar sólo el “submit” de la transacción. Para el caso de la LAN.64 para paquetes sin firmar y con SSL y de 2. En el caso de Internet y tomando nuevamente el tiempo en procesar una transacción basada en un paquete sin firmar y sin SSL. programación que debe ser repetida para cada cliente o lenguaje que consuma el Web Service. la cual propone su invocación como un simple RPC. Las conclusiones extraíbles a partir de los resultados expuestos en el punto 7.3 pueden dividirse en dos grupos fundamentales. se observa un incremento de 1.2 Cursores Al igual que en el caso de las transacciones. tales como la restricción de acceso físico a las líneas de transmisión. se detectó un tema delicado al tener que resolver el problema del mantenimiento de las sesiones. Para esto se 64 . 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. 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. Esto plantea una contradicción con la filosofía de los Web Services. Si se flexibilizan algunos requerimientos (que el cliente elija el timestamp. Tanto el timestamp como el sequence number son válidos para evitar los paquetes duplicados. todavía no lo es aplicada a SOAP. 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. 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.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. fue posible implementar el mecanismo de recorrido de cursores mediante Web Services. Sin embargo para algunas LAN es posible pensar en alternativas de seguridad a otros niveles. considerando la transacción como un formulario. Para el mantenimiento de los tickets. por lo cual puede llegar a ser innecesario el uso de SSL y de esta manera mejorar de 2. se observa un incremento de 1. tomando como base la duración de una transacción de paquetes sin firmar y sin SSL.37 para paquetes firmados y sobre SSL. 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.41 para paquetes firmados y sobre SSL. 8. Por ejemplo. y no los paquetes que puedan generarse para el llenado del formulario). También se observa que el firmado del paquete afecta en 1. para utilizar Web Services stateful.2. 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.01 para el caso de una transmisión sobre SSL. sobre LAN y sobre Internet.

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

y los Web Services pueden interactuar directamente con la capa de negocios o con la capa RMI. 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. con requisitos similares al caso de cursores. los Web Services presentan serios problemas de performance en ambientes LAN. la interface con la capa de negocios no debería basarse exclusivamente en una de las dos tecnologías. 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. 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. que requiere de configuraciones especiales en los firewalls para comunicarse a través de Internet. puede concluirse que para un sistema que tenga como escenarios de interacción tanto Internet como LAN. Por un lado. y por otro RMI es una alternativa cerrada.Informe de Proyecto de grado Estudio e implementación de Web Services A modo de resumen. lo cual era esperable. no se aconseja. In 66 . para LAN e Internet. aunque por lo ya expuesto. tanto para el caso Web Services como para el caso RMI. La siguiente figura propone una arquitectura que ejemplifica estos conceptos. Cabe destacar que los Web Services son utilizables también a través de la LAN. Desde Internet. sólo es posible acceder a la capa de Web Services. A continuación se presentan las gráficas de velocidades en función del tamaño de la ráfaga.

00 0. supóngase el caso de una aplicación GUI que maneja un combo para 67 .00 2. Por ejemplo.50 0.00 20000.6.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.00 G randes 2000.00 70000.00 bytes/seg bytes/seg Chicos 6000.00 200000.00 1 20 40 60 80 100 T a ma ñ o R á f a g a 0.00 Medianos Grandes 4000. una buena estrategia a seguir consiste en no realizar pequeños pedidos de datos. llevándolas a valores entre 16-14 y 8-7.00 50000.00 60000. sino en ráfagas) constituye una alternativa efectiva.00 Chicos Medianos 300000.00 4.Informe de Proyecto de grado Estudio e implementación de Web Services Velocidad Web Ser vices (Internet) 8000.00 5.00 3.00 Chicos Medianos Gr andes 60.00 0.00 6000.00 20. el utilizar ráfagas disminuye la diferencia entre las velocidades. para ráfagas mayores a 140 valores. traerlos junto con datos asociados o que tengan una alta probabilidad de ser requeridos a continuación. Esto demuestra que la solución propuesta (no traer datos en forma unitaria.00 5000.00 4.00 1 20 40 60 80 100 Tamaño Ráfag a 120 140 160 180 200 0. puede observarse que para el caso LAN.50 Chic os Medianos Gr andes 40.50 1.00 0.00 400000.00 40000.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 1 20 40 60 80 100 120 140 160 180 200 0.50 3.00 30000.00 8000.00 2000.00 100. Para el caso Internet se da un fenómeno similar.00 Chicos Medianos Grandes 1000.00 Chicos 4000.00 2.00 10000.00 100000.00 Velocidad RMI (LAN) 10000. Relación entre v elocidades (LAN) Relación entre v elocidades (Internet) 140. o en caso de hacerlo.00 600000.00 Medianos Grandes 3000. como se presenta en las siguientes gráficas.00 80.00 1.00 500000.00 700000.50 120. en donde la diferencia de velocidades se reduce a valores entre 2 y 1.00 1 20 40 60 80 100 120 140 160 180 200 Ta ma ño R á f a g a Ta ma ñ o R á f a g a Velocidad RMI (Internet) 12000.00 Velocidad Web Services (LAN) 7000.

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

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

Sign up to vote on this title
UsefulNot useful