Comprender las especificaciones de servicios web, Parte 6: WS-Interoperability

El objetivo de los servicios web es permitir la comunicación entre distintos sistemas de software y hardware. Estos sistemas difieren típicamente en sus configuraciones de hardware y de software. Estas diferencias se han superado a través de la definición de protocolos estándar, como los utilizados en la construcción de servicios web. Ocasionalmente surgen temas de incompatibilidad incluso cuando se utilizan estos protocolos estándar, los cuales pueden conducir a problemas de interoperabilidad, Este tutorial, Parte 6 de la serie "Understanding web services specifications", explica la naturaleza y el origen de los problemas de interoperabilidad de los servicios web. Este tutorial le presenta también el Perfil Básico WS-I, que es un conjunto de pautas que deben respetar los servicios web para lograr una interoperabilidad óptima.

Manas Mandal, Architect, Consultant

Manas Mandal es arquitecto de una empresa de desarrollo de productos con sede en India. Se especializa en desarrollo basado en Java, J2EE, servicios web y BPEL. Tiene más de 10 años de experiencia en servicios de software y desarrollo de productos.



Hernan Silberman, Freelance Writer, Freelance Developer

Hernan Silberman es ingeniero de software, vive en San Francisco y trabaja para un importante estudio de animación ubicado en Silicon Valley. Se especializa en la construcción de aplicaciones distribuidas.



08-08-2011

Antes de comenzar

En este tutorial aprenderá sobre la Interoperabilidad de los servicios web, o WS-Interoperability. Este tutorial está destinado a programadores que arman servicios web y desean asegurar que sus servicios estén diseñados para funcionar bien para la mayor cantidad de usuarios potenciales. Comprender los verdaderos problemas del mundo de la interoperabilidad que afectan a los servicios web y las mejores prácticas que se pueden aplicar para evitarlos puede marcar la diferencia entre un servicio web que es fácil de manejar para los usuarios y uno que está lleno de problemas.

A fin de comprender este tutorial, debe tener una comprensión básica del Protocolo simple de acceso a objetos (SOAP) y las tecnologías relacionadas, como por ejemplo WSDL. Los ejemplos de este tutorial utilizan Java™ y el kit de herramientas SOAP Apache Axis2 SOAP. Lea los primeros cinco tutoriales de esta serie, especialmente la Parte1 y la Parte 2, para obtener una mejor compresión.

Acerca de esta serie

Esta serie tutorial enseña los conceptos básicos de los servicios web siguiendo las hazañas del periódico ficticio, Daily Moon, personal utiliza servicios web para crear un sistema de flujo de trabajo para incrementar la productividad en este entorno competitivo.

La Parte 1 empieza simplemente, explicando los conceptos básicos de los servicios web y mostrándole cómo utilizar SOAP, la especificación que subyace en la mayoría de lo que vendrá, y conecta el departamento de clasificados con el Sistema de Gestión de Contenido.

La Parte 2 lleva las cosas un poco más allá, al explicar cómo usar Web Services Description Language (WSDL) para definir los mensajes producidos como se espera por el servicio web, lo que le permite al equipo crear servicios y a los clientes que se conectan a ellos con más facilidad.

La Parte 3 encuentra al equipo con una cantidad de servicios implementados y un deseo de ubicarlos con facilidad. En respuesta, Universal Description, Discovery and Integration (UDDI) provee un registro que permite realizar búsquedas de servicios disponibles a una manera de publicitar sus propios servicios a otros.

En la Parte 4, Rudy, editor deDaily Moon, decide que el periódico necesita implementar mejores procedimientos de seguridad para servicios web que acceden a sus sistemas internos.

La Parte 5 muestra los cambios que deben hacer los equipos para acceder a esos servicios recientemente protegidos.

Esta Parte 6 de la serie trata del armado de la verificación de los servicios web interoperables. Los miembros del personal del periódico ya conocen la importancia que tiene el llegar al mayor público posible, así que deciden analizar sus servicios web para asegurarse de que a cualquiera que quiera utilizarlos le resulte fácil hacerlo.

Finalmente, la Parte 7 muestra cómo utilizar Lenguaje de ejecución de procesos de negocios para servicios web (WS-BPEL) para crear aplicaciones complejas desde servicios individuales.

Acerca de este tutorial

En la Parte 6 de esta serie tutorial de servicios web, el personal de Daily Moon trabaja para asegurar que sus servicios web sean lo más interoperativos posible. Los miembros del personal están seguros de que los servicios cumplen los requisitos comerciales con los que empezaron, pero no están seguros de que los servicios funcionarán para todos los que deseen utilizarlos. Anteriormente los problemas de interoperabilidad eran comunes en los servicios web debido al gran alcance de las especificaciones SOAP y WSDL originales, y debido a que la interpretación de las especificaciones quedaba al albedrío de los desarrolladores, lo que condujo a implementaciones incompatibles. Estos problemas se han resuelto a través de la experiencia y la adopción de un conjunto de mejores prácticas como se especifica en el Perfil Básico WS-I.

Para Daily Moon (y la mayoría de las organizaciones), la presión yace en garantizar la mayor circulación posible de los servicios web de la organización, así que las organizaciones investigan el tema para asegurarse de que sus servicios web no tengan problemas de interoperabilidad.

Este tutorial le enseña sobre los problemas de interoperabilidad del servicio web con un enfoque práctico. Las partes anteriores de esta serie le mostraron cómo incorporar un servicio web a su propio software y cómo armar sus propios servicios. La sexta entrega se apoya en las anteriores y se concentra en lo que usted puede hacer para asegurarse de que los servicios web que produce son fáciles y libres de problemas para los programadores que los utilizarán.

Prerrequisitos

El código utilizado en este tutorial no es específico para ningún lenguaje o entorno de programación. Los ejemplos brindados son los mismos utilizados durante toda esta serie tutorial. Para seguir los ejemplos debe tener el siguiente software instalado:

Java 2 Standard Edition versión 1.4.2 o superior - Todas estas herramientas están basadas en Java, al igual que los servicios y clientes que armará en este tutorial.

Apache Axis2 versión 1.0 Axis2 es un kit de herramientas SOAP de funciones completas que brindan implementaciones de varias API de servicio web que incluyen SOAP y WSDL. Un kit de herramientas como Axis2 es invaluable cuando se trata del desarrollo de servicios web. Existen kits de herramientas de alcance similar para otros lenguajes y entornos de programación. El proyecto Axis en Apache tiene una larga historia y se originó con un esfuerzo de IBM llamado SOAP4J.

Apache Geronimo u otro servidor de aplicación – Esta serie tutorial utiliza el servidor Apache Geronimo J2EE (que es la base del servidor IBM WebSphere® Community Edition). Puede utilizar otros servidores de aplicación, pero Geronimo es simple, liviano y gratuito, así que es una buena elección para instalar y ejecutar rápidamente.


Generalidades

Este tutorial comienza con un rápido panorama del paisaje de los servicios web y una introducción a los problemas de interoperabilidad y sus orígenes.

Comprender la necesidad de servicios web

Durante una generación, los programadores han estado armando programas de software que hablan entre ellos. En la actualidad, cada lenguaje de programación viene con bibliotecas de software que hacen que la programación de redes sea posible, fácil y predecible.

