+1
Joel Munter, Intel
desk: 480.552.3076
cell: 602.790.0924
-----Original Message-----
From: Chiusano Joseph [mailto:]
Sent: Wednesday, March 05, 2003 1:23 PM
To: Farrukh Najmi
Cc: Munter, Joel D; Duane Nickull;
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:]
> >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/
> >>>
> >>>
> >
> >
> >
> >
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
