The way I view it: - an ESB is an optional decentralized proxy service - it can monitor or enhance a services capabilities without requiring modification to a downstream service - ESBs might also help to manage dependencies and interface evolution - the major benefit is that it should be more productive than building these things in a framework of your own - lock-in is a fact of life, even if you build something yourself -- those people could leave, and you've lost your braintrust
The reason it's useful is because service contracts are constantly evolving. New breeds of consumers evolve, with different requirements. New classes of QoS are required... etc. You can evolve the source, or use an intermediary as lubricant. Either approach has its appropriate context. For example, if one creates a bunch of SOAP/RPC time-series data services, wouldn't it be useful to be able to overlay an RSS or Atom feed on top of them, so a new class of consumers could access those services? Sure, you could build such an overlay.... or you could modify the source service and add another endpoint / content type... or you could use an ESB. Which would be more productive? It depends on your context... Anyway, to me an ESB is similar to the concept I've heard of a "SOAP Router" 3 or 4 years ago, though ideally should allow a variety of protocols. Not mandatory, but useful. Of course, the marketplace is pretty confusing about what is/is-not an ESB, and how much priorietaryness is/should-not be there, etc., so the risks are high enough to be cautious. Cheers Stu --- Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > Hi all, > > I'd like to find out how list members view the use > of ESBs in SOA. Based > on what I've read and discussions I've had off list, > I suspect a fair > number of people view an ESB as an essential > component of a SOA. > > In my own talks on the topic I tell people that ESBs > are especially good > for bridging legacy applications to a SOA. Beyond > this, they can > certainly add a lot of value in the monitoring and > control area. > However, I think there's been way too much marketing > hype from the > vendors that conflates ESBs with SOA. Especially now > that WS-Addressing, > WS-ReliableMessaging, and WS-AtomicTransactions are > becoming standard > components of the SOAP stacks (and WS-Eventing is > getting closer), the > value added to Web services by an ESB seems to me to > be minimal for all > but the largest enterprises. > > The main drawback I see to using an ESB is that > you're building your > enterprise around proprietary software. Even the > open source ESBs all > have their own unique ways of configuring and > managing services. The net > effect is that you're locked into a particular > service bus and will find > it increasingly difficult to break free over time. > > How do other people feel about this? > > - Dennis > > -- > Dennis M. Sosnoski > SOA, Web Services, and XML > Training and Consulting > http://www.sosnoski.com - http://www.sosnoski.co.nz > Seattle, WA +1-425-296-6194 - Wellington, NZ > +64-4-298-6117 > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
