Many organizations are adopting Message Oriented Middleware (MOM) as a platform for solving complex integration issues. One of the key concepts in MOM is message brokering. Each piece of data within a MOM is described as a message (sometimes referred to as an event). Because these messages are transported between various applications, XML is now the de facto standard for describing event data. When working with XML in a MOM scenario, you need to understand several key issues, including message identification and message size.

XML tips

Application developers will walk away with useful XML information and coding that they can use on the job. Delivered each Wednesday, our XML tips will help subscribers stay ahead of the technology curve. Sign up now!

Identifying messages
With most middleware platforms, it’s relatively easy to determine when a new event occurs. Basically, the event appears as a message on a particular channel or queue. Just because there’s a message on a channel doesn’t mean it’s the message the application is waiting for or one that the application can handle. In order to process the message, the application (which waits for new events to appear on the channel) must first identify what type of message it receives. Many different types of messages might appear on the channel. For example, data events can occur that include application-specific data. Other events are control events that affect the behavior of the application.

There are two popular methods for determining which kind of event the application has received. Because we are assuming that the data is packaged as XML, the first method involves examining the XML and determining the event type based on the XML root element. For example, if the root element is a <Customer> element, the event is a customer event.

Another approach is to use the native typing mechanism provided by the middleware. Many middleware platforms include support for event types, which encapsulate the events being transported on the message bus. By defining distinct event types within the middleware, you can encapsulate each XML event as a specific event type, even though the event data (essentially an XML string) remains the same. This approach allows the application to examine the event wrapper only, without having to look at the XML data.

Message size
The size of the message that’s sent on the message bus can also play a role in your application design. Messages (that is, XML documents) can become very large—some XML documents can be as large as several hundred pages of text. Sending a document this size is not an issue necessarily; however, in the context of volume, it can be a major problem. Most enterprise middleware systems have a limited amount of system resources (specifically RAM memory). When there are many large events in numerous queues in the system, the resources can quickly become taxed and performance can suffer.

When you’re designing a solution that uses XML to describe messages, keep in mind the size and volume of the messages. If the messages are large, then only transmit a limited number of them. If the volume is large, then the messages should be smaller. If a lot of data is being sent, it might be worthwhile to examine it for the essential components and redesign the XML schema. Chances are that the specific message being sent doesn’t require all the data in the XML when the XML is really large. That data could be extracted into a smaller XML document and sent as a more specific message rather than a generic one.

When you’re using a middleware platform to integrate various applications, XML can provide a robust and flexible method for describing message data. By examining the event type or the root XML element, you can determine what kind of message has been sent. You can easily run into performance issues if the size of the messages is not in balance with the number of messages being sent; splitting apart large messages can help boost overall system performance.