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?


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]