No solo hay herramientas de bajo nivel para enviar bits de una computadora a otra, sino que también hay protocolos de alto nivel como HTTP que brindan un conjunto de reglas comunes que hacen posible que dos programas conversen, a pesar de que los construyeron de manera independiente personas diferentes y se implantaron en diferentes máquinas y sistemas de software. Imagine lo que pasa, por ejemplo, cuando hace clic en un enlace de su navegador Web y carga una página que jamás ha visto. A través de la adopción de unos pocos estándares (HTTP, HTML, TCP/IP), su navegador Web puede llamar a otros sistema de computadora, capturar una página Web y presentársela a usted. Este tipo de red de software no planeado y dinámico es potente. Los servicios web son un intento de ampliar este poder a los desarrolladores de sistemas empresariales.

Ver la complejidad y el desafío

Al igual que hay diferencias en la manera en que Microsoft® Internet Explorer y Mozilla Firefox interpretan algunas páginas Web, hay diferencias en cómo dos programas de servicios web interpretan los mensajes SOAP que intercambian entre ellos. Como puede imaginar, estas diferencias pueden dar como resultado problemas serios que son difíciles de resolver. Los mejores diseñadores Web dedican mucho tiempo y energía a comprender como funcionan sus diseños en un conjunto de navegadores distintos, y hacen pruebas como locos para asegurarse de que sus HTML, CSS y Javascript funcionen de manera adecuada en cada uno. Hay estándares y especificaciones que formalizan HTML, CSS y Javascript, pero estas especificaciones se han interpretado de maneras diversas, y los navegadores no son inmunes a errores y ambigüedades. El resultado es que estas especificaciones se han interpretado de maneras diversas y no todos los navegadores se comportan de la misma manera. Lo mismo ocurre con las especificaciones que definen las diversas tecnologías de servicios web, como SOAP, WSDL, UDDI, XML Schema y HTTP.

A pesar de la simplicidad que inspiraron los servicios web, la construcción actual de servicios web exige know-how y paciencia, como ejemplifica esta serie tutorial. Para armar servicios web en la actualidad, debe ser un programador experimentado que conozca al menos un lenguaje y entorno de programación. Debe conocer las redes informáticas y una familia de tecnologías estándar utilizadas en los servicios web actuales, como XML, SOAP, WSDL o XML Schema. También debe comprender una cantidad de técnicas prácticas necesarias para utilizar estas tecnologías — y hay muchas —.

Imagine que realiza este ejercicio de capacitación sustancias (puede llamarlo carrera) e intenta conectar su software a otra porción de software que utiliza servicios web solo para descubrir que no funciona. Este escenario no solo es increíblemente frustrante, sino que también es bastante común (generalmente cuando tiene tiempos de desarrollo acotados).

Respetar mejores prácticas y disciplina

Para ayudar a catalogar y solucionar estos problemas de interoperabilidad, un grupo de ingenieros conocido como la Web Services Interoperability Organization (WS-I) ha producido un conjunto de recomendaciones para desarrolladores servicios web que, si se siguen, pueden ayudar a producir servicios web y consumidores de servicios web que funcionen bien juntos. Este conjunto de recomendaciones que se conoce como Perfil Básico WS-I. Si es un desarrollador de servicios web, debe agregar este acrónimo a su currículum. Comprender los problemas de interoperabilidad de servicios web y diseñar servicios proactivamente para evitarlos se ha convertido en una responsabilidad importante para los desarrolladores de servicios web, al igual que diseñar una compatibilidad entre navegadores se ha convertido en una responsabilidad importante para los diseñadores Web.

No hay una solución definitiva para eliminar todos los problemas de interoperabilidad. La computación distribuida en un entorno heterogéneo es una actividad compleja, y seguramente habrá problemas de interoperabilidad. La mayoría de estos problemas se pueden evitar, con disciplina y las mejores prácticas descritas en el Perfil Básico WS-I.

Siguiendo la historia hasta ahora

Esta serie sigue al personal del periódico ficticio Daily Moon mientras pasan muchas de sus operaciones diarias a un sistema basado en servicios web. En la Parte 1, el Departamento de Clasificados aprendió sobre SOAP interactuando con el Sistema de Gestión de Contenidos, y en la Parte 2, crearon su propio servicio, y lo definieron utilizando Web Services Description Language (WSDL). Luego en la Parte 3, aprendieron cómo interactuar con un registro UDDI, y también cómo encontrar información dentro de uno, lo que en última instancia los condujo a crear uno para la empresa a fin de permitir a otras organizaciones interactuar con Daily Moon. Debido a que Rudy insistió en que sus colegas Gene y Francis brindarán una manera de prevenir el acceso no autorizado a sus sistemas en la Parte 4, Gene y Francis tuvieron que implementar WS-Security para sus servicios web. En la Parte 5, Rudy se dio cuenta de que debía definir las políticas para los servicios web a fin de hacer cumplir que los clientes que accedieran a los servicios web de Daily Moon lo hicieran de la manera indicada, garantizando la seguridad que se construyó en la Parte 4 de esta serie.

Ahora, continuando la historia del personal de Daily Moon, este tutorial describe las experiencias de los miembros del personal a medida que se preparan para lanzar su servicio web de clasificados al público. Phil está manejando este lanzamiento, y quiere asegurarse de que el documento WDSL y el servicio que describe sean lo más accesibles y sin problemas posibles para las personas que deciden utilizarlo para enviar avisos clasificados (e ingresos) a Daily Moon. Phil ha utilizado otros servicios web en el pasado y conoce bien la gravedad de los problemas de interoperabilidad.


Generalidades de la interoperabilidad

Esta sección describe el plan para comprender los problemas de interoperabilidad, cómo realizar pruebas en su búsqueda y algunos términos comunes sobre servicios web.

Comprender el problema

El primer desafío es comprender el problema de la interoperabilidad y su importancia en el mundo de los servicios web. Actualmente los servicios web se construyen utilizando una familia compleja de tecnologías y estándares relacionados, que constituyen muchas fuentes problemas de interoperabilidad. Este tutorial cubre los problemas más comunes y sus orígenes

Luego este tutorial introduce el Perfil Básico WS-I, explicando sus objetivos, lenguaje y muchos de los requerimientos específicos que detalla para los servicios web interoperativos.

Prueba

A continuación, siga a Phil mientras inspecciona los clasificados y los servicios web bancarios delDaily Moonbuscando posibles problemas de interoperabilidad. La organización WS-I produce un conjunto de herramientas de prueba que se pueden utilizar para evaluar la interoperabilidad de un servicio. Este tutorial muestra cómo funcionan estas herramientas y cómo permiten un enfoque a base de pruebas para armar servicios web.

Aprender la terminología

Al hablar de servicios web, es mejor describir las cosas en términos de proveedores y consumidores. He aquí algunas definiciones comunes para ambos :

  • Consumidor: Un consumidor responsable de hacer solicitudes a un servicio que implementa un proveedor.
  • Proveedor: Un proveedor es responsable de escuchar y procesar las solicitudes de servicio del consumidor.

Comprender la interoperabilidad y su importancia

En esta sección, este tutorial presenta el clima de la interoperabilidad detalladamente y describe las causas originales de los problemas de interoperabilidad. Puede ver el caso de los servicios web interoperativos y porqué es importante obtener el grado más elevado de interoperabilidad.

Aprender sobre mensajes e interoperabilidad

Ha aprendido que los servicios web están basados en mensajes XML que viajan hacia y desde un proveedor de servicios web. También ha visto que estos mensajes tienen una estructura simple: sobre, encabezado y carga útil. En la práctica, estos mensajes un poco más complicados y a menudo un programa produce un mensaje SOAP y lo envía a otro programa que tiene problemas para interpretarlo. Este desacuerdo entre los programas es la raíz de la mayoría de los problemas de interoperabilidad.

Incluso si ha construido servicio web SOAP anteriormente, es probable que nunca haya leído las especificaciones SOAP y WSDL. No existen muchas herramientas que hacen innecesario conocer SOAP y WSDL detalladamente para utilizar o construir servicios web. Puede generar consumidores de servicios web e implementaciones de proveedores de servicios web estructurales al introducir un documento WSDL a un generador de códigos como el que brinda Axis2 - usted no tiene que hacer el trabajo pesado. A veces este proceso funciona bien, pero a menudo estas herramientas no logran generar programas utilizables, o lo logran, pero dan como resultado stubs y estructuras que no funcionan bien con otros programas.

En algunos lenguajes de programación dinámicos, como por ejemplo Python, existen bibliotecas que interpretan documentos WSDL cuando es necesario, fundamentalmente creando stubs de servicio ha pedido y facilitando aún más el uso de SOAP sin tener que conocer a fondo las especificaciones SOAP. Así es como deberían funcionar las cosas, pero no siempre ocurre.

Evitar especificaciones ambiguas

Las especificaciones técnicas generalmente son muy claras y no ambiguas. Deben ser claras para que los lectores comprendan los detalles de lo que están trabajando. Sin embargo, a pesar de los mejores esfuerzos, las especificaciones SOAP y WSDL contienen ejemplos y lenguaje sutilmente confusos que obligaban a los desarrolladores a utilizar su mejor juicio y a interpretar por su cuenta cuando encontraban textos poco claros. Esto condujo a varios problemas de interoperabilidad cuando las implementaciones de software diferían en los formatos de mensaje que generaban y esperaban. Esto problemas de interoperabilidad socavan el espíritu de SOAP y los servicios web, que apuntan a ayudar a los programas a comunicarse entre sí.

Resolver la ambigüedad

SOAP es una ciudad que significa Protocolo simple de acceso a objetos, lo cual ha sido polémico desde la primera versión de la especificación, porque la mayoría de las personas concordó en que no era verdaderamente simple de comprender o utilizar. Además de la ambigüedad y los errores, la especificación SOAP es complicada y tiene un alcance demasiado amplio para dar origen a la interoperabilidad que uno esperaría encontrar en el mundo de los servicios web. Por ejemplo, SOAP brinda dos estilos de servicios diferentes (rpc y documento) y dos tipos deusoo cifrado (literal y codificado). La elección de los estilos de servicio y codificado tiene un efecto directo sobre el formato de los mensajes comprendidos por los servicios web. Pueden mezclar y combinar estilos de servicios y codificado, lo que crea las siguientes posibilidades:

  • rpc/literal
  • rpc/codificado
  • documento/literal
  • documento/codificado

Además, los mensajes con estilo documento pueden utilizar un patrón llamado ajustado, que también afecta el cuerpo del mensaje resultante. Es bueno que el desarrollador de software tenga opciones, pero no es fácil decidir que esquema usar. Existe mucha discusión y confusión cuando se trata de elegir entre las cinco opciones disponibles. El Perfil Básico WS-I toma la lista de posibilidades y la reduce por la mitad al recomendar que no se utilice el estilo del mensaje codificado:

"El Archivo prohíbe el uso de codificaciones, inclusive la codificación SOAP.

R2706 Un enlace:wsdl en una DESCRIPCIÓN DEBE utilizar el valor de literal para e atributo uso en todos los elementos soapbind:body, soapbind:fault, soapbind:header, and soapbind:headerfault".

La opción de codificación se eliminó porque era una fuente común de problemas de interoperabilidad: eliminar la codificación ayuda a reducir la variedad de formatos de mensaje con los que tendrá que tratar el software de servicios web, y esto ciertamente ayuda a simplificar y a fomentar una mayor interoperabilidad.

Utilizar SOAP interoperativo

Los servicios web SOAP han recibido algunas críticas en los años recientes. A los desarrolladores que han utilizado SOAP y la familia de tecnologías relacionada que la acompañan podría resultarles difícil decir que es una tecnología complicada y que los desafíos de interoperabilidad son particularmente frustrantes. SOAP es definitivamente potente; pero no es simple. De hecho, desde la versión 1.2 de la especificación SOAP (06/2003), ya no se llama oficialmente SOAP en respuesta a las muchas quejas que dicen que la sigla no es precisa.

En la actualidad hay otras tipos de servicios web que compiten con SOAP. Los más notables son los servicios web inspirados por el concepto de Transferencia de Estado Representacional (REST). REST a más un estilo arquitectónico que una tecnología particular o un estándar formal. Los servicios RESTful (como se los llama) no comparten un formato del mensaje común. El formato queda totalmente al albedrío del diseñador del servicio. Por ende, los servicios RESTful por diseños sufren los mismos problemas de interoperabilidad que los servicios SOAP. Sin embargo, muchos usuarios encuentran a los servicios RESTful más fáciles de construir y utilizar. En la actualidad, muchas organizaciones implementan servicios web en ambos estilos, por ejemplo amazon.com, ebay.com y google.com. Incluso Axis2 incluye soporte para los servicios web RESTful. Ambos enfoques tienen sus méritos, y nos acompañarán durante bastante tiempo.

El formato de mensaje común de SOAP es su función más importante. Cuando las cosas funcionan como corresponde, es fácil ver la promesa de SOAP y la razón por la cual se sigue haciendo tanto esfuerzo continuamente para hacer servicios web interoperativos con SOAP. En la actualidad, con un poco de cuidado y planificación, se pueden evitar los problemas de interoperabilidad comunes que plagaban las primeras implementaciones de servicios web SOAP.

A continuación, veamos el Perfil Básico WS-I.


Presentación del Perfil Básico WS-I

Web Services Interoperability Organization (WS-I) es una organización de la industria con miembros que incluyen a IBM, Microsoft, Intel®, Oracle, SAP, Hitachi y muchas otras compañías líderes. El objetivo de WS-I para lograr la interoperabilidad de servicios web “a través de plataformas, sistemas operativos y lenguajes de programación”. WS-I es un grupo de expertos que brindan asesoramiento a desarrolladores servicios web para ayudarlos a producir software de servicios web interoperativos. WS-I es más conocido como “Perfil Básico”, que es un conjunto de pautas de implementación destinadas a evitar los problemas de interoperabilidad. Estas pautas fundamentalmente son un conjunto invaluable de mejores prácticas.

Dirigirse a su público

Perfil Básico WS-I también es difícil de leer, aunque más conciso que las especificaciones SOAP y WSDL. Y aquí un pequeño trozo del texto del Basic Profile que le muestra cuán complejos se han hecho hoy los servicios web:

"WSDL 1.1 no es claro Con respecto a que espacios de nombre destino de esquema son adecuados para las referencias QName de un elemento WSDL. El Perfil permite referencias QName de elementos WSDL tanto del espacio de nombre destino definido por el elemento xsd:schema, y a espacios de nombres importados. No se permiten las referencias QName a espacios de nombres que se definen únicamente a través de una importación anidada”.

