Re: UDDI

[Matthew MacKenzie <matt@xmlglobal.com>]

Waqar,

The API is still connected very closely to the information model in UDDI, so it
is easier to get a view of the
info model by looking at the flow of the API calls, for instance, do some
searches on uddi.microsoft.com and see how parts of the API show through.  I
know that there only a few basic structures used all though UDDI - the when and
how is the important part.

-Matt

Waqar Sadiq wrote:

> Matthew,
>
> >I will focus on the UDDI query API, mayve Waqar can look into the publish
> API.
>
> For the purpose of mapping, we need to focus on the information models and
> the underlying concepts and data structures rather than on API.  Once that
> mapping has finished, API's will be very easy.
>
> Thanks,
>
> Waqar Sadiq
>
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> Sent: Wednesday, November 22, 2000 5:22 PM
> To: Krishna Sankar
> Cc: ebxml-regrep@lists.ebxml.org
> Subject: Re: UDDI
>
> Krishna,
>
> I think that taking the approach of ebXML RR being an implementation
> agnostic
> interface to registry/repository services is definitely THE approach.  If
> the
> ObjectQueryManager was actually (in java parlance) an abstract class or an
> interface,
> it should be possible to link in any well thought out regrep
> implemementation.
>
> In the case of UDDI,  the "due diligence" needs to be done ASAP so that we
> can find
> out what RR doesn't support direct mapping to so that RR can offer
> abstractions for
> the currently unsupported functionality, and hopefully we will find areas
> for the UDDI
> folks to beef up on.
>
> I will focus on the UDDI query API, mayve Waqar can look into the publish
> API.
>
> Cheers, Happy Holidays to you Americans ;-D
>
> Matt
>
> Krishna Sankar wrote:
>
> > Matt/Waqar,
> >
> >         Yep, designing interoperability as services is my choice. As Waqar
> pointed
> > out, first we need the two-way mapping and then provide these services
> which
> > reflect the mapping.
> >
> > <soapbox>
> >
> >         Knowing what we know now (;=]) there will be at least two registry
> > specifications - UDDI and the ebXML regrep. There could be more in the
> way.
> > Also we already have clients popping up from various vendors - Bow, IBM,
> MS
> > et al. We have to assume that all the registry specifications are
> developed
> > by smart people (I know the regrep has smart folks ;-)) and so each will
> > have it's own advantages. Which means, clients would like to use *all* of
> > them for different purposes.
> >
> >         The ideal goal would be that the clients are registry agnostic -
> i.e. both
> > registries can handle both clients. So we need a UDDI personality service
> > layer for the ebXML regrep and an ebXML regrep personality layer/services
> > for the UDDI registry. Of course, the concept mapping will show the
> > translation capabilities, synergies and limitations (which could grow as
> > both the registries mature)
> >
> >         We sure need to map stuff like the classification in the regrep
> and the
> > IdentifierBag and CategoryBag in UDDI. I would like to see a deliberate
> > matching of API and the data structures so that we know which goes *where*
> > and *why*. Inevitably there will be gaps and some assumptions, which we
> can
> > clarify with the designers like Farrukh and Scott N.
> >
> >         Developing the services would involve working around the
> ebXML/SOAP issues
> > as well.
> >
> > </soapbox>
> >
> >         It will be worthwhile to start the UDDI-regrep concepts mapping
> and data
> > structure mapping so that we understand the similarities and differences.
> It
> > is possible this could raise uncomfortableness in some quarters, but we
> > cannot ignore the elephant(s) in the room ! If we can get a first cut by
> the
> > first week of December, this would help us at the press conference as
> well.
> > The UDDI Vs the RegRep question will be asked (by the press) and we need a
> > decent answer. I hope the answer is interoperability and co-operation.
> >
> >         Matt/Waqar, if you folks can do the due diligence at the mapping,
> I could
> > try developing the interoperable services layer. I am almost thinking of a
> > decorator pattern where the native pass-thru while the hosted calls get
> > translated and transformed.
> >
> >         On a related note, how would we know if a registry is UDDI ? The
> only way I
> > can think of is to send an ebXML message and if it throws out the message,
> > we know it is an UDDI registry !
> >
> >         cheers and have a Happy Thanksgiving
> >
> > -----Original Message-----
> > From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> > Sent: Wednesday, November 22, 2000 1:17 PM
> > To: Krishna Sankar
> > Cc: ebxml-regrep@lists.ebxml.org
> > Subject: Re: UDDI
> >
> > Krishna,
> >
> > I propose that the UDDI functionality be implemented as a service unto
> > itself, just
> > like the ebxml regrep, via a new ServiceInterface.  Is that going in the
> > wrong
> > direction?  I would be hesitant to map existant ebxml regrep actions
> > directly to UDDI,
> > because the UDDI API is well defined and scoped.  The ObjectQueryManager
> > ServiceInterface could be used with the addition of some UDDI specific
> > actions...
> >
> > Comments?
> >
> > -Matt
> >
> > Krishna Sankar wrote:
> >
> > > 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