[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [Ebxmlrr-tech] centralised registry concept
Farrukh Najmi wrote: > (Cross posting to ebxml-dev as this may be of interest to the general > ebXML community) > > ShodZ wrote: > >> hi! >> as per my interpretation of the ebXML registry concepts developed by >> the ebxml technical team ebxml does not specify anything about the >> repository nor does it enforce a centralised registry concept. >> the former is easy to digest but the latter gave me goose bumps. if >> there is no central authority making sure that all business >> entities,willing and capable to perfrom business over the internet >> based on the ebXML specification, then dosen`t ebXML fall short of >> its goals?? just zip 5 years into the future and assume that the >> current versions of the ebXML specifications stand. then if own a new >> company and wanna find a business partner then i would have to >> register with multiple registries. i am ofcourse assuming that >> multiple registries will crop up by that time which i think is >> inevitable. and most of all the big enterprises will have all there >> say in such registries. >> please correct me if i`m wrong >> thank you >> shodhan >> shodZ >> >> > ebXML Registry does not expose an explicit and distinct interface for > the repository. > All access to the repository is through the registry interfaces > (QueryManager and LifeCycleManager). > This does not seem to be an issue so far. > > Call it my personal bias but I do not think that *MOST* centralized > things are not a good idea. Oops! That was a double negative. What I meant to say is that: Call it my personal bias but I prefer distributed architectures over centralized architectures. > > That said, ebXML Registry architecture is flexible. One can operate a > giant, monolithic, centralized > ebXML Registry using the current specs. Or one can operate many > smaller ebXML Registries that can federate > together in a loosely coupled manner. The effect to the end user is > the same. A federation of registries look like > one giant monolithic registry as far as discovery is concerned. > However, a federation scales better and has better distributed > owebrship and management. > > Take your example. Lets say the automobile industry operates several > ebXML Registries that form an > automobile industry federation. Now an tire manufactures can register > themselves in *ANY ONE* (and only one) of those registries > (say "tire manufactures" registry) and they will be discoverable from > *ANY ONE* of the registries in the federation. > > Does that clarify the architecture. > -- Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC