Re: UDDI to ebXML RR mapping

[Matthew MacKenzie <matt@xmlglobal.com>]

Waqar,

I think that mapping UDDI to RR may present some headaches, that is why
I suggested just bridging UDDI to ebXML.  The headaches I forsee are related to
the fact that UDDI uses very specific methods, like
find_business, where RR uses more vague methods, such as
getClassifiedObjects().  In other words, RR is abstract and UDDI is not.

It should be interesting to see how this plays out.

-Matt


Waqar Sadiq wrote:

> Matthew,
>
> This is great.  I was thinking more about mapping basic UDDI concepts to the
> equivalent RR concepts.  Just as an example, what in RR would map to a
> tModel and so forth. I think it would be useful to make a list of concepts
> from both specifications and then map them to each other, concept by concept
> and attribute by attribute.  In the end, it would be great to be able to
> implement UDDI model on top of ebXML model.
>
> Thanks,
>
> Waqar
>
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> Sent: Wednesday, November 22, 2000 3: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