Discerning Web Services

Every technology that has been mentioned for providing Web services is nonproprietary, which means that there is no platform, tool, or language that cannot communicate with Web services (see Figure 1-11). This feature allows the service to be consumed just as today's standard Web pages and applications are. This feature provides the same advantage as providing a Web site today, reaching a broad audience utilizing various infrastructures.

Figure 1-11: Web service integration model

We have also been looking at available technologies. Nothing is required that is only in beta or isn't production ready. It is important to realize that the basic elements of Web services exist today, so nothing is preventing you from deploying and consuming them today. Of course, it will be easier as tools are developed to make the building of Web services easier. Also, as a builder of Web services today, you would likely be considered an early adopter, which carries the usual tradeoffs. It is very much like the situation that existed when the first Web sites came online. You could build Web sites using existing text editors, but it became much easier as HTML editors were developed and became available. Furthermore, you will likely spend time resolving some of the issues discovered as you are breaking ground in this new area.

To reinforce the notion that Web services can be built with today's technologies, this book uses only current, production-tested languages and services in its sample applications. This should help convince you that Web services are actually more of an implementation than a technology advance. This is a new way of thinking about how you build your applications.

In reference to the earlier discussion about the presentation layer, a Web service can allow for a single owner of an application's presentation while utilizing a partner's process. You can think of this process as functionality utilized in an application just as you could with any other business object. In relation to Web sites, instead of an HTML link to another document, the Web server links to a Web service and embeds its functionality into the document it delivers to the client (see Figure 1-12). Since this "linking" happens on the business layer, it is transparent to the user and cannot be readily identified through the resulting HTML code.

Figure 1-12: Application partnership through Web services

Notice that in Figure 1-12, the "Find a hotel" action is not a link. Instead of linking to the hotel's Web site through the browser, clicking this calls a function in the airline's application to access the hotel's Web service. The results of this function are then displayed through the airline's own presentations.

Depending on the implementation, a Web service can appear very similar to a Web application. So how do we better differentiate between the two? Are they mutually exclusive, or is one a subset of the other? This question can be answered simply: Web applications are designed for browsers; Web services are designed for applications. That means that Web applications are standalone applications, and Web services require a "call" by an application. Because they are always referenced by another application, Web services do not come with an interface for end users.

Note 

The applications consuming Web services may or may not be Webbased applications. Often this book refers to a Web application as the consumer due to its specific challenges, but it would be short sighted to think that standard desktop applications or device-driven applications could not also utilize Web services.

While it may seem pretty black and white, this differentiation starts to get a little grayer when you consider that some browsers can support XML natively. Thus, the service could be "called" by a browser directly, and the browser could display the response. However, this wouldn't be a shared process and defeats the whole objective we are trying to accomplish.

To better discern Web services from other applications, it might be helpful to consider a few different application scenarios and determine whether it is a Web service or a Web application. For this exercise, we take a look at a static Web page, an FTP file transfer, and an HTML form submission.

Note 

Please keep in mind that this is not an attempt to determine whether previous application models are "worthy" of being considered Web services. This is simply an attempt to provide a frame of reference to this new approach by analyzing current models with which you may already be familiar.

The Static Web Page

A Web page is probably a good scenario to analyze first, since most developers are familiar with Web pages, and they could be considered the ancestors of Web services. First, we need to look at the technology behind Web sites. Pages are requested and sent over HTTP, which runs on the TCP/IP transport layer. However, the document returned is in HTML format, another markup language that is much less stringent and more forgiving than XML. That would disqualify a Web page as a Web service. However, if the HTML in a Web page were built such that the page is a well-formed XML document, it could technically be qualified as a Web service. This would mean that all tags are closed, all tags are nested in order, and no HTML-specific codes (such as the nonbreaking space) are included. With all these restrictions, many Web pages in production would not pass XML validation (as they were likely not required to). Regardless, it wouldn't be true to the meaning of Web services, since XML-valid HTML still describes only the presentation of data and not the data itself. And what would be the value in qualifying Web pages as Web services? Web page delivery is well understood, and Web services should be differentiated from their predecessor. So, in summary, although a Web page could meet the basic requirements, we assume the common Web page exposed today is not a Web service.

FTP File Transfer

In this example, we look at a File Transfer Protocol (FTP) transfer process. Many processes in production today depend on this service, so it's another good scenario for comparing Web services with what we know and use today. Like Web pages, an FTP transfer uses a protocol that utilizes the TCP/IP layer so the communication method meets the criteria of a Web service. The second piece of the qualification is the XML data document. Most FTP processes use either a comma-delimited or a fixed-width format, which would not comply with the requirements. However, if you use XML to define the data being transferred, the application could qualify as a Web service.

Note that this FTP process would obviously not provide the functionality necessary for an interactive application, as FTP only confirms the sending of data and provides no opportunity for a custom response by the server. However, any thought that a Web service must provide a request/response behavior would be inaccurate. Of course, to have any real value, this process would likely only define half the actual service, since there would need to be an application on the server responding to the document deposited. The transfer of XML documents via Simple Mail Transfer Protocol (SMTP) into a mailbox would be very similar.

HTTP Form Submission

Finally, let's look at an HTTP form submission. We will assume, for the sake of discussion, that the response HTML document involved is defined in well-formed XML, also known as XHTML. Obviously, just like in the previous Web page scenario, HTTP and the document involved meet the criteria for a Web service. However, we need to take a closer look at the actual form submission process. To comply with the guidelines, this data should be submitted through an XML document or through a TCP/IP-compliant process. In case you are not familiar with the form submission process, the data from an HTML form can be submitted in two ways: GET and POST. GET actually takes the data in the form and concatenates it to the URL (Uniform Resource Locator) of the receiving process. POST treats the data slightly differently by including it in the request's HTTP header. Both of these methods are HTTP compliant and thus meet the criteria for a Web service.

Without any other logic, the browser would not be able to do anything beyond displaying the returned XML document. We will look later in Chapter 8 at how we might be able to take advantage of this process in an application by using additional components for handling this data and presenting it to the user in some useful manner.