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:]
> Sent: Wednesday, March 05, 2003 1:03 PM
> To: Munter, Joel D
> Cc: Duane Nickull;
> 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:]
> > Sent: Wednesday, March 05, 2003 12:19 PM
> > To: Chiusano Joseph
> > Cc:
> > 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>
