Finding a Service

Thousands of Web Services are available already, and we have barely scratched the surface.

Design-Time Searching

The current state of the practice for finding Web Services is to go to a site such as SoapClient (shown in Figure 13.6), or XMethods, SalCentral, IBM, or Microsoft, and do a keyword search.

Figure 13.6: A UDDI search for a Web Service.

My first search for the local temperature yielded a Web Service that nicely returned the local temperature, but as it was in Celsius, I wanted a conversion service. Although this is useful, my second search came up empty, despite the fact that there were services available that would convert Celsius to Fahrenheit.

This is pretty much exactly the same shoal the object-oriented and component industries washed up on. The absolute number and variety of components from which you could pick exceeded the ability of most developers to find and use. We need to learn from industries that have solved this problem, such as the electronic component industry, and bring some of their best practices to bear.

This is going to involve an ontology and some directed search to help developers gradually close in on what they are looking for.

Run-Time Searching

Meanwhile, the longer-term intent is to use these technologies to do selection of Web Services on the fly while the system is being used. Most information systems professionals would, at this point, say "No way." There are so many impediments to this that it almost doesn't seem worth pursuing.

However, I know of at least one example that is close enough to make this plausible. Several years ago I met the head of a firm that had become successful dispatching overseas phone calls. The firm's customers were all the major long distance voice companies and all the major undersea cable operators (some of whom were also long distance voice companies). This company kept real-time data on quality of service (number of drops, noise on the line, etc.), capacity, and real-time pricing per channel or cable. Each overseas call was routed to a switch that selected a circuit and completed that portion of the call. This dispatch was done in milliseconds. Each long distance phone company got the best possible rate for each call. The cable operators, through dynamic pricing, could maximize the utilization of their fixed assets, and the end user got a higher-quality call.

I think this provides an "existence proof" for the concept of run-time service selection. However, we need to keep in mind that this example was in a highly circumscribed domain. Essentially there was only one message type, everyone subscribed to the same protocol, and all participants were known ahead of time.

This is where dynamic selection of Web Services will get its start: selecting from a known list of providers. Eventually, as we'll describe later, this may branch out to include heterogeneous (but compatible) WSDLs and inclusion of newly discovered providers.