The UDDI XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only.

Revision of Making the business case from Fri, 2006-08-18 23:41

Today's IT organizations must identify and plan for an architecture that can not only provide for scalability, but also agility, the ability to add new offerings or reorient existing functions in a flexible, minimally disruptive fashion. This agility requires that we think of IT in terms of services, not physical assets. Web services and service-oriented architecture are a practical way to meet these needs.

UDDI is an important element of the Web services infrastructure. By enabling policy-based distribution and management of enterprise Web services, a UDDI registry delivers significant business value. It helps ensure that the functional and practical needs of developers, the operational and scalability requirements of enterprise architects, and the underlying business policies are not in opposition; in fact, it brings all of these needs into closer alignment by increasing software flexibility, reuse, and control.

UDDI helps to increase code re-use and to improve infrastructure management by implementing a standardized means of:

  • Publishing information about web services
  • Finding web services
  • Determining a service's invocation, security, transport protocols and parameters
  • Providing a means to insulate applications from failures or changes in invoked services

Functions like these help address important business questions for both developers building service-enabled applications and for IT organizations managing enterprise SOA infrastructure.

UDDI’s Role in Web Services Development

Benefits such as standards-based interoperability that are provided to programmers by Web services are clear. Nonetheless, when development teams begin to build Web services interfaces into their applications, they soon face issues all too familiar to developers who work in any programming environment: code reuse, ongoing maintenance, and documentation. Moreover, as the number of Web services created within an IT organization grows, the need to manage these services can increase exponentially.

For development teams, registries based upon UDDI help answer needs such as:

  • How can development managers systematically organize and manage Web services across multiple systems and development teams?
  • How can developers systematically manage the process of moving services through each phase of development: from coding to testing to public deployment?
  • How can programmers document interface specifications, message transports, and authentication mechanisms with other developer groups? As the services change over time, how can external applications accommodate the changes?

When developing and deploying Web services applications, UDDI registries help drive better code reuse and developer productivity. A UDDI registry provides an interoperable, standards-based approach for systematically documenting and publishing Web services, regardless of development environment or platform. It can help developers—even across functional groups—find a shared service and use that service within their own applications.

UDDI’s Role in Service-Oriented Infrastructure

Issues of services development point to the larger question of how to design an IT infrastructure that supports Web services development efforts. Although questions such as how best to conceive shared services, to design identity management and authentication mechanisms, and so on are beyond the scope of the UDDI standard (and this paper), UDDI registries represent an important element of this overall question. In a service-oriented environment, enterprise software architects must consider questions such as:

  • How can critical applications be insulated from changes—or failures—in back-end shared services?
  • How can an organization share information about services in a controlled way that reflects its own business rules and policies?
Compounding these issues, a service-oriented approach implies that these questions must be addressed as a routine aspect of run-time operations, not hard-coded into the applications themselves.

 

Registries based upon UDDI provide IT administrators a formal layer of indirection necessary for service-oriented application development and management. By providing a sort of firewall between a service and the applications that call it, system administrators more easily can accommodate changes in the life cycle of specific components—such as for version updates, for policy considerations, or even for service termination.

In addition to the fundamental benefits of run-time binding provided by the registry in a service-oriented architecture, administrators often require control of the publication and distribution of information about deployed Web services, so that software deployment follows business policy. To facilitate these operational and governance needs, the current version of UDDI adds support for features such as client authentication and publish/subscribe for peer registries.

This understanding of how Web services are most often used today is reflected as the UDDI specification has evolved. Its current implementation recognizes the need for federated control in real-world operational environments and further integrates the standard with other elements of service-oriented infrastructure. It provides key capabilities for enterprise-level deployment and is a mature, well-supported standard.

Learning More

Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure. The left-hand navigation bar links to various in-depth resources. In particular, good next steps include:

______________________________________________________

Content for this UDDI Knowledge Base page is provided by the UDDI XML.org Focus Area Editorial Board. Suggestions for editing this page should be made through the Editorial Board Feedback Forum.

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I