OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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>

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

tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]