In one of the most entertaining presentations on the topic ever, Dr. Jim Webber debunks myths about the mainstream ESB concept and explains how a lightweight approach can yield real benefits without giving in to vendor pressure. Jim claims that an ESB often ends up being just a thin veneer on an existing mess, and how an approach that doesn't put intelligence into the network is superior.
Dr. Jim Webber is the SOA Practice lead for ThoughtWorks, where he works on Web Services-based systems for clients worldwide. He has extensive Web Services architecture and development experience and was the lead developer with Hewlett-Packard on the industry's first Web Services Transaction solution. Jim is co-author of the book "Developing Enterprise Web Services - An Architect's Guide."
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Adding features to a service without changing it
I have a question though. I'm trying to think through one of the advantages I think you can get with an ESB architecture. If all messages go via an ESB then features such as security, logging, routing, transformations can be:
1. Managed centrally .. so no need for individual services to implement these features.
2. New features, and updates to old features, can be managed seperately from the services themselves.
This strikes me as positive things becuase it means that different aspects of services can be managed/deployed/changed seperately.
Maybe the features I'm talking about are just technical services? You very, very briefly touched upon technical services in your presentation.
Any thoughts? Or should I just buy the book?
Though I'm a bit worried that he goes over the technical issues with SOAP and WS-* in general, and federated transactions in particular, a bit too quick.
In my experience, most of WS-* simply doesn't work. That's not so bad, as most of it doesn't have any value to me, too, but still ;-).
Distributed transactions in particular have been dismissed by many experts that have worked on the topic for ages. There are highly plausible arguments that they might never work at all.
There is still a lot of work to be done, and at I'm very sceptical if all the WS-* stuff is actually helping to get stuff done or just an impediment.