Re: [service-orientated-architecture] SOA and ESBs

[Steve Jones]

ESB is just a technology that can help in the delivery of an SOA, its nothing to actually do with the architecture (IMO).

I'd also claim that there are two clearly distinct markets in the products at the moment, one for Integration Service Buses (the old school EAI products with an SOA tag on them for the most part) and the newer business service buses (XML only, Aqualogic from BEA being an example).  The ones that bridge to the legacy applications are primarily the integration service bus type, and these are almost death when you try and apply that sort of steam powered hammer to solve pan-enterprise problems. In their individual places they can really help but the worst bit is the name, namely "Enterprise", haven't we learnt from the old EAI world that you will almost NEVER have a single product that spans your enterprise and that such thing isn't a good idea anyway.  ESBs of either variety try and claim they are the only thing that a company needs but clearly this isn't the case.   People need to assume they will have multiple products doing these jobs in different parts of the organisation and its the overall architecture and governance rules that are going to matter in making a consistent view across the enterprise.

ESB is just a product, neither worse (except the old EAI ones) nor better than any other products.  Its not magic and it requires planning.  The worst ones I see are those who are lobbing BPEL engines and the like into the ESB, which means it isn't a bus its an application server.

Apologies for additional grumpiness this morning, I watched Switzerland v Ukraine last night.

On 27/06/06, 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

__._,_.___

SPONSORED LINKS

Computer software	Computer aided design software	Computer job
Soa	Service-oriented architecture

---

YAHOO! GROUPS LINKS

•  Visit your group "service-orientated-architecture" on the web.
   
•  To unsubscribe from this group, send an email to:
   [EMAIL PROTECTED]
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

__,_._,___