[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
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> --Boundary_(ID_s8TvgvjMVAA4ygXDmbahKw) Content-type: text/x-vcard; charset=us-ascii; name=Chiusano_Joseph.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Chiusano_Joseph.vcf Content-description: Card for Joseph Chiusano 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 --Boundary_(ID_s8TvgvjMVAA4ygXDmbahKw)--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]