Chapter 19: Web Services

If there is one term in this book that you will hear more than any other in the halls of information technology, it is the term Web services. Computer magazines, Web sites, and other sources have many reasons to tout the benefits of this XML-based technology. It is simply a powerful and extensible way of moving datasets from one point to another in this cyber world we live in today.

Over the last few years, Web services have grown from being a concept the industry has simply kept its eye on, to a reality that is now planned for in quite a number of recurring IT projects. Web services are filling a need that has existed in the IT industry for some time now, and the major vendors of the world are literally rushing in with solutions that their customers can use to address this need.

This chapter looks at the Web services world (at least to the extent possible in the limited space this chapter offers), including how some of the major vendors of the world make it rather simple for you to build and consume Web services using their tools and technologies. After this chapter, the next few chapters include more discussion on SOAP, WSDL, and the WS-* specifications.

Why Web Services?

One of the first steps in understanding Web services and why so much hype surrounds them is to first understand the problems that they are meant to address. Ever since the industry has moved away from monolithic mainframe computers to the client/server model, users have been wondering how to move data and calculations from one point in the enterprise to another. The Web services model is simply a step toward solving this problem.

Web services are meant to address the problems of connecting disparate systems, creating single repositories, and working towards the holy grail of programming-code reuse. Typically in a major enterprise, you rarely find that the computing thought of an entire organization and its data repositories reside on a single vendor's platform. In most instances, organizations are made up of a patchwork of systems-some based on Unix, some on Microsoft, and some on other systems. There probably won't be a day when everything resides on a single vendor's platform, and all the data moves seamlessly from one server to another. For that reason, various systems must be able to talk to one another despite their differences. If disparate systems can communicate easily, moving unique datasets around the enterprise becomes a simple process that eliminates the need for replication of systems and data stores.

Instead of being looked at as only a means to represent data as XML was viewed when first introduced, the markup language has now become a structure that can bring the necessary integration into the enterprise. XML's power comes from the fact that it can be used regardless of the platform, language, or data store of the system using it to expose datasets.

XML is considered ideal for data representation purposes because it enables developers to structure XML documents as they see fit. For this reason, it is also a bit chaotic. Sending self-structured XML documents between dissimilar systems doesn't make a lot of sense-it requires custom building of both the exposure and consumption models for each communication pair.

Vendors and the industry as a whole, however, soon realized that XML needed a specific structure. If rules are in place to clarify communication, the communication between the disparate systems becomes just that much easier. With rules in place, tool vendors can automate the communication process and the creation of all components for applications using the defined communication protocol.

The industry came together with the goal of defining a common ground for communication, and it settled on using SOAP (Simple Object Access Protocol) as the standard XML structure. The problem that SOAP solved was not a new one. Previous attempts at a solution included component technologies such as Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), and Internet Inter-ORB Protocol (IIOP). These first efforts failed because each of these technologies was either driven by a single vendor or (worse yet) was very vendor- specific. It was, therefore, impossible to implement any of these across the entire industry.

SOAP enables you to expose and consume calculations, complex data structures, or just tables of data that have all their relations in place. SOAP is relatively simple and easy to understand. Like various other Web-based technologies such as PHP or ASP.NET, Web services are also primarily engineered to work over HTTP. With that said, though, there are moves in enterprise to also send SOAP structures via other transport protocols such as TCP. Even though those moves are in place, Web services are still being built to flow primarily over HTTP. If you use HTTP, the datasets you send or consume can flow over the same Internet wires that are already established, thereby bypassing many firewalls (as they move through port 80). Implementing Web services over HTTP is rather simple because these networks are already in place and ready to use.

So what's actually going across the wire? As I just stated, Web services generally use SOAP over HTTP using the HTTP Post protocol. An example SOAP request (from the client to the Web service residing on a Web server) takes the structure shown in Listing 19-1.

Listing 19-1: A sample SOAP request

      POST /MyWebService/Service.asmx HTTP/1.1      Host: www.wrox.com      Content-Type: text/xml; charset=utf-8      Content-Length: 19      SOAPAction: "http://www.wrox.com/HelloWorld"      <?xml version="1.0" encoding="utf-8"?>      <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xmlns:xsd="http://www.w3.org/2001/XMLSchema"        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">          <soap:Body>            <HelloWorld xmlns="http://www.wrox.com/" />          </soap:Body>      </soap:Envelope> 

Take note that this is a request which is sent to the Web service from the client (or consumer) to invoke the HelloWorld WebMethod (WebMethods are discussed later in this chapter). An example SOAP response from this Web service is shown in Listing 19-2.

Listing 19-2: A sample SOAP response

      HTTP/1.1 200 OK      Content-Type: text/xml; charset=utf-8      Content-Length: 14      <?xml version="1.0" encoding="utf-8"?>      <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xmlns:xsd="http://www.w3.org/2001/XMLSchema"        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">          <soap:Body>          <HelloWorldResponse xmlns="http://www.wrox.com/">            <HelloWorldResult>Hello World</HelloWorldResult>          </HelloWorldResponse>          </soap:Body>      </soap:Envelope> 

In the examples from Listings 19-1 and 19-2, you can see that what is contained in this message is an actual XML file. Beyond the normal XML declaration of the <xml> node, you see a structure of XML that constitutes the SOAP message. A SOAP message uses a root node of <soap:Envelope> that contains the <soap:Body> or the body of the SOAP message. Other elements that can be contained in the SOAP message (but are not shown in the preceding example) include a SOAP header, <soap:Header>, and a SOAP fault <soap:Fault>.

Note 

For more information about the structure of a SOAP message, be sure to check out the SOAP specifications. You can find them at the W3C Web site, w3.org/tr/soap. SOAP will also be discussed in the next chapter of this book.