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: RE: [regrep] Core Components and XML Serialization - Which Approach?

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

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
> 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
> > Replication feature - from ebRS v2.35, lin 5188 (p.151):
> >
> > <Quote>
> > Any Submitting Organization can create a replica by using the
> > SubmitObjectsRequest.
> >                       ...
> > Creating a local replica requires the destination registry to read
> > state of the remote object from the source registry and then create
> > local replica of the remote object.
> > </Quote>
> >
> > Joe
> >
> > Duane Nickull wrote:
> >
> >>Joseph:
> >>
> >>Matt MacKenzie, David Webber and I implemented this stuff 2 years
> >>and out that each has merits.  The problem you have identified is
> >>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
> to
> >>be stored in a registry, users need to either copy the appropirate
> >>data with it, or duplicate the RIM data in the Registry Objects
> >>(an un-elegant solution IMHO).
> >>
> >>IN the Wrox book 'Professonal ebXML Foundations" a chapter was
> >>identifying this problem and a solution.  I still believe the
> >>lies somewhere ins a hybrid approach.  This could involve wrapping
> >>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
> >>>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
> >>>Entity (BBIE), etc.)
> >>>- Creation Date
> >>>
> >>>And let's say the Core Component contained "Contact Information"
> an
> >>>individual. In general, there are 2 approaches to representing this
> >>>metadata (let's say for simplicity that you cannot split the
> 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
> >>>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>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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