[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]