Tarea: Diseño de mensajes
Esta tarea describe las acciones necesarias para un modelo de diseño de mensajes completo (catálogo). Trata, como antecedente, los patrones de intercambio de mensajes y la relación del modelo de dominio con el modelo de mensaje. También se describen consideraciones de diseño para la granularidad y el rendimiento de los mensajes.
Disciplinas: Análisis y diseño
Relaciones
Descripción principal
Los mensajes entre los servicios de comunicación y los componentes son un componente importante de la arquitectura orientada a servicios.Incluyen no sólo mensajes de entrada y salida de una determinada invocación de servicio sino también el formato de mensaje interno que se utilizará dentro de la empresa a medida que el flujo de información pase a través de las capas de la arquitectura de la aplicación. En muchos casos, es recomendable utilizar un formato de mensaje común.

Como los servicios incluyen mensajes de entrada y salida, esta tarea se centra en:

  • la identificación y especificación del formato y el contenido de los mensajes de entrada y salida de un servicio,
  • su relación con los modelos de datos subyacentes,
  • las consideraciones y el formato de mensaje común, y
  • las decisiones sobre cómo correlacionar uno y otro de estos mensajes.

La especificación de mensajes para el modelo de servicio debería tener en cuenta perspectivas de la arquitectura de aplicación/arquitectura de empresa, la arquitectura de datos y la arquitectura de integración. Esto incluye:

  • Los estándares de mensaje definidos en un nivel de empresa o de aplicación
  • El modelo de datos o metadatos adecuado que formen parte de una arquitectura de datos
  • Los estándares de transformación de mensajes que forman parte de una arquitectura de integración.

Durante la especificación, es importante entender los estándares de la organización, si están disponibles, en cada una de las 3 áreas de arquitectura. Las especificaciones de mensaje y los modelos de datos están estrechamente unidos. El modelo de datos se compone de entidades subyacentes y sus relaciones, un conjunto de las cuales se puede enviar como parte de un mensaje de salida y ser recibida como entrada de un mensaje entrante. Por tanto, la correlación entre los formatos de mensaje y la arquitectura de datos o el modelo de datos subyacentes es una consideración arquitectónica clave. En algunos casos, los patrones y su implementación, caso del Bus de servicio de empresa, pueden manejar la transformación (y direccionamiento) de mensajes. En muchos casos, puede que necesitemos un manejador explícito para transformar los mensajes de y a modelos de datos.

En la mayoría de los lenguajes de programación orientada a objetos, la invocación de comportamiento se basa en llamadas de método o en paradigmas de transporte de mensajes. C++, por ejemplo, utiliza tablas de punteros de función para invocar el método correcto. Smalltalk, por otro lado, pasa mensajes cuyo destinatario es evaluado en el tiempo de ejecución. Las soluciones orientadas a servicios están de forma inherente basadas en mensajes y aunque los enlaces a lenguajes de programación pueden presentar interfaces basadas en el método para los clientes, no es la realidad de la comunicación con o entre servicios. Otra faceta de la mensajería de servicio es que cada vez más servicios se están desarrollando con interfaces asíncronas, por contraposición a la naturaleza fundamentalmente síncrona de las llamadas de método.

En el área de integración de empresa, se ha utilizado con éxito una clase de tecnología durante un número de años: el Middleware orientado a mensajes (o MOM). Este conjunto de tecnologías está presente en productos como los gestores de colas y los intermediarios de mensajes. Ha proporcionado a las organizaciones de TI un método flexible, escalable y sólido para aplicaciones de conexión no estrecha.

Se ha observado que la arquitectura orientada a servicios es una evolución del desarrollo basado en componentes. En algunos aspectos, esta evolución tiene en cuenta muchas de las lecciones aprendidas a partir del éxito de MOM: cómo unir no estrechamente sistemas de forma efectiva. La infraestructura de MOM ofrece las siguientes características que permiten comunicar sistemas para que evolucionen por separado.

  • Cola de mensajes, para entrega fiable de mensajes incluso en el caso de anomalías en la red o el sistema.
  • Direccionamiento de mensajes, tanto desde el punto de vista del direccionamiento en la red, para rendimiento y fiabilidad, como desde el punto de vista del direccinamiento basado en el contenido del mensaje.
  • Transformación de mensajes, de modo que un servicio de llamada pueda enviar una solicitud de un "producto" cuando el servicio de recepción pueda aceptar solicitudes de "elementos".
  • Adaptadores de mensajes, para permitir que los sistemas que no se desarrollaron originalmente con interfaces de MOM sean tratados por servicios compatibles con MOM.
