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

SOA and ESBs

Expand Messages
  • Dennis Sosnoski
    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
    Message 1 of 70 , Jun 26, 2006
    • 0 Attachment
      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.