Traducción de los patrones de la solución orientada a servicios

En esta sección se describe cómo la solución traduce el diagrama de patrones en artefactos de BizTalk Server.

Conexiones y condiciones de integridad

Podemos empezar prácticamente en cualquier lugar con la traducción de los patrones a componentes de BizTalk Server. Sin embargo, las conexiones entre los componentes son, en efecto, la infraestructura de estos, lo que parece ser un buen punto de partida. Además, en el caso del patrón de agregador, debemos pensar en lo que le dirá que tiene toda la información que necesita. Esto afecta tanto a sus conexiones a otros componentes como a su diseño.

La solución debe proporcionar una forma cómoda y coherente de usarse. La interfaz de servicio especifica cómo otras aplicaciones pueden usarlas. Dado que la solución debe comunicarse con una aplicación heredada mediante IBM WebSphere MQ, IBM WebSphere MQ debe formar parte de la interfaz de servicio. Sin embargo, para las aplicaciones más recientes, una interfaz de servicio web parece una opción obvia. Una interfaz de servicio web proporciona máxima flexibilidad para otras aplicaciones que usan el servicio. Aquí podemos usar la flexibilidad de BizTalk Server para tener una interfaz de servicio dual. Para obtener información sobre cómo exponer orquestaciones como servicios web, vea Cómo asignar orquestaciones a servicios web.

Las demás conexiones son las entre la interfaz de servicio y la lista de destinatarios, entre la lista de destinatarios y las aplicaciones de back-end, y entre las aplicaciones de back-end, el agregador y la interfaz de servicio.

Si la conexión a la lista de destinatarios es sincrónica, la solución no necesita usar correlaciones para asegurarse de que se envían y reciben todos los mensajes a la lista de destinatarios. Las conexiones entre las aplicaciones de back-end y el agregador pueden ser sincrónicas por las mismas razones. El agregador necesita las respuestas de las tres aplicaciones back-end para completar la respuesta de consulta. Los tiempos de respuesta deben ser cortos para que las conexiones sincrónicas sean adecuadas y simplifiquen la solución.

En el patrón de agregador, normalmente hay una condición de completitud. En los casos en los que hay varios servidores back-end y los tiempos de respuesta son lentos, la condición de integridad podría implicar, por ejemplo, recibir al menos una respuesta en un período de tiempo determinado. Esta solución orientada a servicios requiere las tres respuestas para construir el mensaje final. Por lo tanto, aquí, la condición de integridad recibe las tres respuestas.

Nota:

Al recibir solicitudes a través de IBM WebSphere MQ, la solución agrega un identificador de correlación copiando el valor de MQMD_MsgId al MQMD_CorrelId del mensaje de respuesta. Esto forma parte de la forma estándar de usar el adaptador MQSeries en solicitud-respuesta para evitar una posible situación de carrera. Para obtener más información, consulte Correlación de mensajes mediante solicitud-respuesta.

Determinar los límites de orquestación

La solución debe permitir solicitudes desde una cola de WebSphere MQ de IBM, así como a través de la interfaz de servicio web. Colocar la interfaz de servicio en una orquestación, la entrada de IBM WebSphere MQ en otra y la mayor parte del procesamiento en una tercera orquestación mantiene la comunicación externa separada del procesamiento.

Traducción de los componentes a formas de orquestación

Los patrones que se van a traducir en formas estarán, en la solución final, en una orquestación única. Existen numerosas maneras de crear un enrutador basado en contenido en BizTalk Server, incluida la creación de suscripciones de MessageBox. En la solución, el enrutamiento utiliza suscripciones de MessageBox. Una forma de expresión evalúa si el mensaje incluye valores para los campos obligatorios. Una forma de decisión evalúa la variable establecida en la forma de expresión y selecciona la ruta de acceso a través de la orquestación.

La orquestación CustomerService usa la forma paralela para enviar mensajes a las aplicaciones back-end y recibir respuestas simultáneamente. No tiene que esperar a que finalice una aplicación antes de realizar la siguiente solicitud. Si el número de aplicaciones cambiara con frecuencia o si las conexiones a las aplicaciones no eran confiables, la orquestación tendría que traducir el patrón de forma diferente.

En la solución, el agregador debe combinar elementos de tres mensajes de respuesta. El uso de la forma paralela garantiza que la comunicación con los sistemas back-end sea paralela. Y, dado que la forma no finaliza hasta que recibe todas las respuestas o un tiempo de espera, el agregador siempre sabrá cuándo puede continuar. La orquestación usa una forma de transformación que asigna elementos de los tres mensajes de respuesta de back-end y el mensaje de solicitud original a los elementos del mensaje de respuesta.

Nota:

Las comunicaciones con los sistemas back-end también pueden caducar. Para establecer el tiempo de espera, incluya la forma Receive en una forma Scope y establezca la propiedad Timeout del contexto.

Para obtener una lista completa de las formas de orquestación, consulte Formas de orquestación.

Véase también

Patrones de la solución orientada a servicios
Componentes de la solución orientada a servicios