[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] Distributive Directories ?
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC