The Message Oriented architectural (MOA) pattern provides a basis for general asynchronous communication between components. In the pattern, all communication occurs as discrete messages that pass through a message bus. The bus routes messages to the appropriate client based on a routing policy. This pattern is known by two other names, depending on which parts of the architecture are most significant for the design problem:
- the Message Driven pattern because all internal computation in a component is the result of receiving a message from another component.
- the Message Broker pattern, because a broker is responsible for deciding which component receives which message.
The diagram illustrates the pattern. The message bus is modelled as a single component that provides two interfaces to clients:
- IBroker is used to send messages to other clients via the bus.
- IQueue is used to read messages from the bus that have been sent specifically to the client by other clients.
The use of standard interfaces ensures that all messages sent via the bus comply with a prescribed format. This means that every client will know how to parse the structure of a message, even though it may not be able to interpret the content. The figure also shows the internal structure of the MessageBus component. Messages for individual clients are stored in a Queue such that there is one Queue maintained per client. Each queue realises the IQueue interface provided to the appropriate client by the MessageBus. Typically, the client will consume and process messages from the Queue as quickly as it can, using the Queue as a buffer when it experiences a heavy load of messages. The Client will also normally block once it has processed all available messages in its Queue. Separately, clients can send messages using the IBroker interface. This interface is realised by the Broker sub-component. When a message arrives at the interface the Broker decides which Queue the message should be added to, normally, based on the intended end client.
The broker may not be able to deliver a message, if a queue is full, for example, or because the message does not have a valid destination. In this situation, the broker is responsible for handling the message, either by dropping the message, or by notifying the client that the message wasn’t valid (by leaving a message in the sender’s queue).
There are several further advantages to using a centralised message bus to mediate communications:
- Communications security is centralised by ensuring that all messages pass through secured channels on the message bus.
- The broker can be configured dynamically to route messages according to the state of the application.
- The message bus provides a central location for monitoring inter-component communication.
- This is useful for logging interactions between components for debugging or auditing, for example. The structure also makes it easier to identify bottle necks or faulty components, since this is typically indicated by congested queues.
Configuring Message Orientated Architecture
There is considerable flexibility in influencing the behaviour of a message oriented architecture through two mechanisms:
- The relationship between queues and clients. Several clients may be connected to the same queue, for example, if the number of messages added to the queue is typically too much for a single client to handle. Alternatively, a client may listen for messages on several different queues. For example, a client may maintain separate queues for normal and exception messages.
- The policy applied by the broker to distributing messages. The broker may choose between different queues depending on different factors. The broker might choose the queue based on a specific intended recipient, the queue containing the least messages, or the message type, for example.
The broker pattern is structurally similar to the Load Balancing enterprise pattern, except that the broker decides where to send a request based on load.
Sequential data processing applications
Many software applications are required to process large volumes of data, applying a number of transformations between input and output. Examples include: • Video and audio media transcoding, where video is decoded, potentially reformatted (size, colour model etc.) and then encoded. • Textual analysis, where prose is checked for spelling and grammar errors in one language before being translated into another. • Inter-bank payment processing, where very large numbers of small scale currency transfers must undergo a series of validations before being approved. • Processing and synthesising data gathered from scientific instruments. Raw instrument data often needs considerable re-processing and integration before it can be used in analyses. Weather and climate data (temperature, pressure, humidity and so on), for example, is gathered from a variety of sources and using a heterogeneous range of instruments.
Design problems
These related applications present several design problems:
-
Each of the steps in the transformation can take a variable amount of processing time for a given data item. This can result in one or more of the steps becoming an bottleneck which limits the performance of the application as a whole. For example, video data compression may need significant amounts of buffered frame data before it can begin, even though other processes such as frame re-sizing finish more quickly.
-
Steps may need to replaced or re-ordered as the application is adapted to different needs. For example, a generic translation application might need to translate text from French to English, English into Mandarin and so on. In addition, there are different standards for correcting language grammar and punctuation.
-
It may be desirable to have a convenient means of re-using some functions in combination. In the translation application describe above, for example, French to English and English to Mandarin components could be composed to produce a French to Mandarin function.