Tutorial 4: Developing and Deploying Web Services with OMII

You can choose to deploy a Web Service on different levels in the OMII Server architecture, and the choice depends on what feature you wish to utilize from the OMII middleware. In general, an OMII server hosts three types of Web Services:

(i) Axis Web Service: An Axis Web Service is deployed on the OMII Base layer which consists of Apache Tomcat and Axis. By default, there is no security feature included in this type of web services and it is the most basic of all the three Web Service types. However, users can choose to set up HTTPS which provides a transport level security on the OMII Base. (See Securing an OMII Server with SSL.)

(ii) Non-PBAC Web Service: A non-PBAC Web Service is deployed on the OMII Extension layer which offers access to context information of a service request. The OMII extension layer also provides WS-Security support such as message authentication.

(iii) PBAC Web Service: This type of Web Service is similar to the non-PBAC Web Service except it also uses the PBAC (Process Based Access Control) feature. PBAC provides user authorization in terms of service access and it is useful for enforcing business process in service-orientated architectures. PBAC Web Services are deployed on the OMII Extension layer.

Document Scope

Using the Counter Service example which we are going to explain shortly, we are going to illustrate how to develop and deploy each of the three Web Service types mentioned above on an OMII server.

Prerequisites

All Web Services discussed in this document are deployed and tested on OMII_2.0.0 and above. There is a significant difference between OMII_2.0.0 and the releases prior to this. For version 2.0.0 and above, the OMII server and client use AXIS and Apache WSS4J libraries in place of the GEMSS Transport & Messaging and WSSECIT libraries in the previous releases for message payload signing and authentication.

For the prerequisites of each Web Service type, please refer to the Minimum Platform Requirements under the appropriate Web Service section.

The Example Service - Counter Service

The example service used throughout this tutorial is a Counter Service. It allows users to perform the following operations:

create : A counter instance is created on the server.
read: The value of a counter instance is returned.
add: A counter instance value is incremented by a given amount.

The Counter Service provides an interface to more than one counter instance and each instance contains an instance property that stores the current value of the counter instance. Users who use the service can create an instance of his/her own counter and obtain a unique ID that points to the specific instance. He/she can then use the unique ID to read or add to the value of the unique counter instance with subsequent calls to the service. If you are familiar with the Globus Toolkit, this example closely mirrors the structure of the WSRF Counter Service distributed under GT4 and the WS-Core distribution, except that the services we develop do not implement the WSRF notification feature.

How to Develop an Axis Service

Minimum Platform Requirements

1. An OMII_2.0.0 (or above) Server with Base layer.

The Four Steps

1. Writing the service.

2. Writing the WSDD.

3. Deploying the service.

4. Developing the client.

Step 1: Writing the Service

In this section, we are going to write a simple Web Service that uses the Axis libraries. We will refer to it as AxisCounterService. Take a look at the code for the service at Appendix A: AxisCounterService.java. In order to make our code simple to read, we have not included any exception catching in the code.

The logic behind the code is as follows: when a new counter instance is created, a unique UUID (Universally Unique ID) is generated as a reference to the instance. A client can then use the UUID to read the value of the referenced instance or to add a desired value to it. Note that the value of the instance is stored in a file, and we use file locking to ensure that only one operation is performed on one instance at one time.

We compile AxisCounterService with this command:

$javac -g AxisCounterService.java -classpath <LIB>/activation.jar:<LIB>/jaxrpc.jar:<LIB>/axis.jar

From this point onwards, we shall use <LIB> to refer to <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib. If the above compilation is successful, you will get AxisCounterService.class and Counter.class.

We create a directory structure omii/test/service and copy AxisCounterService.class and Counter.Class to omii/test/service.

Step 2: Writing the WSDD

To deploy the service written in Step 1, we need a WSDD (Web Service Deployment Descriptor) file where the deployment parameters are defined, as follows:

<deployment xmlns="http://xml.apache.org/axis/wsdd/"

xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<parameter name="className"

value="omii.test.service.AxisCounterService"/>

</service>

</deployment>

We save the above as axis-counter-service-deploy.wsdd. Let us take a closer look at what the parameters mean:

Service Name:

This specifies the location where our web service can be found. If we combine this with the base address of our Web Services container, we get the full URI of the web service. For example, if the base URL is http://localhost:18080/axis/services, our service's URI would be http://localhost:18080/axis/services/AxisCounterService.

