Directriz: Mediación de servicios
Esta directriz describe las distintas formas para habilitar la comunicación entre consumidores y servicios incompatibles a través de la mediación, transformando las solicitudes del consumidor o los protocolos en formularios que los proveedores de servicios pueden entender.
Relaciones
Elementos relacionados
Descripción principal

Introducción

La mediación es el acto de intervenir entre partes en conflicto para fomentar la reconciliación o el acuerdo mutuo. En sistemas distribuidos, en general, y en soluciones orientadas a servicios, en particular, se necesitan tres formatos comunes de reconciliación.

  • Mediación de interfaz; la mediación de interfaz de sistemas basados en componentes o en objetos es el cambio entre definiciones de operación entre remitente y destinatario. En una solución orientada a servicios, aparece como una no coincidencia en el contenido/esquema del mensaje entre el remitente y el destinatario.
  • Mediación de protocolo; la mayoría de las soluciones comunes basadas en componentes o en objetos suelen fundamentar la comunicación en un protocolo o conjunto de protocolos común. En soluciones orientadas a servicios, lo común es una mezcla de protocolos de toda la solución, una de las ventajas de la arquitectura. Para que se produzca la comunicación entre servicios, los mensajes deberán distribuir distintos protocolos entre remitente y destinatario.
  • Mediación de operación; esta forma de mediación también resulta familiar a los desarrolladores. Está relacionada con el patrón de estrategia común. Un componente puede seleccionar una de las implementaciones de un servicio u operación en concreto según los parámetros de tiempo de ejecución o el contenido de la solicitud. A esto también se le denomina direccionamiento basado en contenido.

Es importante observar que cada vez más plataformas de middleware ofrecen funciones de mediación avanzada sin tener que desarrollar componentes de mediación explícitos. En este caso, como el middleware detecta discrepancias en la estructura de datos o en los protocolos de comunicación, puede realizar la mediación en su tiempo de ejecución. También es posible que estas plataformas proporcionen mediadores que actúen como conmutadores, según el contenido del mensaje o las reglas empresariales, para seleccionar la implementación correcta de una determinada solicitud del cliente.

Mediación de datos en actividades

En el caso de los servicios de conexión en los que la definición de mensajes no coincide o los mensajes requieren transformación entre remitente y destinatario, se puede usar una función suministrada por UML 2.0 Activities para indicar la transformación entre el remitente y el destinatario. Esta función, la asociación de un UML 2.0 Behavior con un ObjectFlow entre dos acciones, permite la identificación de un comportamiento de transformación reutilizable que puede convertir un mensaje en otro (en concreto, a partir de la especificación UML 2.0 Cambia o sustituye señales de datos que fluyen por el límite).

Tal como se indicaba anteriormente,la transformación es un elemento reutilizable. Como tal, se puede identificar para transformar un tipo de mensaje en otro y, a continuación, usarse siempre que sea necesario en mensajes mediadores entre un servicio de envío y otro de recepción. Tenga en cuenta que, aunque UML no ofrece un conjunto de acciones para navegar, leer y actualizar una estructura, éstas son relativamente complejas y podrían resultar muy difíciles de usar en la definición de transformaciones. Se espera que la transformación enlace con una representación más compacta (teniendo en cuenta el lenguaje XSL/T) o con una nueva forma de expresión de las necesidades de acciones UML que se vayan a suministrar.

La mediación de datos también se puede tratar como un patrón concreto de iteración de servicio. Por ejemplo, existe un servicio de mediación explícito responsable de la implementación de una o más transformaciones de datos. En este caso, el mediador debe responder a los mensajes enviados por el cliente, transformar el mensaje y transferir el servicio, tal como se muestra a continuación.

El diagrama se describe en el contenido textual.

Mediación de protocolo en pasarelas de servicio

Por otro lado, en el modelo también se entiende y se da soporte explícito al protocolo de mediación. Como la información de protocolo se especifica como vínculo para un canal de servicio, se pueden introducir elementos adicionales del modelo de <<Servicio>> o de <<Pasarela de servicio>> que alteren la especificación de protocolo. Por ejemplo, en el siguiente diagrama de estructura compuesta verá dos particiones, una para servicios presentados en Web y otra para servicios internos. También existe un canal de servicio entre las particiones con un vínculo de "HTTP-SOAP", algo común para servicios presentados en Web.

El diagrama se describe en el contenido textual.

El problema es que, para dar soporte al nivel necesario de rendimiento y a otros requisitos no funcionales, toda comunicación dentro de la partición interna tiene lugar a través de protocolos específicos de plataforma. El siguiente diagrama muestra cómo se conecta un servicio a la pasarela de servicio "Port : ISvcTwo" mediante el protocolo RMI de Java, pero ¿qué ocurre cuando la partición web se conecta a la misma pasarela usando HTTP-SOAP?

El diagrama se describe en el contenido textual.

La respuesta es que la propia pasarela de servicio puede actuar de mediadora del protocolo convirtiendo las estructuras de mensaje y las invocaciones de un formato a otro. Se trata de las funciones comunes normalmente suministras por middleware como Object Request Brokers (ORB) Message Brokers. De hecho, si fuera necesario se podría generar a partir del modelo anterior a dicho middleware, o reificar "Port : ISvcTwo" como un servicio por derecho propio que realiza llamadas desde la partición web y las reenvía a los servicios adjuntos.

De nuevo, la mediación se puede modelar explícitamente como servicio, en lugar de como pasarela de servicio, que exponga la interfaz correcta con el vínculo del cliente y delegue la implementación al servicio del proveedor con un vínculo diferente.

Mediación de invocación mediante composición de servicio

Tal como se ha descrito en la introducción, es habitual definir una estructura en la que un servicio sea dependiente de otro a la hora de realizar alguna operación. No obstante, el servicio real al que se llamará para una solicitud específica dependerá de los detalles incluidos en la solicitud, de quién sea el solicitante y de las reglas empresariales aplicadas con esta información. El ejemplo que normalmente se ofrece para esto es una solicitud de cliente, el servicio de recepción puede elegir una de las dos implementaciones según el nivel del cliente. Por ejemplo, aquellos clientes de los que se sepa que gastan más dinero, podrían obtener un trato preferencial.

El diagrama se describe en el contenido textual.

Tal como se describió anteriormente, es importante en este tipo de mediación intentar externalizar las reglas usadas para seleccionar entre uno o más proveedores de la implementación de operación real. En el diagrama anterior, esto se muestra como un componente de regla adjunto al servicio de mediación. Obviamente se puede crear la solución como un conjunto de servicios en los que el mediador, las reglas y todos los implementadores sean servicios independientes. A continuación verá un ejemplo de esto.

El diagrama se describe en el contenido textual.

Como se puede observar, el componente de mediación no sólo posee su especificación de servicio desarrollada sino también una especificación de servicio que todos los servicios por los que media deben implementar. Esto nos permite definir la estructura compuesta del servicio (mostrada anteriormente) y el comportamiento dinámico mostrado a continuación. Observe que en la estructura anterior, la parte que representa los servicios mediados se indica mediante la interfaz necesaria y aparece con una multiplicidad ilimitada.

El diagrama se describe en el contenido textual.

De nuevo, es posible que este tipo de direccionamiento de mensajes basado en reglas o en contenido sea realizado por la plataforma de middleware seleccionada como parte de la arquitectura de la solución.