Mensajería XML, parte 1

La mensajería XML representa un área dinámica de TI de rápido crecimiento, una situación que la hace emocionante y tediosa al mismo tiempo. A medida que crezcan los intercambios B2B y otras formas de comunicación electrónica entre empresas, la mensajería XML se desplegará más ampliamente que nunca.

Lea toda la serie "Mensajería XML":

  • Parte 1: escribir un intermediario de mensajes XML simple para mensajes XML personalizados
  • Parte 2: mensajería XML a la manera SOAP
  • Parte 3: JAXM y ebXML establecen el nuevo estándar para la mensajería XML

En este artículo, primero exploraremos la mensajería XML y por qué es útil. Luego, profundizaremos en características específicas de mensajería XML, incluido el enrutamiento, la transformación y la intermediación de mensajes. Finalmente, terminaremos con un ejemplo simple de un corredor XML. Después de leer y comprender los conceptos, debe comprender claramente qué escenarios se prestan para implementar una solución de mensajería XML.

¿Qué es la mensajería XML?

Para comenzar nuestra exploración, necesitamos comprender la premisa básica de la mensajería XML y lo que implica el término mensajería . Para los propósitos de este artículo, defino el mensaje de la siguiente manera:

Una colección de campos de datos enviados o recibidos juntos entre aplicaciones de software. Un mensaje contiene un encabezado (que almacena información de control sobre el mensaje) y una carga útil (el contenido real del mensaje).

La mensajería utiliza mensajes para comunicarse con diferentes sistemas para realizar algún tipo de función. Nos referimos a la comunicación como orientada a mensajes porque enviaríamos y recibiríamos mensajes para realizar la operación, en contraste con una comunicación orientada a RPC (llamada a procedimiento remoto). Una simple analogía puede ayudar: piense en la mensajería como correo electrónico para aplicaciones. De hecho, la mensajería posee muchos de los atributos de las personas que se envían mensajes de correo electrónico entre sí.

En el pasado, cuando usaba o trabajaba en un sistema orientado a mensajes, significaba que estaba usando algún tipo de producto MOM (middleware orientado a mensajes) como Rendezvous de Tibco, MQSeries de IBM o un proveedor de JMS para enviar mensajes en un moda asincrónica (unidireccional). La mensajería actual no significa necesariamente que esté utilizando un producto MOM, y no significa necesariamente que se esté comunicando de forma asincrónica. Por el contrario, la mensajería puede ser sincrónica (bidireccional) o asincrónica y utilizar muchos protocolos diferentes, como HTTP o SMTP, así como productos MOM.

¿Por qué la mensajería XML?

¿Por qué querría desarrollar un sistema mediante mensajería? ¿Qué hace que la mensajería sea una técnica de diseño útil y cuáles son los beneficios? Como se mencionó anteriormente, podemos elegir entre dos alternativas cuando se requiera que dos aplicaciones se comuniquen entre sí a través de una red: RPC u orientada a mensajes. El uso de un enfoque basado en RPC (RMI entra en esta categoría) significa que el cliente (o la persona que llama) de la llamada al procedimiento conoce el procedimiento que desea invocar y conoce los parámetros que desea pasar al procedimiento. Además, la persona que llama desea esperar mientras el servidor llamado (la aplicación) completa la solicitud.

En el segundo enfoque, orientado a mensajes, la persona que llama no conoce necesariamente el procedimiento exacto que se invocará, sino que crea un mensaje de un formato específico conocido tanto por el cliente como por el servidor. El cliente crea el mensaje y luego lo envía al servidor a través de la red. Por lo tanto, el cliente no depende del servidor o de los procedimientos del servidor, sino que depende del formato del mensaje. Además, es probable que la comunicación se lleve a cabo de forma asincrónica, lo que significa que el cliente enviará una solicitud pero no esperará (bloqueará) la respuesta. Esto permite que el cliente continúe funcionando incluso si el servidor no está disponible (se bloquea, por ejemplo). Este diseño, en el que el cliente es más independiente del servidor, se considera más débilmente acoplado.

Al evaluar si se debe utilizar un diseño orientado a mensajes, es importante comprender los pros y los contras de dicho sistema. Los pros incluyen:

  • Bajo acoplamiento
  • Enrutamiento y transformación de mensajes más fáciles
  • Carga útil más flexible (puede incluir archivos adjuntos binarios, por ejemplo)
  • Puede utilizar varios mensajes juntos para invocar un procedimiento determinado.

En general, un enfoque orientado a mensajes resulta más flexible que un enfoque RPC.

Ahora aquí hay algunas desventajas:

  • Requiere más trabajo desarrollar una interacción cliente / servidor utilizando un enfoque orientado a mensajes en comparación con un enfoque RPC como RMI porque desarrollar una interacción cliente / servidor a través de un mensaje representa otro nivel de indirección de RPC. La complejidad se agrega mediante la creación del mensaje en el lado del cliente (frente a una invocación de procedimiento en un enfoque RPC) y en el lado del servidor con el código de procesamiento de mensajes. Debido a su complejidad adicional, un diseño orientado a mensajes puede ser más difícil de entender y depurar.
  • Existe el riesgo de perder información de tipo para el lenguaje de programación en el que se envió el mensaje. Por ejemplo, el doble en Java puede no traducirse como un doble en el mensaje.
  • En la mayoría de los casos, el contexto transaccional en el que se creó el mensaje no se propaga al servidor de mensajería.

