[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] ebXML Reg Rep & UDDI interoperability
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC