RE: UDDI

[Krishna Sankar <ksankar@cisco.com>]

Hi,

	For the Vancouver POC, I have proposed and if it get approved, plan to work
on an interoperable suit for UDDI and ebXML Registry. We have some interest
from Scott H of IBM as well.

	The idea is to demonstrate a two way interoperability - UDDI client using
the ebXMl RegRep and an ebXML Registry client using the UDDI registry. This
exercise will bring out the synergies and differences between the two as
well.

	my 2 yens !

	cheers

-----Original Message-----
From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
Sent: Wednesday, November 22, 2000 1:05 PM
To: Waqar Sadiq
Cc: 'ebxml-regrep@lists.ebxml.org'
Subject: Re:


Waqar,

We have been playing with UDDI since it became public, and just a few days
ago
I suggested internally at XMLGlobal that bridging UDDI to ebXML would be
relatively trivial assuming that the UDDI registry is complete, which it is
(test.uddi.microsft.com).  All that would have to be done is to build an
object
sort of like
the ObjectQueryManager object that this group has specified, except into
would
be called UDDIQueryManager, and it's methods or actions would correspond to
the
UDDI find and store methods, such as find_business, store_Tmodel, etceteras.
This object would accept payload and invocation requests over ebXML TRP, and
dispatch the queries on the UDDI registry either remotely with SOAP, or
locally
with a client library, and send the response back using TRP.

example query and response:


Content-Type: multipart/related; version=1.0; boundary=**bound**
Content-Length: 2286

--**bound**
Content-Type: application/vnd.eb+xml; version=1.0
Content-Description: ebxmlHeader
Content-ID: 0
Content-Length: 1466

<?xml version="1.0" encoding="UTF-8"?>
<ebXMLHeader MessageType="Normal"
   Version="1.0">
   <Manifest>
      <DocumentReference>
         <DocumentLabel>find_binding_req</DocumentLabel>
         ...
     </DocumentReference>
    </Manifest>
    ...
    <TPAInfo>
        <ServiceInterface>UDDIQueryManager</ServiceInterface>
        <Action>find_binding</Action>
    </TPAInfo>
    ...
  </ebXMLHeader>

--**bound**
Content-Type: application/xml; version=1.0
Content-Description: find_binding_Req
Content-ID: 1
Content-Length: 324

<find_binding serviceKey="uuid" generic="1.0" maxRows="99"
xmlns="urn:uddi-org:api">
   <findQualifiers/>
</find_binding>
--**bound**--

... and the response would have the uddi response XML body in the payload.
It
may make sense to modify the ObjectQueryManager to handle UDDI requests
internally to itself, I am more partial to simply bridging ebxml and UDDI
right
now.  The UDDI API is very straight forward and is very useful for discovery
of
trading partners and processes.  I saw a really neat demo at the UDDI
workshop
in Redmond of UDDI integration with a procurement app (Great Plains) that
made
good use of this API and registry, I very much hope that we can work the
UDDI efforts into ebXML, and would be willing to elaborate further toward
that
end.

Cheers,

Matt

Waqar Sadiq wrote:

> Hi All,
>
> I know that their is an effort going on in the transport team to map ebXML
> transport layer to other protocols.  I feel that a similar effort in the
> RegRep team may be a worthwhile effort.  More specifically, I think that
we
> should try to map ebXML to UDDI.  I wouldn't be surprised if some members
> have already gone through that effort and in that case sharing of the
> results would be great.
>
> I realize that everybody is pretty busy with other more core issues.
> However, I personally feel that UDDI and ebXML will both survive alongside
> each other and a mapping will strengthen the two specifications.  It will
> also reveal conflicts between the two standards sooner than later.
> Currently both specifications are in the process of being defined and they
> can be changed to align with each other.  Later on, it will be difficult.
>
> While ebXML defines a UML based information model, UDDI does not define
such
> a model.  So if we decide to undertake this, I will be perfectly happy to
> construct and provide the UDDI model.
>
> Thanks,
>
> Waqar Sadiq