In the previous installment of the Beyond Integration series, we talked about some strategies for evolving legacy monolithic systems into finer grained services orchestrated by Mule ESB. As mentioned in this earlier post, following such a path opens the door for implementing new business operations by using the newly created services in novel and previously impossible ways.
One of the main concerns of modernizing legacy application consists in reducing coupling in all its forms. This is why reducing systems and components coupling, by establishing cleaner and clearer interfaces, is often one of the very first steps taken in such an evolution process. Another form of coupling that needs to be taken care of is temporal coupling. Systems that tended to synchronously depend on each other are time-decoupled by the introduction of a messaging intermediation tier, leading to an overall architecture that scales better and is more resilient to failures.
In essence, reducing time-coupling generally translates into evolving from an invocation-driven architecture to an event-driven architecture. In today’s post, I will present how using Mule can be an enabling first step towards the roll-out of such an architecture.
When using Mule to orchestrate or route messages between your business services, a few existing mechanisms allow you to create event producers without disturbing the existing flows of message. Let’s look at a couple of them, namely the wiretap and multicasting routers.
Wiretap Router
A wiretap router is an inbound router that you can use in Mule to send a copy of all incoming messages to another destination.
(Illustration from Enterprise Integration Patterns)
Adding a wiretap router allows broadcasting events anytime a message is received by Mule, for example whenever a service, proxy or orchestration gets called. In Mule, wiretapping occurs before any business logic that could kick in a component or routing logic that could exist in outbound routers. Therefore, a wire tap usually picks up messages as they arrive in Mule and before they’ve been processed by any downstream logic.
It’s of course possible to wiretap message exchanges that occurs between Mule services but incoming messages are usually more meaningful business-wise.
As an example scenario, consider the case of a user authentication service hosted on or proxied by Mule. Wiretapping calls to this service could be used to perform actions, like flushing user specific caches, without waiting for the outcome of the actual authentication operation (which, except in case of an ongoing brute force attack, would succeed most of the time).
Multicasting Router
A multicasting router allows sending copies of the same message to several recipients.
(Illustration from Enterprise Integration Patterns)
By using a multicasting router in lieu of a simple pass-through one, it’s easy to have Mule start sending to a second destination when it was originally only sending to one. Unlike what’s usually done with the wiretap router, the multicasting router is used downstream of a message flow in Mule. Consequently, it’s a good option when you intend to broadcast events only when some business logic have been successfully executed first.
Consider for example the case when you want to broadcast an event whenever a payment has been successfully processed. Within Mule, a message indicating the payment completion already exists and is used to change a database state via JDBC. By multicasting this message to another destination, say a JMS queue or topic, you can start creating new business logic that gets triggered when such an event occurs.
Going Further
Moving away from timely-coupled RPC-style architectures has clearly not been a guaranteed corollary of adopting SOA. By using Mule, it is possible to support the emergence of an architecture that relies more on events and messages in order to scale better and provide a greater business agility.
This post has only scratched the surface of such an architecture. If you’re interested in learning more about event-driven systems and architecture, turn to Event Processing in Action, a book that is just off Manning’s presses. Thinking in term of events requires a mind shift: we have the tools, but it’s up to each of us to make it happen…
