SOAP and Web services
The Simple Object Access Protocol (SOAP) and Web services play a major role in the Microsoft .NET Enterprise Solutions platform. A Web Service is a piece of application code made available over the Web via standard Internet protocols such as HTTP and TCP/IP. SOAP is a lightweight protocol that travels on top of HTTP. It provides the information transport layer for application communication via Web services. Software engineers developing solutions that target the Microsoft .NET Enterprise Solutions Platform build applications that exchange data between various Web services to produce a single, cohesive distributed software application.
Simplicity is the fundamental principle behind the development of SOAP. SOAP does not introduce new technological innovations, but instead builds upon reliable, well known Internet standards like XML and HTTP. As a result, software engineers can leverage existing knowledge of the Internet to develop SOAP-based Web services targeting the Microsoft .NET Enterprise Solutions Platform.
That said, we can formulate three important points about what SOAP is:
SOAP is formatted using XML and transported through HTTP requests. A client sends a SOAP message to a server via HTTP and the server performs application logic based on the client request.
SOAP needs HTTP, nothing else. SOAP is not concerned with operating systems, development languages, or application object models.
SOAP works with existing firewalls, routers, and proxy servers. A network administrator does not have to go out and buy new hardware to support SOAP-based software systems.
Now that we have covered what SOAP is, we will discuss the two distinct types of SOAP messages:
-
Clients send SOAP messages to a server using a Call message.
-
Servers respond back using a Response message.
Listing 3.3 illustrates a SOAP Call message.
Listing 3.3 SOAP Call Message
POST /RegisterPets HTTP/1.1
Host: www.gasullivan.com
Content-Type: text/xml
Content-Length: xxxx
SOAPMethodName: http://www.gasullivan.com/PetService
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
<SOAP:Body>
<AddPetsToRegistry>
<XML Payload Goes Here!>
</AddPetsToRegistry>
</SOAP:Body>
</SOAP:Envelope>
The first four lines in Listing 3.3 are common HTTP syntax. POST is the request type. Hostname, Content-Type, and Content-Length are required for all HTTP messages. Notice the Content-Type of text/xml. XML keeps popping up everywhere! The text/xml value indicates that the payload of this HTTP request is XML. In fact, the SOAP message is a well-formed XML document comprised of a required <SOAP:Envelope> element, a required <SOAP:Body> element, and an optional <SOAP:Header> element. The <SOAP:Header> is not shown in the listing, but would exist between the Envelope and Body elements. A server receiving this message sees the SOAPMethodName in the HTTP Header and executes an AddPetsToRegistry procedure call to add our household pets to a fictitious pet repository at G.A. Sullivan.
Listing 3.4 shows a response to the SOAP Call message above.
Listing 3.4 SOAP Response Message
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxxx
<SOAP:Envelope xmlns:SOAP=" urn:schemas-xmlsoap-org:soap.v1"
<SOAP:Body>
<AddPetsToRegistryResponse>
<return><XML Payload Goes Here!><return>
</AddPetsToRegistryResponse>
</SOAP:Body>
</SOAP:Envelope>
Here we see a typical HTTP 1.1 response with an XML document as the response body. The top three lines are similar to the SOAP Call request. The first line is the HTTP response code and the second and third lines describe content type and length. Again we see the XML based SOAP message with the <AddPetsToRegistryResponse> element containing a <return> element. The actual payload of the response would be an XML document traveling as a child of the <return> element.
WSDL, DISCO, and UDDI
A Web Service accepts messages from a client, performs work based on information contained in the message, and sends a response back to the client. How does a client, or Web Service consumer, learn about the methods a Web Service exposes? This process is enabled through WSDL, the Web Service Description Language. This section explains WSDL and how it fits into the Web services picture.
WSDL is an XML specification that developers use to detail which methods, parameters, and protocols a Web Service exposes. WSDL can be loosely compared to a text-based COM type library that is not specific to any particular operating system platform. It acts as a contract between a Web Service consumer and the Web Service itself.
Imagine a set of cool web services that exist at a site called gasTIX.com. The gasTIX Web services allow customers to search for tickets to upcoming concerts and sporting events. As developers, all we know about is gasTIX.com, not specific endpoints at the site that expose WSDL documents to develop against. The Discovery Protocol (DISCO) defines an XML-based discovery document format, along with a protocol, giving us the ability to scour gasTIX.com for services of interest. The discovery page lists all Web services and the methods available for those services. It also details the expected parameters for each method and a description of the return value.
Taking this one step further, pretend we do not know the specific URL for the Web services we are interested in. The Universal Description, Discovery, and Integration (UDDI) specification allows Web Service authors to advertise the location of their services and gives Web Service consumers the ability to find these services.
NOTE
For more information on SOAP and Web services, see the following web links:
Microsoft Web services Developer Center: msdn.microsoft.com/webservices/
SOAP Specification Version 1.1: msdn.microsoft.com/xml/general/soapspec.asp
Web services Description Language 1.1: msdn.microsoft.com/xml/general/wsdl.asp