[uddi-spec-comment] Re: [ebxml-dev] UDDI vs ebXML RIM/RSS andconvergence..

[Chiusano Joseph <chiusano_joseph@bah.com>]

Great points Steve. I should also add that the UDDI TC has been working
on at least one paper to address the representation of objects
registered in an ebXML Registry within a UDDI Registry - that is, to
provide a tModel (speaking very generally) which references a CPP, CPA,
Business Process definition, etc.  I will defer to the UDDI TC folks to
provide more information on this paper.

As to supporting federated queries: There is probably nothing stopping
anyone from building a sort of "query gateway" that can query for an
entity (using very high-level terms here) that *may* exist in either a
UDDI Registry or an ebXML Registry, but the querying agent has no
advance knowledge of which it resides in. I think that could be very
useful.

Something else that could be useful would be a "replication gateway" in
which contents could be replicated between the registries (or perhaps
transferred from one to the other) in an efficient manner.  

Kind Regards,
Joe Chiusano

Steve Capell wrote:
> 
> Joseph,
> 
> Thank you for your comments - particularly the information on UDDI v3.0
> capabilities (I clearly need to read more on UDDI v3.0).
> 
> I'd say that the analogy is less like the car and more like the basic
> user interface of the car - they all have a steering wheel, gearshift,
> brake & accelerator.  I suspect a joystick driven car might not be very
> successful in the marketplace - no matter how much fun to drive...
> 
> It seems to me that there is not much impetus to merge these
> specifications.  I guess we can live with that if interoperability
> between registries is addressed.  The replication & federation models of
> UDDI and ebXML RIM/RSS is one area that could usefully be the focus of
> some work aimed at providing interoperability.
> 
> If UDDI and ebXML can't exchange data & support federated queries then
> the analogy would be like having an internet with two incompatible DNS
> systems - one is almost bound to fail.
> 
> Regards,
> 
> Steve Capell
> RedWahoo
> Sydney, Australia
> Tel : +61 410 437854
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Sunday, 16 March 2003 12:23 PM
> To: Steve Capell
> Cc: 'Ebxml-Dev@Lists. Ebxml. Org'; ebxml-mktg@lists.ebxml.org;
> regrep-comment@lists.oasis-open.org;
> uddi-spec-comment@lists.oasis-open.org
> Subject: Re: [ebxml-dev] UDDI vs ebXML RIM/RSS and convergence..
> 
> Steve,
> 
> Thanks for your information. I agree that the V3 versions of both
> specifications bring them closer together in terms of functionality than
> ever before. Please see comments below.
> 
> <Quote1>
> ebXML v3 additionally supports the very important concepts of
> associations, cataloging & validation, notifications, and a much more
> powerful security & data model. </Quote1>
> 
> Associations: In UDDI V3, the "keyReference" element is used to describe
> relationships (the UDDI equivalent term for associations).
> 
> Cataloging & validation: Not sure what you mean by this (unless you're
> referring to the fact that the RegistryObject class provides
> catalog-type metadata for RepositoryItems). Also not sure what you mean
> by validation (very broad term).
> 
> Notifications: UDDI V3 has a Subscription API which provides
> notification features.
> 
> Security and Data Model: Not sure what a "powerful data model" means. I
> believe that ebXML Registry's data model is much more "extensive" (in
> terms of the number of structures) due to its more abstract nature, as
> well as its intended usage not only in discovery (which is UDDI's
> focus), but collaboration as well.
> 
> <Quote2>
> Given these facts, it seems to me that UDDI and ebXML RIM/RSS could
> converge very quickly if ebXML v3.0 provided a fully compliant UDDI
> "subset" - including the query & update service syntax. </Quote2>
> 
> What do you feel would be a good reason for such a convergence to occur?
> Don't markets favor multiple approaches/products in a space?
> 
> <Quote3>
> Wouldn't it then be a no-brainer for OASIS to announce "WS-Reg" v1.0
> which would essentially be an ebXML RIM/RSS v3.0 with a fully compliant
> UDDI v3.0 "embedded"? </Quote3>
> 
> Hmmm....if it were, it probably would have happened already.
> 
> <Quote4>
> Then "WS-Reg" v2.0 could deprecate any duplicate query / update service
> syntax so that there is truly one regsitry model. </Quote4>
> 
> What if there were one true car model?
> 
> <Quote5>
> My gut tells me that the commercial weight of IBM, Microsoft etc will
> drive UDDI forward and mean that ebXML RIM/RSS is the one that will
> suffer. </Quote5>
> 
> There will be a Best Practices paper coming soon from the ebXML Registry
> TC called "Registering Web Services in an ebXML Registry" (I have
> co-authored it). Hopefully, this paper will raise awareness of the
> capabilities of ebXML Registry to support the registration of Web
> services.
> 
> <Quote6>
> As a matter of interest, it was certainly much easier to map my
> "abstract data model" (representing the data model reguirements for my
> project) to ebXML than to UDDI.
> </Quote6>
> 
> Yes, which is no surprise. ebXML Registry is designed as an abstract
> data model.
> 
> Kind Regards,
> Joe Chiusano
> 
> Steve Capell wrote:
> >
> > To the OASIS "powers that be",
> >
> > I hope this e-mail is not too provocative but..
> >
> > I have spent the last few days getting "down & dirty" with both UDDI
> > and ebXML RIM/RSS.  Seems to me that UDDI v3.0 could almost be
> > regarded as a fully contained subset of ebXML v3.0 (draft
> > specification). ebXML supports the concept of organsiations,
> > classifications, service bindings, and replication (which basically
> > represents UDDI capabilty). ebXML v3 additionally supports the very
> > important concepts of associations, cataloging & validation,
> > notifications, and a much more powerful security & data model.
> >
> > I guess the differences are things like query syntax, etc.
> >
> > Given these facts, it seems to me that UDDI and ebXML RIM/RSS could
> > converge very quickly if ebXML v3.0 provided a fully compliant UDDI
> > "subset" - including the query & update service syntax.
> >
> > Wouldn't it then be a no-brainer for OASIS to announce "WS-Reg" v1.0
> > which would essentially be an ebXML RIM/RSS v3.0 with a fully
> > compliant UDDI v3.0 "embedded"?
> >
> > Then "WS-Reg" v2.0 could deprecate any duplicate query / update
> > service syntax so that there is truly one regsitry model.
> >
> > There is relatively little real use of either UDDI or ebXML RIM/RSS
> > today so it would not hurt too much to do this merger now.  Leave it
> > another year or two and there will be too much momentum behind one or
> > the other and one will die.  My gut tells me that the commercial
> > weight of IBM, Microsoft etc will drive UDDI forward and mean that
> > ebXML RIM/RSS is the one that will suffer.
> >
> > >From my perspective that would be a bad thing because I think that
> > >the
> > ebXML RIM/RSS specification is much better.  But then Betamax was
> > "better" than VHS....
> >
> > As a matter of interest, it was certainly much easier to map my
> > "abstract data model" (representing the data model reguirements for my
> > project) to ebXML than to UDDI.
> >
> > Regards,
> >
> > Steve Capell
> > RedWahoo
> > Sydney, Australia
> > Tel : +61 410 437854
> >
> > ----------------------------------------------------------------
> > The ebxml-dev list is sponsored by OASIS.
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebxml.org/ob/adm.pl>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard