I've been following this thread with some interest, as I've worked for a number of vendors with ESB offerings.
<your comments>
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.
one or more service platforms (e.g., .NET, a Java EE app server, etc.)
</your comments>
I'm curious to hear your position on .NET in terms of its proprietary standing & why you consider it one of the viable application platforms of choice.
cheers Luie
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
First, let's establish your meaning of the term "ESB". I assume that you are talking about a product. Examples include BEA AquaLogic SB, Cape Clear ESB, Fiorano ESB, IBM WebSphere ESB, IBM WebSphere Process Server, IBM WebSphere Message Broker, IONA Artix, Oracle ESB, Software AG crossvision, Sonic ESB, Tibco BusinessWorks, and webMethodsFabric. Also, open source projects: ServiceMix, Mule, Celtix, etc.You are not referring to what IBM first termed "an architectural pattern". And you are not referring to a multi-product services infrastructure organizations build to support SOA initiatives.
I do not believe that an ESB is an essential component of SOA. When it comes right down to it, you don't need any new products to do SOA. After all, SOA is about design, not technology. Nonetheless, products can be very useful, and I recommend buying at least a few basic components to get started.
The vendor hype surrounding ESBs has been very effective -- you'd be amazed how many requests I get from my clients for help selecting an ESB. But then, organizations frequently want a quick-fix solution. The vendors (and many analysts) are telling them that an ESB is all you need to get "instant SOA", or at the very least, that its an essential component.
But an ESB is not on my list if the few "basic components" that I recommend for getting started with SOA. In fact, I discourage people from starting with an ESB. An ESB does not encourage good SOA behavior. ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos.
In my book, the basic components include:As you say, an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure. Many ESBs also support reliable messaging, asynchronous messaging, and pub/sub exchange patterns. These capabilities can also be pretty useful--but probably not in the initial stages of a SOA project. (Every organization has lots of projects to choose from that don't require these capabilities.) At a later stage in a SOA project, you might also want an orchestration engine, and most ESBs supply one--but that definitely isn't where an organization should start a SOA initiative. All of these capabilities are things that you don't need when first getting started. Therefore an ESB should be a later-stage purchase.
- one or more service platforms (e.g., .NET, a Java EE app server, etc.)
- a SOA management solution (e.g., AmberPoint, Actional, SOA Software)
- a registry ( e.g., Systinet, Infravio)
- an XML gateway if services will be exposed outside the firewall (e.g., IBM DataPower, Reactivity, Forum, Layer 7)
I also definitely don't recommend using an ESB as a central hub for all SOA traffic. You and I had a private discussion a couple of days ago wherein I suggested that all important message traffic should be mediated -- but it should not be mediated by an ESB. It should be mediated by XML gateways and/or SOA management agents. A mediation system should do ALL of the followingAn ESB can only handle the first two. XML gateways and SOA management agents can do all four. My preference for a mediation system is an XML gateway because it offers the added value of hardware acceleration. Although I recommend XML gateways as a basic component only when exposing services outside the firewall, that's only when discussing the initial configuration. When first getting started, I think SOA management is a more important infrastructure component, because you need the monitoring and visibility features that only a SOA management system offers. But as the SOA initiative progresses, I recommend using an XML gateway for mediation between services inside the firewall. (You'll still need SOA management to implement endpoint-based policy enforcement points, but XML gateways make better mediators.)
- virtualization of endpoints (enabling dynamic location, binding, routing, versioning, etc)
- transformations
- security mediation and enforcement of security policies
- monitoring, management, and control
Regarding this point: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.
The same can be said about all SOA infrastructure products. Lock-in is a fact of life. As soon as you implement anything, you're locking yourself into a product. I think it's better to lock yourself into a single product for configuration and management than to deal with dozens of different tools and procedures for configuration and management. That's the primary reason that I recommend using a SOA management system to implement endpoint policy enforcement points rather than using the inherent capabilities of a service platform. Centralized management and control is a good thing. The one caveat is that many ESBs are built on a proprietary MOM protocol, and you definitely need to be cautious about using proprietary protocols. Not only do they lock in the product for that specific service, they also force symmetric deployment of the proprietary protocol. Try to avoid using them.
AnneOn 6/27/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
Do you Yahoo!?
Yahoo! Music: Check out the gig guide for live music in your area __._,_.___
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.
