Re: [ebxml-dev] Distributive Directories ?

[Todd Boyle <tboyle@rosehill.net>]

I would be very excited to see a formal model of federation, since
it could be a natural element within webs of trust generally.

Most of the centralized frameworks of trust such as PKI
with certificates from Verisign etc., or Passport/Liberty schemes,
is they lead to an unnecessary concentration of power in certain hosts
or owners, which inevitably results in excess rents or profits for
those hosts, and compromises everybody's security and privacy.

Trust should be anchored in communities of users, around some
shared resources like registries rather than some overwhelmingly
powerful industry vendor, or some technology portal like Verisign.

Let's build it for local chambers of commerce, or any other natural
aggregation of trust that already exists in communities, yes,
perhaps even local governments, perhaps industry associations,
but good god, not software vendors, telcos, UN/CEFACT,
or Fortune 500 companies.

Todd



At 09:51 AM 4/19/02, Farrukh Najmi wrote:
>One related point on ebXML Registry Federation ideas is that a federation 
>is a very
>loose and voluntary union of registries.
>
>A few points that may help illustrate the concepts follow:
>
>-Any registry could define a new federation and declare itself to be a 
>leader of
>that federation.
>
>-A registry wishing to be a federation leader must implement an additional
>FederationLeader interface
>
>-Any number of registries could voluntarily join that federation.
>
>-A Registry may be a member of multiple federations
>
>-To be able to join a federation a registry must support a FedeationMember
>interface
>
>-Federations support both a peer-to-peer and hierarchical model
>
>--
>Regards,
>Farrukh
>
>
>Farrukh Najmi wrote:
>
> > David,
> >
> > I wanted to mention that ebXML Registry has for more than a year now a 
> planned
> > work item to support Federated ebXML Registries. This work item is now 
> slated
> > for V3 based on the current Registry TC plans. Unlike a replicated 
> approach the
> > federated registry approach is more like a distributed (partitioned) 
> database
> > where the union of all members of a federation appear as a single logical
> > registry to clients performing a federated operation.
> >
> > We intend to have early prototypes done as the federated registry spec 
> evolves
> > in the Open Source implementation of ebXML Registry at:
> >
> >     http://ebxmlrr.sourceforge.com
> >
> > I would be interested in a discussion on requirements for this feature 
> based on
> > our wealth of collective experience.
> >
> > --
> > Regards,
> > Farrukh
> >
> > David Lyon wrote:
> >
> > > Andrzej,
> > >
> > > You've raised some really good points.
> > >
> > > Now I don't profess to be an expert in UDDI or WSDL but I've always liked
> > > the general philosophy behind ebXML. Generally speaking the idea of a
> > > registry is a good one, it's virtually an extension of the Trading 
> Partner
> > > information that is kept in most of the old EDI software programs.
> > >
> > > Has anybody ever considered a Distributive Directory ?
> > >
> > > This is now possible and viable with broadband and offers advantages for
> > > small business over a centralised registry.
> > >
> > > 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.
> > >
> > > The details of the new company are stored in the database of all the
> > > companies that are connected.
> > >
> > > The result is that within a city or region, everybody can have the 
> contact
> > > details of everybody else and their pricelist/catalog.
> > >
> > > One could connect an entire city so that everybody could share everybody
> > > elses information.
> > >
> > > With broadband transmission speeds, a 2gig/hertz processor and a 70 
> gig hard
> > > drive, this seems to be readily achievable. That btw, is the hardware 
> that
> > > the local Plumber can afford.
> > >
> > > Surely this sort of technology is on the verge of becoming a reality. 
> There
> > > are some among us who have seen it in operation.
> > >
> > > Comments ?
> > >
> > > ----- Original Message -----
> > > From: "Andrzej Jan Taramina" <andrzej@chaeron.com>
> > > To: <ebxml-dev@lists.ebxml.org>
> > > Sent: Friday, April 19, 2002 2:10 PM
> > > Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
> > >
> > > > > > Will the registry/repository concept for ebXML eventually merge 
> with
> > > its
> > > > > > counterpart defined for UDDI/Web Services ?
> > > >
> > > > There are some fundamental issues that might prevent this as well 
> as the
> > > political
> > > > ones.
> > > >
> > > > 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
> > > definitions
> > > > 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
> > > directory
> > > > (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
> > > community-level
> > > > 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
> > > distribution/federation.
> > > > Those are big chasms to cross in trying to merge the two together.
> > > Different
> > > > philosophical roots.
> > > >
> > > > Best practice seems to suggest that you use ebXML RegRep for community
> > > stuff,
> > > > and use UDDI more globally which in turn has a "pointer" to the 
> specific
> > > RegRep.
> > > >
> > > > ...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>
> > > >
> > >
> > > ----------------------------------------------------------------
> > > 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>
> >
> > ----------------------------------------------------------------
> > 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>
>
>
>
>
>
>----------------------------------------------------------------
>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>