Teniendo en cuenta los pros y los contras, ¿cuándo debería utilizar un enfoque orientado a mensajes? El escenario más común ocurre cuando la comunicación cliente / servidor se realiza a través de Internet y el cliente y el servidor pertenecen a empresas diferentes. En este escenario, podría ser bastante difícil que las dos empresas se pongan de acuerdo sobre la interfaz del procedimiento. Además, es posible que las empresas no quieran utilizar el mismo lenguaje de programación. En otro ejemplo, las empresas involucradas pueden querer utilizar un modelo de comunicación asincrónica para que ninguna dependa de que la aplicación de la otra esté en funcionamiento.

Otro escenario de mensajería atractivo ocurre cuando está desarrollando un sistema basado en eventos en el que los eventos son creados y luego consumidos por las partes interesadas. La mayoría de las GUI se basan en eventos. Por ejemplo, pueden crear un evento de clic del mouse en el que las partes interesadas escuchan el evento y realizan alguna acción basada en él. En este escenario, el uso de un enfoque de mensajería le permite eliminar la dependencia entre un evento (o acción en un sistema) y la reacción del sistema al evento que se realiza en el servidor.

Ahora que entendemos un poco sobre la mensajería, estamos listos para agregar XML a la ecuación. La adición de XML a la mensajería significa que podemos hacer uso de un lenguaje de formato de datos flexible para nuestros mensajes. En la mensajería, tanto el cliente como el servidor deben acordar un formato de mensaje. XML facilita esto al decidir muchos problemas de formato de datos y con la adición de otros estándares XML como Rosetta Net. No se requiere ningún trabajo adicional para crear un formato de mensaje.

¿Qué hace un agente de mensajes XML?

Un intermediario de mensajes actúa como servidor en un sistema orientado a mensajes. El software de intermediario de mensajes realiza operaciones con los mensajes que recibe. Estas operaciones incluyen:

  • Procesamiento de encabezados
  • Comprobaciones de seguridad y cifrado / descifrado
  • Manejo de errores y excepciones
  • Enrutamiento
  • Invocación
  • Transformación

Procesamiento de encabezados

Header processing is usually one of the first functions performed in the message upon its receipt within an XML broker. Header processing involves examining the header fields of incoming messages and performing some functions. Header processing could include adding a tracking number to an incoming message or ensuring that all of the header fields necessary to process the message exist. In the example XML message below, the message broker could check the to header field to ensure that this is the proper destination for this message.

Security checks and encryption/decryption

From a security perspective, a message broker can perform several different operations, but most likely you'll want to accomplish the "big three" of security: authentication, authorization, and encryption. First, once it determines that the message contains data that can be used to authenticate, the message broker will authenticate messages against a security database or directory. Second, the message broker will authorize operations that can be performed with this type of message and an authorized principal. Finally, the message that arrives at the message broker may be encrypted using some encryption scheme. It will be the broker's responsibility to decrypt the message in order to process it further.

Error and exception handling

Error and exception handling is another important piece of functionality performed by the message broker. Generally, the message will respond to the client (assuming a synchronous invocation) with an error message, caused when the message sent to the broker does not contain sufficient or accurate information. Another cause for errors or exceptions would occur when servicing the request (actually invoking a procedure/method based on the payload of the message).

Routing

Message routing is branching logic for messages. It occurs at two different levels in a message. The first, header-level routing, determines if an incoming message is bound for this application or needs to be resent to another application. The second, payload routing, determines which procedure or method to invoke once the broker determines that the message is bound for this application. Together these two types of routing enable a rich set of functionality when dealing with messages.

Invocation

Invocation means to actually call or invoke a method with the data (payload) contained in the incoming message. This could produce a result that is then returned through the broker back to the client. What is invoked could be anything, including an EJB Session bean, class method, and so on.

Transformation

Transformation converts or maps the message to some other format. With XML, XSLT is commonly used to perform transformation functionality.

An example XML message

Below you'll find an XML message used in the sample application that follows. Notice the header and body portions. This example is a "saveInvoice" type of message, in which the body contains an invoice that needs to be saved.

   companyReceiver companySender saveInvoice      John Smith 123 George St. Mountain View CA 94041   Company A 100 Main St. Washington DC 20015    IBM A20 Laptop 1 2000.00       

You may wonder whether there is an advantage to developing a custom XML message. Why not use one of the existing message standards like ebXML or SOAP to encapsulate the payload (the invoice)? There are a couple of reasons. The first is to demonstrate some of the contents needed in a message without all of the complexity of explaining a full-blown industry standard. Second, although the existing standards fill most needs, there still will be scenarios in which using a custom message will better fit the needs of a situation, much like the tradeoffs between using a higher-level protocol like HTTP or SMTP and using raw sockets.

A prototype XML broker implementation

Having discussed the reasons for using a messaging design in your application, we will now proceed to a prototype XML messaging broker implementation.

Why should you develop a custom message broker implementation instead of using an existing one? Well, because many of the implementations for XML messaging products are new, so it's important to know what goes into a basic implementation. Also, it's possible that because XML message brokers are somewhat immature products, you'll need to develop your own to get the features you want.

The basic broker presented here can service two types of messages: a request to create an invoice, which it stores on the filesystem, and a client code component, which just reads the XML message from a file and sends it.

The broker comprises three main parts: a listener piece that receives incoming messages on some transport (in this example there will only be an HTTP implementation provided); the main broker piece, which will decide what to do with an incoming message; and the invocation piece that will actually perform some logic based on the incoming message. Let's look at each in more detail.

Receive the message from the transport

Un mensaje encontrará primero la parte del oyente del corredor. La mayoría de los intermediarios de mensajes XML brindan soporte para muchos transportes (protocolos) diferentes como HTTP, SMTP, JMS (la implementación de un proveedor en particular), etc. Nuestro corredor lo permite aislando la parte de transporte. La pieza que se muestra a continuación simplemente recibe el mensaje en un transporte determinado, coloca el mensaje entrante en una variable de cadena y llama al agente único: