Munter, Joel D wrote:
>This reads a lot like UDDI Replication...
>
ebXML Registry and UDDI have very little in common at this point.
Hopefully this will change in the future.
UDDI replication requires a prior contract between the registries and
uses transactional replication. UDDI does not expose any client API to
enable clients to effect replication.
ebXML Registry uses loosely coupled replication on a per object basis
without imposing requirements for prior contract between the two
registries. ebXML Registry uses its existing LifeCycleManager API to
allow clients to create and remove replicas within a registry.
Can you clarify where you see the similarities other than the word
"replication", which has been around for almost a decade or more now in
database circles?
--
Regards,
Farrukh
>
>Joel Munter, Intel
>desk: 480.552.3076
>cell: 602.790.0924
>
>
>-----Original Message-----
>From: Duane Nickull [mailto:]
>Sent: Wednesday, March 05, 2003 12:19 PM
>To: Chiusano Joseph
>Cc:
>Subject: Re: [regrep] Core Components and XML Serialization - Which
>Approach?
>
>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/
>>>
>>>
>
>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
