[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-dev] Benefits of UDDI
-----Original Message-----Greetings --
From: Thomas B Winans [mailto:firstname.lastname@example.org]
Sent: 02 September 2004 15:09
To: Faisal Khan
Subject: Re: [uddi-dev] Benefits of UDDI
I assume that your requirements eventually call for your web services to be published for general consumption. While it is probably easier at present to use a custom directory service, the benefits that I see to sticking with UDDI (and making it a robust offering from the specification all the way to either a commercial or open source product -- so I hope vendors are reading this) include the following:
• /fontfamily>Interoperability. This is undoubtedly the most important of Web Service architectural goals.
• /fontfamily>Open and standards-based software solutions. Standards provide the necessary guidelines for constructing new software solutions and encapsulating legacy systems with common syntax, making each system more integrate-able – thereby improving the lifecycle manageability of these systems, and reducing their cost of ownership.
• /fontfamily>Standardized service interfaces that are clearly traceable to key enterprise tasks (as opposed to data entities only) and that encapsulate proprietary implementation details at the same time. For decades we have seen business applications constructed to manage data entities only, or that incorporate a set of business processes that are, at best, minimally configurable by users. Their APIs are published at a data entity level, complicating the task of building application integrations by making it necessary to understand specifics of application data models and hardwired business processes. Proper incorporation of Web Services into business software infrastructure will result in exposing a catalog of business services that can be reused with at least significantly less regard for their underlying implementations. Easy reuse of business services engenders business agility: multiple implementations of a single business service is avoided, making rapid composition and automation of business processes using these services straightforward, and the result more easily maintainable.
• /fontfamily>Extended business reach. Web services enable business partners to relate in a more automated way today as a function of using common syntax and network protocols. Assuming partners establish a common semantic model for interacting at the business process level, they can automate their interactions to a greater degree than in the past – thereby enabling business process automation beyond traditional enterprise boundaries. The ability to scale beyond traditional boundaries will be fundamental to making enterprise efforts to globalize successful.
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.
On Sep 2, 2004, at 6:45 AM, Faisal Khan wrote:
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.