Home

Content

An enterprise has multiple applications that are being built independently, with different languages and platforms. The enterprise needs to share data and processes in a responsive way.

• How can I integrate multiple applications so that they work together and can exchange information?

Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.

Asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Sending a message does not require both systems to be up and ready at the same time. Furthermore, thinking about the communication in an asynchronous manner forces developers to recognize that working with a remote application is slower, which encourages design of components with high cohesion (lots of work locally) and low adhesion (selective work remotely).

An enterprise has two separate applications that need to communicate, preferably by using Messaging.

• How does one application communicate with another using messaging?

Connect the applications using a Message Channel, where one application writes information to the channel and the other one reads that information from the channel.

When an application has information to communicate, it doesn't just fling the information into the messaging system, it adds the information to a particular Message Channel. An application receiving information doesn't just pick it up at random from the messaging system; it retrieves the information from a particular Message Channel.

An enterprise has two separate applications that are communicating via Messaging, using a Message Channel that connects them.

• How can two applications connected by a message channel exchange a piece of information?

Package the information into a Message, a data record that the messaging system can transmit through a message channel.

Thus any data that is to be transmitted via a messaging system must be converted into one or more messages that can be sent through messaging channels.

In many enterprise integration scenarios, a single event triggers a sequence of processing steps, each performing a specific function. For example, let's assume a new order arrives in our enterprise in the form of a message. One requirement may be that the message is encrypted to prevent eavesdroppers from spying on a customer's order. A second requirement is that the messages contain authentication information in the form of a digital certificate to ensure that orders are placed only by trusted customers. In addition, duplicate messages could be sent from external parties (remember all the warnings on the popular shopping sites to click the 'Order Now' button only once?). To avoid duplicate shipments and unhappy customers, we need to eliminate duplicate messages before subsequent order processing steps are initiated. To meet these requirements, we need to transform a stream of possibly duplicated, encrypted messages containing extra authentication data into a stream of unique, simple plain-text order messages without the extraneous data fields.

• How can we perform complex processing on a message while maintaining independence and flexibility?

Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).

Each filter exposes a very simple interface: it receives messages on the inbound pipe, processes the message, and publishes the results to the outbound pipe. The pipe connects one filter to the next, sending output messages from one filter to the next. Because all component use the same external interface they can be composed into different solutions by connecting the components to different pipes. We can add new filters, omit existing ones or rearrange them into a new sequence -- all without having to change the filters themselves. The connection between filter and pipe is sometimes called port. In the basic form, each filter component has one input port and one output port.

Multiple processing steps in a Pipes and Filters chain are connected by Message Channels.

• How can you decouple individual processing steps so that messages can be passed to different filters depending on a set of conditions?

Insert a special filter, a Message Router, which consumes a Message from one Message Channel and republishes it to a different Message Channel channel depending on a set of conditions.

The Message Router differs from the most basic notion of Pipes and Filters in that it connects to multiple output channels. Thanks to the Pipes and Filters architecture the components surrounding the Message Router are completely unaware of the existence of a Message Router. A key property of the Message Router is that it does not modify the message contents. It only concerns itself with the destination of the message.

Applications are communicating by sending Messages to each other via Message Channels.

• How does an application connect to a messaging channel to send and receive messages?

Connect an application to a messaging channel using a Message Endpoint, a client of the messaging system that the application can then use to send or receive messages.

Message Endpoint code is custom to both the application and the messaging system’s client API. The rest of the application knows little about message formats, messaging channels, or any of the other details of communicating with other applications via messaging. It just knows that it has a request or piece of data to send to another application, or is expecting those from another application. It is the messaging endpoint code that takes that command or data, makes it into a message, and sends it on a particular messaging channel. It is the endpoint that receives a message, extracts the contents, and gives them to the application in a meaningful way.

An enterprise is using Messaging to integrate applications.

• What will the messaging system do with a message it cannot deliver?

When a messaging system determines that it cannot or should not deliver a message, it may elect to move the message to a Dead Letter Channel.

The specific way a Dead Letter Channel works depends on the specific messaging system’s implementation, if it provides one at all. The channel may be called a “dead message queue” Monson Haefel, p.125 or "dead letter queue". MQSeries, Dickman, pp.28-29 Typically, each machine the messaging system is installed on has its own local Dead Letter Channel so that whatever machine a message dies on, it can be moved from one local queue to another without any networking uncertainties. This also records what machine the message died on. When the messaging system moves the message, it may also record the original channel the message was supposed to be delivered on.

An enterprise contains several existing systems that must be able to share data and operate in a unified manner in response to a set of common business requests.

• What is an architecture that enables separate applications to work together, but in a decoupled fashion such that applications can be easily added or removed without affecting the others?

Structure the connecting middleware between these applications as a Message Bus that enables them to work together using messaging.

A Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces. This is analogous to a communications bus in a computer system, which serves as the focal point for communication between the CPU, main memory, and peripherals. Just as in the hardware analogy, there are a number of pieces that come together to form the message bus:

When two applications communicate via Messaging, the communication is one-way. The applications may want a two-way conversation.

• When an application sends a message, how can it get a response from the receiver?

Send a pair of Request-Reply messages, each on its own channel.