Dentro de los diferentes aspectos que hemos estado discutiendo en el contexto de este proyecto (Crear un ESB) estamos en este momento revisando el modelo de mensaje universal [1].
La idea es tener un único esquema de mensajería con el ESB simplificando de esa manera enormemente el problema.
Mensaje Universal
Las aplicaciones para comunicarse con la plataforma de integración utilizan mensajes XML. Un mensaje no contiene sólo información de los argumentos a utilizar en la llamada a la operación del servicio de negocio. Además de esta información propia del negocio contiene mucha información de utilidad para la plataforma.
La información propia de la plataforma son datos que se trasmiten fuera de banda. La idea es que no se mezclen con los datos de negocio.
Para simplificar la modelo y que la integración con la plataforma de integración se define usar un mensaje canónico de comunicación. Fowler llama a este mensaje universal como Canonical Data Model. La siguente figura muestra el patrón de Fowler.
Figura 1: Patrón Canonical Data Model.
La idea es que todas las aplicaciones y servicios usan un esquema de mensaje único. Está definición facilita el trabajo para los desarrolladores de servicios y aplicaciones porque siempre deben usar el mismo esquema.
Este mensaje para poder ser útil para todos los servicios debe ser capaz de contener los datos fuera de banda (para la plataforma) y los datos de negocio (para el servicio). Esto se logra implementando el patrón Envelope Wrapper, que se muestra en la siguiente figura.
Los datos de negocio, son insertados en el mensaje. Este mensaje viaja por la plataforma y al momento de consumir el Servicio de Negocio los datos de negocio son extraídos y pasados al servicio. La respuesta del servicio sigue el mismo proceso pero hacia la aplicación, que cuando recibe la respuesta la extrae del mensaje.
Figura 2: Patrón WRAPPER
Esquema de Mensaje propuesto
Para la plataforma de integración se propone el uso de un esquema de mensaje que tiene tres grandes secciones:
- HEADER
- BODY
- ERROR
El esquema con estas tres secciones se muestra en la siguiente figura.
Figura 3: Esquema mensaje universal.
HEADER
La sección HEADER tiene como objetivo contener los datos de contexto necesarios para que la plataforma pueda actuar. Son los datos fuera de banda. En la siguiente figura se muestra la información que contiene e HEADER.
Figura 4: HEADER mensaje universal.
Los campos de está sección son lo siguientes:
Ø HASH
- Request: Es la firma de los argumentos de llamada.
- Repsonse: Es la firma de la respuesta.
Ø Gestión: es un diccionario de campos para destacar información del mensaje que debe ser almacenada en el LOG para gestión de manera destacada.
Ø Expiración: da el tiempo de vida del mensaje. Se usa para procesos de larga duración.
Ø Secuenciador: es el atributo que permite ensamblar una respuesta que viene dividida en partes.
- Secuencia: Identificador del mensaje dividido.
- Posición: indica que parte del mensaje es.
- Fin: indica si es la última parte del mensaje.
Ø CorrelationID: Es el identificador de correlación. Tiene como objetivo ser un identificador único de los mensajes. Como no es posible tener un generador de números únicos para todas las aplicaciones que se conectan a la plataforma de integración, esto es un identificador compuesto.
- appOrigen: Identifica la aplicación que llama a la plataforma.
- § idUsuario: Identifica al usuario de la aplicación.
- § idRequest: identificador de transacción de la aplicación.
- § timeStamp: Fecha y hora de la llamada.
- § CanalRespuesta: Para respuestas asíncronas indica la URI del canal de respuesta.
- serDestino: identifica al servicio que se está llamado. Esta es una identificación lógica, porque es el motor de integración quien cursará la llamada para el servicio finalmente.
- § isServicio: identificador del servicio.
- § URI: URI del servicio expuesto por la plataforma.
BODY
En el BODY se encuentran los parámetros de la llamada a la operación de negocio y en respuesta, viene la respuesta del servicio.
En la figura 5 se muestra el esquema.
Los parámetros son opcionales y son una tabla hash de parámetros serializados en XML.
La respuesta es un TAG de XML sin esquema porque puede contener cualquier información.
Error
Aquí se almacena la información de excepciones que ocurren en el circuito de la llamada al servicio. Este es un TAG opcional.
Los campos de esta sección son los siguientes:
- Ø idError: Identificador del error.
- Ø dateTime: Fecha y hora del error.
- Ø Origen: es la glosa del lugar dónde se produjo el error.
- Ø Tipo: Es el tipo de error.
- Ø Decripcion: Es la descripción del error.
Figura 4: BODY y ERROR del esquema XML
El siguiente código muestra el esquema XSD
<?xml version="1.0" encoding="utf-8"?>
<!– edited with XMLSpy v2006 rel. 3 sp1 (http://www.altova.com) by Juan Pablo (Datco) –>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="xml1">
<xs:annotation>
<xs:documentation>Raiz</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Header">
<xs:complexType>
<xs:sequence>
<xs:element name="correlationId">
<xs:complexType>
<xs:sequence>
<xs:element name="appOrigen">
<xs:complexType>
<xs:sequence>
<xs:element name="idAplicacion" type="xs:string" nillable="false" />
<xs:element name="idUsuario" />
<xs:element name="idRequest" />
<xs:element name="timestamp" />
<xs:element name="CanalRespuesta" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="serDestino">
<xs:complexType>
<xs:sequence>
<xs:element name="idServicio" type="xs:string" />
<xs:element name="uri" type="xs:anyURI" />
<xs:element name="Versión" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="tipoRequest" />
<xs:element name="version" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="secuenciador">
<xs:complexType>
<xs:sequence>
<xs:element name="secuencia" type="xs:int" default="1" />
<xs:element name="posicion" type="xs:int" default="0" />
<xs:element name="fin" type="xs:boolean" default="true" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="expiracion" type="xs:dateTime" />
<xs:element name="gestion" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="campo" type="xs:string" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="hash" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="request" />
<xs:element name="response" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="body">
<xs:complexType>
<xs:sequence>
<xs:element name="parametros" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="parametro" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="nombre" type="xs:string" />
<xs:element name="valor" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="respuesta">
<xs:complexType>
<xs:attribute name="datetime" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="error" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="idError" />
<xs:element name="datetime" />
<xs:element name="Orgien" />
<xs:element name="tipo" />
<xs:element name="Descripcion" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Código Esquema XSD del mensaje universal.
Referencias
[1] http://www.enterpriseintegrationpatterns.com/CanonicalDataModel.html
..:: Liarjo of Locksley ::.. 