Comments on: Your ESB ate my SOA http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/ Mon, 26 Jul 2010 20:40:47 +0200 http://wordpress.org/?v=2.8.4 hourly 1 By: Vincent Partington http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/comment-page-1/#comment-4725 Vincent Partington Thu, 08 Feb 2007 10:58:50 +0000 http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/#comment-4725 It\'s funny how the Enterprise Services Bus products are not actual buses. Instead they are hubs to which everybody connects. This seems to combat the feared \"point-to-point problem\" but in fact the point-to-point could still exist while being routed though the \"Enterprise Service Hub\" which by then is just a bottleneck. See this nice article on InfoQ for some more thoughts on this subject: http://www.infoq.com/articles/ESB-alternative It\’s funny how the Enterprise Services Bus products are not actual buses. Instead they are hubs to which everybody connects. This seems to combat the feared \”point-to-point problem\” but in fact the point-to-point could still exist while being routed though the \”Enterprise Service Hub\” which by then is just a bottleneck.

See this nice article on InfoQ for some more thoughts on this subject:
http://www.infoq.com/articles/ESB-alternative

]]> By: rswart http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/comment-page-1/#comment-4502 rswart Wed, 31 Jan 2007 10:13:55 +0000 http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/#comment-4502 Somehow I get the feeling you are putting all the blame on the ESB. Please let me defend the poor guy (or is it a girl?). ESB\'s do not reinforce application silos, it is the way most companies use them: as an integration broker. They just create a hub-and-spoke architecture using an ESB. IMO, an ESB should be a lightweight ‘bus’ by nature. So not an all-knowing centralised nexus surrounded by dumb nodes. A true ESB should consist of intelligent nodes that can act in a distributed (federated) fashion. This also enables a more gradual, evolutionary approach to SOA with tiny, agile steps. I definitely see merit in using an ESB from the start. The problem is that some companies rebrand their heavy weight integration broker as an advanced ;-) ESB. Another issue I see is that people tend to think that when they use SOAP and WSDL that they are creating a SOA. Many service descriptions (WSDLs) I encounter are so specific that describe an one-to-one interface not allowing re-use (one-to-many), while this one of the promises of SOA (and before that Component Based Development). Here I fully agree with you: SOA is about analysis and design. Where this should be a big up-front design or a more agile approach is another question. Somehow I get the feeling you are putting all the blame on the ESB. Please let me defend the poor guy (or is it a girl?).

ESB\’s do not reinforce application silos, it is the way most companies use them: as an integration broker. They just create a hub-and-spoke architecture using an ESB. IMO, an ESB should be a lightweight ‘bus’ by nature. So not an all-knowing centralised nexus surrounded by dumb nodes. A true ESB should consist of intelligent nodes that can act in a distributed (federated) fashion. This also enables a more gradual, evolutionary approach to SOA with tiny, agile steps. I definitely see merit in using an ESB from the start.
The problem is that some companies rebrand their heavy weight integration broker as an advanced ;-) ESB.

Another issue I see is that people tend to think that when they use SOAP and WSDL that they are creating a SOA. Many service descriptions (WSDLs) I encounter are so specific that describe an one-to-one interface not allowing re-use (one-to-many), while this one of the promises of SOA (and before that Component Based Development). Here I fully agree with you: SOA is about analysis and design. Where this should be a big up-front design or a more agile approach is another question.

]]> By: Sander Hoogendoorn http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/comment-page-1/#comment-4193 Sander Hoogendoorn Thu, 18 Jan 2007 08:47:34 +0000 http://blog.xebia.com/2007/01/18/your-esb-ate-my-soa/#comment-4193 Good thinking indeed! As always I am tempted to agree with you. However, there is a nice aspect about introducing an ESB - in whatever implementation; as most companies start off by building one themselves. It seems to help people think "in services". For instance, I recently visited a customer who told me that they had just implemented an ESB (using .NET by the way, sorry for that). Now, at this time, no services were implemented yet, but the IT department stood firmly on the demand that every new project should consider releasing there software as services on their ESB. Thus, within reasonable time the customer hoped to get a bunch of services running. On the other hand, projects are required to find out if any existing services match there requirements. I agree, this is not a very top-down approach to introducing services, but it is pragmatic and will help organisations thinking in services. So, the ESB is indeed not technically required in a SOA, but might assist SOA awakenings Good thinking indeed! As always I am tempted to agree with you. However, there is a nice aspect about introducing an ESB – in whatever implementation; as most companies start off by building one themselves. It seems to help people think “in services”. For instance, I recently visited a customer who told me that they had just implemented an ESB (using .NET by the way, sorry for that). Now, at this time, no services were implemented yet, but the IT department stood firmly on the demand that every new project should consider releasing there software as services on their ESB. Thus, within reasonable time the customer hoped to get a bunch of services running. On the other hand, projects are required to find out if any existing services match there requirements.
I agree, this is not a very top-down approach to introducing services, but it is pragmatic and will help organisations thinking in services. So, the ESB is indeed not technically required in a SOA, but might assist SOA awakenings

]]>