La Mayor parte del Perfil Básico es más fácil de seguir que el párrafo anterior, pero es importante recordar que es una especificación técnica que cubre más de 200 problemas comunes de interoperabilidad, algunos de los cuales atribuye al lenguaje ambiguo de otras especificaciones técnicas.

Las especificaciones como SOAP, WSDL y Perfil Básico WS-I son redactadas en su mayoría por desarrolladores de herramientas, como del por ejemplo las personas de Apache que producen Axis2. Para desarrolladores que arman servicios web, gran parte del Perfil Básico no tiene un efecto directo sobre la manera en que trabaja, pero es buena idea saber lo que contiene el Perfil Básico. Hay algunas partes de él a las que querrá prestar atención minuciosa. Por ejemplo, el Perfil Básico contiene bastante información sobre cómo se deben ver los documentos WSDL.

Explorar los objetivos del Perfil Básico WS-I

El Perfil Básico inclusive un conjunto de principios rectores que ayudan a ejemplificar sus objetivos. Estos principios se reproducen a continuación (con algunos comentarios). El Listado 1 le da una sensación del alcance y el tono del Perfil Básico.

Listado 1. Principios rectores de WS-I
No guarantee of interoperability.  It is impossible to completely 
guarantee the interoperability of a particular service. However, the Profile does 
address the most common problems that implementation experience has revealed to 
date.
Restriction vs. relaxation. When amplifying the requirements of referenced specifications, the Profile may restrict them, but does not relax them (for example, change a MUST to a MAY).

El Perfil Básico ajusta los elementos sueltos de otras especificaciones, pero jamás los afloja.

El Listado 2 es otro ejemplo de la filosofía de ajuste de especificaciones grandes del Perfil Básico, al igual que en el ejemplo literal y codificado mencionado anteriormente.

Listado 2. Más principios rectores de WS-I
Multiple mechanisms.  If a referenced specification allows multiple 
mechanisms to be used interchangeably, the Profile selects those that are 
well-understood, widely implemented, and useful. Extraneous or underspecified 
mechanisms and extensions introduce complexity and therefore reduce 
interoperability.

Vale la pena leer los principios adicionales que figuran en el Listado 3 pues ayudan a fijar el tono de WS-I y deben dejarle la impresión del alcance y el valor del Perfil Básico.

Listado 3. Más principios rectores de WS-I
Future compatibility.  When possible, the Profile aligns its requirements 
with in-progress revisions to the specifications it references. This aids 
implementers by enabling a graceful transition, and assures that WS-I does not 
'fork' from these efforts. When the Profile cannot address an issue in a 
specification it references, this information is communicated to the appropriate 
body to assure its consideration.
Compatibility with deployed services. Backwards compatibility with deployed web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues.
Focus on interoperability. Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability.
Conformance targets. Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP messages) rather than the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone.
Lower-layer interoperability. The Profile speaks to interoperability at the application layer; it assumes that interoperability of lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and well-understood. Similarly, statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting web services specifically; WS-I does not attempt to assure the interoperability of these protocols as a whole. This assures that WS-I's expertise in and focus on web services standards are used effectively."

Estos Principio se fijan en alcance y el tono para el resto del Perfil Básico y abordan la experiencia de sus autores. El Perfil Básico se preocupa principalmente de la interoperabilidad, y adopta un enfoque pragmático a las recomendaciones para que sean fáciles de adoptar ampliamente.

Taxonomía del Servicio WS-I

Como se mencionó los principios rectores más arriba, el Perfil Básico divide un servicio en Objetivos de cumplimiento o artefactos sobre los cuales hace recomendaciones. La siguiente es una lista completa de los artefactos que cubre:

  • MESSAGE -- elementos de protocolo que transportan el SOBRE (como los mensajes SOAP o HTTP).
  • ENVELOPE -- la serialización del elementosoap:Envelopey su contenido.
  • DESCRIPTION -- descripciones de tipo, mensajes, interfaces y su protocolo concreto y enlaces de formato de datos, y los puntos de acceso de red relacionados con los servicios web (como por ejemplo descripciones WSDL).
  • INSTANCE -- software que implementa unwsdl:porto unuddi:bindingTemplate.
  • CONSUMER -- software que invoca unaINSTANCE.
  • SENDER -- software que genera un mensaje conforme a los protocoles relacionados con él.
  • RECEIVER -- software que consume un mensaje conforme a los protocolos relacionados con él (como por ejemplo procesadores SOAP).
  • REGDATA -- elementos del registro que están involucrados en el registro y el descubrimiento de servicios web (como por ejemplo tModels UDDI).

Todas las recomendaciones del Perfil Básico se hacen en el contexto de uno de los elementos anteriores. El Perfil Básico utiliza un conjunto simple de calificadores para comunicar la importancia de la recomendación que se hace. el Listado 4 muestra una recomendación de muestra extraída del Perfil Básico.

Listado 4. Una recomendación WS-I de muestra
Several versions of HTTP are defined. HTTP/1.1 has performance advantages, 
and is more clearly specified than HTTP/1.0.
R1141 A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0. R1140 A MESSAGE SHOULD be sent using HTTP/1.1.

Esto es bastante fácil de seguir. Observe que cada uno de los requisitos anteriores tiene un identificador único, que puede ser útil para reverenciarlo en conversaciones o durante pruebas. Este siguiente punto podría parecer un poco tedioso, pero debido a que intenta ser lo más claro e inequívoco posible, el Perfil Básico formaliza los términos que utiliza en sus recomendaciones. Estos términos, y sus intenciones se muestran en el Listado 5.

Listado 5. Terminología del Perfil Básico
MUST.  This word, or the terms "REQUIRED" or "SHALL," means that the 
definition is an absolute requirement of the specification.

MUST NOT. This phrase, or the phrase "SHALL NOT," means that the definition is an absolute prohibition of the specification.

SHOULD. This word, or the adjective "RECOMMENDED," means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT. This phrase, or the phrase "NOT RECOMMENDED," means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY. This word, or the adjective "OPTIONAL," means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein, an implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.)

Toda especificación formal necesariamente tiene términos complejos como los que figuran en el Listado 5. Es importante leer las definiciones de estos términos porque toda recomendación del Perfil Básico se hace utilizándolas. Esta formalidad también es importante porque muchos problemas de interoperabilidad surgían de la ambigüedad de otras especificaciones.


Combinar el Perfil Básico WS-I y SOAP

Esta sección describe algunas de las recomendaciones del Perfil Básico que podrían existir con los sobres SOAP, errores y el uso de HTTP.

Utilizar sobres SOAP

SOAP especifica un protocolo basado en mensajes XML que viajan en sobres El Perfil Básico requiere que los servicios web utilicen este esquema como se define en la especificación SOAP y agrega varias restricciones a su uso. El siguiente es un resumen de las restricciones que impone el Perfil Básico. No es una lista completa, pero le da un indicio de la amplitud y el alcance del Perfil Básico.

  • El Perfil requiere que los sobres se adapten a la estructura especificada en SOAP 1.1. Parece que decimos algo obvio, y de hecho así es; pero también aclara que la mensajería SOAP 1.1 es la única estructura de mensajes que soporta el Perfil.
  • Los sobres no deben contener una Document Type Declaration (DTD) o Instrucciones de Procesamiento. Éstas se citan por el Perfil como fuentes de vulnerabilidades de seguridad, sobrecarga de procesamiento y ambigüedad semántica. Asimismo, los sobres no deben contener declaraciones de espacio de nombres XML xmlns:xml="http://www.w3.org/XML/1998/namespace y xmlns:xml="http://www.w3.org/XML/1998/namespace.
  • En un sobre, no debe haber elementos hermanos al elemento del cuerpo. El perfil dice que la interpretación de dichos elementos hermanos no es clara, así que el Perfil los prohíbe. Esto formaliza la noción de que un mensaje SOAP es un sobre, con un único cuerpo, y contiene una carga útil.
  • Como se mencionó antes, el Perfil elimina los mensajes SOAP codificados prohibiendo el uso del atributo soap:encodingStyle. Es una recomendación importante porque ha habido mucha discusión sobre este tema, y muchos problemas de interoperabilidad se pueden rastrear al uso de los mensajes XML codificados.

