[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Core Components and XML Serialization - Which Approach?
<Quote1> UDDI does not expose any client API to enable clients to effect replication. </Quote1> UDDI v3 has a Replication API. <Quote2> ebXML Registry and UDDI have very little in common at this point. Hopefully this will change in the future. </Quote2> I respectly differ (on the first sentence), when comparing the V3 specs of both registries. I believe that notwithstanding the obvious "main focus" of each registry, from a high-level functionality perspective the 2 registries have more in common than many people are aware of. Some things that come to mind are: - Classification (UDDI calls this categoryBag) - Digital signature support - Federated registries - Publish/subscribe - Host redirection - Cursor support (UDDI calls this "chunks") Beyond that there are glaring differences, such as: - UDDI's large support for policies - UDDI's publisher-assigned keys - ebXML's information model extensibility (Slot mechanism) - ebXML's Content Management feature In terms of representing Web services, those that compare the UDDI and ebXML representations of Web services will see that there are direct parallels between the 2 representations. Joe Farrukh Najmi wrote: > > 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/ > >>> > >>> > > > > > > > >
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]