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 ?


Andrzej,

> The dream of dynamic discovery of trading partners (which might drive more
need of
> federated RegReps), is just that.  A dream.

Not so. I've been in Asia recently and seen a project where they
demonstrated
it working. It's not a dream because I've seen it.

David Lyon
www.globaltradedesk.com

----- Original Message -----
From: "Andrzej Jan Taramina" <andrzej@chaeron.com>
To: "David Lyon" <david.lyon@globaltradedesk.com>
Cc: <ebxml-dev@lists.ebxml.org>
Sent: Tuesday, April 23, 2002 9:00 AM
Subject: Re: [ebxml-dev] Distributive Directories ?


> David:
>
> > 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
> RRs:
>
> > 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)...
>
>
>
> ...Andrzej
>
> Chaeron Corporation
> http://www.chaeron.com
>
>
>
> ----------------------------------------------------------------
> 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