Anne has given a very comprehensive answer. There's not much to add except to say that from the IONA point of view, we feel that what seems to be the dominant definition of an ESB is not the right one. We picked the ESB product category for Artix because it is the closest category we could find but unlike most ESBs we are not tied to any particular application server or message broker.
We would completely agree with Anne that the ESB is not necessarily the starting point for SOA infrastructure. It could be, but you could also start with another component such as a process engine, registry/repository, or management platform.
And we would also agree generally that the ESB is most useful in service enabling and connecting existing applications into an SOA. However we do think that including service creation as part of the ESB is important, especially when preserving the mission critical qualities of service that the existing applications already depend upon. It's important to include the QoS and associated policies in the creation process so that you have a single environment for creation and connectivity. This helps ensure security policies such as single sign on are consistently implemented, transactions bridged, reliability policies enforced etc.
We do not tend to agree with the segmentation between the ESB function and the mediation function. Our configurable runtime can be deployed either at the endpoints or as an intermediary.
Overall I believe the major point is that you should not have to buy any more software than you really need to do SOA. As Anne said, it may be possible for you to do your SOA using software you already have. As a general statement, I believe most IT departments have the features and functions they need - probably they do not even use all the features and functions in the software they already own.
So to be really effective as a part of SOA infrastructure we believe an ESB has to play as well as possible with what's already there. We believe in delivering incremental value into the existing environment for a price point that's relative to where we are in the industry maturity cycle. We are at the stage of improving existing investments rather than making investments in completely new applications. This is a generalization that of course has exceptions to the rule but we believe the balance has shifted.
In this context what we do with Artix (and Celtix follows the same architecture and design principles) is offer a productivity tool for including existing applications into an SOA.
If you already have a lot of Microsoft or J2EE systems we do not suggest getting rid of them to do SOA. If you already have a significant investment in EAI tools we do not suggest getting rid of them either. What we do say is that you do not need to invest in additional Microsoft, J2EE, or EAI infrastructure simply to service enable and connect existing applications into an SOA.
We completely agree that SOA is an approach, not a technology, and that customers should start figuring out what they want to do before even thinking about infrastructure technology. We offer various parts of this infrastructure technology in addition to our ESB but for the ESB in particular (since that was the question) we suggest that once you define your service contracts we can help implement them using WSDL that is compatible with most existing communication protocols and data formats already in use.
This is an unusual definition of an ESB, but we think it is the best fit for customer SOA requirements since it eliminates a lot of work that you'd otherwise have to do to manually code WSDL mappings for all these formats and protocols.
Eric
----- Original Message ----
From: Dennis Sosnoski <[EMAIL PROTECTED]>
To:
[email protected]Sent: Tuesday, June 27, 2006 2:14:17 AM
Subject: [service-orientated-architecture] SOA and ESBs
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-ReliableMessagin g, and WS-AtomicTransactio ns 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