Utilizar errores SOAP

El Perfil Básico ajusta Diversos detalles con los sobres SOAP con error:

  • Primero define que un error es un sobre que tiene un elemento individual secundario de soap:Body que tiene un elemento individual secundario de soap:Fault. Ninguna otra cosa debe interpretarse como error.
  • Los códigos de estado HTTP no deben utilizarse para determinar la presencia de un error. Interprete el mensaje SOAP para determinar la presencia de un error.
  • Cuando un sobre es un error, solo se permite tener elementos secundarios para faultcode, faultstring, faultactor y detalles. Estos elementos no deben estar calificados por espacio de nombres.
  • Por extensibilidad, el Perfil Básico dice que los errores SOAP pueden tener cualquier cantidad de elementos secundarios que aparecen en el elemento detalle.

Nuevamente, son solo aspectos destacados. La mayoría de estas recomendaciones no afectan a los autores de servicios web directamente pero es importante conocerlos en caso de que se encuentre con problemas de interoperabilidad.

Comprender SOAP y HTTP

Debido a que HTTP es el transporte más común y popular para los mensajes SOAP y porque el Perfil Básico lo selecciona como el enlace a utilizar para los servicios web y para recomendar algunas mejores prácticas adicionales, se aplica lo siguiente:

  • Los mensajes se deben enviar con HTTP 1.0 o HTTP 1.1, pero se prefiere HTTP 1.1 y se debe utilizar siempre que sea posible.
  • Los mensajes que solicitan HTTP deben utilizar el método HTTP POST y no deben utilizar HTTP Extension Framework, que SOAP 1.1. permite.
  • Se debe utilizar un código de estado HTTP 2XX para indicar el resultado exitoso de una solicitud HTTP. Cuando el mensaje de respuesta contiene un sobre que no es un error, se debe utilizar el código de estado 200. 200 o 202 debe indicar un resultado exitoso cuando no surge un sobre SOAP de la solicitud HTTP.
  • El valor del campo de acción SOAP en el encabezado HTTP utilizado con un mensaje de solicitud debe ser una cadena citada. Esto parece ser un detalle menor, pero tiene un efecto sobre WSDL, que debe verse como uno de los siguientes ejemplos:
    • <soapbind:operation soapAction="someAction" />. Esto da como resultado un encabezado HTTP que dice SOAPAction="someAction"
    • <soapbind:operation soapAction="" />. Esto da como resultado un encabezado HTTP que dice SOAPAction=""
    • <soapbind:operation /> . Esto da como resultado un encabezado HTTP que dice SOAPAction=""

Aprender sobre el Perfil Básico WS-I y WSDL

La sección de recomendaciones para descripciones de servicios del Perfil Básico comienza estableciendo como requisito que esté disponible WSDL de un proveedor de servicios para un consumidor de servicios web al solicitarlo. Esto resalta la importancia de WSDL como el contracto de servicios web y ayuda a promover un entorno de servicios web que conduce a un uso ad hoc de los servicios web. Siempre podrá encontrar un servicio en un registro, solicitar su WSDL, interpretar WSDL y utilizar el servicio.

Explorar la estructura del documento

El Perfil Básico requiere que las descripciones del servicio se escriban en una versión XML 1.0 válida. Las especificaciones de WSDL o XML Schema no exigieron una versión particular. El Perfil Básico formaliza esta decisión para ayudar a la interoperabilidad.

El Perfil Básico coloca restricciones en el uso de la instrucción de importación WSDL, restringiendo su uso a casos donde el documento que se importa es el mismo documento WSDL. Este es otro requerimiento importante porque aborda un ejemplo en la especificación WSDL 1.1, que incorrectamente muestra la instrucción de importación WSDL siendo utilizada para importar definiciones XML Schema. El perfil coloca una restricción similar sobre los usos de la importación de XML Schema, diciendo que debe ser utilizada únicamente para importar definiciones XML Schema.

Cuando importa un documento WSDL a otro documento WSDL, el Perfil Básico requiere que los dos documentos WSDL estén en el mismo espacio de nombre (el atributo targetNamespace en el elemento wsdl:definitions del WSDL que se importa deben tener el mismo valor que el atributo espacio de nombres en el elemento wsdl:import en el WSDL que realiza la importación.) Fundamentalmente esto restringe las importaciones para que incluyan elementos de espacio de nombres principales que ya están definidos en el espacio de nombres, prohibiendo lo que se llegó a conocer como coerción de espacios de nombres.

El Perfil Básico recomienda que los elementos de un documento WSDL aparezcan en un orden específico. Los elementos de importación WSDL deben preceder a todos los demás elementos del espacio de nombres WSDL excepto wsdl:documentation. Los elementos de tipo WSDL deben preceder a todos los demás elementos del espacio de nombres WSDL exceptowsdl:documentation y wsdl:import. El elemento de documentación WSDL puede aparecer como el primer elemento secundario de wsdl:import, wsdl:part, y wsdl:definition además de los elementos citados en WSDL 1.1.

El perfil advierte contra el uso de extensiones WSDL, porque fácilmente pueden conducir a problemas de interoperabilidad.

Introducir tipos

El Perfil Básico elimina el tipo de array WSDL, lo que se ha interpretado en diversas maneras distintas. Wsdl:arrayType y soapenc:ArrayType deben evitar. Se desalienta la antigua convención de nombrar los arrays utilizando ArrayOfXXX. En cambio, los arrays se deben declarar utilizando una secuencia como la que se muestra en el Listado 6.

Listado 6. Definición básica de array que cumple con el Perfil Básico
<xsd:element name="MyArray1" type="tns:MyArray1Type"/>
<xsd:complexType name="MyArray1Type">
  <xsd:sequence>
   <xsd:element name="x" type="xsd:string" 
    minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

Comprensión de los tipos de puertos

El Perfil Básico prohíbe la sobrecarga de nombres en un wsdl:portType. Esto significa que cada operación debe tener un valor definido para su atributo nombre.

Aprender sobre enlaces

Un wsdl:binding en una DESCRIPCIÓN DEBE ser un enlace rpc-literal o un enlace documento-literal. Este hecho se repite ya un par de veces en este tutorial debido a su efecto importante sobre el formato del mensaje.

Un wsdl:binding en una DESCRIPCIÓN DEBE utilizar el valor de literal para el atributo use en todos los elementos soapbind:body, soapbind:fault, soapbind:header y soapbind:headerfault.

Como puede ver, el Perfil Básico hace recomendaciones que afectan WSDL. WSDL es una especificación muy importante utilizada en los servicios web. Las recomendaciones WSDL del Perfil Básico indicadas en esta sección son aquellas por las cuales es más probable que sea afectado. Abordan los problemas de interoperabilidad relacionados con WSDL más comunes con los servicios web.


