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 ?


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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC