UDDI and ebXML

[Klaus-Dieter Naujok <knaujok@pacbell.net>]

By now most of you have seen the announcement about UDDI. Many of
you have posted responses and questions to the announcement. The
most pressing question is how does it relate to ebXML.

Having spend the last 36 hours in talking to some of you, as well
as getting guidance from my executive members and project team
leads let me pass on what my view is in regard to UDDI.

First, it is a very positive sign confirming that our efforts are
on the right track. With many of our own participants joining the
project, UDDI will hopefully move from the proprietary solution
towards a open specification and at the same time ensure
interoperability with ebXML.

In regard how does it relate to our own work. Many of you may not
be aware of it, but our Business Process and Register & Repository
Team had right from the start in their work plan Trading Partner
registration and discovery. Because of previous work done by
CommerceNet in this area they did not spend much time on the
topic. This created the impression that this was not an ebXML
deliverable. You may recall that our main goal is not to reinvent
the wheel and instead use work that fits our requirements and
needs. Therefore the plan was to use the eCo specification
(http://eco.commerce.net/rsrc/index.cfm) instead of developing our
own. Having talked to the BP and RR team leads this was
reconfirmed to me again today.

So where does that leave UDDI and ebXML? In my view ebXML should
continue with its plan to use the eCo specification since it is a
open specification and fits our needs. Further, it never hurts to
take a look at other work in order to reconfirm what one is
currently doing. Adopting UDDI at this stage is premature since
there has not been an offer to make this an open specification,
this is planned for much later. Further, UDDI sits on top of SOAP
and utilize 30 SOAP type messages for querying, requesting and
receiving information. Yes, it is true that the services
identified by the trading partner can be of any type, including
ebXML. However, one needs to interface to the register in order to
use it, and that will require to use SOAP and the UDDI SOAP type
messages. Therefore, instead of ebXML changing its specification
to be UDDI compliant I see a benefit for UDDI to ensure ebXML
interoperability as their first step towards a truly open
development effort.

In closing, I don't see that with the UDDI announcement our game
plan needs to change. There will always be initiatives that may
create overlap because companies can't wait for standardization to
finish. In a perfect world those efforts would ensure
interoperability.  Knowing that many of our own participants have
joint UDDI in an effort to ensure openness and interoperability, I
am convinced that over time UDDI will be a tool ebXML implementers
can utilize.

Regards,

Klaus

--
Klaus-Dieter Naujok                                ebXML Chair
Antioch, CA USA                                +1.925.759.1670

PGP Finger: 6A4B 1683 CD99 E7BE F855  CC2F 4569 6BD8 76BD 1117