Sharp R.The poor man's guide to computer networks and their applications.2004

for use and can be found by the SOAP lookup service. In particular, this involves publishing the existence of the web service in a service registry, in a manner analogous to what we have seen in the case of Corba. Details of how to do this can be found on the Web at:

http://xml.apache.org/soap/docs/index.html

The Client for an Apache SOAP web service has to construct the SOAP messages to be sent to the Server, and must receive and analyse the responses. To facilitate this, Apache SOAP provides a number of classes from packages under org.apache.soap for constructing and manipulating essential objects for SOAP. The most important of these are summarised in Table 12.3.

Table 12.3: Main classes in the Apache SOAP environment

A complete skeleton for a Client for the Blipper web service is shown in Figure 12.6. To complete the Client, it is necessary to provide implementations for all the methods; as an example, the complete implementation of the add method is shown in Figure 12.7. It is important to note that, in relation to the examples which we have seen previously, the methods all carry a URL as an extra parameter, namely the URL at which the service is available.

To make use of a web service in a practical application a description of the service must be produced in a standard format. This document, which is encoded as an XML document, is structured according to the rules of the Web Service Description Language (WSDL) [39], and includes:

A de nition of the service interface;

A de nition of the service implementation;

If it is a concrete implementation rather than an abstract service description which is being described, a description of the service endpoint (typically the URL used for contacting the service).

As in the cases of RMI and CORBA, the description must be propagated to the service registry as part of the process of publication of the service. A protocol known as the Universal Description, Discovery and Integration (UDDI) protocol is used by service providers

import java.io.*; import java.net.*; import java.util.*;

import org.apache.soap.util.xml.*; import org.apache.soap.*;

import org.apache.soap.rpc.*;

public class BlipClient

{public void blip(URL url, int i) throws Exception

{int nblip = add(url, i)

System.out.println(new Date() + ": " + Integer.toString(nblip,10)

+" blips");

}

public static void main(String[] args)

{try

{URL url = new URL("http://xxxxxxxxx"); start(url,20);

blip (url, 1);

blip (url, 4); stop (url);

}

catch (Exception e)

{ e.printStackTrace(); }

}

public static void start(URL url, int i) throws Exception { // implementation of start

}

public static int add(URL url, int n) throws Exception { // implementation of add

}

public static int stop(URL url) throws Exception { // implementation of stop

}

Figure 12.6: Skeleton for a Java client for the Blipper web service

public static int add(URL url, int n) throws Exception

{// Set up call of remote method Call call = new Call();

// SOAP encoding specification

String encodingStyleURI = Constants.NS_URI_SOAP_ENC; call.setEncodingStyleURI( encodingStyleURI );

//Set parameters for service locator call.setTargetObjectURI( "urn:xmethods-Blipper" ); call.setMethodName( "add" );

//Create vector with parameter(s) and insert into Call object Parameter param1 = new Parameter("n", int.class, n, null);

Vector params = new Vector(); params.addElement( param1 ); call.setParams( params );

// Invoke the remote service

Response resp = call.invoke(url, "/Blipper");

// Deal with the response if( resp.generatedFault() )

{// The call did not succeed. Fault f = resp.getFault();

System.err.println( "Fault= " + f.getFaultCode()

+ ", " + f.getFaultString() ); throw new Exception();

} else

{// The call was successful. Retrieve return value. Parameter result = resp.getReturnValue();

Int addobj = (Int) result.getValue(); return addobj.intValue();

}

}

Figure 12.7: Implementation of method add for the Blipper web service

Figure 13.1: A multi-tier system with three tiers

The Client is a client of the middle-tier server, which deals with the actual application and is itself a client of the database server in the lowest tier.

cover a lot of ground, and run to several hundred pages, so they are not really suitable as introductory material.

For full details of Internet protocols, you need to refer to the Internet Requests for Comments (RFC's), of which several important ones are listed in the Bibliography. These can all be obtained from the Internet itself via the Web page:

http://www.rfc-editor.org/rfcsearch.html

from where you can search for and retrieve RFCs by number or keyword. It is not possible to see directly from an RFC which status it has, i.e. whether it describes an accepted standard, a proposed standard or just a draft for comment. To nd this out, you need to look at the latest version of the list of Internet standards; this list is itself an RFC, currently RFC3300. Standards from the International Telecommunications Union (ITU- T), the International Organization for Standardization (ISO) and IEEE can be purchased from these organisations.

These notes have focussed on how to construct distributed applications based on the simplest form of client-server model, with one or more clients and a single server. While this is an important and very much used model, it is by no means the only one. Many interesting systems use multi-tier models, where a server can itself be a client for one or more other servers. A simple example of this is shown in Figure 13.1, which shows a three-tier architecture, involving presentation, an actual application and data storage.

A further development of this is to use hierarchical architectures, in which participating processes are organised in a tree-like structure, and where information passes up and down

99

the branches of the tree. Other systems make use of a set of cooperating agents. Agents may be static (permanently resident on particular systems) or mobile, and exchange information in an intelligent manner in order to solve some problem. A good source of information about this type of system is the book by Omicini et al. [33], which describes the architecture of agent systems and how agents communicate in order to solve their given problems, while reference [2] gives a speci c example of the use of agents for information retrieval in the Internet.

Finally, you may nd it interesting to look at the so-called GRID architecture, a recent trend in the design of very large distributed systems, which potentially o ers users global access to computational power and other resources. The essence of a GRID is { by analogy with the electric grid { that it o ers access to resources without the users having any idea where the resources actually come from. Reference [5] describes the ideas in detail.

c Robin Sharp 2004