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: [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.


[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