Re: [regrep] RE: [uddi-spec] ebXML Registry / UDDI Convergence

[Andrew Hately <hately@us.ibm.com>]

I'm not sure I see the need for a "super-standard".  There are several directory and registry protocols in existence that serve different purposes of integration.  A "super-standard" or one size fits all solution to registering data does not seem achievable to me.  The argument that all data typically ends up in one directory and registry does not hold in my opinion.  In every network, there are a number of registries and directories serving different purposes and we certainly cannot entertain merging them all into one abstract unfocused specification.  More concretely, consider that each operating system has some type of native registry, a DNS mechanism, an authentication directory or federation, a directory model file system and so forth. By analogy, I don't think theres a need to retrofit DNS to fit into a directory schema or vice versa.  Merging one or more classes of registry and direct!
ory to a single specification or even merging two specifications because they happen to be declared using XML constructs does not seem the most fruitful course when the models and purpose are different.

Perhaps the scope of these two registriy specifications have aligned more than I thought, but UDDI has been focused on externalizing most concepts through one conceptual mechanism, the tModel which links in external concepts, whereas ebXML has always struck me as a model where the concept itself would be modelled and internalized into the registry.  These two distinct approaches do not merge easily.  Initially, I would not support merging two models as the only technical argument I've seen has been posted by Christina Portillo and it illustrates that some areas that have not been considered in scope for UDDI.  The notions of asset, dependency, resource and namespace management and externalized transaction were not considered necessary to find and invoke a service.  Each of these notions may have relevance in the future of service discovery and electronic integration, but I don't think our first reaction should necessaril!
y be to introduce a variety of new concepts into UDDI or create a "super-standard" simply because they exist in other existing or developing registry specifications.  Some of the information posted by Christina alludes to some reasonable requirements that will help us guide or future work, but I would prefer to initiially examine the utility of these proposals rather than merge specifications with different models.

I believe the right first step has been suggested and is even underway which is the technical notes to discuss the interoperability and modeling effort noted by Anne, Joel and others.  This first step would at least delineate any perceived advantages of each specification and give us an idea of what is required to model the requisite registry information for services in at least the ebXML and UDDI environments.  If this effort illustrates distinct overlap or deficiency, we should proceed with that information to help guide future work for this group.


Andrew Hately
IBM Software Solutions and Strategy
UDDI Development, http://uddi.ibm.com/

Matthew MacKenzie <matt@xmlglobal.com> 09/27/2002 11:27 AM

To:        David RR Webber - XMLGlobal <Gnosis_@compuserve.com>         cc:        uddi-spec@lists.oasis-open.org, regrep@lists.oasis-open.org         Subject:        Re: [regrep] RE: [uddi-spec] ebXML Registry / UDDI Convergence

I'm suggesting a new "super-standard" based on both works, with a 
modular design just like ebXML Registry has now.  A robust registry 
needs both replication and federation, so that isn't an issue to me.

-Matt
On Friday, September 27, 2002, at 08:42  AM, David RR Webber - 
XMLGlobal wrote:

> Message text written by Matthew MacKenzie
>>
> As for coexistence -- I can't see that, not from a business/sales
> perspective at least. <
>
>>>>>>>>
>
> Matt,
>
> Now you've got me putting on my Marketing / Bus Dev hat!
>
> The big difference I see is the formal replicated v federated models,
> coupled with the tModel/WSDL v ebXML architecture stack.
>
> And this then comes back around to the business needs.
>
> So if you are trying to deploy an eMarketplace with lots
> of eCommerce sites and you want a strict and formal
> member directory / participation control structure - with
> simple push/pull content interactions - then UDDI makes sense.
>
> If you are looking to build a cross industry supplychain
> B2B world with multi-threaded business processes
> between many collaborating peers then ebXML gives you that.
>
> Similarly if you are looking to document reference industry
> domain vocabularies, transactions and classifications
> and codelists, then ebXML registry is the right choice.
>
> Does it makes sense to keep complete separation for
> ever here?  Clearly three years from now we would like to
> see a common infrastructure - and providing support
> for the two mechanisms - replicated / federated.
>
> But as a marketing person - I'm seeing you'd make the
> product modular - so customers can buy a simple
> base registry, and then step-up to more functionality
> as they need it.
>
> DW.


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>