SOA, ESB, and Events — No 2.0

Expanding on my recent podcast, I wanted to add a word or two on the EDA (or Event Driven Architecture) buzz that popped faster than anything I've ever seen before and was replaced as SOA 2.0. Events are an integral part of any loosely coupled design. Mapping them to the SOA world, when using the vendor-generated web services tools didn't (and still doesn't) seem to fit. Maybe that's where people thought they could slip in a 2.0.

However, since we've already understood that the only things that pass between services are messages, then a message embodies an event as well. All we have to do is take care of the whole publish/subscribe semantics and technology. Simple, right?

Actually, it isn't that hard.

In the podcast, I describe using the abstractions introduced in the bus pattern/design to take care of the semantics. You want to subscribe to the Order Cancelled event of the Order Fulfillment service? Just implement the interface IMessageHandler<OrderCancelledMessage>. When the bus will see that handler, and it knows that the OrderCancelledMessage is owned by the Order Fulfillment Service (available at an endpoint different than your own), then the bus knows it needs to subscribe to that message with the service. One way it can do that is by sending a subscribe message to the service. The bus layer of the service will handle that message without passing it up the stack.

So far I haven't said anything new.

The important thing to see here has to do with contracts. If Service A wants to subscribe to messages of type X from Service B, does that make X part of Service A's contract? Of course not! So why do today's vendor implementations automatically cause that to occur? Just because a service, or a client for that matter, handle certain types of messages that doesn't say anything about their contract. If you look for the most recent technology stack coming out of any vendor targeting SOA you'd probably find Microsoft's Windows Communication Foundation (WCF - formerly known as Indigo). First of all, the fact that WCF poorly supports this core principle of SOA is incomprehensible. To top it off, it causes exactly the same effect as older stacks when it comes to Events (separate from OO level "events").

After doing a number of successful SOA implementations, I can tell you that the vast majority of service to service communication is event based, while running at around 40% for client to service scenarios. If you find that message types that are defined by numerous services, in the best case all you have is a technology that doesn't support events well; in the worst case, your service boundaries could be wrong.

Events really are the backbone of an SOA. The bus pattern/design supports events naturally. Don't settle for less.

Posted by Udi Dahan at 03:57 PM  Permalink