I believe so - ebRS v2.35, line 5116 (p.149):
<Quote>
The following rules govern how a registry joins a federation:
· Each registry must have exactly one Registry instance within that
registry for which it is a home. The Registry instance is owned by the
RegistryOperator and may be placed in the registry using any operator
specific means. The Registry instance must never change its home
registry.
</Quote>
Joe
Duane Nickull wrote:
>
> One item that needs to be possibly added is a "home" localtion for each
> Registry Object. Each object could have an associated value of its'
> home location and a psuedo "refresh from home location" attribute to
> ensure that content is fresh, yet it is unnecessary to poll the home
> address looking for updates in a manner that uses resources unwisely.
>
> I don't know if the Registry team has looked at this as part of the
> federated approach.
>
> Duane
>
> Chiusano Joseph wrote:
> > Thanks Duane - that's the exact kind of feedback I was looking for.
> >
> > Sounds like this is covered in v3.0 by the Federated Registries Object
> > Replication feature - from ebRS v2.35, lin 5188 (p.151):
> >
> > <Quote>
> > Any Submitting Organization can create a replica by using the standard
> > SubmitObjectsRequest.
> > ...
> > Creating a local replica requires the destination registry to read the
> > state of the remote object from the source registry and then create a
> > local replica of the remote object.
> > </Quote>
> >
> > Joe
> >
> > Duane Nickull wrote:
> >
> >>Joseph:
> >>
> >>Matt MacKenzie, David Webber and I implemented this stuff 2 years ago
> >>and out that each has merits. The problem you have identified is that
> >>once a CC or BIE is copied, serialized and transmitted to a remote
> >>location, it looses its' RIM metadata (context). That includes
> >>classifications, associations etc. Therefore, if CC's and BIE's are to
> >>be stored in a registry, users need to either copy the appropirate RIM
> >>data with it, or duplicate the RIM data in the Registry Objects itself
> >>(an un-elegant solution IMHO).
> >>
> >>IN the Wrox book 'Professonal ebXML Foundations" a chapter was written
> >>identifying this problem and a solution. I still believe the solution
> >>lies somewhere ins a hybrid approach. This could involve wrapping the
> >>actual Registry Object with a RIM Metadata envelope before it is
> >>serlialized and transmitted.
> >>
> >>Duane Nickull
> >>
> >>Chiusano Joseph wrote:
> >>
> >>>All,
> >>>
> >>>I've been thinking more about this issue...that is, given a set of
> >>>metadata attributes (such as those specified in the Core Components
> >>>spec), which should be part of the RIM (through a binding) and which
> >>>should be "pushed down" into the contents - i.e. as a "wrapper" for the
> >>>core component or associated entity.
> >>>
> >>>For example, lets say we need to provide for the following metadata for
> >>>a Core Component (this is all hypothetical):
> >>>
> >>>- Object Type (Basic Core Component (BCC), Basic Business Information
> >>>Entity (BBIE), etc.)
> >>>- Creation Date
> >>>
> >>>And let's say the Core Component contained "Contact Information" for an
> >>>individual. In general, there are 2 approaches to representing this
> >>>metadata (let's say for simplicity that you cannot split the metadata up
> >>>- that is, you must include all metadata in one approach):
> >>>
> >>>(1) As part of serialization
> >>>(2) As part of RIM
> >>>
> >>>Approach #1 would look as follows (note "CoreComponentMetadata" header,
> >>>with data in "CoreComponentData" element):
> >>>
> >>><CoreComponent>
> >>> <CoreComponentMetadata>
> >>> <ObjectType>BCC</ObjectType>
> >>> <CreationDate>2003-01-03</CreationDate>
> >>> </CoreComponentMetadata>
> >>> <CoreComponentData>
> >>> <ContactInformation>
> >>> <PersonFirstName>Harry</PersonFirstName>
> >>> ...more elements here...
> >>> </ContactInformation>
> >>> </CoreComponentData>
> >>></CoreComponent>
> >>>
> >>>Approach #2 would look as follows:
> >>>
> >>>- ObjectType and CreationDate are RIM attributes
> >>>- Serialization looks as follows (note no "CoreComponentMetadata"
> >>>element):
> >>>
> >>><CoreComponent>
> >>> <CoreComponentData>
> >>> <ContactInformation>
> >>> <PersonFirstName>Harry</PersonFirstName>
> >>> ...more elements here...
> >>> </ContactInformation>
> >>> </CoreComponentData>
> >>></CoreComponent>
> >>>
> >>>My question is: What are the distinct advantages and disadvantages to
> >>>each of these approaches? And which previals (if any) as the most
> >>>advantageous/preferred approach to representing Core Components and
> >>>their associated entities?
> >>>
> >>>Looking forward to some great insight...Thanks!
> >>>
> >>>Joe
> >>
> >>--
> >>VP Strategic Relations,
> >>Technologies Evangelist
> >>XML Global Technologies
> >>****************************
> >>ebXML software downloads - http://www.xmlglobal.com/prod/
> >
>
> --
> VP Strategic Relations,
> Technologies Evangelist
> XML Global Technologies
> ****************************
> ebXML software downloads - http://www.xmlglobal.com/prod/
