[regrep] A different perspective on OASIS ebXML v3 enhancementproposals.. .

["Munter, Joel D" <joel.d.munter@intel.com>]

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
joel.d.munter@intel.com
(480) 552-3076
(602) 790-0924 (cell)