Previous Section Next Section

The Role of Registries

As we look at the evolution of object programming and component programming models, it is clear that the concept of an object or component registry is an essential element in the framework, facilitating the discovery and the use of components. Imagine trying to write Java code without having access to a browsable set of JavaDocs, or working in Smalltalk without having access to a class browser. If you consider the Web services concept as an evolution of component programming, it follows that for the purpose of service discovery, you need to have access to registries of business and service descriptions that can be browsed and queried.

Recall the service-oriented architecture from Chapter 1, repeated here in Figure 7.1.

Figure 7.1. Service-oriented architecture.


In a service-oriented architecture, the service provider publishes the service description of a Web service to a service registry. The service requestor queries the service registry (through a find operation) to retrieve one or more service descriptions that meet certain criteria, fulfilling a step within the application's business processes. The service description contains sufficient information to allow a service requestor to bind to and invoke the Web service.

Service Discovery at Design Time and Runtime

It is important to note that service discovery can happen at application design time or at runtime. At application design time, a human designer, through a browser or other user interface, performs a find operation on a service registry, examines the result of the find, and incorporates the service description returned by the find into application logic. We discussed in Chapter 6 some of the tooling that can consume WSDL service descriptions and generate code for integration with the application.

In many cases, the service interface definition is used to build a proxy that the application logic uses to invoke the Web service and consume its response. The actual service implementation, including network location and other properties, such as which network protocol to use, is left unbound at design time, to be determined at runtime. At runtime, then, the application itself issues a find operation against the service registry to locate one or more service implementation definitions that match the service interface definition used by the application. Based on application logic such as best price, best terms, and so on, the application chooses which Web service from among the results of the find operation to invoke, extracts network location and other information from the service implementation definition, and invokes the Web service.

Multiple Mechanisms of Service Discovery

The role of the service registry in a service-oriented architecture can be fulfilled by several different mechanisms. Recall that the purpose of the registry is to provide mechanisms by which the service provider can deliver service description(s) to service requestors.

Figure 7.2 illustrates a continuum of service description techniques.

Figure 7.2. Kinds of service registries.


There is a trade-off here between simplicity of the registry mechanism and the sophistication of the publishing/searching techniques. Let's briefly discuss each of these points on the continuum.

The simplest approach is for the service provider to directly send the service description to the service requestor. This approach uses tried-and-true techniques such as e-mail, FTP, or even "sneaker-net" to file-transfer the service description to the service requestor. This approach is useful, particularly if the service requestor already has a business relationship with the service provider.

This approach is very simple—in fact, there really is no registry per se; manual techniques using network protocols implement the publish and find operations. However, the approach is not very dynamic and certainly provides little opportunity for anonymity. If for some reason the description of the service changes, it becomes more difficult for the service provider to communicate this to any and all service requestors that use that service. This approach does not yield very loosely coupled systems; the application must be reworked in order to change which business partner's Web service is invoked. Of course, the service requestor could cache the service descriptions in some sort of repository, but that technique then begins to look a lot less simple.

Many Web services runtimes, including Axis, provide a mechanism by which the Web Service description can be retrieved using a simple HTTP GET operation. In Chapter 6, we showed how the ?WSDL parameter can be used to return the WSDL for any Web service deployed to Axis.

The second approach uses basic Web techniques to publish and advertise Web service descriptions to a Web site. In this case, the Web site acts as a service registry, and the publish operation is simply an act of Web publication. A simple browser can retrieve a list of service descriptions and the find operation is complete. Simple techniques such as these provide the basics of a find operation, and in many cases this basic approach is sufficient for the requestor to obtain the service description.

Techniques such as IBM's ADS graphics/book.gif or Microsoft's .NET DISCO graphics/book.gif provide improvements on the simple HTTP GET. With this technique, the service provider publishes service descriptions to one or more Web sites, using one of the ADS or DISCO conventional file formats. The service provider then communicates the URL of one of these Web sites to potential service requestors. In fact, even that step is not necessary, because DISCO and ADS have been built with Web crawlers in mind. So, just as Web crawling built up directories of the World Wide Web, so could Web crawlers build up directories for the "Web service" Web.

