Topic 7a: Approaches to Web Services

Earliest approaches to networked applications

Earliest approaches did not involve XML or HTTP at all. Instead, client and server applications exchanged binary (non XML) data using custom (non HTTP) protocols: examples include CORBA, RMI (Sun), DCOM (Microsoft).

The philosophy was very much to develop distributed applications in the same manner as standard programs: the clients for these applications were typically standalone programs, rather than web applications, such as a Visual Basic or Java desktop application which needed to communicate with a remote database over the network. Therefore, non-network programmers felt relatively "at home" with these technologies.

The arrival of the true Web Service (XML over HTTP)

The arrival of XML as a data format led to the development of distributed approaches which exchanged XML, rather than binary data. Furthermore, the XML was sent using the standard protocol of the web, HTTP, delivered over port 80

So why XML over HTTP?

We know that XML will follow certain syntax rules, so parsers (e.g. DOM or SAX) can be used to interpret the data
By contrast, each older approach (CORBA, RMI, DCOM etc) used its own data format, each of which was different, and also typically exchanged binary data (non human readable)
The use of HTTP over port 80 means that they are unlikely to be blocked by corporate firewalls
Traditional distributed approaches such as CORBA use their own protocols and ports so firewall blocking is more likely

Remote Procedure Call Methods (XML-RPC and SOAP)

The first XML/HTTP-based approach we will look at is the Remote Procedure Call (RPC) approach. RPC-based web services share similarities with CORBA and the like in that they seek to allow the developer to develop the application in the same manner as a non-networked application. The basic unit is the function (also known as method or procedure); when you want to call the web service, you call a function much like you would in a regular program

Reminder: a function is a reusable module of code, such as the JavaScript functions you wrote when we did AJAX

The Web Service specifies a list of functions which clients may call over the net

Example of the RPC approach

If HitTastic! developed an RPC-based Web Service, it might offer a list of functions such as:

searchForSongByTitle(title)
searchForSongByArtist(artist)
searchForSongByAll(title,artist,year)
getWeekOfRelease(title,artist)
getBiggestHit(artist)

Each client could then call any one of these functions, depending on what they wanted to do.

Here is an example of code which calls an RPC web service. (note that this is a 'pseudolanguage' based on PHP: the code would not look exactly like this, but I've simplified it to illustrate the point)


$artist = $_POST["artist"]; 
$h = WebService('hittastic.com').getBiggestHit($artist);
echo "Biggest hit of $artist is: ";
echo  $h.title + " released in " + $h.year;

$songs = WebService('hittastic.com').searchForSongByArtist($artist);

for($i=0; $i < $songs.length; $i++)
{
    echo $songs[$i].title + ' came out in ' + $songs[$i].year;
}

Note how in the code we are calling the functions of the Web Service

Firstly we are looking up the biggest hit of that artist, then looking up all hits by that artist

Note also how the code illustrates the guiding principles of RPC-based approaches:

Individual operations of the Web Service are defined by functions
Complex data structures or objects (such as the data structure representing a hit, returned by both method calls) can be transferred intact across the web from application to application
The goal is to enable the development of seamless web applications where the fact that you are calling a web service is invisible to the developer
... thus making non-network programmers feel "at home"

How is the data transported using RPC?

In RPC, not only the data itself (e.g. the artist), but also the type of the data (e.g. number or string), and the function we're calling, is encoded as XML and sent across the web This makes RPC messages both:

Very structured, which means RPC web services can be very robust as they can reject data of incorrect type (e.g. if you supply a string when the web service is expecting a number)
but also very bulky as a lot of information is sent as well as the actual data

Here is an example of some data which would be transferred across the web using XML-RPC:

<methodCall>
    <methodName>findChartPosition</methodName>
    <params>
        <param>

            <value>
                <string>Oasis</string>
            </value>
        </param>
        <param>

            <value>
                <string>Wonderwall</string>
            </value>
        </param>
    </params>

</methodCall>

and here is an example of the result from the web service:

<methodResponse>
    <params>
        <param>
            <value>            
                <int>2</int>

            </value>
        </param>
    </params>
</methodResponse>

Notice how the XML making up the request and response encodes not only the data itself, but also the structure of the function call:
- the function (method) name findChartPisition
- the data type of the information (string for the input data "Oasis" and "Wonderwall", and int (integer i.e. number) for the chart position returned
SOAP is similar but more complex

URL-based approaches

RPC based approaches distinguish different operations of the Web Service with different function calls. However, this is ignoring the fact that there is an existing Web feature that can be used to distinguish between different operations on the same server - namely the URL.

Rather than specifying different operations through functions, we can specify different operations by varying the URL
Each URL typically points to a server-side script which generates XML in response to the user's request
The web services you've seen so far take this approach

Why URL based approaches?

More in the spirit of the Web - you can use the Web's existing mechanism without having to deal with an extra layer
Less difficult to implement: to build a RPC-based application, you have to install RPC libraries on both the client (for formatting the message to send) and the server (for interpreting the message and formatting the response). By contrast, with URL-based approaches, all you need to do on the server side is provide appropriate XML in response to that URL, and on the client side use standard libraries (e.g. cURL) to send data to that URL.
There are no new standards to learn, so easier for beginners to get started: the only difference between developing a standard web application and a URL-based web service is that the script specified by the URL generates XML data, not HTML content
Typically we send just the data itself, and no extra information (see above) meaning data sent using URL-based approaches is less bulky

Plain old XML ("POX") over HTTP

POX is the most basic, and simplest, URL-based approach. Each web service operation is specified by a URL; you call the URL, using cURL for example, and get the XML back. For example, for HitTastic! :

hittastic.com/webservice.php?action=searchForSongByTitle&searchterm=Rock DJ
hittastic.com/webservice.php?action=searchForSongByArtist&searchterm=Beatles
hittastic.com/webservice.php?action=getWeekOfRelease&searchterm=Wonderwall,Oasis
hittastic.com/webservice.php?action=getBiggestHit&searchterm=Beatles

Notice how one script (webservice.php) is performing all the different Web Service operations. We tell the script which operation to perform using the action attribute. This is a common method of implementing "POX" web services, rather than having a separate script for each action. The script could then use if or switch statements to perform different actions.