Estudiar los escenarios de uso del Perfil Básico WS-I

En un documento individual del Perfil Básico, WS-I define un conjunto de tres Escenarios de uso que describen tres patrones comunes para acceder a los servicios web. El documento de escenarios de uso muestra cómo funcionan estos tres escenarios de uso y cómo se pueden implementar los artefactos que se encuentran en los servicios web, como por ejemplo WSDL.

Una de las funciones importantes de los siguientes escenarios de uso es que se pueden componer, lo que significa que puede utilizarlos como bloques de construcción para armar escenarios de uso más complejos.

Aprender del escenario de uso unidireccional

El escenario de uso unidireccional es aplicable en situaciones en las cuales un consumidor de servicios web debe enviar un mensaje a un proveedor de servicios y el consumidor no requiere una garantía de que el mensaje se entregará o procesará. Por supuesto, se harán todos los intentos para entregar y procesar el mensaje. Pero en caso de que algo salga mal, no hay un canal disponible para informar al consumidor sobre el fallo debido a las funciones de este escenario de uso:

  • No se genera ni se espera un mensaje de respuesta SOAP.
  • No se requiere al transporte subyacente que garantice la entrega del mensaje al proveedor.

¿Por qué querría utilizar un sistema que incluye estas salvedades importantes? Hay algunas situaciones en las cuales el mensaje potencialmente no ha entregado no significa un desastre, como cuando se envía un mensaje a un registro de aplicación. El escenario unidireccional es una buena elección en dicho caso porque es liviano. Puede ayudar a la escalabilidad de un sistema porque el consumidor no debe esperar que se procese o prepare la solicitud para ninguna clase de respuesta de parte del proveedor. El sistema puede pasar a otra cosa.

El documento escenarios de uso detalla cómo se utiliza el escenario de uso unidireccional en WSDL. Es levemente diferente según si usted utiliza un enlace documento y literal o un enlace rpc y literal (los únicos dos tipos de enlace permitidos por el Perfil Básico) Los escenarios de uso se construyen sobre el Perfil Básico. Describen técnicas que cumplen los requisitos del Perfil Básico.

En Cualquier caso, el escenario unidireccional requiere que se envíe un único mensaje de entrada al proveedor, y no se especifica ningún mensaje de salida.

Comprender el escenario de uso solicitud/respuesta sincrónica

La solicitud/respuesta sincrónica es el tipo de patrón de uso más común para los servicios web y la computación distribuida en general. Éste escenario de uso es de natural para nosotros porque describe con exactitud muchas situaciones que experimentamos en el mundo real. Por ejemplo, cuando se detiene a pedir indicaciones para llegar a la cafetería más cercana, usted debe:

  1. Buscar a alguien que parezca que pueda ayudarlo.
  2. Preguntarle sí sabe cómo llegar a una cafetería cercana.
  3. Esperar que piense una respuesta.
  4. Escuchar mientras le responde.

No es muy útil pedirle instrucciones a alguien y luego irse sin esperar que responda, que es lo que haría si utilizara el escenario de uso unidireccional. En este ejemplo, es importante que espere a que el destinatario procese la información que le ha proporcionado y formule una respuesta que usted pueda utilizar.

En el escenario solicitud/respuesta sincrónica, el servicio recibe un mensaje de solicitud SOAP y produce un mensaje de respuesta SOAP que el cliente espera con ansiedad.

Comprender El escenario de uso básico de devolución de llamada

El escenario básico de devolución de llamada es para situaciones donde al consumidor le interesa recibir un resultado de parte del proveedor, pero el consumidor no desea quedarse a esperar el resultado. Éste podría ser el caso, por ejemplo si el consumidor le pidiera al proveedor que prepare un informe complicado que requeriría tiempo de procesamiento sustancial. En lugar de esperar el informe, el consumidor le da al proveedor suficiente información para que sepa cómo devolver la llamada al consumidor cuando el resultado esté listo.

La devolución de llamada básica se logra al componer dos escenarios de uso de devolución de llamada asincrónicos, una solicitud inicial del consumidor al proveedor, que en último lugar da como resultado una respuesta final del proveedor al consumidor. El Listado 7 que muestra cómo WS-I describe el escenario de devolución de llamada básico.

Listado 7. Escenario de devolución de llamada básico
1. Consumer initiates the service by sending a SOAP message bound to an HTTP 
request to the Provider (the "initial request")

2. Provider acknowledges receipt using a SOAP message bound to an HTTP response to 
the Consumer (the "initial response")

