introducción a los web services148.206.53.84/tesiuami/uami11732.pdf · • la arquitectura...

Unidad: Iztapalapa División: CBI Grado: Licenciatura en Ingeniería Electrónica Área de Concentración: Computación Título del Trabajo: Introducción a los Web Services Nombre: Miguel Cadena Chárraga (matrícula: 91320546) Asesora: Dra. Elizabeth Pérez Cortés

México, D.F., a 07 de Diciembre de 2004

Introducción a los Web Services

Miguel Cadena Chárraga Página 1 12/10/2004

Índice

Tema Página Convención Tipográfica 3Introducción 41. ¿Qué son los Web Services? 71.1 Fortalezas de los Web Services 81.2 ¿Quién está adoptando los Web Services? 82. La W3C 92.1 ¿Quién conforma a la W3C? 92.2 Actividades de la W3C 103. La Actividad de Web Services 123.1 Grupos de Trabajo 123.1.1 Web Services Architecture Working Group 123.1.2 XML Protocol Working Group 123.1.3 Web Services Description Working Group 133.1.4 Web Services Choreography Working Group 133.2 Grupo de Interés 133.2.1 Semantic Web Services Interest Group 133.3 Grupo de Coordinación 133.3.1 Web Services Coordination Group 134. La Arquitectura de Web Services 144.1 Agentes y Servicios 144.2 Solicitantes y Proveedores 144.3 Descripción del Servicio 154.4 Semántica 154.5 Utilizando Web Services 154.5.1 Las entidades se conocen 164.5.2 Acuerdo sobre la descripción del servicio y semántica 174.5.3 Implementación de la descripción del servicio y semántica 174.5.4 Intercambio de mensajes 185. Ejemplo Teórico: Agente de Viajes, búsqueda dinámica de servicios 195.1 Descripción 195.2 Alcance 205.3 Accionistas / Intereses 205.4 Actores / Objetivos 205.5 Escenarios de Uso 215.6 El usuario solicita disponibilidades de fechas de viaje 215.7 El usuario escoge un vuelo y busca hoteles 225.8 El usuario paga la habitación de hotel y el vuelo 235.9 Notas sobre el escenario 246. Protocolos No Propietarios: SOAP, WSDL y UDDI 266.1 SOAP 1.2 (Simple Object Access Protocol) 266.1.1 Estructura de un Mensaje SOAP 276.2 WSDL 1.2 (Web Services Description Language) 286.2.1 definitions 286.2.2 types 286.2.3 message 286.2.4 portType 28



Tema Página 6.2.5 binding 286.2.6 service 296.3 UDDI 2 (Universal Description, Discovery and Integration) 296.3.1 BusinessEntity 306.3.2 BusinessService 306.3.3 BindingTemplate 306.3.4 TModel 306.4 Implementaciones Abiertas y Comerciales de SOAP, WSDL y UDDI 326.4.1 Implementaciones Abiertas 326.4.2 Implementaciones Comerciales 327. Ejemplo Práctico: WorldTime 337.1 Objetivo 337.2 Entidades Participantes 337.2.1 Entidad Solicitante 337.2.2 Agente Solicitante 337.2.3 Entidad Proveedor 337.2.4 Agente Proveedor 337.3 Caso de Uso del ejemplo WorldTime 337.4 Explicación de los Cuatro Pasos Utilizados en la Invocación del Web

Service Ejemplo 34

7.4.1 Las entidades se conocen 347.4.2 Acuerdo sobre la descripción del servicio y semántica 347.4.3 Implementación de la descripción del servicio y semántica 347.4.4 Intercambio de mensajes 397.5 Ejecución de la aplicación ejemplo 407.5.1 Intercambio conversacional de mensajes, implementado bajo un

patrón de solicitud y respuesta 40

8. Conclusiones 48Anexo A1 – Instalación/Configuración del ejemplo práctico WorldTime 50A1.1 Código fuente del ejemplo 50A1.2 Requisitos de Software Locales (Windows o Linux) 51A1.3 Pasos para Instalar/Configurar el ejemplo 51Anexo A2 – Glosario 54A2.1 HTTP (Hypertext Transfer Protocol) 54A2.2 HTML (HyperText Markup Language) 54A2.3 XML (eXtensible Markup Language) 54A2.4 XML Schema 55A2.5 Lenguaje de programación Java 55Bibliografía 56



Convención Tipográfica A continuación se enlista la convención tipográfica utilizada en el contenido de este documento:

Tipo de fuente Utilización Itálica Énfasis, títulos, y primera ocurrencia de términos. Courier New Código fuente Courier New Itálica Nombres de etiquetas, clases, métodos, argumentos,

operaciones, archivos, directorios y menús Courier New subrayada URLs (Uniform Resource Locators)



Introducción Un Web Service es una técnica innovadora de cómo implementar aplicaciones que definen interfaces para comunicarse entre si por medio de la Internet, bajo una arquitectura orientada a servicios[1]. La iniciativa formal para definir los Web Services comienza a principios del año 2002[7]. Previo a esta fecha, un problema recurrente aún existente es la interoperabilidad entre aplicaciones. Esto significa que un Web Service representa una arquitectura diferente a las formas tradicionales de diseñar las aplicaciones. Particularmente se resuelven dos problemas típicos, a saber:

• La comunicación se realiza mediante mensajes de texto, transportados por un protocolo público (no propietario). Es decir, ahora la comunicación se libera de la dependencia de la plataforma y lenguaje de programación de las aplicaciones que se comunican. En otras palabras, ahora se trata de comunicaciones no binarias, sino de información en texto; cuya codificación es estándar en cualquier lenguaje y plataforma.

• La arquitectura orientada a servicios propone que las aplicaciones sean

conformadas por entidades que proveen servicios definidos a través de interfases definidas. Por ejemplo, un servicio en Internet que permite comprar boletos para un cine, requiere de utilizar a su vez diferentes servicios en un orden específico; como son solicitar el servicio de salas disponibles que estén exhibiendo la película solicitada y utilizar un servicio de cobro por tarjeta de crédito. En resumen un Web Service puede ser desde un único servicio hasta la orquestación de varios servicios en un orden conveniente para proveer un servicio principal.

Por la complejidad implícita en los Web Services, para el diseño de los mismos,

se debe estar familiarizado con las siguientes tecnologías: el protocolo HTTP (Hypertext Transfer Protocol), el protocolo HTTPS (Hypertext Transfer Protocol Secure), el metalenguaje XML (eXtensible Markup Language), el estándar XML Schema, el protocolo SOAP (Simple Object Access Protocol), el lenguaje WSDL (Web Services Definition Language) y un lenguaje de programación preferentemente orientado a objetos enfocado a la Web como Java o en su defecto C# (C Sharp) (ver Anexo B, glosario). Además se requiere aplicar las tecnologías anteriormente mencionadas bajo la arquitectura de los Web Services. Esta arquitectura fue definida por la W3C (World Wide Web Consortium) en febrero del 2004 (ver capítulo 2). Así el objetivo de este trabajo es introducir al ingeniero de sistemas al uso de los Web Services mediante un ejemplo teórico y un ejemplo práctico donde se utilizaron las anteriores tecnologías y se observa la implementación de la arquitectura orientada a servicios. Particularmente el ejemplo práctico (ver capítulo 7) consiste en que una persona pueda solicitar a una entidad proveedor un servicio que proporciona la fecha y hora de una ciudad solicitada. Para comprender el ejemplo práctico previamente se especifican en un ejemplo teórico (ver capítulo 5) los pasos que conforman la solicitud y la respuesta de un Web Service.



Se considera importante mencionar que para el ingeniero de sistemas que se inicia en el campo de los Web Services es fundamental conocer los antecedentes metodológicos citados en este trabajo como es la definición de la arquitectura propuesta por la W3C (ver capítulo 5). La arquitectura de los Web Services no impone el lenguaje de programación y la plataforma a utilizar para implementar las aplicaciones que solicitan y proveen Web Services. La metodología utilizada en el ejemplo práctico (WorldTime, ver capítulo 7) de este trabajo consta de lo siguiente:

• Sistema operativo: Windows XP. Este sistema operativo fue elegido por ser el más popular, de fácil acceso y didáctico para computadoras de uso personal.

• Plataforma de desarrollo: BEA WebLogic 8.1. Esta plataforma de desarrollo fue seleccionada por ser la más completa que existe hoy en día para desarrollar Web Services, ya que incluye un editor de Java altamente flexible, las implementaciones de SOAP y WSDL (protocolo de mensajes y lenguaje para definir interfases respectivamente) y un ambiente de pruebas integral que requiere de poca intervención manual para publicar la aplicación desarrollada en el servidor de aplicaciones.

• Lenguaje de programación: Java. Este lenguaje se ha convertido en el lenguaje de facto para implementar aplicaciones independientes del sistema operativo en que se ejecutan y sobre todo para desarrollar aplicaciones Web.

• Servidor: computadora personal. Dada la versatilidad de la infraestructura de software anteriormente mencionada, ésta puede ser cargada en una computadora personal de menores recursos comparados con los recursos disponibles en un servidor industrial, permitiendo replicar el ambiente del servidor de aplicaciones.

Por último, la estructura de este trabajo está dirigida a un lector cuyos

conocimientos son fundamentales en la computación pero no específicos en el desarrollo de Web Services. Para facilitar el acceso a los capítulos que conforman este trabajo se hace una presentación resumida de cada uno de ellos: Capítulo 1: ¿Qué son los Web Services? Se expone la definición de qué son los Web Services, los estándares que los conforman, sus fortalezas y quién está adoptándolos. Capítulo 2: La W3C Se da un panorama de la importancia de la W3C como organismo que regula la definición de estándares utilizados para desarrollar aplicaciones Web, se explica quién conforma la W3C y qué actividades ha y está desarrollando, entre las cuales se encuentra la actividad de Web Services. Capítulo 3: La Actividad de Web Services Se explica qué grupos están asignados a la definición de Web Services y qué lenguajes y protocolos están en proceso de revisión para convertirse próximamente en estándares.



Capítulo 4: La Arquitectura de Web Services Se revisa detalladamente la arquitectura de los Web Services, resaltando los entes que intervienen en una interacción de solicitud y respuesta de un Web Service, así como los pasos necesarios para dicha interacción. Capítulo 5: Ejemplo Teórico: Agente de Viajes, búsqueda dinámica de servicios Una vez entendida la arquitectura, los entes participantes y los pasos necesarios durante la interacción de solicitud y respuesta de un Web Service, se ejemplifica lo anterior con un caso simple donde un usuario utiliza un agente de viajes para comprar por cargo a tarjeta de crédito, un paquete vacacional conformado de transporte aéreo y hospedaje. El agente de viajes a su vez requiere invocar tres Web Services diferentes: cargo por tarjeta de crédito, compra de transporte aéreo y compra de hospedaje. Capítulo 6: Protocolos No Propietarios: SOAP, WSDL y UDDI Se revisan los tres estándares fundamentales que componen a un Web Service, explicando cómo funcionan, para qué sirven, y cómo están definidos. Capítulo 7: Ejemplo Práctico: WorldTime De igual forma que se revisó en el Capítulo 5 un ejemplo en donde se detallan y explican los pasos que conforman la interacción de solicitud y respuesta de un Web Service, en este capítulo se revisa un ejemplo práctico. Se provee en el CD que acompaña este trabajo, el código fuente de la aplicación ejemplo, así como toda la plataforma necesaria para poder recrear todo el ambiente de ejecución de la prueba. Capítulo 8. Conclusiones Finalmente se exponen las conclusiones alcanzadas en la realización de este trabajo. Anexo A. Instalación/Configuración del ejemplo práctico WorldTime Se explican los pasos necesarios a seguir para recrear el ejemplo práctico de este trabajo en una computadora personal, utilizando la misma plataforma de desarrollo y el código fuente del ejemplo. Anexo B. Glosario Se definen algunos términos tecnológicos utilizados a lo largo de este trabajo, sugiriendo ligas de interés (en Internet) para una consulta más profunda del tema.



