[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Core Components and XML Serialization - Which Approach?
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/ ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]