[regrep] Re: [uddi-comment] A different perspective on OASIS ebXML v3enhancementproposals.. .

Please understand that the thoughts in this email are based on a very
thorough understanding of UDDI as well as from a thorough understanding
of the issues involved in trying to merge the UDDI and ebXML information
models.

As JAXR API specification
lead I am uniquely qualified on the subject on UDDI and ebXML convergence.
The JAXR Expert Group defined what I assert is the a complete unification
of UDDI and ebXML Registry V2 capabilities, albeit at the Java API level.

It is my educated assertion that the issues involved in actual standards
convergence are very similar to the issues addressed by the JAXR API and
that the JAXR experience is directly applicable.

The JAXR experience taught me many valuable lessons. One of the central
lessons was that real convergence of the two specifications will require
convergence of the information models. The other lesson we learned in JAXR
was that UDDI information model can be defined in terms of ebXML information
model. However, ebXML information model cannot be defined in terms of UDDI
information model. The reason is based upon a well known and well understood
software principal:

"It is theoretically possible to map a more specific API on top of a
more generic API while it is theoretically impossible to map a more generic
API on top of a more specific API."

The same software concept in lay terms could be said:

"One can fit a small shoe inside a big shoe, one cannot fit a big shoe
inside a small shoe"

If I were to describe the difference between UDDI and ebXML in one sentence
it would be:

"UDDI information model and API is specific while ebXML information
model and API is generic"

The gist of the JAXR experience suggests that ebXML registry features
cannot leverage UDDI in a substantial way beyond simple things like registering
ebXML Registries in the UBR (UDDI Business Registry).

I have followed the development of UDDI V2 and V3 specs very closely
and know the specs intimately. I also know the ebXML registry V3 proposal
well.

-I do not see any way of using UDDI multi-registry features in ebXML.
UDDI model is based on transaction replication and is quite complex. Our
proposal relies on a much simpler and more flexible federated model. One
in which replication while possible for fault tolerance and load balancing
reasons, is not necessary.

-I do not see how we could use anything from UDDI in place of our REST
proposal. Our proposal is tailor made for our registry. UDDI does not have
a repository. How will it provide a RESTFul method  getRepostoryItem
when it has no such concept as Repository Item?

-I do not see how we could use anything from UDDI in place of our event
notification proposal. Again ours is based on our adhoc query mechanisms.
UDDI has no Adhoc query mechanisms. How will it provide the ability to
define event Selectors using our adhoc query mechanism?

Finally all our features leverage our other features synergistically.
For example, to create/remove/join/leave a federation no new APIs are added.
Our existing LifeCycleManager capabilities from V2 are used as is.

I am all for working towards convergence. But we must walk for a good
long time before we can run down that road together. To walk that road
we must focus on cooperation and interoparability between UDDI and ebXML.
Convergence at this point would be an impractical idea.

The REST interface is a great example of a V3 feature that was specifically
designed to facilitate cooperation with UDDI. Please see my note on this
use case posted in October 2001:

 http://lists.oasis-open.org/archives/regrep-cooperating/200110/msg00001.html

And when we are good and ready to work on convergence, I would suggest
fundamental horizontal areas such as security as a starting point for building
common ground between UDDI and ebXML.

In conclusion, I must agree with Matt and David that we must not get
distracted in our V3 work. We already are behind on two proposals:

-Content based queries

-Type extensibility

We need all our resources focused on getting a high quality V3 done
by December. We would then be able to engage in convergence discussions
with greater focus.

I humbly submit that the OASIS ebXML Registry TC must focus on reading
ebXML Registry specifications and proposals and helping defines V3 rather
than getting distracted with ideas that are unlikely to bear any fruit
in the next 6 months.

--

Regards,

Farrukh

 

 

"Munter, Joel D" wrote:
All right, I said that I was now a lurker... but
with these latest

proposals, I feel that I must offer some opinions.

[1] I have read the Cooperating Registries Proposal v0.7

[2] I have read the Event Notification Proposal 0.5

[3] I have read the REST Proposal v0.5

While all are well written and include substantial detail, I offer the

following "controversial" position:

(If you cannot handle controversy, please skip this entire email.)

80-90% of the requirements covered by these three proposals can be handled

by a well thought out and judicious use of UDDI.  In my humble
opinion, you

are reinventing much and not adding significant value.  Please
take your

hands away from the keyboard and read on before replying.  I know
that you

want to begin replying, please don't yet.  I see a very big

not-invented-here attitude.  This was also true when much of the
web

services modeling was added to the OASIS ebXML v2 specifications. 
I argued

then and I am doing so again now.  With UDDI specifications now
at OASIS,

you are all responsible for looking much more deeply into cooperation

between the two environments.

I ask you all to thoroughly read UDDI V3.

Most of the Use Cases Presented in [1] can be handled through the use
of the

UDDI business relationship structure.  This was available in UDDI
v2.

There are tModels and simple taxonomies already available that describe

peer-to-peer, parent-child, and identity relationships between business

entities in UDDI.  As services are contained within business entities,
guess

what, with good programming and best practices, that relationship can
be

extended to services within businesses.

The use of the relationship structure can be extended to reflect any
number

of hierarchies of ebXML registries.  These cover almost all of
the Use Cases

listed within [1].  tModels and taxonomies have been discussed
previously on

this list and more recently on the UDDI lists that describe good technical

approaches at "registering ebXML registries and ebXML based services
within

UDDI.  These Technical Notes and best practices must be finished
but are

available for review in draft form.  Again, this was available
in V2

registries.

UDDI V3 adds multi-registry communication, object transfer, subscription

protocols, and maybe as a surprise to some of you, even an optional
RESTful

interface to some of the UDDI functionality.  The subscriptions
protocol and

RESTful stuff in UDDI V3 obviate the need for most (but not all) of
[2] and

[3], respectively.  All of the relevant security requirements
and

node/registry policy management that UDDI should add was added in V3.

I ask you all to keep an open mind.  Before you commit to reinventing,
I

again request that you educate yourselves on UDDI V2 and V3.

Thanks,

Joel Munter

Distributed Systems, Intel Labs



(480) 552-3076

(602) 790-0924 (cell)

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>