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: Re: [ebxml-dev] Distributive Directories ?


> The philosophy behind a Distributive Directory is that a company joins an
> Exchange and when they do their details are broadcast (name, address,
> net-address) to everybody on the exchange.

UDDI does that by providing a similar distributed approach.  How it works in a "real 
world" environment is yet to be seen.

ebXML Reg/Rep is intended to serve a more specific "community".  Maybe auto 
parts suppliers for a specific supply chain, or a particular town/city, so having a 
distributed directory is not as valuable.

In fact, the 8 Fallacies of Distributed Computing will make widely distributed 
directories rather problematic.  Also, broadband is not quite as ubiquitous at the 
small business/independent contractor level (eg. your plumber, who can probably 
afford better hardware than we can).

Farrukh then notes that there is an ebXML Reg/Rep work item to provided federated 

> I would be interested in a discussion on requirements for this feature
> based on our wealth of collective experience.

I don't see this as being very useful in the short term (say two year span), relative to 
other work items.  The 8 Fallacies come into play, but beyond that, most companies 
are still evaluating whether and how to implement basic trading partner 
communications with MHS....not to mention BPM which will rear it's head shortly 
thereafter.  Realistically, how soon will anyone really want/need to implement 
federated RegReps?

Since UDDI already supports federation/replication, why re-invent the wheel?  Just 
have UDDI point to multiple RegReps.  I would resist the temptation to enter into a 
"features competition" with UDDI, since they target different needs (global vs. 
specific community).

My vote is that other work items will be critical earlier.  For exaple, beefing up BPSS 
to support complex multi-party interactions will provide more benefit to ebXML 
adopters. Accelleration of the Core Components and UBL work is a thorny problem, 
but one that will provide massive payback if it can be resolved.

The dream of dynamic discovery of trading partners (which might drive more need of 
federated RegReps), is just that.  A dream.  For at least the next few years, 
companies will initiate dealings with partners they already know about from other 
sources, and the initial negotiation/contracting/due dilligence process will be very 
much a P2P process.

My 1.44 cents worth (Canadian exchange being what it is)...


Chaeron Corporation

[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