1. ¿Qué son los Web Services? De acuerdo a la definición de la W3C, un Web Service es un sistema de software diseñado para poder interactuar de máquina a máquina de forma interoperable a través de una red. Cuenta con una interfase descrita en un formato procesable por máquina (específicamente WSDL). Los demás sistemas interactúan con el Web Service de la forma establecida por su descripción utilizando mensajes SOAP, típicamente transportados utilizando HTTP (pudiendo también ser FTP (File Transport Protocol) y SMTP (Simple Mail Transport Protocol)) con una serialización XML en conjunto con otros estándares relacionados a la Web[2].

La forma más simple de visualizar los Web Services es como el software que sabe comunicarse con otros tipos de software a través de la red. Los Web Services son esencialmente una infraestructura entre modelos de componentes existentes. En específico, un Web Service cumple con los siguientes criterios[1]:

- Es capaz de exponer y describirse así mismo para otras aplicaciones, permitiéndoles a esas aplicaciones entender qué hace el servicio.

- Puede ser localizado por otras aplicaciones vía un directorio en línea, si el servicio fue registrado. De no ser así, su dirección deberá conocerse de antemano.

- Puede ser invocado por la aplicación origen mediante protocolos estándares.

Un Web Service simple se caracteriza por tres estándares, SOAP para el formato de los mensajes, WSDL para la definición de la interfase del servicio, y UDDI (Universal Discovery Description and Integration) para el servicio de registro/búsqueda del servicio, que en su conjunto, proveen una funcionalidad básica de solicitud y respuesta. Los Web Services simples generalmente no son transaccionales por naturaleza. En cambio, generan peticiones generales solicitando información.

Los Web Services simples pueden utilizarse para proveer eficientemente

información como noticias, mercado bursátil, y reportes del clima para sitios Web. Por otro lado, un Web Service complejo quizá involucre a varios participantes, resultando en transacciones de ejecuciones largas con varios socios comerciales o proveedores. Un ejemplo de un Web Service complejo es que un proveedor pueda revisar la base de datos de una compañía cliente para anticipar sus necesidades. Sea el caso de una ensambladora de autos, que en su base de datos radica la información de inventario y el acceso a 1,000 proveedores. Seria bastante bueno que los proveedores pudieran revisar directamente de la base de datos, información del inventario sobre las autopartes que abastecen. Si el inventario decrece por debajo de un nivel prestablecido, el software podría automáticamente ordenar un cargamento de las autopartes específicas del proveedor para la ensambladora de autos.



1.1 Fortalezas de los Web Services[1]

No importa si las organizaciones que requieren interoperar utilizan un mainframe vs. un servidor NT, o software in-house vs. software de paquete. Los Web Services son neutrales en plataforma, y aquellos que los adopten no tendrán que preocuparse de cuestiones como la compatibilidad binaria entre diferentes sistemas operativos.

La neutralidad de la que hablamos es crítica cuando es necesario integrar sistemas con diferentes organizaciones. La integración de procesos de negocio entre empresas con middleware tradicional siempre ha sido difícil porque es poco probable que dos firmas estén utilizando las mismas tecnologías. Además, es menos probable que estén escritas en el mismo lenguaje, tal como C, C++, o Java. Sin embargo, el XML puede ser interpretado por cualquier lenguaje y puede ser enviado desde cualquier middleware, por lo que no importa si se está utilizando Java, Microsoft, CORBA (Common Object Request Broker Architecture) o lo que sea.

Los estándares y la simplificación conllevan al desarrollo de aplicaciones más rápidas a costos más bajos. Con herramientas de desarrollo basadas en estándares, los fabricantes de software ya no podrán cobrar grandes cantidades por el uso de sus tecnologías propietarias. 1.2 ¿Quién está adoptando los Web Services?[1]

El campo de los Web Services está divido en dos. Por una parte, Microsoft está promoviendo .NET, una iniciativa de Web Services que requiere el uso del software Windows. Por el otro lado, Sun Microsystems se está enfocando en una estrategia de Web Services orientada a Java. Soportada por más de treinta de los fabricantes de software más grandes, la plataforma Java 2 de Sun, Edición Enterprise (J2EE), es la propuesta con una visión de una red orientada a servicios, la cual Sun ha mantenido por varios años, dando lugar a Java, Jini, y tecnologías sofisticadas similares. La fortaleza de J2EE radica en que los usuarios no están atados a la visión de una sola compañía. Está construido sobre cosas que llevan tiempo en uso, mientras que .NET es una rearquitectura de la plataforma Microsoft. Como resultado, .NET tiende a ser utilizada en organizaciones que están muy cometidas a Windows.



2. La W3C

La W3C - World Wide Web Consortium es un consorcio internacional constituido por organizaciones privadas y gubernamentales, principalmente del sector de la Tecnología de la Información. Fue fundada en Octubre de 1994 y su misión es dirigir la Web al desarrollo de su potencial máximo, lo cual, lo hace a través del desarrollo y promoción de tecnologías (especificaciones, guías, software y herramientas) que dan lugar a un foro para la información, comercio, inspiración, pensamiento independiente, y entendimiento colectivo[3].

Los siete puntos que describen los objetivos y principios de operación de la W3C, son[4]: 1. Acceso Universal a toda información disponible vía la Web, para el beneficio de cualquier persona. 2. Una Web Semántica que permitirá expresarnos en términos que las computadoras puedan interpretarnos e intercambiemos con ellas información para que nos resuelvan problemas cotidianos. 3. Para promover un ambiente de mayor colaboración se debe construir una Web que inspire confianza, haciendo responsables a las personas por lo que publican. 4. Garantizar interoperabilidad mediante el diseño y promoción de lenguajes y protocolos no propietarios para evitar la división del mercado tecnológico. 5. Construir una web con capacidad de evolución en una mejor Web. 6. Favorecer la descentralización como un principio moderno para reducir la vulnerabilidad de la Web como un todo. 7. Brindar al usuario final una multimedia enriquecida. 2.1 ¿Quién conforma a la W3C?[5]

La W3C es un consorcio internacional, constituido a la fecha (Junio/2004) por 363 organizaciones y un staff de 69 personas de tiempo completo de diferentes partes del mundo. La infraestructura tecnológica de la W3C reside en tres lugares, en el Massachusetts Institute of Technology Laboratory for Computer Science [MIT/CSAIL] en Estados Unidos, en el European Research Consortium for Informatics and Mathematics [ERCIM] en Sophia-Antipolis, Francia, y en el Keio University Shonan Fujisawa Campus en Japón.



Algunas organizaciones miembro son: - Adobe Systems Inc. - America Online, Inc. (AOL) - American Express - Apple Computer, Inc. - AT&T - Avaya Communications - BEA Systems, Inc. - The Boeing Company - Canon, Inc. - ChevronTexaco - Cisco Systems - Citrix Systems (Cambridge) Ltd. - Computer Associates - Electronic Data Systems (EDS) - ERICSSON - Fuji Photo Film Co., Ltd. - Google, Inc. - HP - Hitachi, Ltd. - IBM Corporation

- Intel Corporation - Israel Internet Association - Macromedia - Microsoft Corporation - Mozilla Foundation - NEC Corporation - Nokia - Nortel Networks - Novell, Inc. - O'Reilly & Associates, Inc. - The Open Group - Opera Software - Oracle Corporation - Sharp Corporation - Sony Corporation - Sun Microsystems, Inc. - Toshiba Corporation - United States Department of the Navy - VeriSign, Inc.

Los miembros de la W3C envían a sus ingenieros a colaborar en los Grupos de Trabajo de la W3C, que junto con el staff técnico de la W3C, producen especificaciones técnicas para tecnologías Web. La W3C es dirigida por Tim Berners-Lee, el inventor de la Web. La W3C lleva a cabo la mayor parte de su trabajo a través de su sitio web. Se mantienen alrededor de 680,000 páginas web en el dominio de www.w3c.org y otras 796,000 páginas de listas de contenido de correos en lists.w3c.org. 2.2 Actividades de la W3C[6]

La W3C organiza en Actividades el trabajo necesario para el desarrollo o evolución de una tecnología Web. Cada Actividad tiene conformada su propia estructura, consistiendo típicamente de un Grupo de Trabajo (Working Group), un Grupo de Interés (Interest Group) y un Grupo de Coordinación (Coordination Group). Dentro del alcance de una actividad, estos grupos generalmente producen recomendaciones (el equivalente a la publicación de un estándar por otras organizaciones) y reportes técnicos, así como código fuente. Para cada Actividad es muy importante estar relacionada a la Actividad de Aseguramiento de Calidad (Quality Assurance – QA).



Para organizar las Actividades que están relacionadas, el equipo de la W3C las agrupa en cuatro dominios, que son Arquitectura (Architecture), Interacción (Interaction), Tecnología y Sociedad (Technology and Society), y la Iniciativa de Accesibilidad Web (Web Accessibility Initiative - WAI).

Actividades relacionadas organizadas por dominios Arquitectura - DOM - Internationalization - URI - Web Services - XML Interacción - Device Independence - Graphics - HTML - Math - Multimodal Interaction - Style - Synchronized Multimedia - Voice Browser - XForms

Tecnología y Sociedad - Patent Policy - Privacy - Semantic Web - XML Key Management Iniciativa de Accesibilidad Web - WAI International Program Office - WAI Technical Activity Actividad de Aseguramiento de Calidad - Quality Assurance

El equipo que conforma la W3C presenta un reporte de estatus por cada Actividad (denominado como Declaración) en cada Junta del Comité de Consejería, la cual se lleva a cabo dos veces al año.

La lista de todas las Actividades así como sus Declaraciones, son actualizadas

previamente a cada Junta del Comité. Cada Actividad está bajo la supervisión de un Líder de Actividad, quien es miembro del grupo de la W3C. Cabe señalar que todos los Grupos de Trabajo colaboran en forma libre de regalías.



3. La Actividad de Web Services[7] La W3C trabaja en la infraestructura de los Web Services para desarrollarlos a su potencial máximo, definiendo la arquitectura y las tecnologías medulares. El trabajo que se realiza en esta Actividad forma parte del Dominio de Arquitectura de la W3C. En Septiembre del 2000, la W3C comenzó la Actividad del Protocolo XML para satisfacer la necesidad de un protocolo basado en XML para el envío de mensajes entre aplicaciones. En Enero del 2002, la Actividad de Web Services dio inicio, fortaleciendo la Actividad del Protocolo XML al extender su alcance a todos los diferentes aspectos de los Web Services. La Actividad de Web Services está calendarizada para continuar hasta el 31 de Enero de 2006. Todos los grupos de la Actividad de Web Services llevan a cabo sus discusiones técnicas en listas de correo públicas, exponen los procedimientos de sus juntas de manera pública, y proveen copias de todos sus documentos a través de su página web. La Actividad de Web Services se compone de tres Grupos de Trabajo, un Grupo de Interés y un Grupo de Coordinación que coordina el trabajo de la Actividad. 3.1 Grupos de Trabajo 3.1.1 Web Services Architecture Working Group En Enero/2002 le fue asignado por un período de dos años el realizar un documento que definiera la arquitectura, la cual explica como embonan todas las piezas de los Web Services. En Febrero/2004 el grupo publicó el documento de la Arquitectura de los Web Services (ver el siguiente capítulo, 4. La Arquitectura de Web Services). 3.1.2 XML Protocol Working Group Fue creado en Septiembre/2000 y originalmente le fue asignado desarrollar una plataforma de mensajes basados en XML, contemplando entre los entregables:

- Un sobre para encapsular datos XML para transferirlos de forma interoperable permitiendo intermediarios tipo proxies, caches y gateways.

- Un mecanismo para utilizar el transporte de HTTP 1.1 en el contexto de un protocolo XML.



La plataforma de mensajes resultante de este trabajo es SOAP versión 1.2, la cual fue liberada como una recomendación de la W3C el 24/Enero/2003. El grupo actualmente está trabajando (asignado hasta el 31/Enero/2005) en la parte de archivos adjuntos y la optimización de la transmisión de mensajes SOAP, esperando publicar el último draft en Mayo/2004. 3.1.3 Web Services Description Working Group El grupo fue creado en Enero/2002 y es responsable de desarrollar para los Web Services (asignado hasta el 31/Enero/2006) un lenguaje para describir interfaces y como interactuar con ellas. La interfase de un Web Service es descrita de tal forma que le permite fácilmente a los solicitantes del servicio encontrar como hacer uso del servicio. El grupo actualmente está elaborando la versión 2.0 de WSDL, esperando publicar el último draft en Mayo/2004. 3.1.4 Web Services Choreography Working Group Mientras que WSDL 2.0 describe solamente un servicio, resulta interesante el poder combinar servicios simples para obtener resultados complejos. Actualmente se debe acompañar a la descripción WSDL con descripciones de un lenguaje natural complejo que especifiquen las obligaciones de los participantes y detallen como utilizar un servicio. El siguiente paso es remplazar parcialmente estas instrucciones algo imprecisas por un lenguaje preciso. El grupo fue creado en Enero/2003 y es responsable de diseñar (asignado hasta el 31/Diciembre/2004) un lenguaje para componer y describir las relaciones e intercambio de mensajes entre Web Services. A esta composición se le conoce como la Coreografía de los Web Services. El primer draft del lenguaje de descripción de coreografía ya ha sido publicado y se espera publicar el último draft a finales del 2004. 3.2 Grupo de Interés 3.2.1 Semantic Web Services Interest Group Su misión es proveer un foro abierto para los miembros de la W3C así como para los no miembros, discutiendo temas de Web Services orientados esencialmente hacia la integración de Tecnologías Web Semánticas con el trabajo en curso de la W3C sobre Web Services. 3.3 Grupo de Coordinación 3.3.1 Web Services Coordination Group Su responsabilidad es garantizar que exista coordinación entre los grupos que conforman la Actividad de Web Services, la Actividad de Web Semántica que realiza trabajo relacionado, y con el resto de la W3C.



4. La Arquitectura de Web Services[2]

Esta arquitectura no intenta especificar cómo deben implementarse los Web Services, y no impone restricción alguna de cómo pudieran combinarse. Especifica tanto las características mínimas que son comunes a todos los Web Services, como un número de características que para muchos Web Services son necesarias, pero no para todos. La arquitectura de Web Services es de interoperabilidad: identifica esos elementos de la red global de los Web Services que son requeridos para garantizar la interoperabilidad entre dichos servicios. 4.1 Agentes y Servicios Un Web Service es una noción abstracta que debe ser implementada por un agente en concreto. El agente es la pieza concreta de software o hardware que envía y recibe mensajes, mientras que el servicio es el recurso que se caracteriza por el conjunto abstracto de funcionalidades que se proveen. Para ilustrar esta diferencia, se podría implementar un Web Service en particular utilizando un agente un día (a lo mejor escrito en un cierto lenguaje de programación), y al día siguiente utilizar un agente diferente (quizá escrito en un lenguaje de programación diferente) con la misma funcionalidad. Aún cuando el agente cambió, el Web Service continua siendo el mismo. 4.2 Solicitantes y Proveedores El propósito de un Web Service es proveer alguna funcionalidad en nombre de su dueño, sea una persona o una organización, tal como un negocio o un individuo. La entidad proveedor es la persona u organización que provee un agente apropiado para implementar un servicio en particular. Una entidad solicitante es una persona u organización que desea hacer uso del Web Service de la entidad proveedor. Utilizará un agente solicitante para intercambiar mensajes con el agente proveedor de la entidad proveedor. Cabe resaltar que en la mayoría de los casos, el agente solicitante es el que inicia el intercambio de mensajes, pero esto no ocurre siempre. Sin embargo, para ser consistentes, se utilizará el término agente solicitante para el agente que interactúe con el agente proveedor, aún en los casos cuando el agente proveedor sea el que inicie el intercambio de mensajes.



4.3 Descripción del Servicio La mecánica del intercambio de mensajes está documentada en la descripción de servicio de un Web Service (WSD – Web Service Definition). La WSD es una especificación (procesable por máquina) de la interfase de un Web Service, escrita en WSDL. Define los formatos de los mensajes, tipos de datos, protocolos de transporte, y formatos serializables de transporte que deben ser utilizados entre el agente solicitante y el agente proveedor. También especifica uno o más puntos de la red en donde puede invocarse a un agente proveedor, y posiblemente contenga información sobre el patrón de intercambio de mensajes esperado. En esencia, la descripción del servicio representa un acuerdo que gobierna la mecánica de interacción con ese servicio. 4.4 Semántica La semántica de un Web Service es la expectativa común sobre el comportamiento del servicio, particularmente en respuesta a los mensajes que le son enviados. Esto se puede comprender como el contrato entre la entidad solicitante y la entidad proveedor en relación al propósito y consecuencias de la interacción. Aunque este contrato representa el acuerdo general entre la entidad solicitante y la entidad proveedor en cómo y porqué sus respectivos agentes interactuarán, no está necesariamente por escrito o explícitamente negociado. Puede ser explícito o implícito, escrito o verbal, procesable por máquina u orientado a los humanos, y puede ser un acuerdo legal o informal (no legal). Mientras que la descripción del servicio representa un contrato que gobierna la mecánica de la interacción con un servicio en particular, la semántica representa un contrato que gobierna el significado y propósito de esa interacción. La línea divisoria entre estos dos no es necesariamente rígida. Conforme más lenguajes semánticamente enriquecidos son utilizados para describir la mecánica de la interacción, más de la información esencial migrará de la semántica informal a la descripción del servicio. Conforme esta migración se va dando, más del trabajo requerido para alcanzar una interacción exitosa puede ser automatizado. 4.5 Utilizando Web Services A continuación se detallan los cuatro pasos requeridos en el proceso de invocar un Web Service (ver Figura 1). Aunque estos pasos son necesarios, tal vez no sean suficientes: muchos escenarios requerirán pasos adicionales, o una especialización de estos pasos fundamentales. Inclusive, el orden en que se realizan estos pasos podría variar de una situación a otra.



Figura 1. El proceso general de invocar un Web Service. 4.5.1 Las entidades se conocen La entidad solicitante y proveedor saben el uno del otro, en el sentido de que la parte que inicie la interacción deberá estar al tanto de la otra parte. Existen dos casos:

a. En un caso típico, el agente solicitante será el que inicie. En este caso diríamos que la entidad solicitante debe estar al tanto de la entidad proveedor, es decir, el agente solicitante deberá de algún modo obtener la dirección del agente proveedor. Existen dos formas en que típicamente esto ocurrirá: (1) la entidad solicitante puede obtener la dirección del agente proveedor directamente de la entidad proveedor, ó (2) la entidad solicitante puede utilizar un servicio de búsqueda para localizar una descripción del servicio apropiada (la cual contiene la dirección para invocar el agente proveedor) vía una descripción funcional asociada, ya sea mediante una búsqueda manual o una selección automatizada.

b. En otros casos, el agente proveedor puede iniciar el intercambio de mensajes

entre los agentes solicitante y proveedor. En este caso, cuando se dice que las entidades solicitante y proveedor están al tanto uno del otro realmente significa que la entidad proveedor está al tanto de la entidad solicitante, es decir, el agente proveedor de alguna forma obtiene la dirección del agente solicitante. El cómo ocurre esto es dependiente de la aplicación e irrelevante para esta arquitectura. Aún cuando se espera que este caso sea menos común en comparación a cuando el agente solicitante sea el que inicie, es importante en algunos escenarios de empuje o suscripción.



4.5.2 Acuerdo sobre la descripción del servicio y semántica La entidad solicitante y proveedor concuerdan en la descripción del servicio (un documento WSDL) y semántica que regirá la interacción entre los agentes solicitante y proveedor.

Lo anterior no significa necesariamente que las entidades solicitante y proveedor deban comunicarse o negociar el uno con el otro. Simplemente significa que ambas entidades deberán entender lo mismo (o de forma compatible) sobre la descripción del servicio y semántica, intentando mantener dichos entendimientos. Esto se puede lograr de diversas maneras, tales como:

- Las entidades solicitante y proveedor podrían comunicarse directamente la una con la otra, para acordar explícitamente sobre la descripción del servicio y semántica.

- La entidad proveedor podría publicar y ofrecer la descripción del servicio y

semántica como contratos tómalo o déjalo que la entidad solicitante tendría que aceptar sin modificaciones como condición de uso.

- La descripción del servicio y semántica (excepto la dirección de red del servicio

en particular) pueden ser definidas como un estándar por una organización industrial, y utilizadas por muchas entidades solicitante y proveedor. En este caso, el que las entidades solicitante y proveedor logren estar de acuerdo se debe a que ambos de forma independiente se apegan al mismo estándar.

- La descripción del servicio y semántica (tal vez exceptuando la dirección de red

del servicio) pueden ser definidas y publicadas por la entidad solicitante (aún siendo escritas desde una perspectiva de entidad proveedor), y ofrecidas a entidades proveedor en forma de tómalo o déjalo. Esto puede ocurrir, por ejemplo, si una compañía grande requiere que sus proveedores provean Web Services que se apeguen a una descripción del servicio y semántica particular. En este caso, el acuerdo se logra cuando la entidad proveedor adopta la descripción del servicio y semántica que la entidad solicitante publicó.

Dependiendo del escenario, el Paso 2 (ó partes del Paso 2) puede(n) ser

ejecutado(as) antes que el Paso 1. 4.5.3 Implementación de la descripción del servicio y semántica La descripción del servicio y semántica son alimentadas a, o conformadas en, ambos agentes solicitante y proveedor como apropiadas. En otras palabras, la información de la descripción del servicio y semántica debe ser alimentada a, o implementada en, los agentes solicitante y proveedor. Existen varias formas para lograr esto, y esta arquitectura no especifica o le importa, que métodos son utilizados. Por ejemplo:

- Un agente podría estar codificado para implementar una descripción del servicio y semántica, fija y particular.

- Un agente podría estar codificado en una forma más genérica, y la descripción del servicio y/o semántica deseada podría ser alimentada de forma dinámica.