Pasos
Utilizar estándares de mensaje
Cuando se definen especificaciones de mensaje para los servicios identificados, es importante tener en cuenta los estándares de mensaje de una empresa, si existen.  Allí donde no se definan estándares de mensaje, resulta aconsejable desarrollarlos. Allí donde existan esquemas de mensaje industriales, se recomienda aprovecharlos.  Por ejemplo, se han definido especificaciones de mensajería XML para sectores relacionados con las finanzas, la dirección, los viajes (OTA XML [Open Travel Alliance, http://www.opentravel.org/online_schema.cfm]) y las comunicaciones.  Además, existen esquemas específicos no industriales disponibles en OAGIS [Open Applications Group, http://www.openapplications.org/index.htm].

Formato de mensaje común

Los mensajes comunes hacen referencia a mensajes que se han transferido por los niveles de una arquitectura de nivel n.  Normalmente, se captura la información de la interfaz de usuario, enviada a través de un nivel del controlador, procesada en las capas empresariales o de aplicación y, a continuación, pasadas a una capa de persistencia o un sistema heredado de fondo. Durante cada una de estas transferencias, se intercambia un mensaje entre los niveles en que cada uno puede tener un formato diferente.  La cuestión clave es acordar un estándar para un formato de mensaje común dentro de la empresa, de modo que se pueda superar cualquier sobrecarga de traducción de formato allí donde no se utiliza un bus de servicio de empresa (ESB) o si su uso se considera caro desde el punto de vista de la traducción de formato. El uso de un ESB cuidará de muchas de estas mediaciones, transformaciones y direccionamiento.  Ésta es la capa de integración tal como se describe en el modelo de capas de la arquitectura orientada a servicios.

En algunos casos, puede bastar acordar los formatos de mensaje de entrada y salida. El asunto de un formato de mensaje común es una decisión arquitectónica clave: puede decidir "hacer el suyo propio" tal como se especifica aquí, adoptar modelos de la industria como el XML OTA del sector de los viajes o adoptar modelos específicos que no sean de la industria como aquellos definidos por OAGIS. En algunos casos, la decisión será utilizar un formato de mensaje de empresa común que actualice campos del mensaje y lo pase al siguiente nivel para un posterior proceso.  Si dicho esquema común no se puede alcanzar debido a factores políticos, entonces podrán designarse adaptadores que traduzcan los mensajes a un formato de mensaje común. También se pueden aprovechar como parte de un ESB.

Consideraciones sobre ISV : Los mensajes que invocan servicios realizados dentro de paquetes de ISV puede que deban aumentarse con atributos de datos para satisfacer restricciones dentro del modelo de datos de paquete de ISV.  Dichos elementos de datos se pueden identificar a través del análisis del servicio realizado dentro del componente de paquete de ISV o pueden también identificase a través del análisis de servicio de abajo a arriba de paquetes de ISV.  Como puede que estos atributos no se identifiquen hasta la realización de servicio, puede que deban retroajustarse al mensaje común una vez identificados.

Formato de mensaje común y arquitectura de datos

En general, los servicios no deberían indicar nada sobre los modelos de datos subyacentes.  Más bien, deberían utilizarse para encapsular los modelos de datos subyacentes cuyos almacenes de datos sean aprovechados por los componentes de servicio que realizan los servicios. Por tanto, los servicios que sean ver, editar, suprimir, añadir búsqueda y otras operaciones de una base de datos pueden no ser buenos candidatos pero podrían utilizarse como operaciones de componente subyacente tal como se utilizan hoy en día.

Las arquitecturas de datos existentes que definen modelos de datos conceptuales, lógicos o físicos son orígenes necesarios en la definición de formatos de mensaje comunes.  Las definiciones de formatos de mensaje común deberían coordinarse con esfuerzos de arquitectura de datos y modelos de datos.  Este análisis garantizará la disponibilidad de los almacenes de datos y los esquemas adecuados para los componentes de servicio que ejecutarán nuevos servicios.  La arquitectura de datos existente será mejorada para que contenga nuevos servicios si es necesario añadir nuevos datos a los sistemas subyacentes.

En muchas empresas, los sistemas existentes a menudo reflejan la existencia de silos e islas de datos que colaboran a través de los procesos de lote.  La migración desde almacenes de datos aislados es posible a través de los servicios.  La identificación de orígenes de datos de un proveedor de servicios se realiza durante la realización de servicio.

Consideraciones sobre ISV: El modelo de datos lógico necesita contener los modelos de datos predefinidos, a menudo implícitos, incorporados en los paquetes de ISV.  Por tanto, debe producirse la transferencia de mensajes entre aplicaciones empaquetadas y los modelos de datos existentes.  Esto se lleva a cabo a menudo a través de API ofrecidas por los ISV. En una arquitectura orientada a servicios, los adaptadores de estos modelos de datos de ISV se convierten en algo importante, especialmente si el ISV no expone sus datos y funciones subyacentes a través de servicios.

Tenga en cuenta que en algunos casos en los que el modelo de datos de ISV es accesible, se puede personalizar el modelo para que contenga los mensajes necesarios para dar soporte a los servicios identificados.  A la inversa, si el modelo de datos no es accesible, la mensajería de servicios puede estar limitada por el modelo de datos contenido dentro del ISV.  Se puede emplear también un mecanismo de mediación para atajar el problema.  La mediación, como es el caso de la suministrada por un ESB, se puede utilizar en este contexto para dar soporte a la comunicación con paquetes de ISV.  El modelo de datos de ISV también puede dictar atributos adicionales que sean necesarios más allá de los requeridos para implementar el servicio.

Formato de mensaje común con todos los servicios relevantes

Los formatos de mensaje común deben estar reconciliados con los mensajes de entrada/salida de los servicios individuales, de modo que estén relacionados y asignados para permitir que los servicios adecuados los utilicen y actualicen cuando sea necesario. Puede que los servicios necesiten extraer información o esperar resultados del formato de mensaje de empresa.  Éstos se documentan en la plantilla Formato de mensaje común de servicio.
Reutilización del modelo de dominio

En el concepto Concepto: Diseño de dominio, se describió la noción de modelado de dominio, parecida a la noción de modelo de análisis o modelo de análisis empresarial en la representación de conceptos centrales del dominio empresarial sin dependencia de la tecnología. Resulta claro que los mensajes utilizados por los servicios son conscientes de la tecnología (si no específicos de tecnología en el caso del esquema XML utilizado para servicios web), de la misma forma que el esquema de base de datos utilizado para almacenar los datos de dominio es tecnología específica del servicio. De hecho, podemos tener en cuenta la siguiente relación.

El diagrama se describe en el contenido textual.

Esto muestra la relación entre el modelo de dominio usado para el descubrimiento de elementos de dominio clave y el modelo de mensaje como realización del modelo de dominio como conjunto de elementos transferido a los servicios y devuelto por ellos.

El diagrama se describe en el contenido textual.

A continuación se muestra un típico modelo de componente/Java en el que podemos observar la separación de la interfaz de la clase y la inclusión de funciones de "objeto usuario" para obtener y establecer el valor de las variables de estado. Se trata de un enfoque muy común, pero cuenta con la desventaja de que, si el cliente y el componente están en espacios de dirección diferentes o en una máquina distinta, el coste de comunicar cada llamada es alto en términos de acceso al estado global de cualquier componente.

El diagrama se describe en el contenido textual.

Otro problema es la relación entre componentes, la noción de que una cuenta tiene un conjunto de clientes es difícil de desarrollar en este estilo y normalmente concluye con la gestión de listas de identificadores utilizados para recuperar objetos individuales.

Al desarrollar un modelo de servicio podemos utilizar un enfoque de identificación de servicio controlada por datos que nos lleve a la especificación de un servicio AccountMgr y un servicio MeetingMgr. La primera especificación de servicio actúa como ubicación central para gestionar cuentas y contactos. De hecho, el modelo de datos central para las soluciones de Gestión de relaciones con los clientes (CRM) se creó utilizando éste y otros servicios. El segundo servicio se ha separado porque puede ser utilizado por las soluciones de CRM y otras soluciones para reservar reuniones y relacionarse con las aplicaciones Groupware de la empresa.

A continuación se muestra un ejemplo del modelo; enseña las especificaciones de servicio, los mensajes se pueden asumir a partir del modelo de dominio anterior.

El diagrama se describe en el contenido textual.

Comprender los patrones de intercambio de mensajes

Cuando se piensa en los mensajes, existe una tendencia natural a considerarlos simplemente parámetros de las operaciones. Esto se hace probablemente porque la representación de UML de servicios utiliza operaciones con parámetros y el Lenguaje de descripción de servicios web (WSDL 1.1) utiliza un enfoque parecido. No obstante, cuando se piensa en términos de servicios y especificaciones de servicio, resulta más útil pensar que los mensajes son elementos reutilizables producidos o utilizados/consumidos por una operación de servicio. En el habla de los servicios, la operación simplemente se convierte en un intercambio de mensajes, si bien es cierto que un intercambio con nombre de un servicio es distinguible de otro intercambio que pueda utilizar los mismos mensajes de entrada y salida.

La noción de patrón de intercambio de mensajes ha sido de interés en el mundo de los estándares de servicios web, como parte de un análisis del uso de servicios en el desarrollo de estándares para dar soporte a su especificación.Un patrón de intercambio de mensajes nombra una combinación particular de mensajes producidos, usados o consumidos entre dos servicios (o entre un servicio y un cliente) y proporciona un vocabulario a diseñadores de servicios para describir operaciones en especificaciones de servicio.

A continuación se muestran patrones de intercambio comunes que se pueden utilizar en la definición de especificaciones de servicio. Dichos patrones se encuentran normalmente durante el modelado de colaboraciones de servicio.

Solicitud/Respuesta síncrona: Se trata en efecto de una invocación de método tradicional en la que el cliente de servicio envía un mensaje a un servicio y, a continuación, bloquea la espera hasta que se recibe una respuesta del servicio.

El diagrama se describe en el contenido textual.

Mensaje de una dirección: En este caso, el cliente simplemente envía un mensaje al servicio, no esperando una respuesta. Este patrón se puede considerar una llamada de método asíncrona sin tipo de respuesta, lo que significa que el cliente de servicio continúa la ejecución después de que el mensaje se haya enviado, en lugar de esperar que el servicio procese el mensaje.

El diagrama se describe en el contenido textual.

Notificación: En este caso, el servicio es responsable de devolver mensajes al cliente (normalmente otro servicio). Para conseguirlo, el cliente debe estar de alguna forma registrado en el servicio, de modo que el servicio sepa dónde enviar los mensajes de notificación.

El diagrama se describe en el contenido textual.

Solicitud/Respuesta asíncrona: Se trata de una combinación del mensaje de una dirección y la notificación. El cliente del servicio envía un mensaje, incluyendo una dirección a la que responder. Cuando el servicio completa su proceso, vuelve a llamar al originador. El hecho de que los clientes de servicio envíen el primer mensaje de forma asíncrona los obliga a realizar un seguimiento de todas las solicitudes enviadas, de modo que las respuestas, cuando se reciben del servicio, puedan correlacionarse con la solicitud original.

El diagrama se describe en el contenido textual.

Publicar/suscribir: Se trata de nuevo de una combinación. Un cliente de servicio registra interés en un "tema" con un servicio de publicación. Otros servicios o clientes de servicio publican mensajes (envían mensajes) al servicio de publicación identificando el tema asociado con el mensaje. Si el tema coincide con clientes anteriormente registrados, se les notificará el nuevo mensaje. En este caso es posible acoplar no estrechamente los servicios que participan. Cualquier cliente o publicador sólo necesita conocer la ubicación del servicio de publicación y se pueden añadir nuevos clientes a la solución sin realizar un esfuerzo importante.

El diagrama se describe en el contenido textual.

Gestionar granularidad de mensajes

Los servicios tienen como objetivo proporcionar operaciones de gran granularidad. De esta forma, los mensajes que fluyen dentro y fuera de tales operaciones tienden también a tener mayor granularidad. Este problema se resaltó originalmente pronto en el desarrollo de soluciones de servicio web en las que el uso de HTTP como transporte, SOAP como protocolo y XML como formato de conexión tendía a producir respuestas relativamente lentas y requisitos de banda ancha altos. Por ejemplo, consideremos una solicitud para una oferta de acción de un servicio. Una oferta de acción simple se mostró a menudo en los primeros días de los servicios web. El símbolo de denominación abreviada es cuatro caracteres y la respuesta es un número decimal. En un estilo RPC, protocolo binario, podemos esperar que el identificador de mensaje añada alguna carga, digamos 8 bytes, y por tanto podemos esperar en algún sitio de la región de 8+4 para la solicitud y 8+8 (para un decimal de precisión alta) de respuesta. Con HTTP/SOAP, podemos esperar algo de la siguiente forma:

Solicitud Respuesta
  SOAPAction: "http://www.webservicex.net/Quote"
User-Agent: MyAgent 1.0
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://www.webservicex.net/">
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:Quote>
<tns:Symbol>IBM</tns:Symbol>
</tns:Quote>
</soap:Body>
</soap:Envelope>
  HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Connection: close
Content-Length: 522
X-AspNet-Version: 1.1.4322
Date: Mon, 21 Mar 2005 00:34:21 GMT
Content-Type : text/xml; charset=utf-8
Server : Microsoft-IIS/6.0Cache-Control: private, max-age=0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<QuoteResponse xmlns="http://www.webservicex.net/">
<Quote><Last>89.28</Last>
</Quote>
</QuoteResponse>
</soap:Body>
</soap:Envelope>

Las personas que pronto adoptaron tecnología de servicio web llegaron a dos conclusiones. Primero, los servicios se optimizarón en un pequeño número de operaciones que suministraban datos como documentos en lugar del estilo más complejo de modelos de componente tradicionales. Esto tiene la ventaja de amortizar la carga de los protocolos de una carga útil de datos reales más grande. Igualmente, entre servicios de una empresa, al menos entre servicios de la misma solución, se eligieron enlaces de protocolo más pequeños y simples y se reservó HTTP/SOAP para situaciones en las que era necesario, caso de conexiones con servicios externos a la empresa.

Esta noción no es enteramente nueva. Incluso en el mundo de los componentes, el patrón Objeto de valor, o la Fachada de servicio J2EE son enfoques para reducir el número de comunicaciones directas e inversas entre cliente y servidor. Ambos utilizan la noción de enviar una copia completa del estado de componente al cliente en lugar de utilizar las funciones de objeto usuario tradicionales. Para los servicios, también podemos considerar el hecho de que los que se están desarrollando están más estrechamente alineados con los modelos de empresa, en especial con los modelos de proceso empresarial. De esta forma, los mensajes vienen a reflejar documentos de empresa comunes de la misma forma que los conjuntos de transacciones EDI (intercambio de datos electrónico) representan documentos empresariales como pedidos, facturas, avisos de envío, etc.

Gestionar el rendimiento del intercambio de mensajes

En general, el uso de mensajes grandes es válido en la superación del rendimiento de las comunicaciones, aunque en algunos casos los mensajes de datos grandes pueden ser un problema. Por ejemplo, en los mensajes de SOAP anteriores, vimos cómo el tamaño de mensaje, utilizando HTTP, SOAP y XML aumentó considerablemente el tamaño de los datos. Se trata de una queja frecuente en los sistemas anteriores creados con tecnologías de servicios web. Por otro lado, estos problemas nos han permitido aprender algunas lecciones interesantes como la consideración del rendimiento desde el punto de vista del rendimiento de código, el diseño de mensajes y la opción de protocolo como una actividad de diseño temprana.

Un aspecto importante que debe tenerse en cuenta es que cuando movemos grandes trozos de estado de servicio a cliente o de cliente a servicio, estos mensajes representan realmente instantáneas obsoletas del estado de servicio. Por tanto, una de las consideraciones es gestionar explícitamente esta condición de "obsoleto" identificando el tiempo que los datos se pueden considerar fiables o darlo en "usufructo" al cliente de modo que caduque después de un determinado tiempo. Para obtener más información, consulte la documentación técnica Uso de arquitectura orientada a servicios y desarrollo basado en componentes para crear aplicaciones de servicio web.

Otro tema que debe tenerse en cuenta es el almacenamiento en caché del contenido. El almacenamiento en caché es normalmente un problema que se soluciona con una optimización del rendimiento de las aplicaciones, pero en una solución orientada a servicios, la naturaleza distribuida y la comunicación basada en mensajes se presta bien a la inserción de cachés entre clientes y servicios. Estas memorias caché no son las típicas memorias caché de base de datos utilizadas para optimizar consultas sino más bien cachés utilizadas en servidores web y proxies web. De hecho, en el caso de los servicios web que utilizan HTTP y SOAP, estos proxies se pueden utilizar como memorias caché para ofrecer respuestas de servicio en determinadas situaciones.

No obstante, el problema, en relación con el uso de alguna memoria caché, es realmente cómo entiende la memoria caché las políticas utilizadas para ofrecer contenido de la caché y cómo un servicio puede invalidar la memoria caché. La infraestructura técnica utilizada para alojar y gestionar servicios desplegados debería proporcionar funciones de almacenamiento en caché. Un área de política de servicio que esperamos ver en el futuro es el suministro de información sobre gestión de memoria caché.

Más información