The Idea behind this pattern is that most problems can be solved using a collection of
services that send messages to each other in an asynchronous manner.
Think of your team at work. You solve problems together but your collaboration and
communication is based on asynchronous messaging. You rarely ask someone to do
a certain task and then stand next to him and wait. You send a message (mostly by mail)
and then you know that in some time the job will be done. You continue to work. This is Asynchronous Messaging!
In this pattern there are number of services that sends messages to each other in Asynchronous Messaging via a bus.
In this pattern we have 3 main players:
1. The “Message”
2. The “Bus”
3. The “Handlers” (They can activate the services)
The bus will act as a shared area for messages to be transmitted on.
The bus has two main parts:
· The Messages queues
· The Handlers Lists.
For each “Message Type” a handlers queue and a message queue will be built on the bus. (“Publish”)
Handlers can enlist to a handles queue of a certain message type (“Subscribe”)
These of course can and will be done dynamically on runtime.
Subscribing on a message type means “I know to do something for that request”
When a service want ask for another service to do something for her, she will send a messages to bus.
The bus will receive that message and invoke (Asynchronously) all the handlers
that previously subscribed for that message type.
It will also publish a “message type” for the response and subscribe a “handler”
on it, which will fetch the result from the “asynchronous response” message.
The Bus Handlers and Messages
· Implement IHandle which means they have a Handle(IMessage msg) method that gets a
message from the bus and do something with it.
If the handler want to send a response or to activate another handler it will create a
message and send it to the queue. (assuming some handler subscribed on it)
· Many handlers can subscribe on one “Message Type” thus enabling multicast, also
enabling many infrastructure operations to be executed for each massage by subscribing handlers .
· Has a Message Type.
· A message includes also some more messaging information (like: RelatesTo, CallerID etc)
which is the implementation of WS addressing ideas.
· Might include some data.
· Includes a collection of handlers according to message types (Hash)
· Includes messages queues according to message types (Hash)
· All messages go through the bus. When a new message arrives it is put in the proper
queue and all the handlers for that message type are invoked asynchronously.
· The bus exposes the interface to publish a “message type”, to subscribe a handler and to send and receive a message.
· The bus can hosted in any kind of process (like a WCF service for example).
This host will read from a repository (Config / DB / Other) a list of messages and handlers to create initial subscription lists.
Conceptually the bus is a central entity that may systems register to:
The asynchronous messaging pattern in a distributed world
In a distributed system the bus is hosted in a service called the “Bus Edge Service”.
The distributed system will include many such “Bus Edge Services”.
The service exposes one major function: HandleMsg(Message msg).
With this method it possible to create a SOAP message and send it to another “Bus Edge Service”
In the SOAP message header the IMessage information is included.
This way such services (that expose a bus) can exchange messages.
The WCF service gets the SOAP message, construct an IMessage message and
put it on it’s local bus. Now the local handlers will respond.
The handler can do anything…
It will make sense that every bus will have a handler that gets a message and send it to another bus edge service.
This way handlers in different locations can send messages to each other.
Using the information of a message and the WS addressing information which
is included in every message it is possible to ask a brokers where is the bus that contain a handler that can do the job.
The IMessage field “RespondTo” will include the address of the “Bus Edge Service” of the actual client.
Clients and the Bus Edge Service
Clients can consume a certain Bus Edge Service to put a message on that bus.
The client assumes there is handler registered for that message type.
This handler will subscribe another handler that is in charge of responding to the result and send
it back to the client. Of course this handler will initiate a process of “Doing the Job”…
The client will usually consume the closest “Bus Edge Service” (usually in the same domain).
In this case it is acceptable to open a port and wait for a message that a local handler on that local Bus Edge
Service will send back to the user with a result.