3.6. Publishing a Web Service

Up to now, this chapter has covered guidelines for designing and implementing your Web service. Just as important, your Web service needs to be accessible to its intended clients. Recall that some Web services are intended for use by the general public. Other Web services are intended to be used only between trusted business partners (inter-enterprise), and still others are intended for use just within an enterprise (intra-enterprise).

Regardless of whether a service is to be accessible to the public, other enterprises, or even within a single enterprise, you must first make the details about the Web service—its interface, parameters, where the service is located, and so forth—accessible to clients. You do so by making a description of the Web service available to interested parties. As noted in “Web Services Description Language” on page 36, WSDL is the standard language for describing a service. Making this WSDL description available to clients enables them to use the service.

Once the WSDL is ready, you have the option to publish it in a registry. The next section describes when you might want to publish the WSDL in a registry. If you make the WSDL description of your service available in a public registry, then a Java-based client can use the JAXR APIs to look up the description of your service and then use the service. For that matter, a client can use the same JAXR APIs to look up the description of any Web service with an available WSDL description. This section examines registries from the point of view of a service developer.

3.6.1. Publishing a Service in a Registry

Publishing a service in a registry is one method of making the service available to clients. If you decide to publish your service in a registry, you decide on the type of registry to use based on the likely usage scenarios for your service. Registries run the gamut from public registries to corporate registries available only within a single enterprise.

You may want to register Web services for general public consumption on a well-known public registry.

When you make your service available through a public registry, you essentially open the service's accessibility to the widest possible audience. When a service is registered in a public registry, any client, even one with no prior knowledge of the service, may look up and use the service. Keep in mind that the public registry holds the Web service description, which consists not only of the service's WSDL description but also any XML schemas referenced by the service description. In short, your Web service must publish its public XML schemas and any additional schemas defined in the context of the service. You also must publish on the same public registry XML schemas referred to by the Web service description.

When a Web service is strictly for intra-enterprise use, you may publish a Web service description on a corporate registry within the enterprise.

You do not need to use a registry if all the customers of your Web services are dedicated partners and there is an agreement among the partners on the use of the services. When this is the case, you can publish your Web service description—the WSDL and referenced XML schemas—at a well-known location with the proper access protections.

3.6.2. Understanding Registry Concepts

When considering whether to publish your service via a registry, it is important to understand some of the concepts, such as repositories and taxonomies, that are associated with registries.

Public registries are not repositories. Rather than containing complete details on services, public registries contain only details about what services are available and how to access these services. For example, a service selling adventure packages cannot register its complete catalog of products. A registry can only store the type of service, its location, and information required to access the service. A client interested in a service must first discover the service from the registry and then bind with the service to obtain the service's complete catalog of products. Once it obtains the service's catalog, the client can ascertain whether the particular service meets its needs. If not, the client must go back to the registry and repeat the discovery and binding process—the client looks in the registry for some other service that potentially offers what it wants, binds to that service, obtains and assesses its catalog, and so forth. Since this process, which is not insignificant, may have to be repeated several times, it is easy to see that it is important to register a service under its proper taxonomy.

Register a service under the proper taxonomy.

It is important to register your service under the proper taxonomies. When you want to publish your service on a registry, either a public or corporate registry, you must do so against a taxonomy that correctly classifies or categorizes your Web service. It is important to decide on the proper taxonomy, as this affects the ease with which clients can find and use your service. Several well-defined industry standard taxonomies exist today, such as those defined by organizations such as the North American Industry Classification System (NAICS).

Using existing, well-known taxonomies gives clients of your Web service a standard base from which to search for your service, making it easy for clients to find your service. For example, suppose your travel business provides South Sea island-related adventure packages as well as alpine or mountaineering adventures. Rather than create your own taxonomy to categorize your service, clients can more easily find your service if you publish your service description using two different standard taxonomies: one taxonomy for island adventures and another for alpine and mountaineering adventures.

You can publish your Web service in more than one registry. To further help clients find your service, it is also a good idea to publish in as many applicable categories as possible. For example, a travel business selling adventure packages might register using a product category taxonomy as well as a geographical taxonomy. This gives clients a chance to use optimal strategies for locating a service. For example, if multiple instances of a service exist for a particular product, the client might further refine its selection by considering geographical location and choosing a service close to its own location. Using the travel business service as an example, such a service might register under the taxonomies for types of adventure packages (island and mountaineering), as well as under the taxonomies for the locales in which the adventure packages are provided (Mount Kilimanjaro or Tahiti), thus making it as easy as possible for a prospective client to locate its services.

3.6.3. Registry Implementation Scenarios

Once you decide to publish your service and establish the taxonomies that best identify your service, you are ready to implement your decisions. Before doing so, you may find it helpful to examine some of the registry implementation scenarios that you may encounter.

When a registry is used, we have seen that the service provider publishes the Web service description on a registry and clients discover and bind to the Web service to use its services. In general, a client must perform three steps to use a Web service:

These three steps may produce three scenarios. The particular scenario depends on when the binding occurs and whether the client is implemented solely for a specific service or is a generic client. The following paragraphs describe these scenarios. (See Table 3.2 for a summary.) They also note important points you should consider when designing and implementing a Web service. (Chapter 5 considers these scenarios from the point of view of a client.)

• Scenario 1: The Web service has an agreement with its partners and publishes its WSDL description and referenced XML schemas at a well-known, specified location. It expects its client developers to know this location. When this is the case, the client is implemented with the service's interface in mind. When it is built, the client is already designed to look up the service interface directly rather than using a registry to find the service.

• Scenario 2: Similar to scenario 1, the Web service publishes its WSDL description and XML schemas at a well-known location, and it expects its partners to either know this location or be able to discover it easily. Or, when the partner is built, it can use a tool to dynamically discover and then include either the service's specific implementation or the service's interface definition, along with its specific implementation. In this case, binding is static because the partner is built when the service interface definition and implementation are already known to it, even though this information was found dynamically.

• Scenario 3: The service implements an interface at a well-known location, or it expects its clients to use tools to find the interface at build time. Since the Web service's clients are generic clients—they are not clients designed solely to use this Web service—you must design the service so that it can be registered in a registry. Such generic clients dynamically find a service's specific implementation at runtime using registries. Choose the type of registry for the service—either public, corporate, or private—depending on the types of its clients—either general public or intra-enterprise—its security constraints, and so forth.