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

[Steve Capell <steve.capell@redwahoo.com>]

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>