OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ebxml-dev] ......some form of centralized repository is NOT neededRE: [ebxm l-dev] RE: [EDI-L] Article on ebXML Core Components

I would view ebXML Registry as a generic engine / service to classify,
associate, search, and manage the life cycle of any information asset. 
It can be used internally to a business as a Knowledge Management engine
(structured, unstructured data).  Its a standard based approach to some of
the offerings by the KM vendors.  As a example that departs from B2B,
individuals could classify their own documents on their personal desktops,
and a P2P binding would allow federated searches across the enterprise ("who
has done work on such and such a topic?").   UDDI has a specific purpose.

Scott Nieman
Practice Director - Integration
Venturi Technology Partners

-----Original Message-----
From: Andrzej Jan Taramina
To: ebxml-dev@lists.ebxml.org
Sent: 4/18/2002 9:10 PM
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components

> > Will the registry/repository concept for ebXML eventually merge with
> > counterpart defined for UDDI/Web Services ?

There are some fundamental issues that might prevent this as well as the

UDDI is a registry only...no repository, where as ebXML has both.  That
could (and 
may need to be) rectified by the UDDI spec (imagine 10,000 WSDL
pointed to by a UDDI rep.....how would you manage the storage of all
these in a large 
corporation in a doable fashion?  Put them on different web servers all
over the 
company?  Not likely......some form of centralized repository will
eventually be 
needed to complement UDDI).

The big issue is that UDDI has been designed to be a "global" public
(though that does not preclude private implementations), with support
for federation 
and distribution of nodes (meaning that the distributed system appears
as a single 
global registry).  Whereas ebXML RegRep has been designed as a
registry, to target a specific group of parties with a common interest
(a supply chain, 
industry vertical, etc.) and no provision has been made for
Those are big chasms to cross in trying to merge the two together.
philosophical roots.

Best practice seems to suggest that you use ebXML RegRep for community
and use UDDI more globally which in turn has a "pointer" to the specific


Chaeron Corporation

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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC