OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Farrukh, I defer to you on this one.

Duane Nickull wrote:
> 
> I had read this but thought it refers to the Registry Home, not a
> Registry Object Home.
> 
> Clarification?
> 
> Duane
> 
> Chiusano Joseph wrote:
> > 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/
> >
> 
> --
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]