[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [uddi-spec-comment] RE: [ebxml-dev] UDDI vs ebXML RIM/RSS andconvergence..
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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]