Web Services Mechanics


There are several more difference between Web Services and other remote methods.

Vendor-Neutral Application Program Interface Exposed as Extensible Markup Language

To reiterate, the essential part of Web Services is creating an interface that can be bound with XML. Some Web Services are XML interfaces on legacy systems, and some are new programs built specifically with an XML interface. Using XML as the binding mechanism decouples the consumer and producer. The primary decoupling is at the binding level; the two systems no longer need to use the same binding scheme, and indeed need to know very little about each other.

Document-Style Application Program Interface

In a traditional remote procedure call, the called routines must agree on number and order of parameters being passed back and forth. By default, Web Services calls are set up exactly the same. (Default refers to the use of tools that promote the use of Web Services, such as Microsoft's Visual Studio Programming environment; the behavior that results when you set up the Web Service using Wizards; or the behavior that results when you don't override the default behavior). If you define a service with three parameters, you will get the stub of a calling program with the same three parameters.

However, this behavior can be overridden.[99] By putting the interface in "document mode" (kind of an odd way to describe it), you essentially allow the producer the option of "finding" the parameters in the incoming XML document. Clearly there are limits to what you can find, but if the information is in the document, tagged as agreed on, and in an equivalent structure, you can extract the parameters. This can drastically reduce the impact of a change to a message, and it allows the same producer to handle multiple different requests.

Asynchronous Processing

Another level of decoupling possible with Web Services, but not the default, is support for asynchronous processing. A synchronous process is one where the initiator of a request waits for the response before doing anything else. An asynchronous process doesn't wait. For humans, a phone call is synchronous; voice mail is asynchronous.

People become confused on this concept with computer architectures when they start talking about many "layers" simultaneously. Generally, asynchronous processes need queues to buffer up requests in case the respondent is busy servicing another call. The confusion comes when people see a queue, and assume the process is asynchronous. Some part of the process probably is asynchronous, but the end-to-end process may not be. A Web site may have a queue and may process requests asynchronously, but if the end user (or requesting process) is waiting on the response, the end-to-end process is synchronous. Note that this makes the definition of synchronous somewhat subjective (it depends on which process you're reviewing).

Programmers and programming environments by default promote synchronous processing. However, synchronous processing is extremely inefficient. Synchronous processing environments must be set up and tuned to average (or really two standard deviations around average) response time. Imagine you have a compute-intensive service that requires 1 second of server time for each request. If the requests come in asynchronously—that is, you don't care about the response time—you could handle 60 requests a minute and wouldn't care if they were bursty (came in bursts) or leveled. If it is set up for synchronous processing, the configuration is greatly dependent on the response time requirement and how bursty the arrival rate is. So if your requirement is to supply 2-second response time, and the arrival rate averages 60 per minute, but could be as high as 10 per second, you would need five servers to handle the load (each on average used only 20% of the time).

Most developers immediately respond with, "But our system has to be synchronous." Processes do work better synchronously, but all processes could be done asynchronously, and many at very little penalty other than some additional design time. Many interesting hybrids of interfaces can be partially synchronous, or synchronous for default case and asynchronous for other cases.

It is beyond the scope of this book to go into how to do this, but in the context of the semantics of Web Services, the important point is that the Web Service interface can be set up to handle messages asynchronously, which is exactly what you will want to do in many cases.

Getting around the Internet in a SOAP Envelope

SOAP originally stood for standard object access protocol, although there is some movement toward a rename to service-oriented architecture protocol, to take advantage of where this parade is headed, or just dropping the expansion altogether.[100][101][102]

Regardless of the terminology, SOAP is just an envelope (Figure 13.1), a container in which to ship an XML payload. The SOAP envelope was designed to allow for easy routing around the Internet, including through firewalls (over port 80, the port that Internet Web servers us to service http: requests). The SOAP envelope transports its payload to the destination, where it is released in the form of an XML message that can invoke a Web Service.


Figure 13.1: SOAP is an "envelope" for transmitting an XML message.

Describing the Interface with Web Services Description Language

Web Services description language (WSDL) is an XML language used to describe the interface to a Web Service. It is possible to use Web Services without WSDL. If you already know the interface to a Web Service, you can just access it. But WSDL was invented for those cases where you don't already know the interface to the Web Service.

Figure 13.2 shows the basic sequence of activity. The requestor gets the WSDL file, which describes the location of the service and the messages that can be called on it. The requestor then calls the service.

click to expand
Figure 13.2: Using WSDL.

This would be a good time to pause and note that the time between message 2 and message 3 in Figure 13.2 might be short or long. By "long time," I mean human time. The current state of the practice is that a human finds the WSDL files and then configures the request, by hand, to make the Web Service call. We call this design time. It is usually hours to days. We'll discuss later what needs to be in place to convert this to a run-time activity.

Finding a Service with Universal Description, Discovery, and Integration

Universal description, discovery, and integration (UDDI) is a registry for Web Services. It serves the same function as the Yellow Pages, in that it lets you find out about services that you may not have been aware of (provided the service has registered with the registry). Figure 13.3 shows the sequence of steps and technologies used to invoke a previously unknown service. First the provider of the service registers the service with a UDDI service registry (step 1 in the diagram). Later, potential consumers of the project look for and eventually find a service that will do what they want. Their search was a UDDI search; what they received was a WSDL description of the messages they would use to invoke the service. As in the WSDL-only example, there is a step, which is currently manual (step 4), where the consumers take the WSDL and incorporate it into their system. At the time of use, they construct an XML message with their request, stuff it in a SOAP envelope (step 5), and send it to the destination they learned about from the registry.

click to expand
Figure 13.3: A UDDI-based registry of Web Services.

The service provider accepts and processes the message, composes a reply (also an XML message), and sends it back in a SOAP envelope (steps 6, 7, and 8). Finally the consumer consumes the message.

[99]See http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.html?dwzone=webservices for a description of how to set the parameters to override this default behavior.

[100]See http://archive.devx.com/javaSR/articles/smith1/smith1–1.asp for further information.

[101]See http://www-106.ibm.com/developerworks/webservices/library/ws-mvc/?dwzone=webservices for further information.

[102]See http://www.vbxml.com/soap/articles/tk2/ for further information.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net