My google alert picked up Stefan Tilkov's post agreeing with Radovan Janecek's Anti-SOA post. So I will add in my own equally valid opinion to this chain.

To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.

While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provocative.

ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).

My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.

My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.

At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.