Recent articles appearing on-line about the future of B2B are focussing on UDDI and ebXML. The more I look into both these initiatives, the more it looks like they compete head-to-head. What are the opinions of other members here at TheServerSide.com?
Some Links about UDDI & ebXML:
This link covers UDDI concepts
This link covers ebXML
This link offers an opinion on both & was what triggered my reaction re competition between them....
My interest is in forming a strategy for the company I work for. This has involved attending a number of workshops on various aspects of XML.
ebXML is supported by groups and orgs (UN/CEFACT & Oasis)that have a very strong interest in EDI and coming up with a more universal EDI like capability based on XML (ebXML Framework).
UDDI is Microsoft & IBM & is being used by Ariba. Each of these entities has set up a UDDI Registry.
What I am trying to determine is do these two initiatives compete directly. or are they addressing two distinct opportunities.
Doug Marker - Technical Architect
ebXML/Oasis have recently agreed to integrate SOAP technology into its stack so it seems that they are co-operating and leveraging each other rather than competing no?
Soap appears to be a very small part of what UDDI & ebXML represent.
I believe there is goodness in the 2 initiatives adopting soap as the XML message wrapper.
I guess the question is though, do UDDI and ebXML have the same goals & if so are they addressing different segments of the same opportunity ?, or will they converge ?, or will one displace the other ?
Cheers - Doug Marker
It looks like ebXML may be the OS/2 of e-commerce architecture standards. ebXML looks more fully defined to address all the needs of e-commerce, based on the article you linked to, but there are implementations of UDDI and its associated web services architectures available right now (for example, IBM's web services toolkit), and the simplicity of UDDI makes it relatively easy to use. In contrast, I don't know where to start if I wanted design a system for ebXML.
More ominously (for ebXML) UDDI has marketing muscle behind it (IBM, MS and Ariba). Because of that, I know where to go to get toolkits, UDDI servers and tutorials. Whereas until today, ebXML was for me just another *XML standard that I figured I could ignore till it whacked me on the nose.
So, if it comes to direct competition between the two, ebXML may get "beaten" by UDDI's installed base and perceived ease of use. That said, there is plenty of OS/2 still out there . . .
That seems like a pretty good assesment. ebXML does look complicated. It supports Business Profiles and can register Business Logic for a company. The BL includes use cases and scenarios and these are supposed to be able to converted into logic using a UML format called UMM.
My interpretation of the above is that if company A wants to conduct transactions with company B, it can interrogate the BL & either buy 3rd party software that will support the defined transactions, or can generate the required logic (which includes Schemas & OOT app logic) to add to its own systems that will enable transacting with company A.
Also re IBM & UDDI, - ebXML is mostly designed by IBM. The VP of Oasis is the IBM scientist (based at T J Watson Research center) that did the core ebXML design.
UDDI was started after the ebXML initiative - could be just like you say - might be too complex. But it could be that UDDI will turn into ebXML in time ?
Cheers - Doug Marker
Maybe the two will end up serving different "tiers" of organizations. For example, the same enterprises that need the full J2EE range of EJB, JMS, etc will need ebXML. The smaller companies that satisfy their needs with servlets and JSP can satisfy their web service needs with the simpler UDDI and web services.
A lot of companies are focusing today on Web Services, a way to propose services on Internet and to call them using SOAP. UDDI is just a registry where companies can register, describe their business and the Web Services they propose. It's like the yellowPages, but specialized for Web Services. Moreover, UDDI does not provide a way to describe Web Services formally. This lack of formalization can lead to a real mess.
ebXML goes a lot further : its goal is to provide an global e-business infrastructure to enable companies of any size and any location to discover each other, discuss the terms of their collaboration, and conduct business by exchanging XML based messages. A part of this project consists of the definition of a global repository where companies can register, specify and store the business processes they support (with a formal description, including the ones of the Web Services used). The storage and discovery of the web services is the only part where the 2 projects are in competition (in fact IBM, Microsoft and Ariba conducted UDDI to accelerate the process of normalization leaded by UN/Cefact and OASIS).
So to answer your question : if you only need to propose Web Services : use UDDI. But if your goal is to conduct business with your partners on internet, define trading partners collaboration and formalize your business processes : wait for ebXML!
SOAP may not be enough to handle complex business
transactions. For example, SOAP needs other protocols to handle things like security and transactions.
ebXML is a much more fully featured spec that addresses many of these concerns.
The 'S' in SOAP stands for something - Simple. Its good for what it does, but little more.
Business must also decide on whether to implement business to business communication using RPC'ish communication (SOAP)
or more of a messaging paradigm.
RPC has the disadvantage of making clients block everytime
until a response comes back from their request.
With a messaging system, there is no blocking. The message can be sent, and listeners can be setup to notify the client when their ship has come in.
Anyone have any thoughts/opinions on this?
The impression I got of what SOAP does, is that it provides a 'wrapper' for XML documents, and the purpose of the wrapper was so the XML documents had a consistent way to be accessed, and handled as messages.
I understand that in order to pass an XML document from one location to another using HTTP, that there needs to be a recognised behavior and thus supporting capability for recognising and handling the XML document at each end. I saw the SOAP wrapper as that mechanism and SOAP standard as defining the rules.
The benefit of SOAP seems to be that an ordinary Web Server that has SOAP capability, can receive and handle an XML document - I may have this perception back-to-front as I haven't 'touched' any SOAP code & thus am trying to abstract my perception.
Cheers - Doug Marker
Yes J R .
A messaging system based on XML is inherently superior to RPC based protocols, from my point of view.
XML overcomes the limitations of message based interfaces (no extensibility, binary format etc) and keep the advantages: streaming, unlimited quantity of information in one only unit.
The interface definition is also simpler to define also with XML messages. It is necessary ONE only API: the XML DOM (perfectly defined) and a number of XML documents to interchange (perfectly definable,using XML xchema or DTDs)
An added extra feature which is not only desirable, but fundamental in the context of massive decoupled remote distributed systems (Web services): The XML interchange messages can be extended for the needs of some subset of clients and servers while the rest don´t have to modify inmediately their XML-DOM based packet access code.
That decoupling is a must in the Internet distributed scenario, as is non blocking, asyncronicity and streaming.
I wonder how ALL these features can be achieved by using old concepts like RPC based protocols (SOAP, RMI, CORBA, COM and so on).
See further discussion on SOAP_XML vs EJB in this same portal.
Alberto Gómez Corona. Ibermatica.