Guerilla SOA

Jim Webber has posted a very entertaining video presentation on Guerilla SOA which although I do not entirely agree with his conclusions, is well worth the watch.

One thing Jim fails to explain is how to achieve publish/subscribe with pure WS-* on the WCF stack. In order to achieve this message exchange pattern today, one needs some kind of service bus topology.

He also talks about implementing SOA based entirely on open standards (such as WS-RM), but doesn't consider the fact that in many cases we need transactional durable asynchronous messaging.

We want the sending of a message and its receipt to be transactional, but we want the sending to be decoupled from the receipt such that the receiver does not need to wait for the sending thread to commit its transaction before it can commit its transaction.

We simply cannot have a transaction spanning two services. This is going to couple our services unacceptably. We must leverage an asynchronous messaging infrastructure such as that provided by an ESB.

Something else Jim does not consider is the need for service virtualisation and message routing. We don't want each service to have to know the location of all other services with which it collaborates. We do not want to have to configure each endpoint independently. It is well accepted that point-to-point communications are an administrative nightmare. We want a decentralised distribution model with centralised configuration.

Where I do agree wholeheartedly is that ESB technology is particularly appropriate and useful for providing an EAI capability behind the service boundary.

I also agree that putting smarts in the network (in the ESB) is a very bad idea. With SOA, the service is the top level construct and all smarts must go behind the service boundary. Once you have smarts inside the network, you are really violating your service boundaries, bleeding functionality outside the boundary. There will be a separate post on this later down the road.

In my opinion, the ESB still delivers capabilities in the fabric between services not yet matched by stacks such as WCF. Not to say that we won't necessarily get there in the end.