Re: Positioning with UDDI (was RE: Tactical Proposal: Split V2 wo rkitems into V2 and V3 (repost))

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

I agree with Lisa's statement 100%.

The ebXML registry specs place their emphasis on the registry not the repository.
Notice that we dropped the term repository from the title of our specs in Tokyo
as an explicit recognition of this fact.

The strength and design center of OASIS ebXML Registry specs IMO have always
been:

-A flexible, generic and extensible registry information model
-Flexible ways to relate registry objects with each other
-Flexible ways to classify registry objects using arbitrary, structured
classification schemes
-Flexible and powerful ways to query the registry objects
-Robust security mechanisms (particularly surrounding publishing and discovery of
registry objects)
-A minimal yet flexible XML interface to the registry that can accommodate new
features with minimal change
-Ability to support arbitrary content in the repository

Notice that in the above list repository was only mentioned in the last bullet.
All other areas where we excel have to do with registry and not the repository.

While I value Joel's opinion on many matters, I find the suggestion of using UDDI
as the registry for OASIS ebXML Registry baffling. Take away our Registry
capability and we have, as Lisa put it mildly, a "content-free" set of specs.

I would like to share some recent experience at attempting to bring these two
efforts a little closer together in the JAXR API:

     http://lists.oasis-open.org/archives/regrep/200108/msg00047.html

Although JAXR is attempting unification at a Java API level, and we are talking
about unification at the registry spec level, IMO, the issues are very similar.
In JAXR, experts from both UDDI and ebXML arrived at the following approach to
unification:

-Use the ebXML RIM as base information model
-Extend/improve RIM to accommodate UDDI's focus on web service
publishing/discovery
-Recognize that there are different types of users who need business APIs and
power users who want the flexibility of a more generic API
-Use UDDI's business API as model for JAXR's business API
-Use ebXML Registry interface as model for JAXR's generic API
-Provide robust security

The intended result is to provide the simplicity and ease of use of UDDI and the
power and flexibility of ebXML registries in a unified abstraction API.

I would hope that any well intentioned and objective efforts to unify the two
specifications would come up with a solution that is not too far from what the
ebXML and UDDI experts in JAXR came up with.

--
Regards,
Farrukh

Lisa Carnahan wrote:

> Joel,
>
> Could you please clarify what you mean by " a possible
> concept of the Oasis Registry TC accepting UDDI as its "Registry" allowing
> the Oasis Registry TC to complete its definition of the Repository
> functionality and specification."?  Specifically your use of the terms
> 'registry' and 'repository'?  Currently our specs are relatively silent on
> the content in the repository.  In fact, most of our work has been on the
> information model/services that make use of the metadata in a
> registry.  Our specs would be fairly content-free if we focused on the
> repository.  Am I missing something here?
>
> --lisa
>
> At 02:16 PM 8/21/2001 -0700, Munter, Joel D wrote:
> >reply:
> >
> >I'd like to highlight the thoughts made by both Scott and Dan earlier in the
> >thread.  The original note floated by Sun/IBM bridging ebXML Reg/Rep and
> >UDDI was intended to be a starting point.  Dan's suggestions that we should
> >look to define ebXML Reg/Rep and UDDI common vs. distinct use cases for
> >interoperability have merit.  I'd like to additionally submit a possible
> >concept of the Oasis Registry TC accepting UDDI as its "Registry" allowing
> >the Oasis Registry TC to complete its definition of the Repository
> >functionality and specification.
> >
> >My point in bringing up the idea this way is to highlight that we probably
> >need to establish a separate sub-team, we should brainstorm various
> >interoperability alternatives, and do real work on this.
> >
> >Joel
> >
> >-----Original Message-----
> >From: David RR Webber [mailto:Gnosis_@compuserve.com]
> >Sent: Tuesday, August 21, 2001 1:56 PM
> >To: Lisa Carnahan
> >Cc: Scott Hinkelman; regrep@lists.oasis-open.org
> >Subject: Re: Positioning with UDDI (was RE: Tactical Proposal: Split V2
> >work i tems into V2 and V3 (repost))
> >
> >
> >Message text written by Lisa Carnahan
> > >My thought is that
> >it is beyond the scope of our TC to define TModels for CPPs, BPs and the
> >like.  These should be defined by the appropriate ebXML committee (i.e.,
> >the Big UN/CEFACT committee...(the name escapes me)).   What our
> >TC  discussed on our conference call was to limit our TModel definitions to
> >
> >only those that would help ebXML Registries be found and defined in a
> >consistent manner.<
> >
> >Lisa,
> >
> >That seems to me to be probably the last we see of it!
> >
> >Not wanting to rain on the UDDI parade - I would offer -
> >that since we have the TModel expertise - (a fact that will probably
> >not go un-noticed when we try and punt to these other groups...)
> >
> >we should instead do drafts here of what we see these all should
> >be - and then submit them to these other guys to pour holy-water on them.
> >
> >Not to mention that we can probably make a good case for setting
> >TModels guidelines with registry for content as a task in our domain.
> >
> >Just trying to push the peanut a little more effectively!  I know - I
> >really
> >don;t want to do the TModels either - but the thought of it disappearing
> >off - to reappear sometime later - and then not aligned to our thinking -
> >worries me more than the comparitively small amount of work to
> >get us a sound base here...
> >
> >Thanks, DW.
> >
> >
> >----------------------------------------------------------------
> >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>
begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard