Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Anne Thomas Manes
    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,
    Message 1 of 70 , Jun 27, 2006
    • 0 Attachment
      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:
      • 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)
      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.

      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 following
      • virtualization of endpoints (enabling dynamic location, binding, routing, versioning, etc)
      • transformations
      • security mediation and enforcement of security policies
      • monitoring, management, and control
      An 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.)

      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.

      Anne

      On 6/27/06, Dennis Sosnoski <dms@...> 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


    • Luie Matthee
      ... Ok, the assumtion is the foresee word. ... Within reason. If the J2EE interfaces are exclusively used then I would argue that the lock in story is not
      Message 70 of 70 , Jul 2 10:54 PM
      • 0 Attachment
        > If you are developing applications that are to be deployed on a
        > Windows platform, and you don't foresee a need to port them to other
        > platforms, then .NET is certainly a viable platform.

        Ok, the assumtion is the "foresee" word.

        > As I said in my original response to Dennis, as soon as you implement
        > and deploy a solution, you've locked yourself into that platform --
        > whether it's IBM WebSphere, BEA WebLogic, JBoss JEMS, Sonic ESB,
        > webMethods Fabric, Sun SeeBeyond, Apache Axis, Spring, Struts,
        > Hibernate, or whatever. If you think that developing with Java somehow
        > gives you vendor and/or framework independence, you're deluding
        > yourself.

        Within reason.
        If the J2EE interfaces are exclusively used then I would argue that the
        lock in story is not appropriate.
        Using any non-public specification will create a lock in  scenario.
        I've worked on my projects that used JBoss in the dev & test environments. Then deployed into production on WebSphere.
        I also had a project that used JBoss for dev & test and built the application to run
        in production on WebSphere & WebLogic.

        > .NET is a comprehensive, easy-to-use, development framework -- far
        > easier than any Java-based counterpart. And it's certainly better
        > optimized for the Windows platform than any Java framework. It
        > performs better, and except for the most extreme cases, supports
        > comparable scalability. Why wouldn't it be viable?

        Not wanting to open a can of worms or debate the point.
        Yes .NET can be used as can any other technology.
        Just wanted to get an insight into your mind set on .NET.

        Thanks for your comments.

        cheers Luie


        On Yahoo!7
        360°: Your own space to share what you want with who you want!
      Your message has been successfully submitted and would be delivered to recipients shortly.