Fwd: UDDI and ebXML

[Nicholas Kassem <Nick.Kassem@eng.sun.com>]

FYI in case you missed this. Nick.

>Date: Thu, 07 Sep 2000 12:24:42 -0700
>From: Klaus-Dieter Naujok <knaujok@pacbell.net>
>Subject: UDDI and ebXML
>To: ebXML General List <ebxml@lists.ebxml.org>
>Reply-to: Klaus-Dieter Naujok <knaujok@pacbell.net>
>X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;5)
>Priority: Normal
>List-Owner: <mailto:ebxml-help@lists.ebxml.org>
>List-Post: <mailto:ebxml@lists.ebxml.org>
>List-Subscribe: <mailto:ebxml-request@lists.ebxml.org?body=subscribe>
>List-Unsubscribe: <mailto:ebxml-request@lists.ebxml.org?body=unsubscribe>
>List-Archive: <http://lists.ebxml.org/archives/ebxml>
>List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-request@lists.ebxml.org?body=help>
>
>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