The next section will provide you with an introduction to web services and an overview of how they work and what they are. You will learn about wire formats such as SOAP, XML dialects such as WSDL, and how they all come together to enable the loose coupling, highly portable framework of web services.
Defining Web Services
Put simply, a web service is a service that is provided by a piece of software running on the Web. More specifically, it is a service that responds to requests on a specific TCP/IP port that are formatted in a specific way. The responses to these requests are also formatted in a specific fashion. Any network client that knows the format of sending and receiving messages can communicate with a web service.
Two of the main building blocks of web services are SOAP and WSDL. SOAP and WSDL are both discussed briefly later in the chapter. Entire books on the subject of web services will contain more specifics on both SOAP and WSDL; this book provides only a brief introduction of each topic and a discussion of how to create web services using Visual Studio .NET 2003.
Overview of SOAP
When a message is sent to a web service, it is sent via SOAP (Simple Object Access Protocol). SOAP is a wire format, which means some language or dialect that formats data transmitted on the wire. There are other wire formats, but SOAP is the format that is used to carry web service payloads from one endpoint to another.
In non-.NET applications, applications communicate with each other via RPCs (Remote Procedure Calls). The RPC mechanism is a standard that allows for one application to invoke a method hosted by another application and to obtain the results. There is a specific binary format for passing parameters on RPC calls and obtaining results. RPCs are almost always blocked by routers due to security problems.
Other binary standards for remote communication between applications (such as DCOM [Distributed Component Object Model or Distributed COM]) cannot be routed. As a result, RPC and DCOM fail when it comes to providing the capability for an application to communicate across routers or wide networks like the Internet.
SOAP provides an XML-based dialect for describing remote method invocations and message transmission between applications. If you encode a request to invoke a method at one end of a network connection and send it to a remote application, you can then receive the result of that method execution as another SOAP message sent back. This is the fundamental basis for web services.
A common misconception is that SOAP is a communication protocol, like HTTP. In fact, SOAP is only a wire formata specification for encoding messages that will be transmitted via network. When a client communicates with a web service via SOAP, the client is actually sending SOAP messages (called envelopes) within the body of an HTTP request. If you have played with Remoting much, you know that you can use SOAP to encode messages sent on non-HTTP TCP ports. It is important to realize the distinction between communication protocol and wire format because it will help you understand the more complex topics later.
Everything relevant to web services communications that utilize SOAP (some web services communication can be done with pure HTTP) takes place within the SOAP envelope. The idea of messages (rather than Remote Procedure Calls) is more and more becoming the preferred way of viewing web services.
The following is a sample of what an empty SOAP envelope might look like. Remember that SOAP is a specific dialect of XML, so all SOAP must be well-formed XML and SOAP elements must be included within the appropriate namespace for proper validation:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <!-- Header information, can be any well-formed XML including user credentials, etc --> </soap:Header> <soap:Body> <!-- The actual body of the SOAP envelope --> <!-- contains the serialized method invocation or results --> <soap:Fault> <!-- If an error occurred, it will be serialized here --> </soap:Fault> </soap:Body> </soap:Envelope>
You don't have to spend too much time learning the SOAP format. Visual Studio .NET 2003 and the .NET Framework abstract most of the work for you so that you can view web service execution as either RPC-like calls or transmissions of messages. If you want more detail on SOAP itself, you can consult the actual W3C specification at www.w3.org/2000/xp/Group. The XML Protocol Working Group site contains links to all the information you need on the SOAP specification and status of standardization of the latest version.
Overview of WSDL
For a client to know what methods are exposed by a particular service, the parameters of those methods, and how to interact with the service, the client must be able to obtain information about the service. That information is stored in a specific format called WSDL (Web Services Description Language).
This format describes the interface to the web service, including information about whether the service is communicating using a message-style format or using a more RPC-like method. For more information about WSDL, its format, and other details, you can check out the W3C site at www.w3.org/TR/wsdl.