[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 know you are Joel, and thanks for your great work! The reply was not meant for you, but for the listserv as a clarification for all of what you referred to. I am not so sure that the 2 replication mechanisms are as similar as you claim, and wanted to put forth that information to elicit other impressions. Joe "Munter, Joel D" wrote: > > Hi Joe, > > I am quite familiar with the steps to bring a new node into a UDDI > Registry as I led the team that drafted much of this text. I am curious > why you sent it in direct reply to my comment. > > I was commenting that much of the "replica" modeling within the ebXML > Federated Registry specification language is analogous to the thought > process and modeling that we did for UDDI. > > The ebXML Federated Registry concept of "home" is analogous to the UDDI > notion of custodian node and so on. > > Please note: I have no plans to participate in any long convoluted > thread comparing the virtues or issues with either approach. I was > simply pointing out that this is one of several areas of overlap between > the two specifications. > > Joel Munter, Intel > desk: 480.552.3076 > cell: 602.790.0924 > > > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: Wednesday, March 05, 2003 1:03 PM > To: Munter, Joel D > Cc: Duane Nickull; regrep@lists.oasis-open.org > Subject: Re: [regrep] Core Components and XML Serialization - Which > Approach? > > From UDDI v3 spec: > > 7.8 Adding a Node to a Registry Using Replication > > The following steps MAY be used to add a node to a registry that uses > UDDI V3 replication. A registry policy may be defined for the addition > of a node and the policy MAY define a different or more detailed process > than the following process > > 1. Add the new node to the Replication Configuration Structure with the > operatorStatus value set to "new". If a communicationGraph is used in > the registry's replication Configuration Structure, one or more edges > MUST be added so the new node may call the get_changeRecords API. > > 2. Administrators of the existing nodes are notified of the update. They > each retrieve and process the new information in the configuration file > in order to add the new node as one of the parties with which their > implementations are willing to authenticate and communicate. To verify > the ability to communicate, each node pair within the current UDDI > registry SHALL successfully exchange the do_ping message. > > 3. Once all existing nodes within the registry have verified the ability > to successfully communicate with the new node, the configuration file is > changed a second time to add appropriate edges to the communicationGraph > in order to introduce the new node into the active replication graph. > The messages allowed between the new node and its primary may be > restricted to allow for startup processing. Replication then proceeds > to provide change records to the new node which establish in it a > current image of the registry > > 4. The new node MUST issue a get_changeRecords API call to an existing > node and SHOULD process all available changeRecord elements. As nodes > MAY limit the number of changeRecord elements in a response, processing > all available changeRecord elements MAY require several > get_changeRecords API calls. > > 5. When the new node has completed processing of the change history and > is ready to engage in all UDDI registry activities, the operatorStatus > value, within the Replication Configuration Structure, WILL be updated > from "new" to "normal" and any message restriction that may have been > imposed earlier may be removed. The updated replicationConfiguration > will be distributed to the nodes defined within the communicationGraph > via replication. > > "Munter, Joel D" wrote: > > > > This reads a lot like UDDI Replication... > > > > 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/ > > > > > > > -- > > 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>
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]