Fiorano and Sonic Release Enterprise Service Bus Products

Discussions

News: Fiorano and Sonic Release Enterprise Service Bus Products

  1. Long time MOM (message oriented middleware) vendors Sonic and Fiorano have both announced Enterprise Service Bus (ESB) platforms in the last few days. Sonic ESB 5 and Fiorano Tifosi 2002 ESB are integration brokers that support building of orchestrated business processes that integrate via web services, JMS, and other protocols.

    Links:
    Fiorano 2002 ESB and press release.
    Sonic ESB 5 and press release.

    The ESB is a new type of middleware that has gained a lot of press and attention this past year According to Sonic, ESBs are built upon 5 principles:

        1) Service-oriented architecture (SOA). ESBs implement a service-oriented architecture (SOA), supporting service-based interactions among cooperating applications based on XML messages and enhanced Web services standards. This allows interactions between departments, business units, or with business partners to be defined in coarse-grained business terms, rather than in complex and brittle application interfaces. As a result, ESBs can accommodate and absorb significant change in the implementation details of individual applications or services connected to the bus.

        2) Enterprise-grade communications backbone. ESBs must provide an enterprise-grade communications backbone required to reliably connect applications across multiple geographic, administrative or security domains, based on the Java(TM) Message Server (JMS(TM)) standard.

        3) Support for standards. By supporting standard methods and mechanisms to develop and interconnect applications across the enterprise, such as WSDL, SOAP, JMS and J2EE-CA, ESBs dramatically reduce the implementation time and total cost of ownership of integration projects.

        4) Intelligent routing. ESBs automate business transaction routing based on XML document contents and business rules. This eliminates the need to hardcode this functionality into application code or establish rigid relationships between services.

        5) Deployment flexibility and distributed management. ESBs provide the ability to centrally configure, deploy, and manage services that are distributed across the enterprise. Unlike centralized, monolithic application server or integration broker architectures, ESB's allow for optimal flexibility, and further allow services to be managed and scaled independently of each other for operational efficiency. Location transparency allows services to be upgraded, moved, or replaced without having to modify any application code.

    Threaded Messages (14)

  2. When I am discussing ESB architecture (as a functional wrapper around WS), first rule of distributed programming formulated by Marin Fowler always comes to my mind: "Don’t distribute". Paraphrasing one of the latest articles by Fowler: "…when I see transparent service location in architecture presented to me, I’m always struggling with two choices: stand up and walk out or stay and spend a huge amount of time trying to explain why this approach is fundamentally flawed".

    Although this may be a little bit opinionated, this shows great divide in perception of middleware infrastructures that are implicitly “forcing” location transparency for distributed services for *any* system development.

    Many times I have come across the opinion, which I personally share, that ESB is essentially the infrastructure for WS that adds necessary plumbing for enterprise WS-based development. Since WS are mostly meant for external integration, the location transparency and associated performance problems will not have a significant affect on WS which are already expected to be slow by definition.

    Thanks!
    Nikita Ivanov
    Fitech Labs, Inc.
  3. \Ivanov\
    Although this may be a little bit opinionated, this shows great divide in perception of middleware infrastructures that are implicitly “forcing” location transparency for distributed services for *any* system development.
    \Ivanov\

    I think there are alot of advantages to such transparency. The only time it gets you into trouble is when the network aspect is completely hidden and developers are taking big performance hits or unwittingly introducing points of failure into the their system without realizing it.

    As for Fowler's views on it - IMHO he oversimplifies most issues too much for my taste.

        -Mike
  4. <Nikita>
    Paraphrasing one of the latest articles by Fowler: "…when I see transparent service location in architecture presented to me, I’m always struggling with two choices: stand up and walk out or stay and spend a huge amount of time trying to explain why this approach is fundamentally flawed".
    <\Nikita>

    I struggle to understand where Fowler is coming from here. Distributed architectures are a primary mechanism for addressing scalability. As the demands on your system grow you add capacity in the form of additional boxes with the load shared by the components deployed on that box. (The alternative to this is to add processors but Amdahl's law shows that there are diminishing returns from that approach).

    The goal for the architect is to construct a flexible system that allows you to seamlessly add new capacity. The obvious way to do this is with "transparent service location". The alternative is to hardwire locations in and have to rewire the system everytime you add capacity - a brittle and unattractive architecture.

    Steve
  5. Recently Fowler also recently advocated hard coding as much as possible in code - with an example hard-coding discount structures in the Java code itself, and changing the code if the discount structure changes.

    Personally I find about half of what he advocates extremely reasonable and excellent advice. The other half seems to be driven by his need to publish, to illuminate the latest idea he's behind (XP in this case), and to drive business to his company.

    Sorry to be so blunt in this sort of forum, but I think he takes his role as a "luminary" in the industry a bit too seriously at time, and unfortunately others take everything he commits to pen or bits as gospel.

        -Mike
  6. I found the recent Fowler article on "Errant Architecture" which is an extract from his book on enterprise patterns. The link is below (requires registration at CMP)

    http://www.sdmagazine.com/documents/s=7897/sdm0304a/sdm0304a.htm?temp=src8Ub4XpT

    His thesis is that taking a fine-grained object model and distributing gratutiously will be bad for your health and if you are doing that for reasons of performance then you will fail. I'm suprised that this merits saying in an article/book but can only trust that he has clients who erroneously try this.

    However, this thread originally started on a discussion of Enterprise *Service* Buses - ie products which enable integration in the context of a service oriented architecture. With SOAs we are talking about coarse-grained, loosley-coupled architectures with documents typically being passed between services using asynchronous messaging.

    Fowler seems to ignored the SOA evolution and assumes that we are all doing distribution of a sea of fine-grained and tightly-coupled objects. I also suspect that his views on the cost of distribution are out of date. 1Gb ethernet and switch-based networks that typically run between servers these days have dropped the cost of distributed computing. In many solutions the cost of accessing disk dwarfs the remote service invocation.

    Steve
  7. <press>
    Service-oriented architecture (SOA). ESBs implement a service-oriented architecture (SOA), supporting service-based interactions among cooperating applications based on XML messages and enhanced Web services standards. This allows interactions between departments, business units, or with business partners to be defined in coarse-grained business terms, rather than in complex and brittle application interfaces.
    </press>

    Isn't BPEL4WS and WS-Coordination/WS-Transaction the set of standards offered for supporting interactions among services based on XML? Is there a problem solved better by proprietary routing that cannot be solved by BPEL?

    Cheers.

    Jill.
  8. ESB vs. BPEL4WS[ Go to top ]

    Hi Jill,
    I think ESB solves different problem or rather “sits” on a different level. ESB does not provide generic business process modeling but rather provides necessary plumbing for effective usage of WS. Another point is that BPEL4WS as well its predecessors and derivatives (ebXML, BPML, XMDL, etc.) did not get a wide acceptance because they are perceived as way too general and provide little incentives to follow actual standards.

    Regards,
    Nikita Ivanov.
    Fitech Labs, Inc.
  9. BPEL4WS or not BPEL4WS[ Go to top ]

    Nikita,

    As a BPEL vendor, our view is obviously biased but I would still like to disagree: the advent of message driven interactions is driving the need for workflow ( = logic that coordinate what messages are sent and received, what to do when exceptions occur, how to undo part of a flow (compensate), etc...).

    The proof of that is that every messaging/integration broker offer some type of workflow tool. Most are proprietary.

    BPEL4WS is emerging as one of the standards for orchestration: providing developers with a standard set of constructs for modeling flow and interweaving services into long-running business processes.

    Standards are powerful: Who remembers Culinet? They were the dominant DB vendor of the pre-SQL era. Standards are important for developers because it allows you to resell your skills across projects/jobs.

    As a developer, you will soon have to deal with web services, asynchronous conversations and flow. At that point you have 4 options:
    1) Build a homegrown mini-workflow engine as part of your application.
    2) Learn the proprietary tools offered by the Sonic's of the world
    3) Pick WSCI + BPML
    4) Pick BPEL4WS

    Edwin
  10. BPEL4WS or not BPEL4WS[ Go to top ]

    Hi Edwin,
    Agree with most of your points. My last post was actually to reply on difference between ESB and BPEL-like specifications (which are quite different).

    When you running the company with BPEL4WS-based product your view and audience is definitely somewhat distorted (the same happens here at Fitech). I will still however reiterate my point that we have had ebXML long before and it did not materialize as much as we hoped, and, although, BPEL now rides WS wave, I think it will take couple more years or more to get it more mainstream for developers and more important for business people to understand (with the help of companies such as yours).

    Most of customers we have talked to, that indeed use or plan to use WS, are still struggling with the basics of WS and technologies like ESB can provide necessary enterprise augmentation to SOAP/WSDL/UDDI implementations. And of course, standards do matter, but only small fraction of standards do get up on top and survive over the significant stretch of time, and that is a surely complicated process.

    Good luck!
    Nikita Ivanov.
    Fitech Labs, Inc.
  11. BPEL4WS or not BPEL4WS[ Go to top ]

    Infoworld and CNET just announced that IBM, Microsoft and BEA as planning to submit BPEL to OASIS. If this ends up being true then it will accelerate the adoption of BPEL and in turn increase the demand for ESB. I do not think that BPEL will suffer from the same problem ebXML did (over complexity): the reality is that is you are coordinating interactions on top of a bus then you need workflow.

    My point is that the adoption of ESB and orchestration standard are linked: one without the other is useless and the vendors like Sonic combine a standard based bus with a proprietary flow engine. The end result is that they do not really deliver the promise of standards because the customer ends up being locked in the flow layer :-(

    Time will tell if BPEL is another ebXML or another SQL!

    Thanks!

    Edwin
  12. EAI/ESB?[ Go to top ]

    I find it humorous that you are saying Sonic isn’t standard because it doesn’t support a standard that hasn’t seen widespread use yet.

    I think we can all agree that the whole BPM area is still very young.

    So many of these higher level web services APIs are still pretty much vapor at this point. PDF doesn’t compile.

    It will be interesting to watch the ESB market grow. I think it has a lot of potential for a more standards based integration approach.

    What are people’s opinions in comparing ESB to classic EAI (ala webMethods)? I know that you can do anything you want with either approach (at least that is what the vendors will tell you), but practically speaking what approach would you take if you could buy one?

    The relative openness of the ESB approach appeals to me because a single vendor doesn’t own you the way one would with 1 EAI tool. It appears that you can take a “best of breed” approach. Pick an ESB, pick adapters that you need (or just write them yourself), when the BPM picture is more clear, pick an XML based BPM engine, etc.
  13. Kick the vapor[ Go to top ]

    <michael>
    I think we can all agree that the whole BPM area is still very young. So many of these higher level web services APIs are still pretty much vapor at this point. PDF doesn’t compile.
    </michael>

    The area is indeed young. If you are an early adapter, you might what to kick the tires and see how BPEL4WS compiles.

    Edwin
  14. BPEL4WS or not BPEL4WS[ Go to top ]

    <Nikita>
    Most of customers we have talked to, that indeed use or plan to use WS, are still struggling with the basics of WS and technologies like ESB can provide necessary enterprise augmentation to SOAP/WSDL/UDDI implementations. And of course, standards do matter, but only small fraction of standards do get up on top and survive over the significant stretch of time, and that is a surely complicated process.
    </nikita>

    I am lost as to what ESB can help customers with. Once customers publish Web services using SOAP/WSDL, etc, isn't the next step being orchestration of these Web services into business flows? If an ESB product does not support BPEL4WS to do that, what does it support then?

    Cheers.

    Jill.
  15. It's hemped up MOM[ Go to top ]

    Standard reliable messaging stuff ... HTTP isn't the best at guaranteed delivery, only once delivery, store forward, etc.