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/
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