Class Name:

<parameter name="className" value="omii.test.service.AxisCounterService"/>

This parameter refers to the class which implements the service interface (in our case, it is omii/test/service/AxisCounterService from the previous section).

Allowed Methods:

This parameter allows all public methods in the class AxisCounterService to be accessible by clients.

Scope:

The scope refers to the deployment scope when the value is set to "request". This means whenever there is a request to the web service, a new service implementation instance is created to deal with the request. The service instance will be removed after the request is complete.

Step 3: Deploying the Service

To deploy the service, we need to first package the web service classes in a jar file. In addition, we also need to include in the jar a manifest file which contains information about the class being packaged. The manifest file looks like this:

Manifest-Version: 1.0

Created-By: Steve Crouch (OMII)

Class-Path: axis.jar activation.jar jaxrpc.jar

Name: OMII

Title: AxisCounterService

We save the above manifest file as man.txt. Recall from Step 1 that we have placed AxisCounterService.class and Counter.class in the directory structure omii/test/services/. The omii in the command below refers to this directory structure which contains the input classes. This is the command we use to create the jar file:

$jar cvmf man.txt axis-counter-service.jar omii

At this point, we obtain a jar file called axis-counter-service.jar. We are now ready to deploy the web service. The deployment involves doing the following:

(i) Copy axis-counter-service.jar to <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib.

(ii) Change the owner and group of axis-counter-service.jar to some appropriate values, e.g.

$chown omii_tomcat_owner:omii_tomcat <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib/axis-counter-service.jar

(iii) Using the WSDD file written in Step 2, we can now deploy the AxisCounterService with the Axis AdminClient tool as follows (make sure the OMII container is started before you execute the following command):

$java -classpath <LIB>/axis.jar:<LIB>/activation.jar:<LIB>/jaxrpc.jar:<LIB>/commonslogging.jar:<LIB>/commons-discovery.jar:<LIB>/saaj.jar:<LIB>/mail.jar org.apache.axis.client.AdminClient -lhttp://localhost:18080/axis/services/AdminService axis-counter-service-deploy.wsdd

What this command does is to copy the content of axis-counter-service-deploy.wsdd and append it to <your-omii-server-home>/jakarta-tomcat- 5.0.25/webapps/axis/WEB-INF/server-config.wsdd.

To check if the deployment is successful, point your browser to http://localhost:18080/axis/servlet/AxisServlet. You should see AxisCounterService listed as one of the services on the container.

Step 4: Developing the Client

We need to develop a client in order to communicate with the web service on the server. The Axis WSDL2Java tool makes writing the client easy by generating stub classes (from the Web Service WSDL) that can be used by the client to talk to the service.

Here is the command to generate the stubs (make sure the OMII container is running at this point):

$java -classpath <LIB>/axis.jar:<LIB>/activation.jar:<LIB>/jaxrpc.jar:<LIB>/commons-logging.jar:<LIB>/commons-discovery.jar:<LIB>/saaj.jar:<LIB>/mail.jar:<LIB>/wsdl4j.jar org.apache.axis.wsdl.WSDL2Java -o . -d Request -p omii.test.client http://localhost:18080/axis/services/AxisCounterService?wsdl

The option -o refers to the output directory, -d refers to the deployment scope, -p overwrites all namespaces to package mappings and uses this package name instead, and the last argument on the command line refers to the AxisCounterService WSDL URI. If the above is run successfully, you should be able to find all the stub classes under omii/test/client.

Refer to Appendix B: AxisCounterClient.java which shows a simple client written using the generated stubs. Do not forget to replace http://test.omii.ac.uk:18080... with your own machine URL and port number.

This client implements the following workflow: create a counter resource -> read the counter initial value -> add 5 to the counter value -> read the changed value. You may choose to implement a different workflow if wish.

To compile the client code, do this:

$javac -g AxisCounterClient.java -classpath .:<LIB>/jaxrpc.jar:<LIB>/activation.jar:<LIB>/axis.jar

Now we are ready to test the web service with our client. To do so, run the following command:

$java -classpath .:<LIB>/jaxrpc.jar:<LIB>/saaj.jar:<LIB>/activation.jar:<LIB>/xmlsec.jar:<LIB>/axis.jar:<LIB>/commons-logging.jar:<LIB>/commons-discovery.jar:<LIB>/mail.jar <LIB>/wsdl4j.jar AxisCounterClient

