[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-dev] Benefits of UDDI
Certainly these benefits have been promised before by other paradigms and technologies. Object technologies promised reuse. Component and messaging technologies promised the benefits of standards and the ability to scale beyond traditional enterprise boundaries. The difference between past attempts to realize these benefits with other technologies and current attempts based upon Web Services primarily is that there is broad acceptance of XML, http, SOAP and WSDL as fundamental standards (de facto or otherwise) for Web Service-based interaction. And equally fundamental as an emerging standard to widespread adoption and use of Web Services is UDDI.
Registry technologies are commonplace today. Microsoft has Active Directory and J2EE has JNDI, both of which leverage LDAP (light weight directory access protocol). LDAP derives from X.500, and X.500 registries are complex to design, install and maintain over time. Many IT executives who have the mandate to demonstrably ensure that corporate technology money is wisely spent also have many lessons learned relating to registry technologies. CIO’s having experience with registries are likely to object when Web Services infrastructure vendors introduce yet another registry to corporate infrastructure – even if they buy into the long-term benefits of Web Services. They may endorse taking a very deliberate approach toward Web Service adoption that equates to developing with Web Services using no registry, and instead, hard-coding connections into the endpoints, or building small custom registries on top of existing infrastructure to determine if what they are being told about Web Service technologies and service-oriented architectures is the same old vendor-serving hyperbole they’ve seen and heard before wrapped neatly in XML-laden buzzwords.
Such caution is prudent because there is more than enough Web Services-related hyperbole to go around. Service oriented architecture development is complex, and an IT organization should be prudent in order for development and operations to learn the boundaries of Web Service enabled applications with specific emphasis on UDDI. It is my belief that UDDI, an integral component to a Web Services-oriented architecture, is not part of the hyperbole. BUT at the same time, I am certainly aware of how far UDDI needs to go to be robust, and to be more than a directory. UDDI is advertised by the UDDI committee as a registry. Unfortunately, UDDI does not really live up to the "registry" part beyond basic directory services that a human would consume. Basic categorization of UDDI seems always to have been a bit imprecise (is it a registry, or is it a yellow pages directory?). The use of the word "registry" is all over in UDDI docs, so I will take the UDDI spec team's original intention to be to create a registry. Given that, there are tremendous deficiencies with UDDI "products" today (either commercial or free). Notable holes in these products can be seen in the operational and administration areas. Basic command line UDDI tools are missing. Operational use cases (such as one that describing how UDDI v3 keys are properly distributed and managed) are simply not mentioned in the specs, consequently they are not provisioned by any products (even those used by the public registry operators). Use cases are not considered for dynamic inquiry/bind -- the use cases the UDDI spec committee considers can be scoped to be directory-related use cases only ... and then they cannot be considered a complete basis of same.
With all of that said, I would recommend starting with a UDDI registry and using the UDDI standards (as they currently are) to make UDDI go as far as they can go rather than starting with a proprietary registry and expecting to evolve toward a standard. There are open source versions of UDDI (v2, I am unaware of v3 as open source) such as Novell's if you'd like to control a UDDI instance, or there are registries like Systinet's or IBM's with which you can experiment on line (these are v3). Making UDDI work is, in my view, fundamental to the success of Web Services at large. Without being overly dramatic, I think there is much at stake.
Currently i am using simple mysql database for searching my services
(as they are very small in number). Can any body suggest what benefits
i can get if i use UDDI registry for publishing and discovering
Thanks in advance for your replies.