- Un agente podría ser creado primero, y la descripción del servicio y/o semántica podrían ser generadas o deducidas del código del agente. Por ejemplo, una herramienta podría examinar un conjunto de archivos de clases existentes para generar una descripción del servicio.

Independientemente del enfoque utilizado, desde el punto de vista informativo

tanto la semántica como la descripción del servicio deben de alguna forma ser alimentados a, o implementados en, tanto el agente solicitante como el agente proveedor antes de que los dos agentes puedan interactuar. 4.5.4 Intercambio de mensajes El agente solicitante y el agente proveedor intercambian mensajes SOAP a nombre de sus propietarios. Nota acerca de estar de acuerdo sobre la semántica y la descripción del servicio: Aunque es conveniente decir que las entidades solicitante y proveedor deben estar de acuerdo sobre la semántica y la descripción del servicio, es una ligera simplificación (y tal vez un poco desorientadora) decir que ambos deben estar de acuerdo sobre la misma semántica y descripción del servicio.

- El estar de acuerdo frecuentemente connota una comunicación activa entre las partes y un acto explícito (tal como el firmar un contrato) para provocar que el acuerdo se convierta en un lazo entre ambas partes, siendo ninguno requerido en el caso del Paso 2 anterior.

- Es una ligera simplificación decir que los agentes solicitante y proveedor deben implementar la misma semántica y WSD, por dos razones: (1) el agente solicitante las implementa desde la perspectiva de la entidad solicitante, mientras que el agente proveedor las implementa desde la perspectiva de la entidad proveedor (por ejemplo, la entrada de uno es la salida del otro), y (2) los agentes solicitante y proveedor sólo necesitan implementar aquellos aspectos de la descripción del servicio y semántica que son relevantes para sus respectivos roles.

En resumen, es conveniente decir que las entidades solicitante y proveedor

deben estar de acuerdo sobre la semántica y descripción del servicio que gobernará la interacción entre los agentes solicitante y proveedor, pero sería más preciso decir que simplemente necesitan una visión congruente o sin conflictos, de la semántica y descripción del servicio de la interacción.

Nota: Cabe señalar que para este capítulo la fuente de referencia (Nota pública del Grupo de Trabajo Web Services Architecture Working Group) es catalogada por sus autores como un documento draft, el cual ser actualizado, reemplazado o marcado como obsoleto por otros documentos en cualquier momento ya que no ha alcanzado el grado de recomendación (el equivalente a la publicación de un estándar por otras organizaciones). Sus autores enfatizan que es inapropiado citar dicho documento diferente a trabajo en progreso.



5. Ejemplo Teórico: Agente de Viajes, búsqueda dinámica de servicios [8] A continuación se describe un ejemplo teórico que permite observar los pasos involucrados en la invocación de un Web Service de acuerdo a la arquitectura revisada en el capítulo anterior. El ejemplo consiste en que una persona pueda comprar mediante un agente de viajes, un paquete vacacional con cargo a una tarjeta crédito (ver Figura 2). En el contexto de los Web Services, un caso de uso es una secuencia de interacciones entre un solicitante de un servicio y uno o más servicios (se logran resultados medibles para el solicitante durante las interacciones). Ya sea resaltando una relevancia arquitectónica o técnica, un escenario de uso representa un paso atómico en un camino a través de un caso de uso. Al combinar y adoptar diferentes escenarios de uso, uno puede generar varios caminos para el mismo caso de uso.

Figura 2. Descripción del Caso de Uso de Agente de Viajes. 5.1 Descripción Una compañía (agente de viajes) quiere ofrecerle a la gente la posibilidad de comprar paquetes vacacionales completos: boletos de avión/tren/autobus, hoteles, renta de autos, excursiones, etc. Proveedores de servicio (aerolíneas, compañías de autobuses, cadenas de hoteles, etc.) proveen Web Services para consultar sus ofertas y realizar reservaciones.



Compañías de tarjetas de crédito también proveen servicios para garantizar pagos realizados por consumidores. Debido a la naturaleza del acoplamiento no tan rígido de los Web Services, el agente de viajes no necesita estar en acuerdo previo con los proveedores de servicio o las compañías de tarjetas de crédito. Esto le permite al agente de viajes tener acceso a mayores servicios, ofreciendo más opciones a sus clientes, a las compañías de tarjetas de crédito ofrecer sus servicios ampliamente y consecuentemente satisfacer a sus clientes, y los proveedores de servicio también pueden ofrecer sus servicios ampliamente y fácilmente, generando más negocio para si mismos. 5.2 Alcance Para esta versión de escenario de uso, se limitará a la compra de paquetes vacacionales. Se asumirá que la cancelación no es posible una vez comprado el paquete. 5.3 Accionistas / Intereses El agente de viajes provee un sistema para brindarle opciones al usuario para sus vacaciones y gana dinero cobrando comisiones por cada paquete comprado. Los proveedores de servicio (hoteles, aerolíneas) ofertan sus servicios poniéndolos ampliamente a disposición utilizando Web Services. Las compañías de tarjetas de crédito facilitan a los clientes utilizar sus tarjetas de crédito en un gran número de casos poniendo a disposición pagos a través de Web Services y generan ganancias con cada transacción de dinero. El consumidor compra fácilmente sus paquetes vacacionales al escoger entre una gran variedad de ofertas. En este escenario, solamente el usuario es humano. El servicio de agente de viajes y los servicios de aerolínea, hotel y de pago con los que el agente de viajes interactúa, son máquinas. 5.4 Actores / Objetivos El objetivo del consumidor es obtener la mejor combinación de servicios y precios satisfaciendo sus necesidades. La intención del agente de viajes es proveerle satisfacción al cliente y vender paquetes. Los proveedores de servicio tratan de vender el mayor número de productos posible.



Las compañías de tarjetas de crédito garantizan y realizan los pagos de los productos comprados. Los desarrolladores utilizan WSDL y plataformas para crear instancias de Web Services. 5.5 Escenarios de Uso Los siguientes escenarios de uso describen como un usuario realizaría una reservación de una paquete vacacional (vuelo y habitación de hotel), y como un desarrollador crearía una porción del servicio.

Debe hacerse notar que se requiere de tecnología adicional para este escenario de uso:

- Mantenimiento de contexto. - Confiabilidad: para generar ganancia, cada paso debe ocurrir - Mecanismos de confianza para los servicios para hacer negocio los unos con los

otros. - Descripción de la coreografía de los servicios: si la reservación de un vuelo

requiere interactuar con un par de Web Services, la aerolínea documentaría en una forma legible por máquina el cómo interactuar con los dos servicios unitarios para lograr el resultado esperado, incluyendo cómo manejar errores si el proceso falla antes de que la operación se complete.

- Etc.

Nótese que este escenario de uso podría ser diferente en las siguientes formas:

- El usuario pudo haber comprado algún tipo de software de agente de viajes; el servicio de agente de viajes podría radicar de manera local en su computadora.

- El usuario podría desarrollar herramientas para interactuar directamente con los servicios de aerolínea y hotel.

5.6 El usuario solicita disponibilidades de fechas de viaje

1. Al usuario se le presenta una forma para completar para que le provea al servicio de agente de viajes los detalles sobre las fechas de su viaje y su destino.

2. El usuario submite la información al servicio para recibir una lista de vuelos correspondientes a su itinerario.

3. El servicio de agente de viajes localiza una lista de aerolíneas.



4. Para cada aerolínea encontrada: a. El servicio de agente de viajes solicita una descripción de cómo

comunicarse con el servicio encontrado. b. El servicio de agente de viajes solicita una lista de vuelos que satisfagan

al usuario. 5. El servicio de agente de viajes le presenta al usuario los resultados de las

solicitudes permitiéndole escoger la mejor opción.

Extensiones: Si no es posible encontrar vuelos, al usuario se le debe notificar como error. Tecnologías y requerimientos: Tecnología de Búsqueda: utilizada por el servicio de agente de viajes para localizar los servicios de aerolíneas. Lenguaje de Descripción: utilizado por las aerolíneas para describirle al servicio de agente de viajes sus servicios de consulta. Respuesta a las Consultas: documentos XML que el servicio de agente de viajes procesa y fusiona. Ontologías: La información que proviene de diferentes servicios de aerolíneas y expresada en diferentes vocabularios XML necesita algo de semántica para ser fusionada con significado. 5.7 El usuario escoge un vuelo y busca hoteles

1. El usuario da a conocer su elección de vuelo. 2. El servicio de agente de viajes solicita a la aerolínea electa poner el vuelo en

espera: a. El servicio de agente de viajes solicita una descripción de cómo poner el

asiento en espera ante el servicio de aerolínea. b. El servicio de agente de viajes envía la solicitud correspondiente.

3. La aerolínea envía de vuelta un identificador de confirmación con una fecha de expiración.

4. El servicio de agente de viajes localiza una lista de hoteles. 5. Para cada hotel encontrado:

a. El servicio de agente de viajes solicita una descripción de cómo comunicarse con el servicio encontrado.

b. El servicio de agente de viajes solicita opciones de hospedaje para el período.

6. El servicio de agente de viajes busca servicios de pago disponibles, y genera una lista de opciones para el usuario.

7. El servicio de agente de viajes le presenta al usuario los resultados de las solicitudes permitiéndole escoger la mejor opción, junto con las opciones de pago ofrecidas.



Extensiones: Si los asientos seleccionados ya no están disponibles, el servicio de agente de viajes le presenta al usuario un mensaje de error y una lista actualizada de los vuelos disponibles a escoger. Tecnologías y requerimientos: Lenguaje de Descripción: utilizado por las aerolíneas para describirle al servicio de agente de viajes sus servicios de poner boletos en espera, por los hoteles para describirle al servicio de agente de viajes sus servicios de consulta. Tecnología de Búsqueda: utilizada por el servicio de agente de viajes para localizar los servicios de hoteles. Ontologías: La información que proviene de diferentes servicios de hospedaje y expresada en diferentes vocabularios XML necesita algo de semántica para ser fusionada con significado. 5.8 El usuario paga la habitación de hotel y el vuelo

1. El usuario le da a conocer su elección sobre el hospedaje al servicio de agente de viajes.

2. El servicio de agente de viajes contacta el servicio de pago que el usuario eligió para confirmar el pago:

a. El servicio de agente de viajes solicita una descripción de cómo garantizar el pago del monto total.

b. El servicio de agente de viajes envía la solicitud correspondiente. c. La respuesta indica que fue exitoso mediante un identificador de

autorización, firmado por la autoridad de pago. 3. El servicio de agente de viajes reserva la habitación del hotel:

a. El servicio de agente de viajes solicita una descripción de cómo reservar una habitación en el servicio de hotel seleccionado.

b. El servicio de agente de viajes envía una solicitud para averiguar cómo cancelar la reservación en caso de que ocurra una problema más adelante en el proceso.

c. El servicio de agente de viajes envía la solicitud correspondiente, junto con el identificador de autorización de pago provisto por el servicio de pago.

4. El servicio de agente de viajes confirma la reservación del vuelo: a. El servicio de agente de viajes solicita una descripción de cómo

comprarle al servicio de la aerolínea un boleto en espera. b. El servicio de agente de viajes envía una solicitud para averiguar cómo

cancelar la reservación en caso de que ocurra una problema más adelante en el proceso.

c. El servicio de agente de viajes envía la solicitud correspondiente, junto con el identificador de autorización de pago provisto por el servicio de pago.

5. El servicio de agente de viajes le cobra una comisión al usuario: a. El servicio de agente de viajes solicita una descripción de cómo solicitar

un pago al servicio de pago. b. El servicio de agente de viajes envía la solicitud correspondiente, junto

con el identificador de autorización firmado por el servicio de pago.



6. El servicio le provee al usuario varios identificadores de confirmación y le desea al usuario unas felices vacaciones.

Extensiones: Si el servicio de pago no confirma la validez de la opción de pago del usuario, al usuario se le debe notificar como error. Si la habitación del hotel no puede ser reservada, al usuario se le debe notificar como error y deberá poder elegir de una lista de opciones actualizada. Si la reservación del vuelo no puede ser confirmada, la reservación de la habitación de hotel debe ser cancelada y al usuario se le debe notificar como error, comenzando el proceso de reservación nuevamente. Tecnologías y requerimientos: Tecnología de Descripción de Servicio: utilizada por la autoridad de pago para describir su servicio de confirmación, por el hotel para describir su servicio de reservación de habitaciones, y por la aerolínea para describir su servicio de compra de boletos mediante la confirmación de lugares en espera. Tecnología de Autenticación: utilizada por la autoridad de pago para firmar la autorización de pago para ser confiada por el servicio del hotel, el servicio de la aerolínea y el servicio de agente de viajes. Tecnología de Encriptamiento: utilizada por el servicio de pago y el servicio de agente de viajes para comunicar la confidencialidad de información de pago del usuario. Ontologías: la confirmación de pago necesita utilizarse de forma que tenga significado para el servicio de viaje, hotel y aerolínea; en otras palabras, la salida de un servicio necesita utilizarse como la entrada (alimentación) para otros servicios que tal vez utilicen vocabularios diferentes. 5.9 Notas sobre el escenario

Este escenario ilustra como un programa, el servicio de agente de viajes, puede interactuar dinámicamente con servicios de aerolíneas y hoteles sin un previo conocimiento de ellos o de cómo trabajan. Gracias a las ontologías utilizadas, el programa puede adaptarse a variaciones de formato que el servicio de una aerolínea podría estar utilizando y adaptarse a la introducción de productos nuevos.

Cabe hacer notar que existe un límite sobre lo que el servicio de agente de

viajes puede entender. Por ejemplo, es probable que pueda entender la introducción de una nueva clase de boletos, digamos la clase Z. Sin embargo, si las restricciones de los boletos clase Z utilizan conceptos con los que no está familiarizado (digamos que los boletos clase Z sólo pueden ser comprados con más de 60 días de anticipación y con una credencial de estudiante internacional válida), los desarrolladores del servicio de agente de viajes necesitarán implementar la lógica extra para habilitarlo a que entienda este tipo de restricción nueva, incluyendo el validar la identificación de estudiante.



Nota: Cabe señalar que para este capítulo la fuente de referencia (Nota pública del Grupo de Trabajo Web Services Architecture Working Group) es catalogada por sus autores como un documento draft, el cual ser actualizado, reemplazado o marcado como obsoleto por otros documentos en cualquier momento ya que no ha alcanzado el grado de recomendación (el equivalente a la publicación de un estándar por otras organizaciones). Sus autores enfatizan que es inapropiado citar dicho documento diferente a trabajo en progreso.



