Re: [regrep] Core Components and XML Serialization - Which Approach?

[Chiusano Joseph <chiusano_joseph@bah.com>]

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/
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard