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

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

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
joel.d.munter@intel.com
(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>