[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Core Components and XML Serialization - Which Approach?
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. We have Duane. There is an attribute called "home" in the ObjectRef class in RIM. Every objects has a home attribute associated with it that determines which registry is its home registry. > > > 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/ >> >> > > -- Regards, Farrukh ---------------------------------------------------------------- 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]