6. Protocolos No Propietarios: SOAP, WSDL y UDDI 6.1 SOAP 1.2 (Simple Object Access Protocol)[9][10[11]

SOAP es un protocolo de comunicación por mensajes vía Internet para aplicaciones. Es independiente de la plataforma y del lenguaje ya que comunica aplicaciones ejecutándose en diferentes sistemas operativos, utilizando diferentes tecnologías y lenguajes de programación.

SOAP está basado en XML (resultando en un protocolo basado en texto a

diferencia de un protocolo binario) y define qué información en XML (contenida en un mensaje SOAP) puede intercambiarse entre nodos SOAP en un ambiente distribuido, como información estructurada con tipos de datos asociados.

SOAP es fundamentalmente un paradigma de intercambio de mensajes de un solo sentido, sin estado. Sin embargo las aplicaciones pueden crear patrones de interacción más complejos (solicitud/respuesta, solicitud/múltiples respuestas, etc.) al combinar los intercambios de un solo sentido con características aportadas por el protocolo subyacente y/o con información específica de la aplicación.

Un nodo SOAP tiene la capacidad de transmitir, recibir, procesar y/o retransmitir

un mensaje SOAP. Un emisor SOAP es un nodo SOAP que transmite un mensaje SOAP, de forma similar, un receptor SOAP es un nodo SOAP que acepta un mensaje SOAP.

Algunos de los patrones que se pueden implementar para intercambio de

mensajes SOAP, son:

Un sólo sentido El receptor final SOAP recibe un mensaje. Solicitud/respuesta El receptor final SOAP recibe un mensaje y emite un mensaje correlacionado Ejemplo: Intercambio conversacional de mensajes o RPC (Remote Procedure Call). Notificación El receptor final SOAP emite un mensaje. Ofrecimiento/respuesta El receptor final SOAP emite un mensaje y recibe un mensaje correlacionado.

Los mensajes SOAP pueden pasar fácilmente a través de proxies y firewalls ya

que pueden ser transportados por diferentes protocolos de aplicación estándar abiertos como HTTP, HTTPS, SMTP, FTP, etc.



6.1.1 Estructura de un Mensaje SOAP La estructura de un mensaje SOAP contiene (ver Figura 3): - Sobre SOAP. MIME (Multipart Internet Mail Extensions) tipo text/xml. Incluye

información de codificación y contextos (namespaces), así como el Encabezado y el Cuerpo SOAP. Su etiqueta (tag) XML es <env:Envelope>.

- Cero o más archivos adjuntos. MIME tipo multipart/related. Sirven de contenedor para más Sobres SOAP o archivos adjuntos arbitrarios.

El Encabezado SOAP es opcional e incluye información de contexto,

autenticación, transacción, administración y semántica de alto nivel que puede ser manipulada por los diversos nodos SOAP por los que pasa el mensaje SOAP en su trayecto del emisor SOAP al receptor SOAP final. Su etiqueta XML es <env:Header>.

El Cuerpo SOAP es mandatorio y procesado únicamente por el receptor SOAP

final. Contiene la información de la aplicación (cuando aplique por ejemplo un intercambio conversacional de mensajes), métodos y parámetros RPC (cuando sea necesario modelar un cierto comportamiento de programación), e información de estatus y/o error. Su etiqueta XML es <env:Body>.

Figura 3. Estructura de un mensaje SOAP.



La última recomendación de SOAP (versión 1.2) emitida por la W3C es SOAP Version 1.2 Part 0: Primer, 24/Junio/2003. http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

En el siguiente capítulo se describe paso a paso un ejemplo que invoca un Web Service, detallando las partes más importantes en el uso de mensajes SOAP. 6.2 WSDL 1.2 (Web Services Description Language)[12] Es una especificación que define cómo describir Web Services mediante una gramática común XML. WSDL describe cuatro partes críticas de información:

- Información de una interfase que describe todas las funciones públicas disponibles.

- Información de los tipos de datos utilizados en todos los mensajes de solicitud y respuesta.

- Información de nexos sobre el protocolo de transporte a utilizarse. - Información de dirección para localizar el servicio especificado.

WSDL representa un contrato entre el solicitante del servicio y el proveedor del

servicio, siendo independiente de la plataforma y el lenguaje, y utilizado principalmente (aunque no exclusivamente) para describir servicios SOAP.

La especificación WSDL está dividida en seis elementos principales (ver Figura 4):

6.2.1 definitions Debe ser el elemento raíz de un documento WSDL. Declara múltiples contextos utilizados a lo largo del documento, y contiene el resto de los elementos que a continuación se describen. 6.2.2 types Describe todos los tipos de datos utilizados entre el cliente y el servidor. WSDL no está limitado a un sistema de tipos de datos, sin embargo, utiliza la especificación W3C XML Schema como la opción por default. 6.2.3 message Describe un mensaje de un sólo sentido, siendo una solicitud de un sólo mensaje o una respuesta de un solo mensaje. Define el nombre del mensaje y contiene cero o más partes, las cuales pueden referirse a los parámetros o valores de regreso del mensaje. 6.2.4 portType Combina varios elementos <message> para formar una operación completa de un solo sentido o de viaje redondo, pudiendo ser definidas varias operaciones. 6.2.5 binding Describe las especificaciones concretas de cómo va a implementarse el servicio en la red.



6.2.6 service Define la dirección para invocar el servicio especificado. Comúnmente incluye una URL para invocar el servicio SOAP.

Figura 4. Estructura de un documento WSDL. La última versión (2.0) de WSDL es el draft emitido por la W3C: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 26/Marzo/2004. ver http://www.w3.org/TR/2004/WD-wsdl20-20040326 6.3 UDDI 2 (Universal Description, Discovery and Integration)[13][14][15][16] El alcance del proyecto UDDI es el funcionar como un registro, de la misma forma como la Sección Amarilla es un registro para los negocios en una área metropolitana dada. Al navegar en un registro UDDI, se debe poder localizar un servicio y una compañía, así como descubrir cómo invocar el servicio.



El proyecto UDDI, fundado en una arquitectura global abierta, independiente de plataforma, y en el uso de la Internet, es una iniciativa de la industria que le permitirá a los negocios de manera fácil, rápida, y dinámica, encontrar y realizar transacciones con otro. Además de la Sección Amarilla, UDDI también se refiere a la Sección Blanca y Verde. La Sección Blanca es un listado de entidades de negocio. La Sección Verde representa básicamente documentos técnicos necesarios para invocar un servicio dado. Las definiciones UDDI son lo suficientemente generales para acomodar servicios de diferentes tipos (servicios manuales o electrónicos), los que no necesariamente son servicios SOAP. Una definición UDDI podría representar un servicio de fax o telefónico. En una base de datos UDDI, existe un modelo de datos, el cual permite publicar y solicitar información de la información contenida. El modelo de datos UDDI contiene los siguientes elementos (ver Figura 5): 6.3.1 BusinessEntity Representa una compañía física (Entidad de Negocio) Cada entidad contiene un identificador único, el nombre del negocio, una descripción breve del negocio, información de contacto básica, una lista de categorías e identificadores que describen al negocio, y una URL que referencia más información acerca del negocio. 6.3.2 BusinessService Representa un servicio ofrecido por una compañía (Servicio de Negocio) Asociado a la Entidad de Negocio, es una lista de servicios de negocio ofrecidos por la misma. Cada entrada de Servicio de Negocio contiene una descripción de negocio del servicio, una lista de categorías que describen el servicio, y una lista de apuntadores a referencias e información relacionada al servicio. 6.3.3 BindingTemplate Instrucciones de cómo invocar un servicio Asociado a cada entrada de Servicio de Negocio, es una lista de nexos que apuntan a especificaciones y otra información técnica del servicio. Pueden ser una URL que provee información sobre cómo invocar el servicio. Las especificaciones asocian el servicio con un tipo de servicio. 6.3.4 TModel Tipo de servicio ofrecido Un tipo de servicio que ha sido clasificado previamente (por una organización) ya que diferentes negocios pueden ofrecer el mismo tipo de servicio. Contiene el nombre del tModel, el nombre de la organización que lo publicó, una lista de categorías que describen el tipo de servicio, y apuntadores a especificaciones técnicas del tipo de servicio tales como definiciones de interfase, formatos de mensaje, protocolos de mensaje, y protocolos de seguridad.



Figura 5. Flujo de mensajes UDDI entre el cliente y el Registro. Existe un registro público de negocios UDDI denominado UBR (UDDI Bussiness Registry) que es un registro de negocios universal, el cual es operado como un servicio distribuido. Un operador de nodo es una compañía que cuenta con la implementación de una instancia del UBR. Los operadores replican los registros a lo largo de todos los nodos de forma periódica, resultando en la disponibilidad del conjunto completo de los campos registrados. Actualmente existen cuatro operadores de nodo para UDDI versión 2, que son:

Microsoft UBR Node ver http://uddi.microsoft.com IBM UBR Node ver https://uddi.ibm.com/ubr/registry.html SAP UBR Node ver http://uddi.sap.com NTT Com UBR Node ver http://www.ntt.com/uddi/

La última versión (3.0.2) de UDDI es el draft emitido por el UDDI Spec Technical Comitee: UDDI (Universal Description, Discovery and Integration) Version 3.0.2, 01/Noviembre/2004. ver http://www.oasis-open.org/committees/uddi-spec/doc/spec/v302.htm



6.4 Implementaciones Abiertas y Comerciales de SOAP, WSDL y UDDI Existen varios productos abiertos y comerciales que han implementado ambientes de desarrollo empresariales para el uso de Web Services entre otros usos, utilizando SOAP, WSDL y UDDI. Algunos productos son: 6.4.1 Implementaciones Abiertas Java System Application Server Platform Edition 8 Descripción: Sun J2EE Application Server ver http://wwws.sun.com/software/products/appsrvr_pe/index.html Apache Geronimo 1.0 Milestone 3 Descripción: Apache J2EE Server ver http://geronimo.apache.org/ Apache Axis 1.3 Descripción: Implementación de SOAP desarrollada en Java. ver http://ws.apache.org/axis Java Web Services Developer Pack 1.5 Descripción: Ant, WSDP Registry Server e implementaciones de APIs para XML y SOAP. ver http://java.sun.com/webservices/downloads/webservicespack.html 6.4.2 Implementaciones Comerciales BEA WebLogic Server 8.1 SP3 Descripción: BEA Application Server desarrollado en Java (basado en J2EE) ver http://www.bea.com/framework.jsp?CNT=overview.htm&FP=/content/products/server/ ver http://www.dev2dev.com/products/wlserver81/index.jsp IBM WebSphere Application Server V6.0 Descripción: IBM Application Server desarrollado en Java (basado en J2EE) ver http://www-306.ibm.com/software/webservers/appserv/was/ SAP Web Application Server Descripción: SAP Application Server desarrollado en Java (basado en J2EE) ver http://www.sap.com/solutions/netweaver/webappserver/index.aspx Oracle Application Server 10g Descripción: Oracle Application Server desarrollado en Java (basado en J2EE) ver http://www.oracle.com/appserver/index.html Microsoft .NET Framework 1.1 Descripción: Ambiente Windows de desarrollo para Web Services ver http://msdn.microsoft.com/netframework/programming/fundamentals/default.aspx ver http://msdn.microsoft.com/netframework



7. Ejemplo Práctico: WorldTime

A continuación se presenta un ejemplo práctico llamado WorldTime en el que se puede observar con mayor detalle cada paso que involucra la interacción al solicitar y proveer un Web Service.

El ejemplo fue escrito totalmente por el autor de este trabajo. Para implementarlo se eligió desarrollarlo sobre la plataforma BEA WebLogic 8.1, utilizando su IDE (Integrated Devolpment Environment) que es el entorno de desarrollo BEA WebLogic Workshop. Se anexa en el CD que acompaña este trabajo, el código fuente de esta aplicación ejemplo, así como el instalador del ambiente de desarrollo BEA WebLogic 8.1, esto con el objetivo de poder recrear totalmente la ejecución del ejemplo. Las instrucciones de cómo instalar el ambiente de desarrollo y de cómo cargar el código fuente del ejemplo, se localizan en el Anexo A - Instalación/Configuración del ejemplo práctico WorldTime de este trabajo. 7.1 Objetivo

Que la Entidad Solicitante, al especificar el nombre de una ciudad del mundo, pueda solicitar mediante Web Services a la Entidad Proveedor, la fecha y hora actual de dicha ciudad. 7.2 Entidades Participantes 7.2.1 Entidad Solicitante Un usuario trabajando de forma local en su computadora.

7.2.2 Agente Solicitante El BEA Workshop Test Browser, el cual permite realizar una interacción manual con el Web Service paso a paso.

7.2.3 Entidad Proveedor Una empresa ficticia que provee servicios de información del tiempo.

7.2.4 Agente Proveedor Un EJB (Entrerprise Java Bean) ejecutándose en el WebLogic Server que expone sus métodos (operaciones WSDL) a través de Web Services. 7.3 Caso de Uso del ejemplo WorldTime El caso de uso del ejemplo WorldTime se muestra gráficamente en la Figura 6.



Figura 6. Caso de Uso del ejemplo WorldTime. 7.4 Explicación de los Cuatro Pasos Utilizados en la Invocación del Web Service Ejemplo[2] 7.4.1 Las entidades se conocen La Entidad Solicitante y Proveedor saben el uno del otro, en el sentido de que la parte que inicie la interacción deberá estar al tanto de la otra parte. El ejemplo es un caso básico en donde la Entidad Solicitante (usuario) no tiene que buscar de forma dinámica (mediante una consulta a un registro UDDI) a una Entidad Proveedor que le ofrezca el Web Service. Para la Entidad Solicitante sólo hay una Entidad Proveedor (empresa ficticia), y ésta le es conocida. 7.4.2 Acuerdo sobre la descripción del servicio y semántica La Entidad Solicitante y Proveedor concuerdan en la descripción del servicio y semántica que regirá la interacción entre los Agentes Solicitante y Proveedor, y 7.4.3 Implementación de la descripción del servicio y semántica La descripción del servicio y semántica son alimentadas a, o conformadas en, ambos Agentes Solicitante y Proveedor como apropiadas.



Para el ejemplo no es necesario que la Entidad Solicitante (usuario) y Proveedor (empresa ficticia) tengan que comunicarse para acordar sobre la descripción del servicio ofertado por la Entidad Proveedor. El acuerdo existe previamente de forma implícita ya que ambos Agentes tienen codificado el entendimiento de la descripción del servicio. El Agente Proveedor (WorldTime.ejb) no tiene que adaptarse a un entendimiento ya que este Agente impone las características del servicio. Por otra parte, el Agente Solicitante (BEA Workshop Test Browser) conoce la descripción del servicio que le ofrecen mediante el EJBControlWorldTimeTestContract.wsdl. En el ejemplo no es necesario que exista un acuerdo entre las Entidades sobre la semántica del servicio (combinaciones de secuencias de operaciones) porque sólo existe una Entidad Proveedor y ésta ofrece solamente una operación (método) en el servicio. De tal forma, la invocación del servicio resulta atómica (indivisible). La operación que se provee en el servicio es que, dado el nombre de una ciudad, se obtiene la fecha y hora actual de la misma. Método: String getCityTimeAndDate(String city) Los seis elementos principales de EJBControlWorldTimeTestContract.wsdl A continuación se revisa en su totalidad la definición de la interfase EJBControlWorldTimeTestContract.wsdl. Para cada uno de los seis elementos principales que conforman la definición, se analiza la sección de código (extracto) correspondiente al elemento en cuestión Se presenta de forma compacta (únicamente expandido hasta el primer nivel) la descripción de servicio en el XML EJBControlWorldTimeTestContract.wsdl (ver Listado 1). El archivo se puede revisar en su forma totalmente expandida consultando el código fuente que se anexa en el CD que acompaña este trabajo.



1 - <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:conv="http://www.openuri.org/2002/04/soap/conversation/" xmlns:cw="http://www.openuri.org/2002/04/wsdl/conversation/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:jms="http://www.openuri.org/2002/04/wsdl/jms/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://www.openuri.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" targetNamespace="http://www.openuri.org/"> 2 + <types></types> 3 + <message name="startTestDriveSoapIn"></message> 4 + <message name="startTestDriveSoapOut"></message> 5 + <message name="finishTestDriveSoapIn"></message> 6 + <message name="finishTestDriveSoapOut"></message> 7 + <message name="createSoapIn"></message> 8 + <message name="createSoapOut"></message> 9 + <message name="getCityTimeAndDateSoapIn"></message> 10 + <message name="getCityTimeAndDateSoapOut"></message> 11 <message name="startTestDriveHttpGetIn"/> 12 <message name="startTestDriveHttpGetOut"/> 13 <message name="finishTestDriveHttpGetIn"/> 14 <message name="finishTestDriveHttpGetOut"/> 15 <message name="createHttpGetIn"/> 16 <message name="createHttpGetOut"/> 17 + <message name="getCityTimeAndDateHttpGetIn"></message> 18 + <message name="getCityTimeAndDateHttpGetOut"></message> 19 <message name="startTestDriveHttpPostIn"/> 20 <message name="startTestDriveHttpPostOut"/> 21 <message name="finishTestDriveHttpPostIn"/> 22 <message name="finishTestDriveHttpPostOut"/> 23 <message name="createHttpPostIn"/> 24 <message name="createHttpPostOut"/> 25 + <message name="getCityTimeAndDateHttpPostIn"></message> 26 + <message name="getCityTimeAndDateHttpPostOut"></message> 27 + <message name="StartHeader_literal"></message> 28 + <message name="ContinueHeader_literal"></message> 29 + <portType name="EJBControlWorldTimeTestSoap"></portType> 30 + <portType name="EJBControlWorldTimeTestHttpGet"></portType> 31 + <portType name="EJBControlWorldTimeTestHttpPost"></portType> 32 + <binding name="EJBControlWorldTimeTestSoap" type="s0:EJBControlWorldTimeTestSoap"></binding> 33 + <binding name="EJBControlWorldTimeTestHttpGet" type="s0:EJBControlWorldTimeTestHttpGet"></binding> 34 + <binding name="EJBControlWorldTimeTestHttpPost" type="s0:EJBControlWorldTimeTestHttpPost"></binding> 35 + <service name="EJBControlWorldTimeTest"></service> 36 </definitions>

Listado 1. EJBControlWorldTimeTestContract.wsdl en su forma compacta.

definitions Están declarados múltiples contextos con funciones específicas, entre los cuales destaca xmlns:s=”http://www.w3.org/2001/XMLSchema” que es el schema por default que sugiere utilizar la W3C para el estándar de XML Schema. Por convención, se utiliza el dominio de www.openuri.org como base para formar contextos evitando ambigüedades en el nombre de elementos y atributos del resto del documento (ver Listado 1, línea 1). types Entre los tipos de datos utilizados entre el cliente y el servidor, destacan los del método getCityTimeAndDate() del WorldTime.ejb. El elemento getCityTimeAndDate de tipo String es el parámetro que recibe el método (ver Listado 2, líneas 2-8), y el elemento getCityTimeAndDateResult también de tipo String es el valor de regreso del método mencionado (ver Listado 2, líneas 9-15).



También cabe resaltar que los headers de los mensajes Soap hacen referencia al elemento conversationID de tipo String (ver Listado 2, líneas 23,29 y 34), que es utilizado para implementar el mecanismo de conversación mediante un identificador único en el intercambio de mensajes.

… 1 <s:schema elementFormDefault="qualified" targetNamespace="http://www.openuri.org/" xmlns:s="http://www.w3.org/2001/XMLSchema">

… 2 <s:element name="getCityTimeAndDate"> 3 <s:complexType> 4 <s:sequence> 5 <s:element name="arg0" type="s:string" minOccurs="0"/> 6 </s:sequence> 7 </s:complexType> 8 </s:element> 9 <s:element name="getCityTimeAndDateResponse"> 10 <s:complexType> 11 <s:sequence> 12 <s:element name="getCityTimeAndDateResult" type="s:string" minOccurs="0"/> 13 </s:sequence> 14 </s:complexType> 15 </s:element>

… 16 </s:schema> 17 <s:schema elementFormDefault="qualified" targetNamespace="http://www.openuri.org/2002/04/soap/conversation/"> 18 <s:element name="StartHeader" type="conv:StartHeader"/> 19 <s:element name="ContinueHeader" type="conv:ContinueHeader"/> 20 <s:element name="CallbackHeader" type="conv:CallbackHeader"/> 21 <s:complexType name="StartHeader"> 22 <s:sequence> 23 <s:element minOccurs="0" maxOccurs="1" name="conversationID" type="s:string"/> 24 <s:element minOccurs="0" maxOccurs="1" name="callbackLocation" type="s:string"/> 25 </s:sequence> 26 </s:complexType> 27 <s:complexType name="ContinueHeader"> 28 <s:sequence> 29 <s:element minOccurs="1" maxOccurs="1" name="conversationID" type="s:string"/> 30 </s:sequence> 31 </s:complexType> 32 <s:complexType name="CallbackHeader"> 33 <s:sequence> 34 <s:element minOccurs="1" maxOccurs="1" name="conversationID" type="s:string"/> 35 </s:sequence> 36 </s:complexType> 37 </s:schema> …

Listado 2. Extracto EJBControlWorldTimeTestContract.wsdl – Tipos de datos.

message De los mensajes definidos destacan, el mensaje de solicitud de la fecha y hora de una ciudad getCityTimeAndDateSoapIn (ver Listado 3, líneas 1-3), y su respectivo mensaje de contestación getCityTimeAndDateSoapOut (ver Listado 3, líneas 4-6).



… 1 <message name="getCityTimeAndDateSoapIn"> 2 <part name="parameters" element="s0:getCityTimeAndDate"/> 3 </message> 4 <message name="getCityTimeAndDateSoapOut"> 5 <part name="parameters" element="s0:getCityTimeAndDateResponse"/> 6 </message> …

Listado 3. Extracto EJBControlWorldTimeTestContract.wsdl – Mensajes. portType De la combinación de mensajes resultan definidas cuatro operaciones. La operación principal es getCityTimeAndDate (ver Listado 4, líneas 14-17) que realmente es el método que expone el EJB. Las operaciones startTestDrive (ver Listado 4, líneas 2-5) y finishTestDrive (ver Listado 4, líneas 6-9) son forzosamente requeridas en cualquier implementación de un intercambio conversacional (como lo es el ejemplo) para marcar el inicio y finalización, respectivamente, de la conversación. Por último, la operación create (ver Listado 4, líneas 10-13) debe existir para proveer un mecanismo de inicialización en la conversación.

El ejemplo no requiere de inicialización alguna, por lo que esta operación no será utilizada, sin embargo pudo haberse implementado un ejemplo más complejo, en donde la inicialización podría establecer el idioma (locale) subsecuente a utilizar en cada solicitud de fecha y hora de una ciudad, siendo el mismo idioma utilizado para la respuesta de la solicitud.

… 1 <portType name="EJBControlWorldTimeTestSoap"> 2 <operation name="startTestDrive"> 3 <input message="s0:startTestDriveSoapIn"/> 4 <output message="s0:startTestDriveSoapOut"/> 5 </operation> 6 <operation name="finishTestDrive"> 7 <input message="s0:finishTestDriveSoapIn"/> 8 <output message="s0:finishTestDriveSoapOut"/> 9 </operation> 10 <operation name="create"> 11 <input message="s0:createSoapIn"/> 12 <output message="s0:createSoapOut"/> 13 </operation> 14 <operation name="getCityTimeAndDate"> 15 <input message="s0:getCityTimeAndDateSoapIn"/> 16 <output message="s0:getCityTimeAndDateSoapOut"/> 17 </operation> 18 </portType> …

Listado 4. Extracto EJBControlWorldTimeTestContract.wsdl – Operaciones. binding Se define que el servicio del ejemplo se implementará en la red mediante el uso de SOAP sobre HTTP (ver Listado 5, línea 2).



… 1 <binding name="EJBControlWorldTimeTestSoap" type="s0:EJBControlWorldTimeTestSoap"> 2 <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

... 3 <operation name="getCityTimeAndDate"> 4 <soap:operation soapAction="http://www.openuri.org/getCityTimeAndDate" style="document" /> 5 <cw:transition phase="continue" /> 6 <input> 7 <soap:body use="literal" /> 8 <soap:header wsdl:required="true" message="s0:ContinueHeader_literal" part="ContinueHeader" use="literal" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" /> 9 </input> 10 <output> 11 <soap:body use="literal" /> 12 </output> 13 </operation>

... 14 </binding> …

Listado 5. Extracto EJBControlWorldTimeTestContract.wsdl – Implementaciones del Servicio. service Se define la dirección (URL) donde se puede invocar el servicio del ejemplo denominado EJBControlWorldTimeTest (ver Listado 6, línea 3).

... 1 <service name="EJBControlWorldTimeTest"> 2 <port name="EJBControlWorldTimeTestSoap" binding="s0:EJBControlWorldTimeTestSoap"> 3 <soap:address location="http://localhost:7001/WEBPWorldTime/Controls/EJBControlWorldTimeTest.jws" /> 4 </port>

... 5 </service>

...

Listado 6. Extracto EJBControlWorldTimeTestContract.wsdl – Dirección del Servicio. 7.4.4 Intercambio de mensajes El Agente Solicitante y el Agente Proveedor intercambian mensajes SOAP a nombre de sus propietarios.



7.5 Ejecución de la aplicación ejemplo[17]

Se deberá ejecutar el Web Service EJBControlWorldTimeTest.jws (posicionarse en dicho archivo dándole doble click, luego oprimir las teclas Ctrl+F5 o accesar la opción de los menús superiores Debug Start). Posteriormente se debe confirmar que sí se desea levantar el servicio del BEA WebLogic Server (application server).

Después de unos instantes aparecerá en pantalla el BEA Workshop Test Browser (maximizarlo preferentemente). Para que el browser permita ir ejecutando paso a paso el ejemplo, manipulando los mensajes SOAP a emitir, así como visualizar los mensajes SOAP a recibir, es necesario seleccionar la pestaña de Test XML (ver Figura 7).

Figura 7. BEA Workshop Test Browser listo para iniciar paso a paso la ejecución del ejemplo. 7.5.1 Intercambio conversacional de mensajes, implementado bajo un patrón de solicitud y respuesta Para iniciar el intercambio conversacional de mensajes es necesario ejecutar la operación startTestDrive.



Figura 8. Ejecución de la operación startTestDrive.

Se observa que a la conversación iniciada le fue asignado el identificador único 1100457755796 por la misma plataforma de prueba, y este identificador se conservará a lo largo de toda la conversación no importando cuánto dure ésta (ver Figura 8). Para continuar con la conversación del ejemplo, es necesario seleccionar la opción Continue this conversation. De igual forma, esto se tendrá que realizar cada vez que se obtenga un mensaje de respuesta y se desee continuar con dicha conversación. Cabe resaltar que cada vez que se opta por continuar la conversación, la plataforma de pruebas le muestra al usuario todas las operaciones disponibles bajo el Web Service con el que se está interactuando. Para cada operación la plataforma de pruebas pre-construye la estructura XML que corresponde a los argumentos que recibirá dicha operación y el usuario sólo debe sustituir los valores machote de los argumentos por los valores reales. Estos argumentos contenidos en la estructura XML, forman parte del mensaje SOAP que se le enviará al agente proveedor del Web Service. Se procede a ejecutar la operación getCityTimeAndDate definiendo como su argumento la ciudad de Paris (ver Figura 9), observando que el Web Service responde con la fecha y hora actual de Paris (ver Figura 10).



Figura 9. Definición de la operación getCityTimeAndDate con parámetro Paris.



Figura 10. Ejecución de la operación getCityTimeAndDate con parámetro Paris.



A continuación se ejecuta la operación getCityTimeAndDate definiéndose como argumento la ciudad de Lisboa (ver Figura 11), la cual se sabe de antemano que no está registrada, lo que se corrobora al observar que el Web Service contesta con el mensaje Lisboa, es una ciudad que no está registrada (ver Figura 12).

Figura 11. Definición de la operación getCityTimeAndDate con parámetro Lisboa.



Figura 12. Ejecución de la operación getCityTimeAndDate con parámetro Lisboa.



Finalmente se selecciona y ejecuta la operación finishTestDrive (ver Figura 13) y se da por concluida la conversación por ambos agentes, solicitante y proveedor (ver Figura 14).

Figura 13. Selección de la operación finishTestDrive.



Figura 14. Ejecución de la operación finishTestDrive.



8. Conclusiones Los resultados alcanzados al implementar el ejemplo práctico WorldTime permiten observar que el objetivo planteado se logró alcanzar utilizando la metodología propuesta. Es decir, la plataforma de desarrollo elegida permite de una forma fácil para el desarrollador que incursiona en los Web Services, implementar aplicaciones que se rigen por la arquitectura orientada a servicios que utilizan los Web Services. Sin embargo, el haber llegado a este alto nivel de implementación se debe a los siguientes puntos: a) Se optó por utilizar la plataforma BEA WebLogic 8.1 que contiene un ambiente de desarrollo y pruebas que requieren poca intervención manual, permitiéndole al programador a que se enfoque únicamente en la lógica de negocio; aislándolo de los inconvenientes que conllevan los detalles de publicar una aplicación desarrollada en un servidor de aplicaciones.

