Radovan Janecek has a nice provocative post on “Anti-SOA”, featuring this “slide”:
- Enterprise Service Bus
- Service intermediation
- Service Oriented Infrastructure
- Some WSM
Having discussed this with him many times before, I believe I know pretty well why he feels this way …
An Enterprise Services Bus (ESB) as advocated by most vendors is SOA’s archenemy. Intelligent infrastructure, in general, is just what one aims to get away from with SOA — otherwise, we just get EAI in disguise. I don’t want to rely on a centralized piece of infrastructure, no matter how federated its deployment may be, simply because once the next merger or acquisition happens, I’ll have two of them, and then three and so on. I don’t want to see all messages flow through the same channels — peer-to-peer communication between service provider and service consumer is not something to avoid, on the contrary — it’s exactly what one should aim for. If I want to enable a consumer to interact with a service, it should require nothing more than the service description, possibly augmented with some profile information. An ESB is perfectly fine if it’s used to support a service implementation (or for service enablement, if you prefer) — the fact that it’s used should not matter to the service consumer.
BPEL as supported via a central engine in the center of my enterprise IT, usually embedded in my ESB, is just as bad — what better way to put intelligence into your infrastructure than putting a programming language into it and create the illusion that programming graphically is somehow not programming? A BPEL engine as a runtime for a different way to implement services is fine, though.
“Service intermediation”, the idea of putting something smart between your consumer and your provider, sounds nice, except it falls into the same category — making your network intelligent instead of your endpoints. Service-oriented infrastructure … well, if it’s the same product category (intelligent infrastructure), I agree it’s anti-SOA. I use the term SOA Infrastructure differently, to refer to the sum of your technical decisions with regards to standards and the technical services you deploy … “Some WSM” falls into the same trap.