3. Provider completes the exchange by sending a SOAP message bound to an HTTP 
request to the Consumer with the results of the initial request (the "final 
request" or "callback")

4. Consumer acknowledges receipt of the callback message with a SOAP message 
bound to an HTTP response (the "final response")

Estos escenarios de uso no están especificados por ninguno de los estándares de servicios web; solo son patrones de comunicación comunes utilizados por los servicios web y las aplicaciones que los consumen. Es importante catalogar estos escenarios, como lo ha hecho WS-I, porque los escenarios les dan a los desarrolladores asesoramiento sobre cómo implementarlos para que sean interoperativos. Para obtener más detalles, lea el documento de escenarios de uso (ver Recursos para obtener un enlace). Allí encontrará ejemplos de las definiciones WSDL utilizada para implementar estos tres patrones de uso definidos por WS-I.


Utilizar las herramientas de prueba WS-I

Los autores del Perfil Básico WS-I deseaban hacer que fuera fácil cumplir sus requisitos. Entienden que la mayoría de los desarrolladores prefieren concentrarse en construir software en lugar de leer otro documento técnico más. Al entender esto, crearon un conjunto de herramientas de prueba que pueden utilizar los desarrolladores para verificar diversos artefactos de servicios web para el cumplimiento del Perfil Básico. Es una estrategia genial ya que a la mayoría de los desarrolladores de servicios web les encantaría saber que sus servicios cumplen los requisitos (y por ende no tienen la menor cantidad posible de problemas de interoperabilidad), y luego pasar a otra cosa. A la mayoría de nosotros no nos interesa convertirnos en expertos en interoperabilidad, aunque nos encantaría beneficiarnos de su experiencia.

Puede descargar una suite de herramientas de prueba directamente de WS-I. Esta suite incluye una herramienta llamada Monitor para interceptar mensajes que van hacia o provienen de un servicio web y una herramienta llamada Analyzer para inspeccionar diversos artefactos de servicios web (inclusive los mensajes interceptados utilizando Monitor).

Volvamos al Daily Moon y a Phil, cuya tarea es preocuparse sobre la interoperabilidad de los nuevos servicios web del periódico. Phil ha pasado un tiempo sustancial investigando la interoperabilidad, ha encontrado WS-I, revisado el Perfil Básico, y descargado las herramientas de prueba WS-I.

Utilizar el monitor WS-I

Las herramientas de prueba WS-I incluyen una aplicación de monitoreo que tiene la capacidad de escuchar las conversaciones que ocurren entre un proveedor de servicios web y un consumidor. Lo hace presentándose como el intermediario donde el consumidor habla con la aplicación de monitoreo, que reenvía solicitudes al proveedor sin modificarlas. El monitor reenvía toda respuesta del proveedor al consumidor, nuevamente sin tocarlas de manera alguna. El monitor lleva un registro de todo lo que ve. Puede ver mensajes SOAP y trafico HTTP: dos componentes importantes de los servicios web que se pueden analizar luego en busca de problemas de interoperabilidad.

La aplicación monitor utiliza un archivo de configuración XML. Las pruebas WS-I incluyen un archivo de configuración de monitor de muestra que, para la versión Java de la suite, se puede encontrar en $WSI_HOME/java/samples/monitorConfig.xml. Phil comienza copiando este archivo de muestra a su espacio de trabajo local y lo edita para especificar una buena ubicación para el archivo del registro que llevará. Decide crear dos configuraciones individuales: una para el servicio de avisos clasificados y otra para el servicio bancario. Los archivos de registros resultantes son importantes porque luego serán analizados por otra herramienta de prueba.

El archivo de configuración de monitor también especifica los puertos donde debe esperar solicitudes de consumidores y los puertos de proveedores a los que debe reenviarlos. Los puertos de proveedores son bastante estándar. Los puertos de escucha predeterminados deben ser seguros para la mayoría de los sistemas. Después de verificar estos números de puerto, Phil decide quedarse con los predeterminados.

Phil se asegura de que sus servicios de prueba estén ejecutándose, y luego inicia el monitor utilizando el archivo de lote proporcionado (Monitor.bat) y el archivo de configuración que creó para el servicio de avisos clasificados. El Listado 8 muestra el resultado que surge del inicio de la herramienta Monitor.

Listado 8. Inicio de la herramienta de monitoreo
$ $WSI_HOME/java/bin/Monitor.bat -config ClassifiedSvcMonitorConfig.xml
Conformance Monitor Tool, Version: 1.0.0, Release Date: 2004-11-19
Copyright (C) 2002-2003 by The Web Services-Interoperability Organization and 
Certain of its Members. All Rights Reserved. Use of this Material is governed by 
WS-I licenses included within the documentation.

  comment ..................... This configuration file is used to test the WS-I 
sample applications running on a single system.
  logURI ...................... log.xml
  replaceLog .................. true
  logDuration ................. 600
  timeout ..................... 3
  addStyleSheet ............... <?xml-stylesheet 
href="../../wsi-test-tools/common/xsl/log.xsl" type="text/xsl" ?>
  man-in-the-middle comment ... null
  redirect [1]
    comment ................... This is a redirect example for local system, port 
8080.
    listenPort ................ 4040
    host ...................... http://localhost:8080
    maxConnections ............ 1000
    readTimeoutSeconds ........ 15
  redirect [2]
    comment ................... This is a redirect example for local system, port 
80.
    listenPort ................ 4041
    host ...................... http://localhost:80
    maxConnections ............ 1000
    readTimeoutSeconds ........ 15
  redirect [3]
    comment ................... This is a redirect example for local system, port 
9080.
    listenPort ................ 8001
    host ...................... http://localhost:9080
    maxConnections ............ 1000
    readTimeoutSeconds ........ 15

The Monitor tool is ready to intercept and log web service messages.
Type "exit" to stop the Monitor.

A continuación, Phil debe cambiar sus casos de prueba para utilizar URLs de servicio alternativo para que el Monitor tenga la oportunidad de interceptar mensajes de cada consumidor y reenviarlos a instancias de servicio en ejecución. Esto se hace fácilmente modificando cada prueba para qué cada una arme la instancia de stub de prueba con una URL de servicio explícita que anule la URL incluirá en el WSDL utilizado para crear el caso de prueba.

Para la prueba de servicio clasificado, significa crear el stub como se muestra en el Listado 9 para que se utilice el puerto de 4040 en vez de comunicarse directamente con el proveedor de servicios, que está en el puerto 8080.

Listado 9. Construcción de ClassifiedServiceStub para la prueba
ClassifiedServiceStub stub =
new ClassifiedServiceStub(null, 
"http://localhost:4040/axis2/services/ClassifiedService");

A continuación, Phil ejecuta cada caso de prueba para el servicio de avisos clasificados. Tiene éxito como se indica en el Listado 10.

Listado 10. Ejecución de ClassifiedServiceTest
$ ant run.test
Buildfile: build.xml

init:

pre.compile.test:
     [echo] Stax Availability= true
     [echo] Axis2 Availability= true

compile.src:

compile.test:

run.test:
    [junit] Running com.bm.classifiedclient.ClassifiedServiceTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.516 sec

BUILD SUCCESSFUL
Total time: 5 seconds

A medida que se ejecutan estas pruebas, Phil observa que el registro de la aplicación monitor salta cuando intercepta las solicitudes y respuestas del consumidor y el proveedor. Las entradas del registro generado se muestran en el Listado 11.

Listado 11. Entradas en el registro monitor
Log message entry [ID, Type, Sender]: 1, request, 127.0.0.1:4582
Log message entry [ID, Type, Sender]: 2, response, localhost:8080

Ahora que se ha realizado el proceso de monitoreo, Phil está listo para ejecutar el analizador para buscar problemas de interoperabilidad.

Utilizar la herramienta de prueba analizador

La herramienta de prueba analizador también utiliza un archivo de configuración XML. Nuevamente, Phil comienza copiando archivo de muestra de la suite de prueba WS-I. Para la suite Java, el archivo de muestra se puede encontrar en $WSI_HOME/java/samples/analyzerConfig.xml. Phil hace dos copias: una copia para el servicio de avisos clasificados y otra copia para el servicio bancario.

El programa analizador es capaz de procesar archivos del registro creado por el monitor para buscar mensajes a analizar. También puede analizar documentos WSDL y otros artefactos.

Phil edita el archivo de configuración de muestra para este servicio, agregando una referencia a su servicio WSDL. El archivo de configuración resultante se muestra en el Listado 12.

Listado 12. Referencia WSDL actualizada en el archivo de configuración del analizador
<wsi-analyzerConfig:wsdlReference>
  <wsi-analyzerConfig:wsdlElement type="port"
      parentElementName="BankService"
      namespace="http://userguide.axis2.apache.org/BankService">
    BankPort
  </wsi-analyzerConfig:wsdlElement>
  <wsi-analyzerConfig:wsdlURI>
    ./BankService.wsdl
  </wsi-analyzerConfig:wsdlURI>

</wsi-analyzerConfig:wsdlReference>

Phil luego se asegura de que la configuración del analizador conozca la ubicación correcta del archivo de registro generado por nuestra sesión de monitoreo. Elige log.xml en el directorio actual. Este cambio se muestra en el Listado 13.

Listado 13. Ubicación actualizada del archivo del registro en el archivo de configuración del analizador
<wsi-analyzerConfig:logFile correlationType="endpoint">
  ./log.xml
</wsi-analyzerConfig:logFile>

En este punto, lo único que debe hacer Phil es ejecutar el analizador, como se muestra en el Listado 14.

Listado 14. Ejecución de la herramienta analizador
$ Analyzer.bat -config BankSvcAnalyzerConfig.xml
Conformance Analyzer Tool, Version: 1.0.0, Release Date: 2004-11-19
Copyright (C) 2002-2003 by The Web Services-Interoperability Organization and 
Certain of its Members. All Rights Reserved. Use of this Material is governed by 
WS-I licenses included within the documentation.
 
  verbose .................... false
  Assertion Results:
    type ..................... all
    messageEntry ............. true
    assertionDescription ..... false
    failureMessage ........... true
    failureDetail ............ true
  Report File:
    replace .................. true
    location ................. report.xml
    Style Sheet:
      href ................... ../wsi-test-tools/common/xsl/report.xsl
      type ................... text/xsl
  testAssertionsFile ......... 
../wsi-test-tools/common/profiles/SSBP10_BP11_TAD.xml
  Message Log File:
    location ................. ./log.xml
    correlationType .......... endpoint
  WSDL Reference:
    WSDL Element: 
      type ................... port
      namespace .............. http://userguide.axis2.apache.org/BankService
      name ................... BankPort
      parentElementName ...... BankService
    wsdlURI .................. bankservice/BankService.wsdl
  description ................ This file contains a sample of the configuration 
file for the Basic Profile Analyzer, which can be used with the other sample 
files.

Please wait while the specified artifacts are analyzed...
Conformance report has been created.

Phil repite este proceso para el servicio de avisos clasificados. El resultado más interesante del analizador es el informe que produce. El informe es un archivo XML que se puede visualizar en cualquier navegador que entienda XSLT, como por ejemplo Internet Explorer o Firefox.

Leer el informe

El informe del analizador brinda una evaluación general de aprobación o desaprobación de cada servicio web que analiza. También brinda una lista detallada de los requisitos del Perfil Básico con sus propias evaluaciones de aprobación o desaprobación. Phil primero carga el informe del analizador para el servicio bancario y observa que ha obtenido una calificación de desaprobación, como se muestra en la Figura 1.

Figura 1. Informe de la herramienta analizador que muestra una calificación de desaprobación
Informe de la herramienta analizador que muestra una calificación de desaprobación

Lamentablemente, parece que este servicio no cumple uno o más de los requisitos del Perfil Básico. El analizador le otorgó una evaluación de desaprobación. Al analizar los detalles, Phil descubre que la descripción WSDL para el servicio bancario no ha cumplido un requisito. El informe brindar bastantes detalles, como se muestra en la Figura 2.

Figura 2. Informe detallado del analizador
Informe detallado del analizador

Después de leerlo un par de veces y mirar el WSDL del servicio bancario, Phil se da cuenta de que el problema debe ser el espacio de nombres que ha incluido en un elemento soap:body como se muestra en el Listado 15.

Listado 15. Ingresar definición con espacio de nombres especificado en soap:body
<input name="BookReqMsg">
  <soap:body namespace="http://userguide.axis2.apache.org/ClassifiedService"
                    use="literal"/>
</input>

Elimina cada definición de espacio de nombres en cada entrada en este archivo WSDL para que se vea como el Listado 16, esperando que permita que la herramienta analizador apruebe este servicio.

Listado 16. El soap:body sin espacio de nombres
<input name="BookReqMsg">
<soap:body 
   use="literal"/>
</input>

Luego vuelve a ejecutar la herramienta analizador, vuelve a cargar el informe en el navegador, y observa que el servicio ahora cumple completamente el Perfil Básico WS-I. Phil tuvo suerte; fue un cambio bastante simple.

Phil se da cuenta de que ha cambiado la descripción WSDL para el servicio bancario. Ahora debe asegurarse de que WSDL siga funcionando de manera adecuada con el kit de herramientas Axis2. Para hacerlo, vuelve a generar la estructura del servicio y las clases de stub de cliente utilizando el comando WSDL2Java, compila todo y vuelve a realizar la prueba. Afortunadamente, todo funciona bien, y puede estar seguro de que el servicio web bancario no tiene los problemas de interoperabilidad descritos en el Perfil Básico.

Phil repite todo este ejercicio para el servicio web de avisos clasificados y tiene una experiencia similar. El servicio falla debido a BP2019. Hace el mismo ajuste a este servicio, y después aprueba todas las pruebas.

Utilizar herramientas alternativas a

Las herramientas de prueba de WS-I son increíblemente útiles y facilitan el cumplimiento de las mejores prácticas del Perfil Básico. Si por casualidad utiliza Eclipse, también tiene la opción de utilizar un conjunto de herramientas alternativas para probar el cumplimiento del Perfil Básico. El Eclipse Web Tools Project incluye una variedad de mejoras útiles para Eclipse, inclusive editores especiales para evitar documentos WSDL y XML Schema, resaltado de sintaxis para muchos formatos de archivos de programación Web, y un conjunto de herramientas de prueba que pueden analizar un documento WSDL para ver si cumple con el Perfil Básico. Aunque las herramientas de prueba de WS-I son impresionantes en su calidad y alcance, muchos descubren que las herramientas del Eclipse Web Tools Project se adaptan mucho mejor a su flujo de trabajo.

Contar con un conjunto de herramientas que le permite validar sus servicios de manera impulsada por las pruebas. Integrar estas pruebas a su entorno de desarrollo puede hacer que este proceso sea aún más eficiente. La Figura 3 muestra un ejemplo del complemento Eclipse Web Tools. Destaca la misma recomendación del Perfil Básico que destacó la prueba de que el analizador que realizó Phil más arriba, pero esta vez se hace en Eclipse y se muestra exactamente en el sitio del problema.

Figura 3. El complementó Eclipse Web Tools destaca errores
El complementó Eclipse Web Tools destaca errores

Inclusión de reclamos de cumplimiento

Ahora que Phil ha verificado que sus servicios aprueban las pruebas de cumplimiento del Perfil Básico, decide anunciar el hecho de dar a los usuarios potenciales de la confianza de que se han realizado todos los esfuerzos para evitar problemas de interoperabilidad. El Perfil Básico describe cómo puede hacer dichos reclamos. Phil sigue los ejemplos para agregar un elemento wsi:Claim a las definiciones de puerto en sus documentos WSDL como se muestra en el Listado 17.

Listado 17. Muestra de un reclamo de cumplimiento del Perfil Básico en un puerto WSDL
<wsdl:port name="MyPort" binding="tns:MyBinding" > 
      <wsdl:documentation>
        <wsi:Claim 
         conformsTo="http://ws-i.org/profiles/basic/1.1" />
      </wsdl:documentation>

Resumen

Este tutorial le presentó los conceptos de la interoperabilidad de los servicios web y le brindó un conjunto simple de prácticas que puede adoptar para aprovechar la experiencia sustancial para evitar los problemas de interoperabilidad. La interoperabilidad es un tema importante, un tema que cada desarrollador de servicios web debe tener muy en cuenta. Aprendió sobre WS-I Basic Profile y las pruebas automáticas que puede correr sobre sus servicios para asegurarse de que no tengan problemas de interoperabilidad comunes.

La popularidad de los servicios web sigue creciendo, y gracias al trabajo de organizaciones como WS-I, se hacen cada vez más fáciles de utilizar a medida que pasa el tiempo y se descubren, documentan y evitan más problemas de interoperabilidad. La programación distribuida a la escala que permiten los servicios web siempre incluirá cierta medida de desafío y complejidad. A pesar de los primeros desafíos de interoperabilidad con los que se encontraban los desarrolladores de servicio web, los servicios web basados en SOAP siguen madurando a medida que los desarrolladores adquieren experiencia y conocimiento sobre los problemas de interoperabilidad y la manera en que deben desarrollar y probar su software para evitarlos.


Descargar

DescripciónNombretamaño
Part 6 source codews-interoperabilitycode.zip172B

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=660826
ArticleTitle=Comprender las especificaciones de servicios web, Parte 6: WS-Interoperability
publish-date=08082011