A Web service is a business component that provides some useful facility to clients, or consumers. Just as Distributed Component Object Model (DCOM) is thought of as “COM with a longer wire,” a Web service can be thought of as a component with a truly global reach. Web services use a standard, accepted, and well-understood protocol called HTTP to transmit data, and a portable data format that is based on XML. HTTP and XML are both standardized technologies that can be used by other programming environments outside of the .NET Framework. So, you can build Web services by using Visual Studio 2005, and client applications (called consumers) that are running in a totally different environment, such as Java, can use them. The reverse is also true; you can build Web services by using Java, and write consumer applications in C#.
You can use several different languages with Visual Studio 2005 to build Web services. Currently, Microsoft Visual C++, Microsoft Visual C#, Microsoft Visual J#, and Microsoft Visual Basic .NET are supported, and it is likely that there will be others in the future. As far as the consumer is concerned, however, the language used by the Web service, and even how the Web service performs its tasks, is not important. The consumer's view of a Web service is of an interface that exposes a number of well-defined methods. All the consumer needs to do is call these methods by using the standard Internet protocols, passing parameters in an XML format and receiving responses also in an XML format.
One of the driving forces behind the .NET Framework and future releases of Windows is the concept of the “programmable Web.” The idea is that, in the future, systems will be constructed by using the data and services provided by multiple Web services. Web services provide the basic elements for systems, the Web provides the means to gain access to them, and developers glue them together in meaningful ways. Web services are a key integration technology for combining disparate systems together; they are the basis for many business-to-business (B2B) and business-to-consumer (B2C) applications.
Simple Object Access Protocol (SOAP) is the protocol used by consumers for sending requests to, and receiving responses from, Web services.
SOAP is a lightweight protocol built on top of HTTP. It is possible to exchange SOAP messages over other protocols but, currently, only the HTTP bindings for SOAP have been defined. It defines an XML grammar for specifying the names of methods that a consumer wants to invoke on a Web service, for defining the parameters and return values, and for describing the types of parameters and return values. When a client calls a Web service, it must specify the method and parameters by using this XML grammar.
SOAP is an industry standard. Its function is to improve cross-platform interoperability. The strength of SOAP is its simplicity and also the fact that it is based on other industry standard technologies: HTTP and XML.
The SOAP specification defines a number of things. The most important are the following:
The format of a SOAP message
How data should be encoded
How to send messages (method calls)
How to process replies
For example, consider a Web service called ProductService.asmx (in the .NET Framework, URLs for Web services have the suffix .asmx) that exposes methods for accessing the Products table in the Northwind Traders database (you will build this Web service later in this chapter). One such method called HowMuchWillItCost allows a client to supply the name of a product and a quantity. The method queries the unit price in the database to calculate the total cost of buying the specified quantity of the product. The SOAP request sent by the client might look like this:
POST /NorthwindServices/Service.asmx HTTP/1.1 Host: localhost Content-Type: application/soap+xml; charset=utf-8 Content-Length: 579 <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http:// www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <HowMuchWillItCost xmlns="http://www.contentmaster.com/NorthwindServices"> <productName>Chai</productName> <howMany>39</howMany> </HowMuchWillItCost> </soap12:Body> </soap12:Envelope>
The request contains two parts: a header comprising everything up to the <soap12:Body> tag, and the actual body of the message in the <soap12:Body> tag. You can see how the body encodes parameters—in this example, the name of the product is Chai and the quantity is 39.
The Web server will receive this request, identify the Web service and method to run, run the method, obtain the results, and send them back to the client as a SOAP result, like this:
HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: 546 <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http:// www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <HowMuchWillItCostResponse xmlns="http://www.contentmaster.com/NorthwindServices"> <HowMuchWillItCostResult>529</HowMuchWillItCostResult> </HowMuchWillItCostResponse> </soap12:Body> </soap12:Envelope>
The client can then extract the result from the body of this message and process it.
The body of a SOAP message is XML. The Web server expects the client to use a particular set of tags for encoding the parameters for the method. How does a client know which schema to use? The answer is that, when asked, a Web service is expected to supply a description of it-self. A client can submit a request to a Web service with the query string wsdl appended to it:
The Web service will reply with a description like this:
<?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" … targetNamespace="http://www.contentmaster.com/NorthwindServices" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> <s:schema elementFormDefault="qualified" targetNamespace="http://www.contentmaster.com/NorthwindServices"> <s:element name="HowMuchWillItCost"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="productName" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="howMany" type="s:int" /> </s:sequence> </s:complexType> </s:element> <s:element name="HowMuchWillItCostResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="HowMuchWillItCostResult" type="s:decimal" /> </s:sequence> </s:complexType> </s:element> </s:schema> </wsdl:types> … </wsdl:definitions>
This is known as the Web Service Description (a large chunk has been omitted to save space), and the schema used is called Web Services Description Language (WSDL). This description provides enough information to allow a client to construct a SOAP request in a format that the Web server should understand. The description looks complicated but, fortunately, Microsoft Visual Studio 2005 contains tools that can parse the WSDL for a Web service in a mechanical manner, and then use it to create a proxy object that a client can use to convert method calls into SOAP requests. You will do this later in this chapter. For now, you can concentrate on building a Web service.