b) El hecho de no haber utilizado las herramientas enfocadas al desarrollo de Web Services propias de Java, permitió de forma menos compleja implementar y ejecutar un Web Service totalmente funcional.

c) Sería deseable explorar en este tipo de ejemplos la utilización de otras plataformas para implementar Web Services como el uso de productos propietarios que incluyen ambientes de desarrollo y prueba, así como de productos no propietarios que generalmente están limitados en su alcance por ser herramientas que requieren de un considerable esfuerzo de programación para integrarlas y proveer el ambiente necesario de implementación.

Por lo tanto las conclusiones son:

• La metodología propuesta en este trabajo muestra un camino fácil, paso a paso, para la implementación de Web Services.

• El ejemplo práctico específico que se seleccionó cumple con los lineamientos de la arquitectura de los Web Services. Sin embargo sería conveniente explorar la implementación de ejemplos más complejos que utilicen múltiples servicios simples para formar un servicio más complejo.

• La organización de este trabajo logra didácticamente introducir de una manera directa a un ingeniero de sistemas ajeno a estas tecnologías en poco tiempo.

• Por otra parte, este trabajo le brinda a un desarrollador experimentado ajeno a los Web Services, una nueva forma de construir aplicaciones, brindándole flexibilidad de escalación y mantenimiento, lo que generalmente las arquitecturas tradicionales proporcionan con mucha dificultad.

