Composite UI for Service Oriented Systems – More message patterns

This blogpost is part of a larger blog post series. Get the overview of the content here.

I briefly mentioned that the message has a body. The body carries on the payload or the actual business data identified by the message. Furthermore a message can contain metadata on its header. This allows the message to carry on additional information which can be consumed by the receiver side. Message forwarders need to make sure that the headers remain intact during the communication process. This means a forward should only append additional information to the metatadata or body but never remove information. Leveraging the metadata which can build up more message patterns.

For example by adding the return address (the logical queue address of the sender) to the message header, a receiver can decide to return a message as a response back to the sender. With that we use to channels for the communication, one for the request and one for the response. This pattern is called Return Address Pattern.

Combining the Return Address Pattern with a correlation id in the header with gain correlated request/response. In this case the message id will be copied to the header as correlation id for messages which are a direct consequence of the received message. This allows us to do request and multiple responses because messages can be correlated together. For example you can also chunk multiple return messages for large responses. This pattern is also important for UI composition techniques which will be discussed later.

Last but not least we have the publish/subscribe pattern. This is the base for “events” between systems. An event in messaging is simply the receipt of a message. Therefore publishing a message is nothing more than sending a message to multiple receivers. We will dive more into the semantics of events later.