Re: [regrep] ebXML Reg Rep & UDDI interoperability

[Farrukh Najmi <farrukh.najmi@sun.com>]

Max Voskob wrote:

>I'm not sure if you discussed this option before, but I thought of providing
>some UDDI interfaces to your Registry.
>
Hi Max,

Thank you for your suggestion.

This idea has been discussed before by other guests on our mailing list 
and in other forums. I think it is a fine idea for a vendor specific 
feature for an ebXML Registry product. I do not think it is a good idea 
for the ebXMl Registry Standard. Here is why.

In the ideal world we would not have two registry specifications but 
would have one. For better or for worse we have two and they differ in 
some very fundamental ways.

The API and information model of UDDI is very specific, while that of 
ebXML Registry is very generic. Additionally, ebXML Registry has a much 
broader set of requirements (and capabilities to match them) than UDDI.

Our architectural choice of generic API and information model has been 
validated over and over. In our V3 work we have found that we are able 
to do many of the V3 features without requiring any new API changes.

Our query API is designed to support any type of ad hoc query without 
having to extend the API every time new query requirements are defined.

Why in the world would we want to adopt an API that is less functional 
than what we have already? What value would it provide to our large and 
growing user community? All it would do is to make our otherwise clean 
information model and API confusing and muddled. Whose interest would be 
served by that?

Our standard is being adopted by Governments, major verticals, fortune 
500 companies and standards organizations because it is so flexible and 
accommodating. You own message at:

    http://lists.oasis-open.org/archives/uddi-spec/200302/msg00021.html

alludes to the fact that governments want ebXML Registry based upon its 
existing capabilities.

In my opinion, the only reason anyone would wish to use ebXML Registry 
over a UDDI interface is for dealing with legacy registry client 
applications until they are re-written to the ebXML Registry API. And 
those who chose JAXR for a client API when using UDDI would find that 
their client applications would easily work with ebXML Registry.

In summary, I think putting UDDI interfaces on an ebXML Registry may be 
OK for vendors to offer as a value-added feature for their ebXML 
Registry product. I do not believe that it makes sense at the standards 
level. I predict that ebXML Registry product vendors will only implement 
the feature you suggest if there is a customer demand for it.

Thanks again for your suggetsion.

-- 
Regards,
Farrukh


>
>Lets say that an organization is using a web-services platform, but they
>want to use Reg/Rep as well. It would be very inconvenient to have 2
>registries - UDDI and Reg/Rep. Why can't they talk to Reg/Rep thru UDDI
>interfaces?
>
>I don't think that implementing all UDDI interfaces is a wise idea, but the
>query interface would definitely come handy.
>
>Still sounds weird? Think again! ;)
>
>Cheers,
>Max
>
>  
>