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
Powered by
eList eXpress LLC