If the run is successful, you will see some output messages on the screen. For example:

UUID: 07B2B240-E7C7-11D9-B41C-B058A163BE2F

Initial value: 0

Changed value: 5

Take a look at /tmp on your server machine. You should find a file, for example 07B2B240-E7C7-11D9-B41C-B058A163BE2F.ser which is the serialized file of the newly created counter instance uniquely identified by its UUID.

How to Develop a Non-PBAC Service

Minimum Platform Pre-requisite

1. An OMII_2.0.0 (or above) Server with Base and Extension layers.

2. An OMII_2.0.0 (or above) Client.

Recall that a non-PBAC Service includes security features in its implementation. Hence, a fully installed OMII-Client is required to provide the security and transport configuration needed to implement the client-side security structure.

The Four Steps

1. Writing the service

2. Writing the WSDD.

3. Deploying the service

4. Developing the client

Step 1: Writing the Service

We will refer to the service which we are going to write here as NonPBACCounterService. Take a look at the example code in Appendix C: NonPBACCounterService.java. Again, we have not included any exception catching in the code in order to make it simple to read.

If we compare the implementation of the NonPBACCounterService with the AxisCounterService described in the previous section, they are quite similar except a non-PBAC Service class extends the EScienceService class which in turn provides us with access to the EScienceService context.

As you can see in this particular implementation, we use the EScienceService context handler to access the distinguished name of an authenticated remote user, as a way to demonstrate how the E-Science handler could be used to access context information (below shows the relevant code excerpt taken from Appendix C). The code prints the distinguished name in the Tomcat catalina.out log file when a clients request is made to the web service. We shall take a look at the log file when we run a client request against the service in Step 4 later.

ServiceContext ctx = getServiceContext();

Principal pUserSubjectDN = ctx.getEScienceContext().

getSecurityContext().getAuthenticatedSubjectPrincipal();

String userSubjectDN = new DNParser(pUserSubjectDN.toString()).

getStandardStringDN();

