RE: UDDI

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

Sorry for the delay in this email.  I needed to discuss this with the ebXML
Steering Committee to get an official response. 

The response is that ebXML Registry Project Team cannot afford to spend any
time on this subject until our specifications are in approval status for
v1.0.  Some vendors by course of nature may consider mapping UDDI to ebXML
and may have a vested interest in doing so.  Any such effort is not to
disrupt the deliverables for ebXML at this time, as the UDDI/ebXML mapping
involves more than just the ebXML Registry, but a combination of Registry,
Trading Partner, and Business Process Project teams efforts.   At some time
there will be either a convergence, or mappings to support interoperable
registries.

====

As Project Team leader for the ebXML Registry I will go on the record that I
am truly disappointed of the UDDI announcement, which I personally feel grew
out of the disbelief that ebXML would be able to deliver any specifications
at all.  Reference the misinformation from Gartner:
http://www.ebxml.org/project_teams/registry/private/gartner_ebxml_19991203.p
df

Maybe we (ebXML) just did this to ourselves by making our draft documents
publically available.  I am just disappointed that when we asked parties to
participate, they did not come to the table but perhaps just monitored our
lists.

Regards,

Scott

-----Original Message-----
From: Waqar Sadiq [mailto:wsadiq@vitria.com]
Sent: Monday, November 27, 2000 11:06 AM
To: 'Nieman, Scott'
Cc: 'ebxml-regrep@lists.ebxml.org '
Subject: RE: UDDI



Scott,

I can understand your position about where this group should be focusing
their time on.  If that is the official position, then that is ok.  The
purpose of my original mail was not to start an official activity but rather
have people with common interest in both specifications spend some cycles on
this exercise.  

I disagree with your assessment of the differences between the 2
specifications.  I think that the differences go beyond taxonomies.  Infact,
I would say that probably none of the concepts map cleanly to each other.
One purpose of a mapping exercise is to reveal those differences.    

Thanks,

Waqar Sadiq

-----Original Message-----
From: Nieman, Scott [mailto:Scott.Nieman@NorstanConsulting.com]
Sent: Sunday, November 26, 2000 10:28 AM
To: 'Matthew MacKenzie '; 'Waqar Sadiq '
Cc: 'Krishna Sankar '; 'ebxml-regrep@lists.ebxml.org '
Subject: RE: UDDI


The fundamental difference is that the ebXML registry information does not
have specific classifications.  UDDI.find_business() can be mapped directly
to ebXML.getClassifiedObjects(Business) IF AND ONLY IF there is a
classification available that describes business discovery.  

This is the major difference.  ebXML RR does not describe the necessary
taxomonies, only provides the infrastructure to enable the support of ANY
classification, and multiple ones at that.  

From a time to market point of view, I do not want RR to engage in a dialog
regarding UDDI to ebXML mappings UNTIL the other ebXML project teams deliver
the necessary classifications to support tp discovery, description of
collaborative business processes, core components, etc.  Otherwise this puts
an UNNECESSARY dependency on RR which spells disaster to me.  I believe that
when these classifications are available, and if this is to become a RR work
item, it would likely require steering committee approval or assignment
since it may overlap with other project teams.

btw, I know that there is effort going on in the BP project team regarding
this mapping (talk to Antoine of Mega International).  So if your passion is
this mapping, please don't duplicate efforts.

Scott

-----Original Message-----
From: Matthew MacKenzie
To: Waqar Sadiq
Cc: Krishna Sankar; ebxml-regrep@lists.ebxml.org
Sent: 11/22/00 6:06 PM
Subject: Re: UDDI

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