Finalmente este trabajo permitió observar en su ejemplo práctico el uso de un

Web Service simple, por lo tanto quedaría pendiente a manera de perspectiva si esta metodología permite implementar un Web Service complejo. Tomando como base que un Web Service complejo es la combinación de diferentes Web Services simples que son invocados en diversas secuencias por la misma complejidad del servicio.



El utilizar la arquitectura de Web Services para implementar aplicaciones complejas promete ser una solución a la constante dificultad de interoperabilidad para proveer servicios en ambientes distribuidos; que a su vez buscan obtener servicios aún más complejos. Esta visión precisamente es la cresta de la ola del estado de la técnica que actualmente se explora tanto en empresas como universidades.



Anexo A1 – Instalación/Configuración del ejemplo práctico WorldTime [17]

En el CD que acompaña este trabajo se incluye en una carpeta de nombre WorldTime, el código fuente de la aplicación ejemplo. Para cargar la aplicación en el entorno de desarrollo BEA WebLogic Workshop es necesario cargar el archivo maestro WorldTime.work.

El instalador del ambiente de desarrollo BEA WebLogic 8.1 se incluye (únicamente versión para Windows) en el CD que acompaña este trabajo en una carpeta de nombre bea_weblogic_platform_8.1_sp3. También se puede descargar el instalador, tanto la versión para Windows como la versión para Linux, del sitio web de BEA: http://commerce.bea.com/downloads/products.jsp

Cabe especificar que este ambiente de desarrollo se puede utilizar sin restricción alguna para desarrollar, sin embargo, para un uso comercial liberando en ambiente de producción es obligatorio comprar la licencia. Un servidor no licenciado está limitado (candado por software) aproximadamente al 3% de su rendimiento total. A1.1 Código fuente del ejemplo Como se mencionó anteriormente, el código fuente del ejemplo se incluye en el CD que acompaña este trabajo, en una carpeta de nombre WorldTime. En dicho directorio se encuentra un archivo de nombre WorldTime.zip. (es necesario descomprimir el zip para extraer su contenido). Todos los archivos y subdirectorios contenidos en dicho zip constituyen una aplicación, desde el punto de vista del ambiente de desarrollo BEA. La lógica de negocio que expone el Web Service está dada por el EJB WorldTime.ejb, el cual incluye un solo método llamado getCityTimeAndDate() (ver Listado 7, líneas 1-17). 1 public String getCityTimeAndDate(String city) 2 { 3 String timeAndDate; 4 5 try 6 { 7 Time cityTime = new Time("Mexico"); 8 timeAndDate = "En " + city + " son las " + cityTime.getTime(city) + 9 " del día " + cityTime.getDate(city); 10 } 11 catch (CityNotFoundException cnfe) 12 { 13 timeAndDate = city + ", es una ciudad que no está registrada"; 14 } 15 16 return timeAndDate; 17 }

Listado 7. Código fuente método getCityTimeAndDate() – WorldTime.ejb.



Como se puede observar por la simplicidad del EJB, la lógica de negocio a su vez depende de la clase Time.java que expone dos métodos (ver Figura 15): String getTime(String city); String getDate(String city);

Figura 15. Diagrama de la clase Time.

El API (generalmente conocido por los programadores como el javadoc) de dicha clase, también se encuentra contenida en el código fuente de la aplicación la cual se localiza en el CD que acompaña a este trabajo. A1.2 Requisitos de Software Locales (Windows o Linux)

1) Disponibilidad del puerto 7001 para el uso del protocolo HTTP. 2) Software instalador de BEA WebLogic 8.1.

A1.3 Pasos para Instalar/Configurar el ejemplo

1) Instalar localmente todos los componentes del BEA WebLogic 8.1 (Se recomienda contar con 1GB mínimo de espacio en disco duro, así como de 256MB mínimo de memoria RAM). Configurar que el directorio raíz de instalación preferentemente sea C:\bea o bien un directorio alterno que se encuentre bajo una ruta que no contenga espacios en su nombre, ya que causaría conflicto con las rutas que Java puede procesar (inconveniencia de utilizar Java en Windows).

2) Invocar el BEA WebLogic Worshop.

3) Cargar la aplicación ejemplo abriendo el archivo maestro WorldTime.work (ver

Figura 16)



Figura 16 . Carga de la aplicación abriendo WorldTime.work.

4) Con un propósito didáctico, identificar el EJB WorldTime.ejb que contiene la lógica de negocio a exportarse vía Web Services. Dicho EJB contiene solamente un método: String getCityTimeAndDate(String city) (ver Figura 17)

Figura 17. Único método, getCityTimeAndDate(), de WorldTime.ejb.



5) También con un propósito didáctico, identificar el Web Service ejemplo EJBControlWorldTimeTest.jws, dándole doble-click (ver Figura 18).

Figura 18. EJBControlWorldTimeTest Web Service.



Anexo A2 – Glosario A2.1 HTTP (Hypertext Transfer Protocol)[18]

Formalmente es un protocolo de aplicación (modelo OSI) el cual es utilizado (por default por los web browsers) para transferir a través de la WWW (World Wide Web) virtualmente todos los archivos y otros datos, ya sean archivos HTML, imágenes, resultados de consultas a bases de datos, etc. Generalmente, HTTP utiliza sockets TCP/IP y el puerto asociado por default es el 80.

Ligas de interés:

HTTP - Hypertext Transfer Protocol, W3C http://www.w3c.org/Protocols/

A2.2 HTML (HyperText Markup Language) [19]

Conjunto de símbolos (códigos) insertados en un archivo (de texto) para ser desplegado como página en un web browser. Los símbolos le indican al browser cómo desplegarle al usuario las palabras e imágenes de la página web. A cada símbolo individual se le refiere como elemento, pero comúnmente se le conoce como etiqueta (tag). La mayoría de las etiquetas se especifican en pares, indicando dónde inicia y dónde termina un efecto de despliegue.

Ligas de interés:

HyperText Markup Language (HTML) Home Page, W3C http://www.w3c.org/MarkUp/

A2.3 XML (eXtensible Markup Language)[20]

Diseñado para mejorar la funcionalidad de la Web al proveer un mecanismo de identificación de información, más flexible y adaptable. Se le nombró extensible porque no es un formato fijo como HTML (un lenguaje único predefinido de símbolos). En cambio, XML realmente es un metalenguaje, un lenguaje que describe otros lenguajes, lo que permite el diseño de lenguajes de símbolos personalizados para un conjunto ilimitado de diferentes tipos de documentos.

Mientras que HTML especifica cómo debe desplegarse la información

(representación), XML identifica la información (da una idea de qué significa y cómo debe interpretarse).

Ligas de interés:

Extensible Markup Language (XML), W3C http://www.w3c.org/XML/



Understanding XML, Sun Microsystems http://java.sun.com/webservices/docs/1.0/tutorial/doc/IntroXML.html

A2.4 XML Schema[21]

Es un estándar complejo para XML que está conformado de dos partes. Una parte especifica las relaciones de la estructura. La otra parte especifica mecanismos para validar el contenido de los elementos XML, mediante la definición del tipo de dato de cada elemento.

Ligas de interés:

XML Schema, W3C http://www.w3c.org/XML/Schema

A2.5 Lenguaje de programación Java[22]

Java es un lenguaje de programación de alto nivel orientado a objetos desarrollado principalmente por Sun Microsystems. Su sintaxis proviene de C++ y es independiente de la plataforma, ya que un mismo programa debe ejecutarse similarmente en hardware diferente.

Java es un lenguaje muy poderoso para el desarrollo de aplicaciones Web principalmente. Cuenta con muchas extensiones y arquitecturas relacionadas, entre otras:

J2ME platform - Java 2 Platform Micro Edition J2SE platform - Java 2 Platform Standard Edition J2EE platform - Java 2 Platform Enterprise Edition JSP - Java Server Pages JDBC - Java Database Connectivity JNDI - Java Naming and Directory Interface Ligas de interés:

The Java Tutorial – A practical guide for programmers, Sun Microsystems http://java.sun.com/docs/books/tutorial/index.html

Java 2 Platform, Enterprise Edition (J2EE), Sun Microsystems http://java.sun.com/j2ee/index.jsp

Java Reference Glossary http://java.sun.com/docs/glossary.html

Eclipse open extensible IDE http://www.eclipse.org



Bibliografía [1] John Edwards, Leveraging Web Services: Planning, Building, and Integration for Maximum Impact (eBook), AMACOM, 2004, páginas 2-6 [2] Web Services Architecture, W3C Working Group Note, 11/Febrero/2004, ver http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ [3] Finding Your Way at W3C, 27/Marzo/2002, ver http://www.w3c.org/2002/03/new-to-w3c [4] W3C …in 7 points, 15/Enero/2003, ver http://www.w3.org/Consortium/Points/ [5] World Wide Web Consortium (W3C) Members, 16/Junio/2004, ver http://www.w3.org/Consortium/Member/List/ [6] W3C Activities, 13/Abril/2004, ver http://www.w3.org/Consortium/Activities [7] Web Services Activity Statement, 28/Abril/2004, ver http://www.w3c.org/2002/ws/Activity.html [8] Web Services Architecture Usage Scenarios, W3C Working Group Note, 11/Febrero/2004, ver http://www.w3.org/TR/ws-arch-scenarios/ [9] W3Schools, Introduction to SOAP, ver http://www.w3schools.com/soap/soap_intro.asp [10] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, 24/Junio/2003, ver http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ [11] SOAP Version 1.2 Specification Assertions and Test Collection, W3C Recommendation, 24/Junio/2003, ver http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/ [12] Ethan Cerami, WSDL Essentials - Web Services Essentials (eBook), O'Reilly & Associates, capítulo 6, febrero/2002, páginas 120-121, ver http://www.developer.com/services/article.php/1602051 [13] Satya Komatineni, Understanding UDDI and JAXR, 27/Febrero/2002, ver http://www.onjava.com/pub/a/onjava/2002/02/27/uddi.html [14] Universal Description Discovery Integration (UDDI) standard, WebServices Mall, ver http://www.webservicesmall.com/profile.asp?pid=105



[15] Tom Bellwood, Understanding UDDI - Tracking the evolving specification, WebServices Mall, IBM, 01/Julio/2002 ver http://www-106.ibm.com/developerworks/webservices/library/ws-featuddi/ [16] OASIS UDDI Register, 16/Septiembre/2003 ver http://www.uddi.org/register.html [17] Building Web Services, BEA WebLogic Workshop Help (Online), 22/Noviembre/2004, ver http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html [18] What is HTTP?, James Marshall, 15/Agosto/1997, ver http://jmarshall.com/easy/http/ [19] HTML, searchWebServices.com Definitions, 2004, ver http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212286,00.html [20] The XML FAQ, Peter Flynn, 01/Mayo/2004, ver http://www.ucc.ie/xml/ [21] XML and Related Spces: Digesting the Alphabet Soup, Sun Microsystems, 07/Agosto/2004, ver http://java.sun.com/webservices/docs/1.0/tutorial/doc/IntroXML3.html [22] Java programming language, Wikipedia-The Free Encyclopedia, 18/Noviembre/2004, ver http://en.wikipedia.org/wiki/Java_programming_language

introducción a los web services148.206.53.84/tesiuami/uami11732.pdf · • la arquitectura...

Documents