Composite UI for Service Oriented Systems – Messaging Introduction

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

Messaging can help to reduce coupling in your system. It also addresses some of the fallacies of distributed computing. But messaging is no silver bullet. You have to carefully choose according to your non-functional requirements, risk analysis, fallacies and more whether it makes sense to use messaging. Messaging can take place inside the same process boundaries (i.e. with Event Aggregators) or over process boundaries. To leverage to full benefit of messaging often a combination of in-process and out of process messaging is used. Let us briefly explore some of the basics about messaging.

The book Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf summarizes messaging very well:

Use 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).

If we combine that quote with what we have learned in the previous blocks and exercises we see that messaging reduces coupling in multiple ways. First it reduces platform coupling by leveraging interoperable standards in the message body (such as XML, JSON and…) and second by using asynchronous messaging it reduces temporal coupling. This all by reducing afferent and efferent coupling while increasing autonomy at the same time. It also provides an active force against the fallacies of distributed computing by forcing developers to think about network, latency, bandwidth and more.

How does it compare to RPC style communication in regards to performance? This will be covered in the next post.