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?


+1

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:23 PM
To: Farrukh Najmi
Cc: Munter, Joel D; Duane Nickull; regrep@lists.oasis-open.org
Subject: Re: [regrep] Core Components and XML Serialization - Which
Approach?

<Quote1>
UDDI does not expose any client API to enable clients to effect
replication.
</Quote1>

UDDI v3 has a Replication API.

<Quote2>
ebXML Registry and UDDI have very little in common at this point.
Hopefully this will change in the future.
</Quote2>

I respectly differ (on the first sentence), when comparing the V3 specs
of both registries.  I believe that notwithstanding the obvious "main
focus" of each registry, from a high-level functionality perspective the
2 registries have more in common than many people are aware of. 

Some things that come to mind are:
	- Classification (UDDI calls this categoryBag)
	- Digital signature support
	- Federated registries
	- Publish/subscribe
	- Host redirection
	- Cursor support (UDDI calls this "chunks")

Beyond that there are glaring differences, such as:
	- UDDI's large support for policies
	- UDDI's publisher-assigned keys
	- ebXML's information model extensibility (Slot mechanism)
- ebXML's
Content Management feature

In terms of representing Web services, those that compare the UDDI and
ebXML representations of Web services will see that there are direct
parallels between the 2 representations.

Joe

Farrukh Najmi wrote:
> 
> Munter, Joel D wrote:
> 
> >This reads a lot like UDDI Replication...
> >
> ebXML Registry and UDDI have very little in common at this point.
> Hopefully this will change in the future.
> 
> UDDI replication requires a prior contract between the registries and
> uses transactional replication. UDDI does not expose any client API to
> enable clients to effect replication.
> 
> ebXML Registry uses loosely coupled replication on a per object basis
> without imposing requirements for prior contract between the two
> registries. ebXML Registry uses its existing LifeCycleManager API to
> allow clients to create and remove replicas within a registry.
> 
> Can you clarify where you see the similarities other than the word
> "replication", which has been around for almost a decade or more now
in
> database circles?
> 
> --
> Regards,
> Farrukh
> 
> >
> >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/
> >>>
> >>>
> >
> >
> >
> >

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