Checking Whether a Server Is Still Reacting

Assume you have a web server and you want to check periodically if it didn't crash again. Then, using a PHP script for this task can be a good idea. Just open a socket to the server and wait (the last parameter of fsockopen() is a timeout value). After this time has elapsed, you know if the server is online or offline.

Checking the status of a server (serverstatus.php)

 <?php    $server = 'localhost';   $port = '80';   $status = 'unavailable';   $fp = @fsockopen($server, $port, $errno, $errstr,     10);   if ($fp) {     $status = 'alive, but not responding';     fwrite($fp, "HEAD / HTTP/1.0\r\n");     fwrite($fp, "Host: $server:$port\r\n\r\n");     if (strlen(@fread($fp, 1024)) > 0) {       $status = 'alive and kicking';     }     fclose($fp);   }    echo "The server is $status."; ?> 

TIP

This works well if only one server's status must be checked. If there are several servers, this approach has some disadvantages. The call to fsockopen() might take up to the timeout value until the next command is executed. Therefore, all servers are checked sequentially and synchronously. This just takes too long for several servers. However, with PHP 5 and stream sockets, this can be done asynchronously. The code is a bit complicated, but Wez Furlong explains this approach in great detail at http://netevil.org/node.php?nid=280.

Understanding Web Services

Some people say Web Services are just old wine in new bottles because the idea behind them is far from new. The basic principle is: Two machines talk to each other. For instance, one machine contains some business logic or, more generally, some information, and the other machine requests this information (or wants to use the business logic).

This has been done for many years, but only a few years ago the major players sat together and started to work on protocols to put the whole communication on top of standards. Some of these standards are now under the aegis of the World Wide Web Consortium (W3C), whereas others are managed by the Organization for the Advancement of Structured Information Standards (OASIS) consortium.

A multitude of books are available on Web Services, with quite a lot of pages. However, in accordance with the concept of this phrasebook, this chapter puts it simple but still gives you all you need to know. There is a protocol that is used to transfer both the request to the Web Service and its response. There are several possiblities, but these two are most common:

• XML-RPC stands for Remote Procedure Call and uses a very simple XML dialect to transport function calls, parameters, and return values. This approach is sometimes called REST, for Representational State. There are some fierce debates about which is better, this protocol or the next one. To make a short and ugly story short: Both have advantages (and disadvantages).

• SOAP once stood for Simple Object Access Protocol, but because it is neither simple nor has too much to do with object access, today SOAP just stands for ... SOAP. It is a rather complex protocol but overcomes many of the limitations of XML-RPC (which was, by the way, created by some parties who also worked on SOAP).

Most of the time, XML-RPC or SOAP calls are transported via HTTP as the carrier protocol. However, other protocols are also possible, including Simple Mail Transfer Protocol (SMTP) or even User Datagram Protocol (UDP).

There is one more important aspect when using SOAP. When you know exactly how a Web Service is implemented, you also know how to call (access, or consume) it. However, many times this information is not available, so there must be a kind of self-description of the Web Service that contains all relevant information, such as which methods or functions are exposed, which parameters and data types do they expect, and what they return. This can be done using a specifically crafted XML file, as well. The standard behind that is Web Services Description Language (WSDL). Today, WSDL is used for all relevant Web Services because then using them is quite simple. Most server-side technologies offer one (or more) means to just read in the WSDL and then access the Web Service like you would access a locally available class.

Generating all this XML is quite complicated. Not that PHP doesn't have good XML support, but the syntax can be quite hard. Luckily, some extensions and external packages make using Web Services much easier. The following phrases each implement a Web Service that just adds two numbers. You will certainly be more imaginative and create some real-world Web Services, based upon this information.