Discussions

XML & Web services: What value ebXML adds to SOAP ?

  1. What value ebXML adds to SOAP ? (2 messages)

    I am not sure that this is the right Forum but it looks as the most appropriate on TheServerSide.
    Ed Roman and others talked a lot about Web Services on JavaOne and always mentioned ebXML placed on the top of SOAP. What value does it add ? Is ebXML = SOAP+Attachments ( multiple MIME types ) or will it be soon or how it relates now and in the future to SOAP? I have some impression about SOAP ( thanks to Ed and JavaOne )but do not know much about ebXML except it is a sort-of-standard in financial industry.
    I've also heard that Microsoft "disagrees" with ebXML. What does it mean in particular for Web Services technology ?

    Thank you for your time and attention.
    -Michael Poulin
  2. ebXML is the business protocol and SOAP is the communication protocol. ebXML is based on typical business activities (sales, marketing, procurement). SOAP is about systems architecture (remote services calls etc.). Microsoft disagree with ebXML, because it has their own standard and software called BizTalk which is part of the .Net strategy.

    Please correct me, if I'm wrong.

    Regards

    Wojtek
  3. What value ebXML adds to SOAP ?[ Go to top ]

    To learn more about ebXML I would suggest that you visit the ebxml site which is at www.ebXML.org

    ebXML stands for Electronic Business XML.

    ebXML as an organization is sponsored by the United Nations center for international trade facilitation UN/CEFACT and the Organization for the advancement of structured information standards (OASIS, www.oasis-open.org).

    In terms of technology, ebXML is just an umbrella term for a whole set of technical specifications each of which is designed to target a particular area for the enablement of electronic business. For the complete list of technical specifications, check the site. However here is a brief introduction to some of the most important ones, then I'll try to clarify some of the misconceptions from the orginal post and Wojtek's follow up:

    Major ebXML technical specs:

    Business Process Specification
    Registry Information Model
    Registry Services Specification
    Collaboration Protocol Profile and Agreement
    Message Service Specification

    In Addition to the technical specs, there are also some important technical reports, particularly:
    Catalog of Common Business Processes
    Core Component Overview
    Core Component Discovery and Analysis
    Core Component Dictionary & Structure (two seperate reports)

    That having been said, let me now address the misconceptions in the other two posts:

    First, Michael Poulin asks what value does ebXML add?

    The answer is that ebXML adds value at all levels so you have to talk about each one individually.

    First, let's talk about registries and repositories:

    One big value that ebXML adds is that ANY individual or organization can operation their OWN ebXML registry/repository and those reg/reps can be EITHER public or private depending on how the operator wants to set it up.

    This is in stark contrast to UDDI which are purely PUBLIC registries and if you want to operate a UDDI registry, you have to get permission for MS, IBM, and Ariba.

    MS, IBM, and Ariba CLAIM that they will eventually hand over UDDI to a standards organization but the have not identified the organization nor have they said when the handover will happen. Originally it was supposed to be after V2, but who know when now.

    The second big VALUE that ebXML reg/reps offer vs. UDDI is that the ebXML reg/rep makes it possible for anyone to define their own classification schemas. In other words, ebXML allows you to INNOVATE. In UDDI, you are stuck with the three classification schemas that they give you.

    As an example, there was an interesting demo at the JAXR booth that showed an ebXML registry operating on top of a UDDI registry. As a result, the ebXML registry allowed you to do "smart" searching on top of the UDDI data by defining meta-geographical classification schemas. So, using the ebXML registry, you could say "Give me all the car manufacturers in Asia" and you would get a list of car manufactures from all of the countries typically thought of as being isn "Asia." Using the UDDI registry alone, you would have had to have gone individually into each country in Asia and queried for auto manufacturers.

    Now let's talk about the Messaging Service Specification.
    There was an ebXML group called Transportation, Routing, and Packaging that was responsible for developing a Message Handing Service. This specification is based on SOAP 1.1 w/Attachments.

    However, the ebXML TRP MHS spec also adds a lot of stuff on top of SOAP that you need in order to do RELIABLE messaging. So, for example, if you want to do non-repudiation using ebXML TRP MHS, you can do it. If you try to do it just using SOAP, then you have to roll your own non-repudiation mechanism and then what happens to your interoperability?

    Interestingly enough, Microsoft eventually realized the limilations of SOAP so they then came out with SOAP Routing and Packaging (SOAP-RP) that tries to match some of the features of ebXML TRP MHS. In developing SOAP-RP, however, M$ BROKE their own SOAP extentions mechanism. Jeesh!!

    I could go on, but hopefully you can start to get the picture.

    When thinking about ebXML vs. M$, you are confonted with all of the traditional dilemmas vis-a-vis M$:

    ebXML is an OPEN, International, standard.

    M$ continues to be closed and proprietary and then seeks use the market power to create a defact standard and then to foist their work on to the world by writing Notes to the W3C.

    If you go with the OPEN standard, then the specs get written first and the implementations come later, but with much great interoperability.

    If you go with the closed proprietary MS approach, then they do an implementation first which you get to playwith and help them debug right away. Then they try to write a spec and sponsor and interoperability forum to try and get their own internal implementations to work together, let alone work with those of other vendors that were written according to the released spec. Lastly, they realize that their first version was brain dead and lacked security so they put out a new version which then breaks all the "standards" of the orginal version and you have to re-write everything you did with those cool tools that they gave right away.

    Hope that helps clear things up.

    best regards

    P Kady