[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Core Components and XML Serialization - Which Approach?
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:duane@xmlglobal.com] >Sent: Wednesday, March 05, 2003 12:19 PM >To: Chiusano Joseph >Cc: regrep@lists.oasis-open.org >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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]