Espacio SOA

Cuando construimos una Arquitectura SOA, lo que al final estamos definiendo es la forma de intercambio de mensajes entre las distintas aplicaciones o sistemas de un entorno distribuido. Por ejemplo, cuando invocamos un Servicio Web por medio de SOAP/HTTP, lo que estamos dando lugar es a un intercambio de mensajes entre el cliente y el proveedor del servicio basado (normalmente) en un patrón de mensajes Petición / Respuesta (Request / Response).

Dependiendo de las necesidades que tengamos de comunicación (sincronía vs. asincronía; comunicación 1 a 1, 1 a N o N a N; mensajes erroneos o correctos; mensajería por eventos, etc…) vamos a definir la forma de intercambio de los mensajes entre las distintas aplicaciones / sistemas de nuestra arquitectura.

Petición / Respuesta (Request / Response)

Es la más utilizadas de todas las formas de intercambios de mensajes (también llamada Request / Reply). Básicamente, consiste en la petición por parte de un cliente a un proveedor de un servicio y la espera de la respuesta en un tiempo determinado.
La principal característica de este patrón de mensajería es que resulta síncrono y bloqueante, por lo que durante el tiempo de ejecución del servicio, el cliente queda bloqueado a la espera. De hecho, es útil el manejo de timeouts para manejar la situación en que no haya respuesta por parte del servidor.
Este tipo de mensajería es el indicado para la petición de ejecución de servicios que suelen ser rápidos o cuando del lado del cliente no se puede seguir la ejecución por necesitar obligatoriamente la respuesta del servidor.
Desde el punto de vista del cliente, es una llamada de tipo RPC (Remote Procedure Call), ya que es bloqueante hasta la llegada de la respuesta.
El protocolo de comunicación más utilizado para este tipo de mensajería es HTTP.

Sólo Petición (One-Way)

Es un tipo de mensajería asíncrono y no bloqueante. Suele utilizarse cuando el cliente no necesita la respuesta inmediata por parte del servidor y puede seguir ejecutándose. En estos casos puede utilizarse tanto HTTP (sin respuesta) como JMS (quizá más apropiado) para la implementación de este tipo de mensajería (también pueden utilizarse otros protocolos como FTP, SMTP, etc…)
En este punto, es importante diferenciar entre Petición / Respuesta y One-way en ambos sentidos.
En el primero de los casos, implica un bloqueo por parte del cliente a la espera de la respuesta del servidor.
En el segundo de los casos, la Petición / Respuesta se implementa como dos llamadas one-way asíncronas, por lo que durante el tiempo de ejecución del servicio, el cliente no queda bloqueado y puede ejecutar otra lógica diferente. De hecho, esta segunda forma requiere que el cliente sea a la vez consumidor y proveedor (ya que necesita implementar algúna forma de binding para ser invocado por parte del servidor en la respuesta). Esta opción es bastante útil cuando se realiza una comunicación con un servidor del que se necesita la respuesta, pero dada la duración de ejecución del mismo, el cliente puede aprovechar para realizar otras tareas programadas. El protocolo de comunicación más utilizado para este tipo de mensajería es JMS por sus características asíncronas.

Request / Callback

Es un tipo de mensajería request / response asíncrona. Normalmente, el cliente puede realizar una invocación al proveedor del servicio y seguir ejecutando otro código. La diferencia con la petición one-way en ambos sentidos, radica en que en la petición, se pasa la información del callback o manejador de la respuesta. Es decir, a nivel del cliente existe una parte que es la encargada de realizar la petición al servicio y otra parte que es la encargada de manejar la respuesta.
La principal complejidad de este patrón de mensajería consiste en que la función de callback debe ser capaz de manejar el contexto o la información de instancia para correlacionar los mensajes de respuesta correctamente con los de la petición.

Publicación / Suscripción (Publish / Subscribe)

Cuando se realiza una petición que no necesita de una respuesta, suele utilizarse el patrón de mensajería conocido como publicación / suscripción. A diferencia del patrón one-way, con Publish / Subscribe se permite la comunicación 1 a N entre el cliente y los distintos consumidores de los mensajes (que se "suscriben" a la publicación del mensaje en cuestión).
Este tipo de mensajería suelen ser implementados por medio de protocolos JMS, que permiten la asincronía y la persistencia de mensajes hasta su procesamiento.
Un ejemplo de Publicación / Suscripción sería la notificación que hace un sistema a otros N sistemas de un cambio en el primero (con un modelo Request / Response o One-Way implicaría notificar 1 a 1 a los sistemas implicados; mientras que con el patrón Publish / Subscribe se puede realizar en un solo paso).

Mensajes de Error (Fault Messages)

Normalmente, en los casos de comunicación que hemos descrito anteriormente, admitimos que los mensajes enviados son correctos y que contienen la información necesaria para su ejecución satisfactoria.
No obstante, a veces, es necesario definir como se realiza el intercambio de mensajes para resultados incorrectos o no esperados.
En el caso de mensajería Petición / Respuesta, la información que devuelve el proveedor del servicio puede ser la de un mensaje de error. En estos casos, la forma en que está definido el mensaje es dependiente del protocolo o el formato a utilizar. Por ejemplo, si utilizamos SOAP como medio de mensajería, se puede definir (aparte del formato de mensaje de la respuesta correcta) un formato para SOAP-Fault como mensajería para casos de excepciones.
En el caso de mensajería asíncrona, la respuesta de un mensaje con excepción puede resultar más complicada, ya que el envío de una petición no implica la llegada de una respuesta. Por ello, se suelen utilizar colas JMS como protocolo de comunicación asíncrona, ya que nos permite implementar medios de asegurar la recepción/envio de los mensajes por medio de reintentos y persistencia de los mismos en las colas.

EDA (Event-Driven Architecture)

La mensajería por eventos, es un tipo de mensajería que se ha puesto de moda con lo que ha venido a llamarse EDA o la evolución de SOA. Consiste basicamente en "automatizar" la generación de mensajes y el envío de los mismos por medio de eventos (que ocurren cuando se produce un cambio en el sistema generador de los mismos, por un timer que se ejecuta cada cierto tiempo, etc…).
Normalmente, un proceso de negocio orquesta la comunicación con los distintos sistemas/aplicaciones implicadas definiendo el orden en que se ejecutan y como se produce la mensajería o comunicación con los mismos.
Con EDA, esa orquestación queda asumida por los propios procesos de cada sistema o aplicación. Es decir, los servicios de negocio que permiten la integración con los sistemas finales tienen un tiempo de ejecución y además, definen cual es el siguiente servicio a ejecutarse en esa "cadena de eventos" que conforman los procesos en una arquitectura EDA.

Links interesantes:

SOAP Version 1.2 Part 1: Messaging Framework
Web Services Message Exchange Patterns
Message Exchange Pattern Wikipedia Definition
Message Exchange Pattern