With ADS or DISCO, the service requestor uses HTTP GET to do a find operation. The result of the find operation is a list of service descriptions. It is now up to the service requestor to determine which of the Web services is pertinent to the business task at hand and invoke that Web service. Although this approach does remove some of the update concerns for the service provider, it still doesn't give the service requestor much extra information about the purpose of the Web service, nor does it give much additional information about the service provider.

The third approach is a repository of WSDL documents. This is similar in spirit to the previous kind of service registry in that it uses HTTP GET as the primary means by which the service requestor retrieves the service description. However, a WSDL repository, such as SalCentral (, additionally offers improved facilities for the service requestor, such as notification when a service description has changed. SalCentral also offers good searching tools, including a rudimentary categorization technique. XMethods ( is another example of a public registry of WSDL documents.

The most sophisticated approach to service registries is Universal Description Discovery and Integration (UDDI) graphics/book.gif ( UDDI provides very sophisticated publish and find capabilities. UDDI includes much more information than just the service description, including business metadata and taxonomies of businesses and services. UDDI not only answers the question, "Where is the Web service located?" UDDI also addresses questions such as, "How does the requestor know what business is providing the service?" Unlike the other techniques, UDDI does not depend on any one particular mechanism of service description.

As we saw in Chapter 1, "Web Services Overview," the Web services community in the W3C has described two layers in the service discovery stack: an inspection layer and a discovery (UDDI) layer. So far, no standard has been proposed or emerged at the inspection layer. We expect that something in this space will emerge to augment UDDI at the simpler end of the spectrum.

Because there is only one standard for service discovery, this chapter will focus on the UDDI specification for service registry and how it is used. We will examine UDDI by reviewing its API and major data structures found in Version 1.0 of the UDDI specification. Throughout the chapter, we discuss the important role of the UDDI Business Registry graphics/book.gif ( We also examine the role of privately hosted UDDI registries as different implementations of the UDDI specification, addressing different service discovery needs. Having covered these roles, we can discuss the new features introduced in UDDI Version 2.0. We will conclude this chapter with an explanation of the best practices for registering WSDL-based Web service descriptions in UDDI.

Scenario Updates

As SkatesTown sells more skateboards, its network of suppliers expands. Let's examine some of the new partners SkatesTown now deals with:

  • The Sports Equipment Manufacturing Consortium (SEMC) is a self-funded consortium of the major manufacturers of sports equipment, whose mission is to establish a set of e-Business standards for this industry. SkatesTown belongs to the consortium and has started implementing and using the SEMC standards.

  • WeMakeIt Inc. is a large manufacturer of industrial components. Its business is to be a components supplier to a wide variety of different finished goods manufacturers. WeMakeIt Inc. manufactures a large range of components in its manufacturing sites in the USA, Europe, and Asia. Of particular interest to SkatesTown, WeMakeIt Inc. manufactures a line of small nylon wheels and wheel bearings ideal for skateboards. Joanna Pravard is the lead Web services developer for WeMakeIt Inc. Joanna is responsible for all of WeMakeIt Inc.'s Web services technologies, including its UDDI registries and its entry in the UDDI Business Registry.

  • A recently created e-marketplace, called e-Torus, has formed to provide efficient buying and selling of wheels and wheel bearings components to finished goods manufacturers. As part of the e-marketplace, e-Torus runs a private UDDI registry listing all the manufacturers of wheels, bearings, and related components. This private UDDI is also a place where service interface standards are established for the marketplace, making B2B buying and selling of these components more efficient and less error prone.

  • Al Rosen of Silver Bullet Consulting "discovered" e-Torus and got SkatesTown to use their e-marketplace services. It is through e-Torus that SkatesTown established its business relationship with WeMakeIt Inc.

  • Some smaller manufacturers, competing with WeMakeIt Inc. in the small wheels and related components e-marketplace, are also briefly introduced to illustrate the benefits of dynamic bind operations. This list includes wheel manufacturers, MakeCircles Inc. and WheelsMadeHere.

    Previous Section Next Section