Servicios web seguros, confiables y con transacciones: arquitectura y composición
Septiembre de 2003
|
IBM Corporation
Donald F. Framework
Tony Storey |
Microsoft Corporation
Brad Lovering
john Shewchuk |
Contenido
1.0 Introducción
1.1 Servicios redactables
1.2 Un ejemplo de composición en la práctica
2.0 Servicios web: una arquitectura de Service-Oriented
2.1 Los servicios se describen mediante esquema y el tipo de contrato no
2.2 La compatibilidad del servicio es mayor que la compatibilidad de tipos
2.3 La orientación del servicio supone que las cosas malas pueden ocurrir y ocurrirán
2.4 La orientación del servicio permite un enlace flexible de servicios
3.0 Especificaciones y funciones del servicio web
3.1 Un enfoque redactable para los servicios web
3.2 Conceptos básicos: transportes y mensajería
3.2.1 Transportes: HTTP, HTTP/S, SMTP
3.2.2 Formatos de mensaje: XSD
3.2.3 WS-Addressing
3.3 Descripción
3.3.1 WSDL
3.3.2 WS-Policy
3.3.3 Obtener descripciones
3.3.4 WS-MetadataExchange
3.3.5 UDDI
3.4 Service Assurances
3.5 Seguridad
3.5.1 WS-Security
3.5.2 WS-Trust
3.5.3 WS-SecureConversation
3.5.4 WS-Federation
3.6 Mensajería confiable
3.6.1 WS-ReliableMessaging
3.7 Transacciones
3.7.1 WS-Coordination
3.7.2 WS-AtomicTransaction
3.7.3 WS-BusinessActivity
3.8 Composición del servicio
3.8.1 BPEL4WS
4.0 Servicios web en la práctica: un ejemplo
4.1 Parte 1: La experiencia del cliente
4.2 Parte 2: La experiencia del proveedor
5.0 Conclusiones
6.0 Confirmaciones
1.0 Introducción
En la actualidad, los servicios web ,específicamente distribuidos que procesan mensajes SOAP codificados con XML, que se envían a través de HTTP y que se describen mediante el lenguaje de descripción de servicios web (WSDL), se implementan ampliamente. (Los términos XML, SOAP y HTTP están en uso común hoy en día y en muchos aspectos su uso se ha movido más allá de sus acrónimos originales. Para obtener integridad, estos acrónimos se enumeran aquí: XML: lenguaje de marcado eXtensible, SOAP, protocolo simple de acceso a objetos y HTTP: protocolo de transferencia de hipertexto). Los servicios web se usan en una variedad de escenarios de integración de aplicaciones: desde el simple, ad hoc, detrás del firewall, el uso compartido de datos a comercio minorista y moneda de Internet a gran escala. Y cada vez se aplican servicios web cada vez más en escenarios móviles, de dispositivo y de cuadrícula.
Los servicios web proporcionan interoperabilidad entre componentes de software que pueden comunicarse entre diferentes empresas y pueden residir en diferentes infraestructuras. Esto resuelve uno de los problemas más críticos a los que se enfrentan los clientes, desarrolladores de software y asociados. HTTP y SOAP proporcionan la comunicación y la interoperabilidad de mensajes. WSDL proporciona la descripción del servicio para admitir la interoperabilidad entre las herramientas de desarrollo; complementa la interoperabilidad de comunicación con la capacidad de intercambiar definiciones de interfaz.
El conjunto básico de especificaciones de servicio web permite a los clientes y proveedores de software resolver problemas importantes. Basándose en su éxito, muchos desarrolladores y empresas están listos para abordar problemas más difíciles con la tecnología de servicios web. El éxito de los servicios web ha llevado a los desarrolladores a querer aún más funcionalidades de los servicios web. Dado que la interoperabilidad significativa de herramientas y comunicaciones ha sido correcta, los desarrolladores ahora esperan que las funciones mejoradas interoperan.
Además de la interoperabilidad básica de mensajes y el intercambio de interfaces, los desarrolladores requieren cada vez más que los servicios de aplicaciones de nivel superior interoperan. Muchas aplicaciones comerciales se ejecutan en un entorno ("middleware" o "sistemas operativos") que proporcionan compatibilidad con funciones como seguridad y transacciones.
IBM, Microsoft y otros miembros del sector suelen pedirse que los servicios web sean más seguros, más confiables y puedan admitir transacciones. Además, se nos pide que proporcione estas funcionalidades a la vez que conservamos la simplicidad y la interoperabilidad esenciales que se encuentran en los servicios web en la actualidad.
En este documento se proporciona información general concisa para el conjunto de especificaciones de servicio web que abordan estas necesidades. Para obtener los detalles de las especificaciones, proporcionamos referencias a los documentos reales. El propósito principal de este documento es definir brevemente el valor que estas especificaciones proporcionan a nuestros clientes. También se describe cómo estas especificaciones se complementan entre sí para crear entornos sólidos para aplicaciones distribuidas.
Nos enfrentamos a un desafío clave de ingeniería: ¿Cómo proporcionamos a los servicios web nuevas funcionalidades de seguridad, confiabilidad y transacción sin agregar más complejidad de lo necesario?
1.1 Servicios redactables
Como hemos hecho con SOAP y WSDL, IBM, Microsoft y nuestros asociados han seguido el principio de diseño de de composición en la definición de especificaciones de servicio web. El enfoque que hemos seguido se basa en el principio de diseño de de composición en la definición de especificaciones de servicio web. Cada especificación desarrollada resuelve una necesidad inmediata y es valiosa en su propio derecho. Por ejemplo, los desarrolladores pueden adoptar mensajería confiable para simplificar su desarrollo de soluciones o adoptar BPEL4WS para definir sus composiciones de servicio. Y mientras cada especificación se sitúa por sí sola, están diseñadas para combinarse y trabajar entre sí.
Usamos el término de composición para describir especificaciones independientes que se pueden combinar para proporcionar funcionalidades más eficaces. Los proveedores de sistemas operativos y middleware pueden admitir funcionalidades compuestas, por ejemplo, los proveedores pueden integrar la compatibilidad de mensajería confiable para comunicar los procesos de BPEL4WS. En este ejemplo se combinan dos especificaciones independientes para simplificar el desarrollo de procesos de comunicación eliminando la necesidad de controlar los errores de comunicación de mensajes durante el diseño del proceso.
La composición permite de consumo incremental o detección progresiva de nuevos conceptos, herramientas y servicios. Los desarrolladores solo necesitan aprender e implementar lo que es necesario y no más. La complejidad de la solución aumenta solo porque aumentan los requisitos del problema y no se debe a la tecnología "hinchazón".
La capacidad de redacción tiene y sigue siendo uno de los principales objetivos de diseño para los servicios web. En los últimos años hemos definido las especificaciones de servicio web más básicas (SOAP y WSDL) para admitir inherentemente la composición. Una de las características fundamentales de un servicio web es una estructura de mensajes normal y de varias partes. Esta estructura habilita la composición de la nueva funcionalidad. Los nuevos elementos de mensaje que admiten nuevos servicios se pueden agregar a los mensajes de una manera que no modifique el procesamiento de la funcionalidad existente. Por ejemplo, es posible agregar de forma independiente identificadores de transacción y números de secuencia de mensajería confiables. Las dos extensiones no entran en conflicto entre sí y son compatibles con estructuras de mensajes preexistentes.
.gif)
Figura 1. La capacidad de redacción permite usar elementos según sea necesario.
En la figura 1 se muestra un mensaje de servicios web simple que contiene elementos para WS-Addressing, WS-Securityy WS-ReliableMessaging. Observe que los elementos WS-Addressing, WS-Security y WS-ReliableMessaging son independientes y estos elementos se pueden usar de forma independiente sin modificar el procesamiento de otros elementos.
Esta característica permite definir la seguridad, la confiabilidad y las transacciones en términos de elementos de mensaje que se pueden componer.
La noción de composición también permite la creación de un conjunto específico de servicios web bien definidos que admiten seguridad, confiabilidad, etc. Estos servicios bien definidos especifican el comportamiento de los servicios necesarios para admitir la funcionalidad de servicio web de nivel superior. Un ejemplo es el servicio de token seguro definido en WS-Trust que emite y valida los elementos de seguridad en los mensajes.
Además, es importante que los consumidores de un servicio puedan determinar las garantías de servicio admitidas y necesarias. Los servicios deben documentar sus requisitos y compatibilidad con transacciones, seguridad, mensajería confiable, etc. WS-Policy permite a los servicios web aumentar incrementalmente su WSDL para documentar qué funciones de transacción, seguridad y confiabilidad admiten o requieren. WSDL y WS-Policy habilitar la composición para la descripción de los servicios. Esto, a su vez, permite a las otras partes comprender qué elementos de mensaje y servicios de nivel superior se emplean al interactuar con el servicio.
1.2 Un ejemplo de composición en la práctica
La figura 2 proporciona información general que muestra la composición en la práctica. Un cliente y un proveedor usan servicios web para procesar pedidos.
.gif)
Figura 2. Composición en un sistema de procesamiento de pedidos
Al compilar estos servicios web, los desarrolladores usan WSDL y documentos relacionados para describir su interfaz de negocio. Estos documentos WSDL describen el conjunto de mensajes que procesarán los servicios web de cliente y proveedor, por ejemplo, el mensaje SubmitPurchaseOrder (SubmitPO) que fluye del cliente al proveedor. Esto se muestra en la parte superior de la figura 2. Una vez que se han implementado las partes principales de la aplicación, los desarrolladores pueden decidir admitir una funcionalidad adicional, por ejemplo, aquí deciden realizar transacciones de procesamiento de pedidos. Para ello, componer los siguientes elementos en la estructura existente:
- Los servicios asocian WS-Policy documentos que describen su compatibilidad con las transacciones a su descripción de WSDL de sus servicios. Tenga en cuenta que estas instrucciones de directiva aumentan pero no modifican fundamentalmente la funcionalidad empresarial existente.
- Para admitir el procesamiento de transacciones, los servicios agregan un elemento de mensaje adicional que describe las transacciones que se componen con, pero no modifican fundamentalmente los mensajes de aplicación existentes.
- Cuando el servicio de proveedor recibe mensajes que contienen el elemento de transacción, usa esta información para comunicarse con un servicio web designado denominado coordinador que admite la función de transacción. De nuevo, este servicio web adicional simplemente agrega a la solución y no requiere modificaciones en la descripción de la funcionalidad empresarial existente.
- Por último, los servicios pueden implementar operaciones adicionales para admitir la integración con el servicio de coordinación de transacciones.
En la ilustración anterior se resaltan estos elementos adicionales.
El modelo es incremental y se puede componer porque:
- La adición de las nuevas funciones se puede realizar independientemente de agregar otras funciones.
- Agregar la función no interrumpe los mensajes existentes, la lógica de procesamiento de mensajes ni WSDL.
La composición es un principio de diseño cada vez más importante, pero el enfoque no siempre se entiende bien. Aunque las especificaciones de servicio web individuales definen cómo interoperan los elementos y servicios individuales, este documento técnico está pensado para proporcionar información general sobre cómo se puede componer la colección de especificaciones para proporcionar servicios web interoperables más sofisticados.
2.0 Servicios web: una arquitectura de Service-Oriented
En los últimos años hemos testigo de una gran actividad centrada en el desarrollo de servicios web. Con toda esta actividad es importante retroceder y formular la pregunta "¿ Por qué?" Sin duda, los servicios web no habilitan nuevos tipos de funcionalidad computacional, después de que todos los servicios web se sigan ejecutando en equipos existentes, ejecutando el mismo conjunto de instrucciones y accediendo a los mismos datos. Además, los protocolos de servicio web en muchos casos pueden aumentar realmente la sobrecarga del protocolo para una tarea determinada.
Una de las razones clave por las que vemos este interés en los servicios web es que los servicios web son adecuados para habilitar una arquitectura de Service-Oriented (SOA). Cuando se usan servicios web para crear un SOA, las soluciones constan de colecciones de servicios autónomos, identificados por direcciones URL, con interfaces documentadas mediante WSDL y procesamiento de mensajes XML bien definidos. SOA es un complemento natural para los enfoques centrados en procedimientos y datos centrados en objetos para la implementación de soluciones. De hecho, al crear un sistema SOA, los servicios individuales normalmente se construyen con una o varias de estas tecnologías.
Una arquitectura de Service-Oriented difiere del sistema operativo y de procedimientos en un aspecto clave: enlace. Services interactúa en función de las funciones de que proporcionan y cómo las entregan. Los sistemas de procedimientos y OO vinculan elementos en función del tipo o el nombre. En las secciones siguientes se proporcionan más detalles.
2.1 Los servicios se describen mediante esquema y el tipo de contrato no
A diferencia de los sistemas anteriores, el modelo de servicio web no funciona en la noción de tipos compartidos que requieren una implementación común. En su lugar, los servicios interactúan basándose únicamente en contratos (WSDL/BPEL4WS para el comportamiento de procesamiento de mensajes) y esquemas (WSDL/XSD para la estructura de mensajes). Esto permite al servicio describir la estructura de los mensajes que puede enviar o recibir o recibir restricciones de secuenciación en estos mensajes. La separación entre la estructura y el comportamiento y la descripción explícita verificable de las máquinas de estas características simplifica la integración en entornos heterogéneos.
Además, esta información caracteriza suficientemente la interfaz de servicio para que la integración de aplicaciones no requiera un entorno de ejecución compartido para crear la estructura o el comportamiento de los mensajes.
El modelo orientado a servicios supone un entorno totalmente distribuido en el que es difícil, si no imposible, propagar los cambios en el esquema o contrato a todas las partes que han encontrado un servicio. La orientación del servicio implica que los contratos y el esquema deben permanecer compatibles con versiones anteriores y pueden contener información que comprende incompletamente determinados sistemas de procesamiento.
Por ese motivo, las tecnologías de contrato y esquema diseñadas para su uso en diseños orientados a servicios permiten más flexibilidad que las interfaces tradicionales orientadas a objetos. En concreto, los servicios usan características como caracteres comodín de elementos XML (por ejemplo, xsd:any), extensiones de esquema y bloques de encabezado SOAP opcionales para evolucionar los servicios de maneras que no interrumpen las aplicaciones implementadas. Estas características son la clave para la composición de los servicios web.
2.2 La compatibilidad del servicio es mayor que la compatibilidad de tipos
Los diseños orientados a procedimientos y objetos normalmente equivalen a la compatibilidad de tipos con compatibilidad semántica. La orientación del servicio proporciona un modelo más completo para determinar la compatibilidad. La compatibilidad estructural se basa en el contrato (WSDL y, opcionalmente, BPEL4WS) y el esquema (XSD) y se puede validar. Además, la llegada de WS-Policy proporciona análisis automatizados adicionales de la compatibilidad de la garantía de servicios entre servicios. Esto se realiza en función de aserciones explícitas de funcionalidades y requisitos en forma de instrucciones WS-Policy.
Con WS-Policy, los servicios describen sus funcionalidades y requisitos de garantía de servicio en forma de una expresión de directiva legible por máquina que contiene combinaciones de aserciones. Esto permite que el servicio se seleccione entre sí en función de "cómo" o "con qué calidad" entregan sus contratos,
Las aserciones de directiva se identifican mediante nombres únicos estables y globales cuyo significado es coherente en el tiempo y el espacio, independientemente del servicio al que se aplique la aserción. Las aserciones de directiva también pueden tener parámetros que califican la interpretación exacta de la aserción.
2.3 La orientación del servicio supone que las cosas malas pueden ocurrir y ocurrirán
Algunos enfoques anteriores para las aplicaciones distribuidas presuponen explícitamente un espacio de tipos común, un modelo de ejecución y un modelo de referencia de procedimiento o objeto. En esencia, el modelo de programación "en memoria" definió el modelo de sistema distribuido.
La orientación del servicio simplemente supone que los servicios se ejecutan de forma autónoma y no hay ninguna noción de ejecución local o entorno operativo común. Por este motivo, un SOA asume explícitamente que los errores de comunicación, disponibilidad y tipo son comunes.
Para mantener la integridad del sistema, los diseños orientados al servicio se basan explícitamente en una variedad de tecnologías para tratar con modos de error parcial y asincrónico. Las técnicas como la mensajería asincrónica, las transacciones, la mensajería confiable y la implementación redundante son la norma en sistemas orientados a servicios.
Además, a diferencia del modelo en memoria, la orientación del servicio supone que no solo un mensaje entrante puede tener un formato incorrecto, sino que también puede haber sido transmitido con fines malintencionados o completamente inesperados. Por consiguiente, los sistemas orientados al servicio se protegen colocando la carga de prueba en todos los remitentes de mensajes exigiendo a las aplicaciones que demuestren que los derechos necesarios se han concedido al remitente. De forma coherente con la noción de autonomía de servicio, las arquitecturas orientadas a servicios suelen basarse en relaciones de confianza administradas administrativamente para evitar mecanismos de autenticación por servicio comunes en las aplicaciones web clásicas.
2.4 La orientación del servicio permite un enlace flexible de servicios
Uno de los conceptos básicos de arquitectura orientada a servicios (SOA) es un enlace flexible de servicios. Los modelos de procedimientos, componentes y objetos más tradicionales enlazan los componentes a través de referencias (punteros) o nombres. Un SOA admite la detección más dinámica de instancias de servicio que proporciona la interfaz, la semántica y las garantías de servicio que espera el solicitante.
En los sistemas orientados a procedimientos o objetos, un autor de llamada suele buscar un servidor en función de los tipos que exporta o un espacio de nombres compartido. En un sistema SOA, los autores de llamadas pueden buscar registros, como UDDI para un servicio.
- Es un mensaje compatible con los requisitos del autor de la llamada. La compatibilidad puede producirse a través de WSDL o mensajes coincidentes de esquemas XML conocidos.
- Que documenta la compatibilidad con las garantías de servicio que requiere el autor de la llamada. Por ejemplo, el autor de la llamada puede querer ciertos enfoques para la seguridad o las transacciones.
El enlace flexible con respecto a la implementación del servicio que permite implementaciones alternativas de comportamiento se puede usar para abordar una variedad de requisitos empresariales. Por ejemplo, las implementaciones alternativas pueden corresponder a proveedores alternativos de una cadena de suministro que permiten una respuesta más rápida a las condiciones cambiantes del mercado. De forma similar, la implementación alternativa podría ser centros de datos distribuidos geográficamente que permitan la tolerancia ante desastres.
3.0 Especificaciones y funciones del servicio web
En esta sección se proporciona información general sobre las especificaciones del servicio web.
3.1 Un enfoque redactable para los servicios web
En esta sección se describen brevemente las especificaciones del servicio web que están disponibles. Explicamos su valor a los proveedores de soluciones, su rol en una arquitectura más amplia y cómo se complementan entre sí.
En la ilustración siguiente se proporciona una agrupación de alto nivel de las especificaciones del servicio web publicadas por IBM, Microsoft y otros. Tenga en cuenta que esta figura no está pensada para implicar una capa estricta entre los grupos; en su lugar, está pensado para proporcionar una intuición sobre las relaciones entre áreas funcionales. Por ejemplo, la seguridad del mensaje no requiere descripción y, de forma similar, descripción es un concepto de tiempo de desarrollo útil para mensajería.
.gif)
Figura 3. Arquitectura de protocolo de servicios web interoperables
3.2 Los conceptos básicos: transportes y mensajería
Si te envío una carta escrita en francés pero esperabas una llamada telefónica en inglés, no nos comunicaremos. La interoperabilidad de los servicios web se enfrenta al mismo problema; abordamos esto proporcionando un conjunto común de transportes y tecnología de mensajería.
Además, para garantizar que estas tecnologías sean eficaces en la práctica, IBM, Microsoft y otros crearon la organización de interoperabilidad de servicios web (WS-I). Recientemente el WS-I publicó un perfil básico que documenta formalmente los mecanismos de mensajería y transporte de servicios web interoperables.
3.2.1 Transportes: HTTP, HTTP/S, SMTP
Este conjunto de especificaciones define los mecanismos de comunicación principales para mover datos sin procesar entre servicios web.
Http, HTTP/S y Protocolo simple de transporte de correo (SMTP) son ejemplos de este grupo. Las implementaciones de servicios web también pueden admitir otros transportes, pero es fundamental proporcionar compatibilidad con protocolos estándar e interoperables.
3.2.2 Formatos de mensaje: XSD
El siguiente grupo de especificaciones define mecanismos interoperables para codificar mensajes de servicio web para el transporte. Los transportes mueven bloques de "bytes" entre servicios. Esto solo resulta útil si los participantes pueden convertir los bytes en estructuras de datos útiles que procesa su aplicación.
El grupo de especificaciones de mensajería define cómo dar formato a los mensajes correctamente. Las definiciones de esquema XML y XML proporcionan el mecanismo para aceptar de forma abstracta las estructuras de mensajes (datos). SOAP define la codificación estándar para representar mensajes XML en la información de bytes que los servicios intercambian a través de transportes.
3.2.3 WS-Addressing
Tanto los mensajes como las respuestas van a algún lugar y proceden de algún lugar. WS-Addressing proporciona un enfoque interoperable e independiente de transporte para identificar remitentes y receptores de mensajes. WS-Addressing también proporciona un enfoque más preciso para identificar elementos específicos dentro de un servicio que envían o deben recibir un mensaje.
En la actualidad, la mayoría de los sistemas que usan servicios web codifican el destino de un mensaje de servicio web con una dirección URL que se coloca en el transporte HTTP. El destino de la respuesta viene determinado por la dirección de transporte de retorno. Este enfoque se basa en el modelo básico de servidor del explorador http.
Con el enfoque actual, la información de origen y destino no forma parte del propio mensaje. Esto puede causar varios problemas. La información se puede perder si una conexión de transporte finaliza (por ejemplo, si la respuesta tarda mucho tiempo y se agota el tiempo de espera de la conexión) o si un intermediario reenvía el mensaje, como un firewall.
WS-Addressing proporciona un mecanismo para colocar el destino, el origen y otra información de dirección importante directamente dentro del mensaje del servicio web. En resumen, WS-Addressing desacopla la información de direcciones de cualquier modelo de transporte específico.
En muchos escenarios, los mensajes se dirigen directamente a un servicio y la información de direccionamiento del mensaje se puede describir simplemente mediante una dirección URL. Pero en la práctica, a menudo encontramos que los mensajes están dirigidos a elementos o recursos específicos dentro de un servicio. Por ejemplo, un servicio de coordinación podría estar coordinando muchas tareas diferentes. El coordinador debe asociar la mayoría de los mensajes entrantes a una instancia de tarea específica que administra y no el propio servicio de coordinación.
WS-Addressing proporciona un mecanismo sencillo y eficaz denominado de referencia de punto de conexión de
La combinación de un control específico sobre el direccionamiento junto con la codificación neutra del transporte del origen del mensaje y el destino permite enviar mensajes de servicio web a través de un intervalo de transportes, a través de intermediarios, y permite patrones de comunicación de duración asincrónica y extendida.
WS-Addressing también permite a un remitente indicar dónde debe ir una respuesta de manera independiente del transporte. Es posible que la respuesta a un mensaje no vaya necesariamente al remitente. Por ejemplo, en HTTP, sin WS-Addressing es imposible especificar que la respuesta se debe enviar en otro lugar.
Estas mejoras en el modelo de mensajería permiten que los servicios web se usen para admitir muchos escenarios empresariales. Por ejemplo, ciertas tareas bancarias requieren revisión humana para su aprobación en determinados pasos. Normalmente hay muchas instancias activas de la tarea en cualquier momento dado. WS-Addressing proporciona un mecanismo general para asociar mensajes entrantes o salientes a tareas específicas. El mecanismo que usa el servicio es transparente para aquellos que usan el servicio a través de una referencia de punto de conexión.
3.3 Descripción
Las especificaciones de transporte y mensaje permiten a los servicios web comunicarse mediante mensajes. ¿Pero cómo saben los participantes cuáles son los mensajes? ¿Cómo documenta un servicio web o describe los mensajes que envía y recibe? El uso de un servicio web requiere una comprensión de los mensajes que consumirá y generará el servicio web: la interfaz para el servicio web. El grupo de especificaciones de descripción permite a un servicio web expresar su interfaz y funcionalidades.
Además de la interoperabilidad de mensajes; estas especificaciones también permiten interoperabilidad de la herramienta de desarrollo. Las especificaciones de descripción proporcionan un modelo estándar que permite que diferentes herramientas de distintos proveedores admitan de forma colaborativa a los desarrolladores. De la misma manera que los servicios web aíslan los asociados de las opciones de implementación e infraestructura, las especificaciones de descripción aíslan a los asociados de las opciones de herramientas de desarrollo.
3.3.1 WSDL
El del lenguaje de descripción de servicios web (WSDL)
WSDL proporciona compatibilidad con un intervalo de patrones de interacción de mensajes. Admite mensajes de entrada unidireccionales que no tienen respuesta, solicitud o respuesta, y una manera de enviar con o sin una respuesta. Los dos últimos patrones permiten a un servicio especificar otros servicios que necesita.
Las mejoras de WSDL propuestas proporcionan compatibilidad con la documentación de protocolos y formatos de mensaje que admite un servicio y la dirección del servicio.
3.3.2 WS-Policy
Las definiciones de WSDL y XSD a menudo no proporcionan suficiente información para llamar a un servicio web. WSDL y XSD definen la sintaxis de la interfaz del servicio, pero no expresan información sobre cómo el servicio entrega su interfaz o lo que espera el servicio del autor de la llamada. Por ejemplo, ¿el servicio requiere seguridad o implementa transacciones?
WS-Policy permite a un servicio especificar lo que espera de los autores de llamada y cómo implementa su interfaz. WS-Policy es fundamental para lograr la interoperabilidad en el funcionamiento funcional de nivel superior del servicio. La seguridad, las transacciones, la mensajería confiable y otras especificaciones requieren un esquema de WS-Policy concreto. Estos permiten a los servicios describir la garantía funcional de que esperan y proporcionan a los autores de llamadas.
El marco de WS-Policy proporciona un modelo base para definir expresiones de directiva.
WS-Policy admite una gramática para agregar instrucciones de directiva y permite la construcción de conjuntos de directivas más flexibles y completos.
WS-PolicyAttachment especifica cómo asociar un conjunto de directivas con mensajes XML y elementos WSDL (operaciones y portTypes).
Juntos WS-Policy y WS-PolicyAttachment proporcionan el marco. Las especificaciones individuales definen sus instrucciones de directiva y esquema específicos del dominio.
Por último, @PageWS-PolicyAssertions proporciona un conjunto fundamental de instrucciones de directiva comunes que se pueden usar para lograr la interoperabilidad.
3.3.3 Obtener descripciones
XML, XSD, WSDL y WS-Policy admiten la descripción de las garantías de interfaz y servicio de un servicio. Pero, ¿cómo pueden los usuarios potenciales del servicio encontrar esta información?
Actualmente, el enfoque más común es a través de intercambios de correo electrónico o palabra de boca. Se necesita un modelo más general y escalable. Hay dos opciones, el servicio puede ir directamente al servicio para obtener información mediante WS-MetadataExchange o puede optar por usar un servicio UDDI que agrega esta información para varios servicios de destino.
Los desarrolladores usan WS-MetadataExchange cuando tienen una referencia a un servicio y necesitan comprender lo que hace. Los desarrolladores usan UDDI cuando quieren encontrar una referencia a un servicio que admita un conjunto específico de funciones.
3.3.4 WS-MetadataExchange
Como se ha descrito anteriormente, los servicios suelen proporcionar información como WSDL, WS-Policy y XSD, que describen el propio servicio. Recopilación que hacemos referencia a información sobre el servicio como metadatos. La especificación WS-MetadataExchange permite a un servicio proporcionar metadatos a otros usuarios a través de una interfaz de servicios web. Dado solo una referencia a un servicio web, un posible usuario puede acceder a un conjunto de operaciones WSDL/SOAP para recuperar los metadatos que describen el servicio. Los clientes pueden usar WS-MetadataExchange en tiempo de diseño, al compilar sus clientes o en tiempo de ejecución.
3.3.5 UDDI
A menudo resulta útil recopilar metadatos sobre una colección de servicios y hacer que la información esté disponible en un formulario que se pueda buscar. Estos servicios de agregación de metadatos son un repositorio útil en el que las organizaciones pueden publicar los servicios que proporcionan, describir las interfaces a sus servicios y habilitar taxonomías específicas del dominio de los servicios. La especificación de interfaz universal de descripción y detección (UDDI) define un servicio de agregación de metadatos.
Las soluciones pueden consultar UDDI en tiempo de diseño para buscar servicios compatibles con sus requisitos. Los desarrolladores pueden usar estos servicios en la definición de sus flujos de trabajo de BPEL4WS, por ejemplo. Las soluciones también pueden consultar UDDI en tiempo de ejecución. En este escenario, el autor de la llamada "conoce" la interfaz que requiere y busca un servicio que cumpla sus requisitos funcionales o que lo proporcione un asociado conocido.
Tenga en cuenta que uno de los mecanismos que se pueden usar para rellenar un servicio UDDI con metadatos es adquirir los metadatos de los servicios mediante WS-MetadataExchange.
3.4 Service Assurances
Los servicios web han generado tanto entusiasmo en parte debido a su capacidad para puentear sistemas dispares. Los desarrolladores han producido muchas soluciones totalmente funcionales mediante las funcionalidades base de transporte, mensajería y descripción. Sin embargo, para que los desarrolladores creen soluciones de integración más eficaces, los servicios web deben proporcionar funcionalidad para garantizar el mismo nivel de garantías de servicio de proporcionadas por soluciones de middleware más tradicionales. No basta con intercambiar mensajes. Las aplicaciones y los servicios residen en middleware y sistemas que proporcionan funciones valiosas de nivel superior, como la seguridad, la confiabilidad y las operaciones de transacción. Los servicios web deben proporcionar un mecanismo para la interoperabilidad entre estas funciones.
3.5 Seguridad
Esta @Pagefamilia de especificaciones es fundamental para los servicios web entre organizaciones. Estas especificaciones admiten la autenticación y la integridad de los mensajes, la confidencialidad, la confianza y la privacidad. También admiten la federación de seguridad entre diferentes organizaciones.
3.5.1 WS-Security
WS-Security es el bloque de creación básico para servicios web seguros. En la actualidad, la mayoría de los servicios web distribuidos dependen de la compatibilidad con el nivel de transporte para las funciones de seguridad. Algunos ejemplos son HTTP/S y BASIC-Auth autenticación. Estos enfoques para la seguridad proporcionan el mínimo necesario para la comunicación segura. Sin embargo, el nivel de función que proporcionan es significativamente menor que el proporcionado por el middleware existente y los entornos distribuidos.
Dos ejemplos resaltan las deficiencias de BASIC-Auth y HTTP/S.
- Un envía un mensaje al servicio B. B procesa parcialmente los mensajes y lo reenvía al servicio C. HTTP/S permite la autenticación, confidencialidad e integridad entre A-B y B-C. Sin embargo, C y A no se pueden autenticar entre sí u ocultar información de B.
- Para que A, B y C usen BASIC-Auth para la autenticación. Deben compartir la misma información de usuario y contraseña replicada. Esto es inaceptable en muchos escenarios.
WS-Security resuelve estos problemas. Admite:
- Tokens de seguridad cifrados firmados. Un puede generar un token que C puede comprobar que procede de A. B no puede falsificar el token.
- Un puede firmar elementos seleccionados o todo el mensaje. Esto permite que B y C confirmen que el mensaje no ha cambiado desde que A lo envió.
- Un puede cerrar el mensaje o los elementos seleccionados. Esto garantiza que solo el servicio previsto para esos elementos pueda usar la información. Esto impide que B vea información pensada para C y viceversa.
WS-Security usa modelos de seguridad existentes (Kerberos, X509, etc.). Las especificaciones definen concretamente cómo usar los modelos existentes de forma interoperable. Los cálculos del servicio web de varios saltos no pueden protegerse sin WS-Security.
3.5.2 WS-Trust
La seguridad se basa en relaciones de confianza predefinidas. Kerberos funciona porque los participantes "confían" en el Centro de distribución de claves kerberos. PKI funciona porque los participantes confían en las entidades de certificación raíz. WS-Trust define un modelo extensible para configurar y comprobar las relaciones de confianza.
El concepto clave de WS-Trust es un servicio de token de seguridad (STS) de . un STS es un servicio web distintivo que emite, intercambia y valida los tokens de seguridad. WS-Trust permite a los servicios web configurar y aceptar qué servidores de seguridad "confían" y confiar en estos servidores.
El STS tiene una amplia aplicabilidad en que se puede usar para emitir tokens de seguridad que hacen una amplia gama de aserciones. En muchos casos, se usará para emitir las mismas aserciones, pero en formatos diferentes. Por ejemplo, un STS podría emitir un token kerberos que asevere que el titular de la clave es Susan y podría hacerlo en función de un certificado X.509 emitido por una entidad de certificación de confianza. Esto permite a las organizaciones usar diferentes tecnologías de seguridad para federar. Un STS también puede emitir un token de seguridad que confirme que el titular de la clave es miembro del grupo BankTellers basado en un token de seguridad entrante que aserte una notificación de identidad.
3.5.3 WS-SecureConversation
Algunos escenarios de servicio web solo implican el breve intercambio esporádico de algunos mensajes. WS-Security admite fácilmente este modelo. Otros escenarios implican conversaciones de varios mensajes de larga duración entre los servicios web. WS-Security también admite este modelo, pero la solución no es óptima.
Hay dos usos sub óptimos de WS-Security en estos escenarios:
- Uso repetido de operaciones criptográficas computacionalmente costosas, como la validación de claves públicas.
- Enviar y recibir muchos mensajes con las mismas claves criptográficas, proporcionando más información que permite ataques por fuerza bruta "interrumpir el código".
Por estos motivos, los protocolos como HTTP/S usan claves públicas para realizar una negociación sencilla que define claves específicas de conversación. Este intercambio de claves permite implementaciones de seguridad más eficaces y también reduce la cantidad de información cifrada con un conjunto específico de claves.
WS-SecureConversation proporciona compatibilidad similar con WS-Security. Los participantes suelen usar WS-Security con claves públicas para iniciar una "conversación" o "sesión" y usar WS-SecureConversation para acordar claves específicas de sesión para firmar y cifrar información.
3.5.4 WS-Federation
WS-Federation permite a un conjunto de organizaciones establecer un dominio de seguridad virtual único. Por ejemplo, un agente de viajes, una aerolínea y una cadena de hoteles pueden configurar dicha federación. Un usuario final que "inicia sesión" en cualquier miembro de la federación ha iniciado sesión eficazmente en todos los miembros. WS-Federation define varios modelos para proporcionar seguridad federada a través de protocolos entre WS-Trust y topologías de WS-SecureConversation.
Además, los clientes suelen tener "propiedades" cuando se ocupan de una empresa. Un ejemplo es una preferencia para los asientos de ventana o pasillo, o un coche de tamaño medio. WS-Federation permite a los miembros configurar un espacio de propiedades federados. Esto permite a cada participante tener acceso controlado seguro a la información de propiedad de cada miembro sobre los usuarios finales.
Las propiedades y la información sobre las personas pueden mantenerse detenidamente para la protección de la privacidad o porque la información proporciona una ventaja competitiva a un miembro específico. Para admitir estos requisitos, WS-Federation admite un modelo de seudónimo. Usuarios que se han autenticado en la agencia de viajes han generado "alias" en sus interacciones con la aerolínea o el hotel. Esto protege la privacidad del usuario final y la ventaja competitiva que la agencia de viajes puede obtener al conocer las propiedades del usuario.
3.6 Mensajería confiable
En un mundo de Internet, casi todos los canales de comunicación no son confiables. Los mensajes desaparecen. Se interrumpen las conexiones.
Sin un estándar de mensajería confiable, los desarrolladores de aplicaciones de servicio web deben compilar estas funciones en sus aplicaciones. Los enfoques y técnicas básicos se comprenden bien, por ejemplo, muchos sistemas operativos y de middleware garantizan que los mensajes tengan identificadores únicos, proporcionen números de secuencia y usen la retransmisión cuando se pierdan los mensajes. Si los desarrolladores de servicios web de aplicaciones implementan estos modelos en sus aplicaciones. Pueden realizar diferentes suposiciones o opciones de diseño, lo que da como resultado poco si hay mensajería confiable.
3.6.1 WS-ReliableMessaging
WS-ReliableMessaging define mecanismos que permiten a los servicios web garantizar la entrega de mensajes en redes de comunicación no confiables.
WS-ReliableMessaging garantiza que los servicios implementen enfoques interoperables y también permiten a los proveedores en tiempo de ejecución facilitar el desarrollo de aplicaciones al proporcionar servicios que implementan los protocolos. Esto simplifica significativamente la tarea de desarrollo de aplicaciones. Después, la lógica de negocios tiene muchas menos condiciones de error que debe controlar.
Por último, el sector tiene un amplio conjunto de middleware orientado a mensajes para enrutar y distribuir mensajes de forma confiable. Cada implementación usa protocolos propietarios. WS-Reliable protocolos de mensajería permiten que diferentes sistemas operativos y de middleware intercambien mensajes de forma confiable. Por lo tanto, admite el puente de dos infraestructuras diferentes en un único modelo de un extremo a otro lógicamente completo.
3.7 Transacciones
Un escenario empresarial complejo puede requerir que varias partes intercambien varios conjuntos de mensajes. Un ejemplo es un conjunto de instituciones financieras que configuran una oferta financiera que implica pólizas de seguros, anualidades, cuentas de cheques y cuentas de corretaje. Los múltiples mensajes intercambiados entre los participantes constituyen una "tarea" lógica o "objetivo".
Para el éxito, las partes deben ser capaces de:
- Inicie nuevas tareas coordinadas.
- Asocie las operaciones a su tarea lógica. Las partes pueden configurar varias cuentas para diferentes clientes al mismo tiempo.
- Acepte el resultado del cálculo. Por ejemplo, ¿todos están de acuerdo en que se configuraron los paquetes financieros?
WS-Coordination, WS-AtomicTransaction y WS-BusinessActivity admiten estos requisitos.
3.7.1 WS-Coordination
@Pagede coordinación de WS es un mecanismo general para iniciar y aceptar el resultado de las tareas de servicio web multiparte y de varios mensajes. WS-Coordination tiene tres elementos clave:
- Un elemento de mensaje denominado contexto de coordinación que fluye en todos los mensajes que intercambian los servicios web durante el cálculo. El contexto de coordinación contiene la referencia de punto de conexión de WS-Addressing al servicio de coordinación y, a su vez, contiene información para identificar la tarea específica que se está coordinando.
- El servicio de coordinación de . El servicio de coordinación proporciona un servicio, descrito mediante WSDL, que proporciona la capacidad de iniciar una tarea coordinada, finalizar una tarea coordinada, permitir que un participante se registre en una tarea y genere un contexto de coordinación que forme parte de todos los mensajes de un grupo.
- El servicio de coordinación también incluye una interfaz, definida en WSDL, que los servicios participantes usan para informarse del resultado de la tarea coordinada.
Un servicio web que recibe un mensaje con un nuevo contexto de coordinación se registra con el servicio de coordinación en el contexto para recibir información de resultados. Otras especificaciones pueden aumentar este marco para los requisitos específicos de dominio y garantía.
WS-Coordination es un marco y una funcionalidad generales. WS-AtomicTransaction y WS-BusinessActivity ampliar este marco para permitir que los participantes del cálculo distribuido determinen de forma sólida los resultados.
3.7.2 WS-AtomicTransaction
WS-AtomicTransaction define un conjunto específico de protocolos que conectan al modelo de WS-Coordination para implementar protocolos de transacciones atómicas tradicionales de dos fases. Es importante tener en cuenta que el modelo atómico de dos fases solo es con respecto a los servicios implicados. Los sitios o servicios de oferta de infraestructura pueden anunciar la confirmación en dos fases, pero usar algún otro modelo intraemprendimiento, como la compensación o el control de versiones. Esta libertad hace que un modelo de confirmación en dos fases sea más útil para los cálculos de Internet de larga duración.
3.7.3 WS-BusinessActivity
WS-BusinessActivity define un conjunto específico de protocolos que conectan al modelo de WS-Coordination para implementar protocolos de transacciones basados en compensación de larga duración. Aunque BPEL4WS define un modelo de transacción para los procesos empresariales, es WS-BusinessActivity que especifica la representación del protocolo correspondiente. Esto, de nuevo, es un ejemplo para la composición de las especificaciones de servicios web.
3.8 Composición del servicio
El elemento superior de la capa de servicio web es composición del servicio. La composición del servicio permite a los desarrolladores "redactar" servicios que intercambian mensajes SOAP y definen su interfaz en WSDL y WS-Policy en una solución de agregado. El agregado es un servicio web compuesto.
3.8.1 BPEL4WS
La especificación de
La composición tiene tres aspectos: estructura , de información y comportamiento de . BPEL4WS presenta tres construcciones que admiten cada aspecto de composición.
Un partnerLink define una asociación con nombre entre el servicio compuesto y un servicio web que participa en la solución general. El servicio compuesto y el servicio participante definen sus interfaces entre sí mediante WSDL y WS-Policy. Un ejemplo podría ser una asociación entre una empresa de fabricación y un proveedor.
El concepto partnerLink y las interfaces WSDL/WS-Policy entre la composición y los asociados definen la estructura de la composición del servicio. Definen los tipos de servicios que colaboran para formar la composición y qué mensajes intercambian con qué niveles de garantía (seguridad, transacciones, etc.)
BPEL4WS también proporciona compatibilidad para definir la información de la composición del servicio. BPEL4WS define el concepto de una variable. El servicio compuesto define un conjunto de variables, cada una de las cuales tiene una definición XSD. El estado actual de un servicio específico es el estado de sus variables. Esto define qué mensajes ha recibido o enviado.
Por último, BPEL4WS admite la definición del comportamiento del servicio compuesto por el concepto de una actividad de . Un BPEL4WS servicio definido es un conjunto de actividades o "pasos", que definen el comportamiento del servicio. Las actividades más básicas envían un mensaje a un asociado o reciben un mensaje de un asociado. Cada mensaje corresponde a una variable. BPEL4WS proporciona compatibilidad para mover datos entre variables.
Un aspecto clave de las actividades de BPEL4WS es que BPEL4WS proporciona compatibilidad especial para definir el comportamiento externo visible (público) de los servicios al permitir el uso controlado de un comportamiento no determinista. Por ejemplo, el hecho de que una comprobación de crédito se realice de forma específica en el proceso de decisión para aceptar una solicitud de compra puede ser una cuestión privada para un proveedor. BPEL4WS permite ocultar el proceso de decisión quitando el comportamiento de la comprobación de crédito de la descripción del proceso, pero mostrando que la respuesta al pedido de compra puede ser aceptación o rechazo. Este tipo de proceso de abstracto se puede usar junto con WSDL para definir protocolos empresariales interoperables entre asociados comerciales y para dominios verticales del sector, como la cadena de suministro.
BPEL4WS también admite varios enfoques para controlar el flujo de ejecución de actividades. Entre ellas se incluyen flujos basados en secuenciación y gráficos. BPEL4WS admite predicados en variables para determinar qué rutas de control sigue el servicio compuesto.
En resumen, BPEL4WS realiza dos adiciones a las especificaciones de servicio web definidas anteriormente.
- BPEL4WS amplía la compatibilidad con WSDL y WS-Policy para describir los servicios. BPEL4WS admite la combinación de servicios web en servicios agregados y la documentación de las asociaciones entre servicios, como el flujo de información y el comportamiento. Esto proporciona compatibilidad con la interoperabilidad entre herramientas de nivel superior que admiten el diseño colaborativo de servicios web.
- BPEL4WS es un lenguaje de ejecución . BPEL4WS permite a los desarrolladores especificar completamente el comportamiento de un servicio web compuesto. IBM, Microsoft y otros asociados proporcionarán entornos que ejecuten BPEL4WS documentos y admitan el diseño y el enlace de tiempo de ejecución a los asociados.
4.0 Servicios web en la práctica: un ejemplo
En el escenario siguiente se muestra cómo se pueden usar juntas las especificaciones de WS para crear servicios web que resuelvan las necesidades del mundo real. El escenario proporciona un ejemplo de la eficaz funcionalidad disponible para los desarrolladores debido a la composición de las distintas especificaciones de WS.
Los servicios web descritos en este escenario se crearon para una demostración conjunta IBM-Microsoft de la tecnología celebrada el 17 de septiembre de 2003. Se usaron para crear una aplicación que sea interoperable, segura, confiable y transaccionada; y que abarca los límites de la organización.
La demostración muestra un ejemplo en ejecución de un sistema federado de procesamiento de pedidos y inventario administrado por proveedores (VMI) para un concesionario de automóviles que ordena una parte de un fabricante de automóviles; a su vez, el fabricante obtiene piezas de un proveedor que opera varios almacenes. Todas las comunicaciones de aplicación a aplicación del sistema se crearon exclusivamente mediante los protocolos de servicio web descritos anteriormente y ejecutándose en una colección de equipos con software IBM y Microsoft.
El escenario se ocupa de algunos de los aspectos más comunes de la realización de negocios: la interacción entre una empresa minorista, su mayorista y el proveedor del mayorista. En el escenario se muestra cómo se pueden componer diferentes especificaciones de WS para automatizar aspectos esenciales del proceso empresarial, como:
- Autenticación para aplicar la seguridad (WS-Security)
- Federación de confianza entre diferentes organizaciones ( WS-Trust y WS-Federation)
- Intercambio de datos para completar una transacción (WS-AtomicTransaction)
- Garantía de que los pedidos se han enviado a través de mensajería confiable (WS-ReliableMessaging)
4.1 Parte 1: La experiencia del cliente
El ejemplo comienza con Heather, un empleado de una empresa denominada Auto Dealer, que inicia sesión en el sitio web seguro de intranet de su concesionario. Este sitio web se crea mediante tecnologías web estándar y fuera de la plataforma. Heather entra en el sitio con su navegador. El acceso al sitio está protegido con contraseña.
.gif)
Figura 4. Heather inicia sesión en el sitio web seguro de la intranet de su empresa y navega a su página personalizada.
Heather hace clic en Mi página. En segundo plano, la aplicación recopila información de la base de datos de inventario del distribuidor automático. Si los niveles de inventario de un elemento se encuentran por debajo de un umbral definido, se genera un informe y se muestra en la pantalla "Sus alertas" de la página de Heather.
Heather ve que su empresa tiene un bajo inventario en hojas de wiper WindshieldPro.
Heather hace clic en el vínculo y se redirige sin problemas a una página web segura en la extranet del fabricante automático, donde Heather puede realizar un pedido. La experiencia es perfecta porque el software auto dealer se basa en servicios web. El servicio web que vincula la intranet del distribuidor automático con la extranet del fabricante automático se compuso mediante WS-Federation. WS-Federation garantiza que un segundo sitio respeta las credenciales de seguridad concedidas por un sitio.
Así es como funciona esto. El distribuidor automático y el fabricante de automóviles han acordado federar sus sitios. WS-Federation coordina una serie de comunicaciones de servidor a servidor. En cuanto Heather haga clic en el vínculo WindshieldPro para llevarlo a la página web del fabricante automático, el servidor de páginas web del fabricante automático consulta su servicio de autorización, que a su vez consulta el servicio de autorización del distribuidor automático. El servicio de autorización del distribuidor automático confirma que Heather es un usuario autorizado, que transmite credenciales, junto con el nombre del concesionario de Heather, de vuelta al servicio de autorización del fabricante automático, que concede acceso a Heather. Esto sucede sin problemas, que todas las notas de Heather es que ha pasado de una página web a otra.
El servicio web también consulta la base de datos de clientes del fabricante automático para solicitar información vinculada a la cuenta de Heather. La información se presenta en una página web personalizada del fabricante automático "Mi página".
.gif)
Figura 5: Redacción de un servicio web mediante WS-Federated permite a Heather pasar sin problemas de su página personalizada en Auto Dealer a su página personalizada en Auto Manufacturer.
La página web personalizada de Heather en la extranet del fabricante automático le permite ver que actualmente no tiene pedidos pendientes; ella tiene un pedido (para 50 SuperTires) en tránsito; y que su lista de pedidos completados incluye 20 unidades de CDPlus y 50 unidades de Limpiador de cuero.
Heather hace clic en "Crear nuevo pedido" y se abre una página nueva, rellenada previamente con la parte que quiere: hojas de wiper WindshieldPro y la fecha de pedido. Todo lo que necesita para entrar es la cantidad. Toda la información necesaria para completar el pedido se rellena desde la base de datos del fabricante automático.
.gif)
Figura 6. Un pedido se realiza fácilmente porque gran parte de los datos de pedidos ya se han importado desde el archivo de Heather en la base de datos del cliente del fabricante automático.
Heather envía el pedido y busca artículos adicionales para comprar, o hace clic en Cerrar sesión, para finalizar su sesión e impedir que cualquier otra persona realice un pedido desde su equipo desatendido.
Tenga en cuenta que la redacción del servicio web con WS-Federation proporcionó tanto el distribuidor automático como el fabricante automático con menores costos administrativos y seguridad de un extremo a otro. Sin esta tecnología, el fabricante automático habría tenido que mantener una lista de todos los empleados autorizados de concesionarios y sus contraseñas. Esto sería costoso, propenso a errores y reducir la seguridad de la aplicación.
Por ejemplo, si Heather abandona su trabajo, su cuenta de usuario se quitaría en auto dealer. Pero si el administrador del concesionario olvidó ponerse en contacto con el fabricante automático sobre su salida, seguiría teniendo acceso al sitio de compra. Con WS-Federation, esto no es un problema, ya que el único sistema que tiene que cambiarse es el servicio de proveedor de identidades del distribuidor automático. Los sistemas del fabricante automático, tanto la aplicación como el servicio de autorización, no tienen conocimientos innatos de Heather, su nombre de usuario o su contraseña.
4.2 Parte 2: La experiencia del proveedor
Aunque Heather ordena las hojas de wishieldPro del fabricante automático, ha pasado medio siglo desde que la empresa realmente hizo sus propias hojas. Las hojas de wiper WindshieldPro proceden de un proveedor, Proveedor.
Tony es el representante de ventas para Proveedor, y comienza su día iniciando sesión en la intranet del proveedor, al igual que Heather ha iniciado sesión en la intranet del distribuidor automático. Pero en lugar de usar un explorador web estándar, Tony trabaja con una aplicación de Windows que tiene compatibilidad integrada con servicios web.
.gif)
Figura 7. La página personal de Tony en la intranet del proveedor le recuerda que compruebe los pedidos y el inventario en uno de sus principales clientes, Fabricante automático.
Cuando Tony hace clic para comprobar los pedidos y el inventario, su aplicación usa un servicio web para pedir datos de inventario a los que Tony puede acceder.
Un aspecto clave de esta solicitud de servicios web de nivel de aplicación es que se compone de WS-Federation que autentica su acceso a la extranet del fabricante automático.
El servicio web devuelve los resultados a la página del proveedor donde se muestra por tipo de producto y recuento de inventario actual.
.gif)
Figura 8. Un servicio web rellena la página proveedor de Tony con datos de inventario de las bases de datos de inventario del fabricante automático. La solicitud se realizó de forma segura mediante su redacción con WS-Security y WS-Federation.
El proveedor ha entrado en un contrato de compra Just-In-Time con el fabricante automático. Tony está autorizado para proporcionar un pedido de reprovisionamiento automático como parte del inventario administrado por el proveedor (VMI) en nombre del fabricante automático una vez que el inventario cae por debajo de 20. Tony hace clic en WindshieldPro para realizar un pedido. Todos los mensajes entre Tony y Auto Manufacturer están protegidos porque la aplicación es compatible con los servicios web compuestos con las protecciones de WS-Security.
.gif)
Figura 9. Un acuerdo Just-In-Time con el fabricante automático permite a Tony entrar en un pedido en nombre de la empresa.
La aplicación de Tony le proporciona una pantalla para crear solicitudes al proveedor con un pedido de compra del fabricante automático. Tony ordena 50 borradores WindishieldPros que se envíen directamente al fabricante automático.
Cuando Tony hace clic en Aceptar, el servicio de almacenamiento, un servicio web compuesto por WS-AtomicTransactions, WS-Security y WS-ReliableMessaging, intenta realizar el pedido con otro servicio web, los servicios de almacenamiento subordinados. Cuando una respuesta no se devuelve inmediatamente desde el servicio de almacenamiento (debido a una interrupción temporal de la red) WS-ReliableMessaging continúa reenviando la consulta, hasta que recibe una respuesta.
Cuando el servicio de almacenamiento recibe el pedido, los retransmite internamente a los dos almacenes físicos de la empresa. Dado que esto implica bases de datos entre ambos almacenes, se usa WS-AtomicTransaction para garantizar el comportamiento transaccional entre las bases de datos.
La aplicación Warehouse divide los pedidos entre los servicios de almacenamiento subordinados para garantizar la cobertura de inventario, 70% de pedido va al almacén 1 y los 30% restantes van al almacén 2. El Coordinador raíz del almacén principal envía un mensaje al Coordinador raíz del almacén 2 solicitando 30% del pedido. El Coordinador raíz del almacén 2 comprueba su inventario y envía un mensaje al Coordinador raíz del almacén principal que no hay suficiente inventario en existencias.
El coordinador principal de raíz sabiendo que no hay suficiente inventario cancela toda la transacción y envía un mensaje a la aplicación de servicio web de Tony que indica el estado, los niveles de inventario y que se canceló la transacción. El coordinador raíz comienza a devolver la transacción y, cuando se completa, vuelve al almacén para indicar que se ha cancelado la transacción.
Tony, con el conocimiento actual del inventario, envía otra solicitud al almacén. El coordinador raíz coordina entre otras entidades transaccionales (controlador de otras transacciones) y envía esta solicitud a los 2 almacenes que pasan por el mismo proceso que antes. Usamos WS-Security para firmar todo el cuerpo del mensaje, por lo que no importa qué dominio esté en usted sabe que está seguro.
Ahora, el coordinador raíz confirma las transacciones, bloquea los recursos y completa la transacción. Se devuelve un mensaje a Tony que indica que la transacción se ha completado correctamente.
WS-AtomicTransaction compone con WS-ReliableMessaging y WS-Security en estos mensajes, para ofrecer un sistema distribuido completo listo para la empresa.
5.0 Conclusiones
IBM, Microsoft y nuestros asociados están desarrollando especificaciones de servicio web que se pueden usar como bloques de creación para una nueva generación de servicios web eficaces, seguros, confiables y transaccionados.
Estas especificaciones están diseñadas de forma modular y compuesta para que los desarrolladores puedan usar solo las funcionalidades que necesitan. Esta composición "similar a componentes" permitirá a los desarrolladores crear servicios web eficaces de una manera sencilla y flexible, al tiempo que solo introducen solo el nivel de complejidad dictado por la aplicación específica.
Esta tecnología permitirá a las organizaciones crear fácilmente aplicaciones mediante una arquitectura de Service-Oriented (SOA). Además, IBM y Microsoft han demostrado aplicaciones SOA seguras, confiables y transaccionadas que ilustran la riqueza de los procesos empresariales que se pueden crear mediante este enfoque. Además, estas demostraciones han estado funcionando en un entorno de seguridad federado en un entorno heterogéneo que consta de software IBM WebSphere y Microsoft .NET.
Anticipamos que estas tecnologías de servicios web estarán disponibles en sistemas operativos, middleware, con herramientas que harán aún más fácil que los desarrolladores usen estas tecnologías. Será emocionante ver las aplicaciones que surgen a medida que los desarrolladores y las organizaciones usan estos sistemas para crear la próxima generación de soluciones basadas en servicios web.
6.0 Confirmaciones
Queremos reconocer a las siguientes personas que han contribuido a estas ideas: (alfabética) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Felipe Moreno, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Jeff Frey, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Scot Gellock, Josh Gray, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Frank Leymann, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Tony Nadalin, Martin Nally, Karla Norsworthy, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.