Web Services

Web Services are a standard way to invoke functionality remotely, potentially from anywhere on the Web, and to express the interchange in terms of XML messages. Riding on the coattails of XML, Web Services have also sprung into almost uniform adoption, primarily because of a need to execute functionality remotely without getting tied into proprietary protocols for interchange.

Before Web Services, developers had to adopt a proprietary protocol to call functionality remotely. In many cases this meant CORBA or Microsoft's DCOM. But there were many problems with these, mostly related to their nonuniform availability. The other issue is that developers are becoming more and more aware of the advantages of mixing synchronous and asynchronous messaging to get the most optimal solutions. Most of the distributed programming interfaces greatly encouraged synchronous messaging.

Synchronous messaging means the calling program will block further execution and wait for a response. This is much more familiar for developers because it makes the remote invocation seem much like a subroutine call. However, there are several problems with this approach, especially as you start to scale up. First, as you begin to rely on more and more remote sources for functionality, you have to deal with the possibility that the service is not available, or is perhaps slow, due to a heavy load. Even if you are dealing only with local services, a synchronous interchange means that all the components and communication channels must be sized to meet peek demands, not average demands, which can often be an order of magnitude different. In asynchronous processing the calling program sends the message, but it does not wait for the reply. The reply (if there is one) will be received later, perhaps on a different channel. Web Services are highly flexible in this regard.

The way Web Services actually work, of course, involves another suite of XML-inspired acronyms. Start with the concept that there is a producer of the service and a consumer of the service. The consumer would like to invoke the producer's service. Here is how it works:

• The producer defines the interface in an XML language called WSDL.

• The producer registers the service in a UDDI registry.

• The potential consumer searches through the UDDI registry for a compatible service, finds the producer's service, and downloads the WSDL definition of how to invoke the service and what if anything to expect back.

• The consumer also gets the location of the producer's service.

• The consumer marshals his or her parameters into the format prescribed by the WSDL request schema, encloses the request in a SOAP envelope (another XML dialect; this one can reach a service destination even through a firewall), and sends the request to the location provided.

• The consumer is informed whether the request will be handled synchronously or not and either waits for the response or arranges to get a response later.

• When the response arrives, the consumer uses the other half of the WSDL definition to figure out what to do with all the tags in the response.

There are a host of issues with Web Services that deal with semantics. For example, for two companies to agree on what the tags in the WSDL messages mean, they will have to agree on the semantics of those tags. If this is to be done without human intervention (a long-term goal), there is an even greater need for a precise semantic definition.