Was the Universal Service Registry a Dream?
A combination of the features in UDDI and RDF may just make the dream come true
Dec. 2, 2004 12:00 AM
It is sometimes beneficial to stop what you're doing, take a look around, and see where you've come from and where you are going. This regrouping is taking place right now across the software industry and is focused on the problem space of Web service description, discovery, and integration. At a high level, this article briefly discusses the progress made to date at solving the problem, describes the benefits and shortcomings of current technology, and presents a vision of the possible future of Web services infrastructure. At its most fundamental level, this article deals with the idea of programmatically locating a Web service that satisfies a specific need and then (programmatically) integrating that service into an application.
SOAP 1.1 (Simple Object Access Protocol) was published as a W3C Note in May 2000 and has since become an industry-standard format for enabling XML-based messaging and remote procedure calls. WSDL 1.1 (Web Services Definition Language) was published as a W3C Note in March 2001 and, despite some ambiguity that has proven a significant hurdle to interoperability, has gained widespread industry support as a mechanism for describing message structure and required transport details. UDDI (Universal Description, Discovery and Integration), the third member (after WSDL and SOAP) of the Web service standards triumvirate, was first published in September 2000.
However, in contrast to its siblings UDDI has not enjoyed the same level of industry acceptance. It is particularly relevant in this article because it is the industry's first attempt to solve the problem of discovery and integration of Web services, in particular as discovery and integration support Web service reuse and sharing. The need to reuse and share services is arguably the most compelling argument for service-oriented architectures (SOAs).
Several factors contributed to UDDI's lackluster start out of the gate.
- UDDI was a specification that was ahead of its time. It was designed to enable management of large numbers of Web services, but at the time of its release, companies tended to have relatively few Web services to manage. Only now, after four years, are companies reaching the point where the number of Web services justifies the need for a registry to aid in organization and discovery of services.
- UDDI was originally intended to serve as a Universal Service Registry that would be a panacea for all the problems of discovery and integration with Web services-based applications. This intention has yet to become a reality. Currently, a search of the registries hosted by companies like IBM and Microsoft typically yields a set of services that are unregulated and thus unreliable - services that do not work, or have been posted by companies that no longer exist, and so on. Enterprises are therefore not using these public forums to organize services and develop meaningful business relationships.
- The UDDI specification has suffered owing to its somewhat esoteric nomenclature, which includes terms such as "tModels" and "BindingTemplates." These terms, while digestible to the infrastructure developers who are building the plumbing, are not as palatable to developers who are writing business-specific applications. These terms negatively affect the usability of UDDI.
As mentioned earlier, this article will also explore how RDF (Resource Description Framework), a developing technology dedicated to defining and maintaining a Web of relationships between different types of information, fills some of the technology holes that have hindered UDDI's ability to fulfill its promise. Although not one of the mainstream Web services specifications, RDF is capable of providing a technology basis for the discovery and utilization of Web services. Specifically, RDF is an XML-based language for representing information about resources and the relationships between the resources intended for representing metadata about these resources. It is one of the building blocks of the W3C's Semantic Web Initiative. Furthermore, OWL (Web Ontology Language; www.w3.org/TR/owl-features
) builds on RDF by providing a formal vocabulary to describe the meaning of classes and properties, thus enabling powerful automated reasoning to be performed on RDF data. While still relatively immature, these standards offer interesting alternatives to the traditional Web services landscape and are worthy of investigation within this context.
Combining the capabilities of the current state of UDDI with the capabilities of RDF and OWL promises to resurrect the quest for the Universal Service Registry. The following sections of this article contemplate the features necessary to build what we're going to call, for the purposes of this article, an Ideal Service Registry (ISR) and how the technologies mentioned earlier will play.
The Ideal Service Registry
The following are some of the features that must be implemented to create an Ideal Service Registry (ISR).
It must be easy to describe Web services in an ISR
There are many ways one can define a service in UDDI, which makes publishing and using inquiry results quite difficult. A big step toward usability, at least with regard to publishing services, came about with the publication of a technical note entitled "Using WSDL in a UDDI Registry, Version 2.0" (available at www.oasis-open.org) that outlines a set of "best practices" for mapping a service description into a UDDI registry. The best practices outlined in this note led to the incorporation of WSDL (an XML-based method of describing the inputs, outputs, and available methods of a Web service) into the UDDI registry. Following these best practices has greatly simplified the process of publishing a Web service into UDDI. Developers simply supply a WSDL URL and a corresponding "BusinessEntity".
There is no standard for mapping a Web service into an RDF registry, although OWL-S has been released and promises to help satisfy this need. A Web service's metadata, such as a description of what it does, its inputs, its outputs, its pre- and post conditions, along with the technical details of how to physically invoke and interact with the service, can all be described in RDF via vocabulary defined by OWL-S. Encoding the details about a service as RDF greatly increases the ability to semantically discover and use Web services. In an order process, for instance, there needs to be a way to know that after calling the ProcessPO Web service one should next call the CheckPOStatus Web service to gather the status of the order.
A UBR (UDDI Business Registry) must have a standard publication API
The publication API of a registry is a common set of commands that are incorporated into client programs to access the facilities of the registry such as adding, deleting, or modifying a registered service. UDDI is solid in this area because it comes with a standard API defined in WSDL that allows a SOAP interface to the publication API. RDF has a proposal for RDF Net API (available from www.w3.org) that defines a SOAP interface for adding, updating, or deleting RDF statements, but it is not a standard and is not tuned for use in defining ISR content.
An ISR must support data described in multiple languages
To accommodate multiple languages, the specific language used in information objects must be described by standard language tags. This allows data to be presented to the person utilizing the information in their preferred spoken/written language (as opposed to programming language.) The latest, most comprehensive proposal is RFC 3066bis (available from http://inter-locale.com). Both UDDI and RDF support the xml:lang adornment of literal values, which can be set to RFC 3066bis values. This is a very important concept as it moves the registry beyond the general discovery of business logic and actually increases the usefulness of the information resulting from the use of a service.
An ISR must support multiple categorization hierarchies.
In both UDDI and RDF, you can classify an entry using multiple classification hierarchies.
In UDDI, categorization hierarchies are called "taxonomies." Organizations such as UNSPSC (Universal Standard Products and Services Codes) and NAICS (North American Industry Classification System) have created sets of UDDI technical models, known as tModels, which describe an interesting categorization hierarchy. (For more information, see http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm.)
RDF calls classification hierarchies "ontologies," which are usually defined using OWL. A number of organizations are creating ontologies. One of the most interesting ontologies is OWL-S, whose authors are trying to create an ontology that will fully define all Web services artifacts and that will include defined places and formats for describing information required during the integration phase of using the registry contents. For more information, see the DARPA Agent Markup Language Homepage at www.daml.org.
Categorization hierarchies should come with user-understandable, locale-specific names
UDDI tModels contain a name property, which can be decorated with the xml:lang property. OWL does not currently have a standard way to attach display information to an ontology although RDFS (RDF Schema) has some predefined properties such as rdfs:label and rdfs:comment, which can be used for the human readable display name and description. These can also be decorated with the xml:lang tags.
It should be easy to derive relationships among entries in the UBR
Two categorization hierarchies can each contain a category that defines the same type of item, but the two categories are often named differently in the different structures (for example, "cars" as opposed to "automobiles"). This situation can occur, for example, when the categories were created by two different people or organizations. To rationalize such overlaps, one must be able to indicate that a category in one hierarchy is the same as a category in another hierarchy. Users that query one category will then also get corresponding entries in the other category. This is currently not possible in UDDI, but is the reason OWL was created. This capability is KEY to making registries useful as it allows meta-relationships to be defined that will allow programs to dynamically find alternative services when their intended service is unavailable, for example.
There are two significantly different aspects to discovery. One is the ability to discover registries to query. The other is the ability to find the appropriate service in a registry.
The first problem could be addressed by a number of industry-accepted standards and de facto standards such as WS-Discovery (http://msdn.microsoft.com) or zeroconf (www.zeroconf.org), or even the locators that are pluggable into software solutions such as WebMethods Fabric (www.Webmethods.com). After configuring some locator rules on the client, one can find all the available registries that match those rules. The rules could define something like a UDP broadcast, the URL of a well-known server, or parameters for a SOAP call.
After your tool has discovered one or more registries, you should be able to navigate easily through the entries in a registry. There should be at least three navigation methods:
ISR queries must have the following attributes:
- Naive walking through all the entries with links among related entries. Optimally, you should be able to infer links so that relationships can grow without having to define every possible link.
- Pre-built or user-defined query that returns a specific entry.
- Query that returns a group of entries, where each entry allows you to navigate to entries that relate to any returned entry. This navigation method is analogous to performing a Google search and then following HTML links from one of the pages returned by the search.
The ISR must nicely support querying data with text descriptions in different languages Text-matching queries in the current incarnation of UDDI must be written specifically to the desired language of the return text. This means queries cannot be pre-canned. It also means that even simple queries must know that "en", "en_US", "en_UK" and "en_AU" are all English. If a query was written for just one of the flavors of English a complete set of English results would not be returned.
When reading the description of a Web service, the user should not get back all English entries, just the one entry that best matches the user's desired language. This becomes even more complicated when a user speaks two languages. For instance, for someone that reads French and English, a query must contain OR clauses for "fr", "en", "en_US", "en_UK" and "en_AU", but in UDDI there is no way to define that any French dialect is preferable to any English dialect.
There is a nice proposal from Jeremy Carroll of HP and Addison Phillips of webMethods (http://inter-locale.com/whitepaper/iswc2004.pdf) on how to solve this problem nicely for RDF query languages. A similar solution could be implemented as an extension to the existing UDDI inquiry API.
The results of the queries should be filtered based on authorization rules
Even within one company, there are services that some users should see and others they should not. Such a security scheme allows administrators or project leads to set up filters that surface "approved" services to the appropriate developers.
UDDI does not yet have a standard data security implementation. Rudimentary security requires you to have a valid user name and password. After a person has been authorized to access a UDDI registry, he/she can then query all information in the registry. UDDI has no mechanism for selectively sharing a certain subset of information with one group of users and another set of information with another group of users. Many UDDI vendors have added proprietary extensions to support security on the data within the UDDI registry, but the security definitions are not portable.
RDF does not have a standard, meaningful security model, and given its roots in the open world of the Web, there does not seem to be widespread interest in solving this problem.
An ISR needs a standard inquiry API
UDDI comes with a WSDL that defines a SOAP interface to the inquiry API. RDF has a proposal for the RDF Net API that defines a SOAP interface for querying RDF statements, but it is not a standard.
An ISR needs a standard query language
UDDI defines a standard query language. RDF has a proposal for an RDF Net API that defines a SOAP interface for querying RDF statements, but it is not a standard. RDF also does not have a standard query language, although the RDF Data Access Working Group is working to define one.
After a service has been discovered, the following features are required to enable you to create a composite application:
An ISR contains a link to the service's WSDL
Either the full contents of the WSDL or a link to the WSDL must be available for a client to interact with the service via the SOAP protocol. This is a common property of UDDI service entries.
OWL-S can be used to define the elements of the WSDL as RDF. In theory, an OWL-S-aware program could read the RDF information and invoke the service without a WSDL. The UBR needs the ability to generate (preferably dynamically) the WSDL from the RDF data in order to support non OWL-S aware SOAP tools that require the WSDL.
A UBR contains information about the prerequisites of each operation
Most operations that are part of a business process have some sort of context, required call order, or other prerequisite. WSDL does not describe prerequisites of a service invocation, which means that information needs to reside in the UBR itself. The OWL-S project is trying to describe this for RDF.
For all the limitations of UDDI, there is currently no alternative registry standard that can match its maturity or features. RDF has much interesting potential, but is still far from being a viable ISR. A combination RDF and UDDI implementation needs mature implementations of a number of components and interfaces that are currently in their infancy. These include:
- A standard query language being worked on by the RDF Data Access Working Group (www.w3.com)
- A query language that usably supports data in multiple languages
- A comprehensive and standardized programming API
- A Web services (SOAP, WSDL) API
- A way to find services across multiple registries
UDDI implementations are solving real-world business problems today and UDDI is not standing still. There are proposals to add RDF features to UDDI. Some UDDI vendors have extended their implementations with more granular security controls, merged service namespace across multiple registries, and identification of equivalent services to allow on-the-fly service failover without requiring hardware clustering. There are solutions for the limitations of UDDI, but it remains to be seen if these and future proposals will be accepted, and if the timeline toward workable implementations will stay ahead of the progress in the RDF world.