Lately, I’ve been playing around a lot with the Windows Azure Service Bus EAI components (currently in CTP). During my upcoming Australia trip (register now!) I’m going to be walking through a series of use cases for this technology.
There are plenty of cool things about this software, and one of them is that you can visually model the routing of messages through the bus. For instance, I can define a routing scenario (using “Bridges” and destination endpoints) that takes in an “order” message, and routes it to an (onsite) database, Service Bus Queue or a public web service.
Super cool! However, the key word in the previous sentence was “or.” I cannot send a message to ALL those endpoints because currently, the Service Bus EAI engine doesn’t support the multi-cast scenario. You can only route a message to a single destination. So the flow above is valid, IF I have routing rules (e.g. “OrderAmount > 100”) that help the engine decide which of the endpoints to send the message to. I asked about this in the product forums, and had that (non) capability confirmed. If you need to do multi-cast messaging, then the suggestion is to use Service Bus Topics as an endpoint. Service Bus Topics (unlike Service Bus Queues) support multiple subscribers who can all receive a copy of a message. The end result would be this:
However, for me, one of the great things about the Bridges is the ability to use Mapping to transform message (format/content) before it goes to an endpoint. In the image below, note that I have a Transform that takes the initial “Order” message and transforms it to the format expected by my SQL Server database endpoint (from my first diagram).
If I had to use Topics to send messages to a database and web service (via the second diagram), then I’d have to push the transformation responsibility down to the application that polls the Topic and communicates with the database or service. I’d also lose the ability to send directly to my endpoint and would require a Service Bus Topic to act as an intermediary. That may work for some scenarios, but I’d love the option to use all the nice destination options (instead of JUST Topics), perform the mapping in the EAI Bridges, and multi-cast to all the endpoints.
What do you think? Should the Azure Service Bus EAI support multi-cast messaging, or do you think that scenario is unusual for you?
Richard Seroter's Architecture Musings 
From a “purist” SOA standpoint, I’d say Service Bus Topics are really the way to go. A Service Bus really isn’t the place to do your message transforms. The bus clients should do that, and keep their internal data requirements “to themselves” rather than introducing the deeper coupling involved in having the transformation at the Service Bus layer. This permits the service bus to be just that – a bus for sending (preferably uniform, master data managed) messages out to all interested parties.
I would expect that in future releases of the EAI bits would be able to have bridges listening to topic subscriptions, thus merging the two approaches.
Would orderservice -> bridge -> topic work for you? that way you can have your transform in the bridge?
It would, but still forces all topic subscribers to receive the same message, vs. sending destination specific formats to each place!