testLogger.log(Level.INFO,"NonPBACCounterService - Getting User

Subject DN: "+ userSubjectDN);

Another significant feature of the NonPBACCounterService is that it implements the message signing and authentication provided by the WS-Security. We shall look at this in more detail when we write the WSDD file in the next section.

Now, we are ready to compile NonPBACCounterService.java with the command below. Recall that <lib> refers to <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib:

$javac -g NonPBACCounterService.java -classpath <LIB>/itinnov-gridservit-0.3.0.jar:<LIB>/itinnov-grid-auth-1.1.2.jar:<LIB>/itinnov-grid-utils-1.2.jar:<LIB>/axis.jar:<LIB>/activation.jar:<LIB>/jaxrpc.jar

If the compilation is successful, you will get NonPBACCounterService.class and Counter.class. Create a directory structure omii/test/service and copy these two classes to omii/test/service.

Step 2: Writing the WSDD

Here is the WSDD file which contains all the information required to deploy the NonPBACCounterService. Please refer to the explanation stated in Step 2 of the AxisCounterService if you are not already familiar with the basic parameters of a deployment descriptor.

<deployment xmlns="http://xml.apache.org/axis/wsdd/"

xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

</handler>

</handler>

</requestFlow>

</handler>

</responseFlow>

</service>

</deployment>

For a non-PBAC service, we add the SecurityContextInitHandler and the IntegrityEnforcementHandler to the request and response flows. These handlers are used to authenticate in-coming messages and sign outgoing messages on the server-side. To find out more about this, please refer to Writing the Deployment Descriptor.

Make sure to replace <your-omii-server-home> with your OMII Server home directory, which is /usr/local/OMII under a default installation. Save the above file as nonpbac-counter-service-deploy.wsdd.

Step 3: Deploying the service

Manifest-Version: 1.0

Created-By: Karen Ng (OMII)

Class-Path: axis.jar activation.jar jaxrpc.jar itinnov-gridservit-0.3.0.jar itinnov-grid-utils-1.2.jar

Name: OMII

Title: NonPBACCounterService

We save the above manifest file as man.txt. Recall from Step 1 that we have placed NonPBACCounterService.class and Counter.class under the directory structure omii/test/services/. The omii in the command below refers to this directory structure which contains the input classes. Below is the command used to create the jar file:

$jar cvmf man.txt nonpbac-counter-service.jar omii

At this point, we obtain a jar file called nonpbac-counter-service.jar. We are now ready to deploy the web service. This involves the following few steps:

(i) Copy nonpbac-counter-service.jar to <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib.

(ii) Change the owner and group of nonpbac-counter-service.jar to some appropriate values, e.g.

$chown omii_tomcat_owner:omii_tomcat <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib/nonpbac-counter-service.jar

(iii) Using the WSDD file written in Step 2, we can now deploy the NonPBACCounterService with the Axis AdminClient tool as follows (make sure the OMII container is running before you execute the following command):

$java -classpath <LIB>/axis.jar:<LIB>/activation.jar:<LIB>/jaxrpc.jar:<LIB>/commons-logging.jar:<LIB>/commons-discovery.jar:<LIB>/saaj.jar:<LIB>/mail.jar org.apache.axis.client.AdminClient -lhttp://localhost:18080/axis/services/AdminService nonpbac-counter-service-deploy.wsdd

What this command does is to copy the content of nonpbac-counter-service- deploy.wsdd and append it to <your-omii-server-home>/jakarta-tomcat- 5.0.25/webapps/axis/WEB-INF/server-config.wsdd.

To check if the deployment is successful, point your browser to http://localhost:18080/axis/servlet/AxisServlet. You should see NonPBACCounterService listed as one of the services on the container.

Step 4: Developing the Client

The client for the NonPBACCounterService follows the same logic as the AxisCounterClient, but with a different implementation, which we will discuss shortly. First, take a look at the client source code in Appendix D: NonPBACCounterClient.java.

We will start by looking at the main function of the source code, the client takes in two input arguments: (i) the full path of the directory where all the security configuration files are stored, e.g. <your-omii-client-home>/nonPBAC-conf, and (ii) the full URI of the web service the client wishes to communicate with, e.g. http://<server>:18080/axis/services/NonPBACCounterService?wsdl.

String confDir = args[0];

String wsdlLocation = args[1];

To make the actual operation call on the service, the client calls the DynamicInvoker through its invokeMethod. This method takes in (i) the operation name, e.g. create, (ii) the portname, e.g. NonPBACCounterService and (iii) a string array containing the operation name and the portname, e.g.create(NonPBACCounterService).

DynamicInvoker invoker = new DynamicInvoker(wsdlLocation);

HashMap map = invoker.invokeMethod(operationName,portName,arbitraryArr);

The result from the operation call may be retrieved accordingly with the following:

for (Iterator it = map.entrySet().iterator(); it.hasNext();) {

Map.Entry entry = (Map.Entry) it.next();

String key = (String) entry.getKey();

Object value = entry.getValue();

String initialValue = value.toString();

System.out.println("Initial value : " + initialValue);

}

The client code can be compiled with the following:

javac NonPBACCounterClient.java -classpath .:<your-omii-client-home>/lib/itinnov-gridservit-0.3.0.jar

Now, we are ready to test the NonPBACCounterService. with the client we have just developed. Run the following command:

java -Djava.endorsed.dirs=<your-omii-client-home>/endorsed -cp <MY_CLASSPATH>:<your-omii-client-home>/nonPBAC-conf -Daxis.ClientConfigFile=$OMII_CLIENT_HOME/conf/client-config.wsdd NonPBACCounterClient <your-omii-client-home>/nonPBAC-conf http://<server>:18080/axis/services/NonPBACCounterService?wsdl

where <MY_CLASSPATH> is a list of all the jars in <your-omii-client-home>/lib. As explained earlier, the NonPBACCounterClient takes in two input parameters: <your-omii-client-home>/nonPBAC-conf and http://<server>:18080/axis/services/NonPBACCounterService?wsdl.

If the test is successful, you should be able to see some output on the screen which looks something like this:

Reading WSDL document from 'http://test1.omii.ac.uk:18080/axis/services/NonPBACCounterService?wsdl'

Preparing Axis dynamic invocation

Executing operation create with parameters:

UUID: a0bf2300-30ac-11da-9cec-b6b1e59517f1

Preparing Axis dynamic invocation

Executing operation read with parameters:

uid=a0bf2300-30ac-11da-9cec-b6b1e59517f1

Initial value : 0

Preparing Axis dynamic invocation

Executing operation add with parameters:

uid=a0bf2300-30ac-11da-9cec-b6b1e59517f1

inc=5

Preparing Axis dynamic invocation

Executing operation read with parameters:

uid=a0bf2300-30ac-11da-9cec-b6b1e59517f1

Changed value : 5

Recall that when we implement the NonPBACCounterService in Step 1, we use the EScience service context to retrieve the DN of the authenticated user and print the DN to the log file on the server. We can now take a look at the retrieved DN in <your-omii-server-home>/jakarta-tomcat-5.0.25/logs/catalina.out and see if you can spot the line similar to the one shown below:

INFO: NonPBACCounterService - Getting User Subject DN: EMAILADDRESS=client@test1.omii.ac.uk, CN=test1.omii.ac.uk, OU=OMII, O=ECS, L=none, ST=Hants, C=UK

How to Develop a PBAC Service

Minimum Platform Pre-requisite

1. An OMII_2.0.0 (or above) Server with Base and Extension layers.

2. An OMII_2.0.0 (or above) Client.

A fully installed OMII Client provides the security and transport configuration required to implement the security framework on the client-side.

The Four Steps

1. Writing the service

2. Writing the WSDD.

3. Deploying the service

4. Developing the client

Step 1: Writing the Service

In this section, we are going to develop a PBAC service using the Counter Service example. We refer to the service as PBACCounterService.

The PBACCounterService is set up in the same way as the NonPBAC service, where some handlers are added to the WSDD file to authenticate in-coming messages and sign outgoing messages. Similarly, PBACCounterService extends the EScienceService class which provides handlers to access information from the E-Science context.

In addition to what has been mentioned above, we include, as the name suggests, PBAC (Process Based Access Control) which controls user access to different operations offered by the Counter Service. For illustration purpose, in this particular example, we enforce an access control whereby when an instance of the counter is created, the client must carry out a read operation before he/she is allowed to add to the counter. To see how this is implemented, take a look at the source code in Appendix E: PBACCounterService.java.

Looking at the create method in the code, instead of generating a UUID as before, we generate a conversation ID which will be used as a unique reference to refer to the newly created counter instance.

String convId = createConvId();

If you take a look at createConvId(), this private function takes in the clients userIssuerDN and userSubjectDN and creates a unique conversation ID which can then be used by the client to communicate with the service. The userIssuerDN and the userSubjectDN are retrieved using an EScienceService context handler. Although both an UUID and a conversationID are unique numbers that can be used to refer to a counter instance, they are different in that a conversationID is mapped to a users certificate details. The mapping is useful when it comes to using PBAC to identify if the user is authorized to perform certain tasks.

Using the newly generated conversation ID, we authorize the user to have access to the read operation after an instance has been created. This is done with the following function:

createAuthorisation(convId, "read");

The above is a private function which retrieves a PBACAuthoriser object from the EScienceService context handler. If you take a closer look at the function, the PBACAuthoriser object is used to open the authorization for a particular user (identified by the users Issuer and Subject Dns) in order to carry out the read operation. The convId refers to a unique counter instance from which the user is allowed to read.

Now, let us take a look at the read operation. Given a conversation ID to refer to a particular counter instance, we check to make sure that the client is authorized to perform the read operation on the counter instance. The line below carries this out:

if ( isAuth(ctx, convId, "read").equalsIgnoreCase("Success") == true )

The function isAuth uses ctx, an EScienceService context handler to retrieve the PBACAuthoriser. The PBACAuthoriser is then used to check if a particular user, identified by the users Issuer and Subject DNs, is authorized to perform the operation read on the counter instance referred to by convId.

If the read operation is performed, the client will then be authorized to do add. This is implemented with the following function call.

createAuthorisation(uid,"add");

If you take a look at the add operation, we check, as we did before, to see if the user is authorized to do add with the following:

if ( isAuth(ctx, convId, "add").equalsIgnoreCase("Success") == true )

We will leave you to explore the rest of the code, which is quite straightforward. Now, to compile the code, do the following:

javac -g PBACCounterService.java -classpath <LIB>/itinnov-gridservit-0.3.0.jar:<LIB>/itinnov-grid-auth-1.1.2.jar:<LIB>/itinnov-grid-utils-1.2.jar:<LIB>/axis.jar:<LIB>/activation.jar:<LIB>/jaxrpc.jar

Recall that <lib> refers to /usr/local/OMII/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib. If the compilation is successful, we will get PBACCounterService.class and Counter.class.

As before, we create a directory structure omii/test/service and copyPBACCounterService.class and Counter.Class to omii/test/service.

Step 2: Writing the WSDD

The WSDD file is similar to that of the NonPBACCounterService.

<deployment xmlns="http://xml.apache.org/axis/wsdd/"

xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

</handler>

<handler name="SecurityContextInitHandler"

type="java:uk.ac.soton.itinnovation.grid.gridservit.wss4j.handler.

SecurityContextInitHandler">

</handler>

</requestFlow>

<handler name="IntegrityEnforcementHandler"

type="java:uk.ac.soton.itinnovation.grid.utils.wss4j.handler.

WSOutboundHandler">

<parameter name="passwordCallbackClass"

value="uk.ac.soton.ecs.iam.grid.utils.PWCallback"/>

</handler>

</responseFlow>

</service>

</deployment>

As before, we add the SecurityContextHandler and the IntegrityEnforcementHandler to the request and response flows. These handlers are used to authenticate in-coming messages and sign outgoing messages on the server-side.

Make sure to replace <your-omii-server-home> with your OMII Server home directory, which is /usr/local/OMII under a default installation. Save the above file as pbac-counter-service-deploy.wsdd.

Step 3: Deploying the Service

To deploy the service, we package the web service classes in a jar file and include in the jar a manifest file which contains information about the class being packaged. They are:

Manifest-Version: 1.0

Created-By: Karen Ng (OMII)

Class-Path: axis.jar activation.jar jaxrpc.jar itinnov-gridservit-0.3.0.jar itinnov-grid-utils-1.2.jar

Name: OMII

Title: PBACCounterService

We save the above manifest file as man.txt. Recall from Step 1 that we have placed PBACCounterService.class and Counter.class under the directory structure omii/test/services/. The omii in the command below refers to this directory structure which contains the input classes. Below is the command used to create the jar file:

$jar cvmf man.txt pbac-counter-service.jar omii

At this point, we obtain a jar file calledpbac-counter-service.jar. We are now ready to deploy the web service. This involves the following few steps:

(iv) Copy pbac-counter-service.jar to <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib.

(v) Change the owner and group of pbac-counter-service.jar to some appropriate values, e.g.

$chown omii_tomcat_owner:omii_tomcat <your-omii-server-home>/jakarta-tomcat-5.0.25/webapps/axis/WEB-INF/lib/pbac-counter-service.jar

(vi) Using the WSDD file written in Step 2, we can now deploy the PBACCounterService with the Axis AdminClient tool as follows (make sure the OMII container is running before you execute the following command):

What this command does is to copy the content of pbac-counter-service- deploy.wsdd and append it to <your-omii-server-home>/jakarta-tomcat- 5.0.25/webapps/axis/WEB-INF/server-config.wsdd.

(vii) To check if the deployment is successful, point your browser to http://localhost:18080/axis/servlet/AxisServlet. You should see PBACCounterService listed as one of the services on the container.

Step 4: Developing the Client

Take a look at the client code listed in Appendix F: PBACCounterClient.java. The source code for the PBACCounterClient is similar that of the NonPBACCounterClient. Hence, we will not be elaborating any further on this.

The client code is compiled with the following:

javac -g PBACCounterClient.java -classpath .:<your-omii-client-home>/lib/itinnov-gridservit-0.3.0.jar

Now, we are ready to test the PBACCounterService with the client we have just developed. Run the following command:

java -Djava.endorsed.dirs=<your-omii-client-home>/endorsed -cp <MY_CLASSPATH>:<your-omii-client-home>/conf PBACCounterClient <your-omii-client-home>/conf http://yourhostname.server.ac.uk:18080/axis/services/PBACCounterService?wsdl

where <MY_CLASSPATH> is a list of all the jars in <your-omii-client-home>/lib. The PBACCounterClient takes in two input parameters: <your-omii-client-home>/conf and http://<server>:18080/axis/services/PBACCounterService?wsdl.

If the test is successful, you should be able to see some output on the screen which looks something like this:

Reading WSDL document from 'http://test1.omii.ac.uk:18080/axis/services/PBACCounterService?wsdl'

Preparing Axis dynamic invocation

Executing operation create with parameters:

UUID: 23

Preparing Axis dynamic invocation

Executing operation read with parameters:

convId=23

Initial value : 0

Preparing Axis dynamic invocation

Executing operation add with parameters:

convId=23

inc=5

Preparing Axis dynamic invocation

Executing operation read with parameters:

convId=23

Changed value : 5