Part III - Deploy a gTwitter server

Please note that due to the current funding situation, the NGS no longer supports a Web Service interface to its resources. We have kept this tutorial online in case it is of use for users of other Grids.

In the first part, we have done the exercises about client programming to use a GT4 web service, and now let's build such a service. The deployment on NeSC is a full GT4 with security, and we're not going to use security with out server. Let's open another terminal window and start our GT4 ws-core container.

$GLOBUS_LOCATION/bin/globus-start-container -nosec

The -nosec determines that the GT4 ws-core server will run in non-security mode.

1. What's involved in building a GT4 web service

There're several things to do:

• Define WSDL file(s) for the service, and factory service for multiple resource support;
• Write implementation code for the service;
• Write WSDD and security descriptor files;
• Compile and generate a GAR file;
• Deploy the GAR file to the container.

These steps are already done for the service running on NeSC. The files are here:

• gtwitter/
  
  • src/
    
    • schema/
    • wsdl/
      
      • Factory.wsdl - WSDL document to describe the factory service
      • GTwitter.wsdl - WSDL document to describe the gTwitter service
    • impl/
      
      • FactoryService.java - Implementation of factory service
      • GTwitterService.java - Implementation of the gTwitter service
      • GTwitterResource.java - Stateful resource to store a user information
      • GTwitterResourceHome.java - Home class to create a resource
      • GTwitterQNames.java - Common place to hold some public constant strings
      • GTDao.java - Data access object for database access to Derby
    • etc/
      
      • security-config.xml - A security configuration file, it specifies transport-level security in our case
    • deploy/
      
      • deploy-server.wsdd - Deployment descriptor to tell the container how to call our service
      • deploy-jndi-config.xml - JNDI configuration to tell the container how to locate the service

2. Modify to suit our local deployment

Because we will use nosec mode in our local deployment, we need to change a little to our code.

First, open deploy-server.wsdd file, and comment off the two securityDescriptor elements like this:

<!-- <parameter name="securityDescriptor" value="etc/gtwitters/security-config.xml"/> -->

Remember, there're two such elements in this file.

The next thing we need to do is to modify the client programs. Fortunately, we put the related block in the base class, so we only need to edit ClientBase.java file.

Comment off this line:

//Util.registerTransport();

and four lines of _setProperty method calls:

// ((Stub)factory)._setProperty(Constants.GSI_SEC_CONV,Constants.ENCRYPTION); 
// ((Stub)factory)._setProperty(Constants.AUTHORIZATION,NoAuthorization.getInstance());
// ((Stub)this.service)._setProperty(Constants.GSI_SEC_CONV,Constants.ENCRYPTION); 
// ((Stub)this.service)._setProperty(Constants.AUTHORIZATION,NoAuthorization.getInstance());

And the last piece to modify is the factory URI, we're going to point to our local server instead of NeSC, so replace this string:

https://tc07.nesc.ed.ac.uk:8443/

with this:

http://localhost:8080/

This means we change security connection https to non-security one http, and port number from 8443 to 8080.

And it's done. We can now compile and make the GAR file.

3. Compile and deploy the service

Our Ant build file contains everything we need to compile and generate the GAR file, just run ant:

cd ~/gtwitter ant

Then let's deploy it on our local GT4 ws-core container. You may need to have Apache Ant installed. If you see ANT_HOME required, try download Apache Ant and install into your home directory and then export ANT_HOME to it.

$GLOBUS_LOCATION/bin/globus-deploy-gar gtwitters.gar

4. Restart GT4 container and test client programs

In the GT4 container running window, press Ctrl-C to stop it, and restart it:

$GLOBUS_LOCATION/bin/globus-start-container -nosec

Back in your working window,

cd ~/gtwitter
ant register -Duser=myself -Dpass=myself
ant login -Duser=myself -Dpass=myself
ant update -Dstatus="hello my local service"
ant streams

5. Explore each other's service

Your gTwitter service is up and running, so why not tell your friends to get them onboard. Tell your friends about your local IP and let them modify their factory URI to call your services.

6. Extend gTwitter

One missing feature is to find out who has followed us. Now try to add this functionality to the gTwitter web service, so that we can issue ant followers command then we get a list of user names that have followed us.

Another feature that exists in Twitter is to send a direct message to a user. Let's try to implement this feature by sending a short message to somebody by username. The message should be added to that users update list, so that when that user issues streams command he/she will see your message.

Hints:

Web services are called remotely, so whatever we add, we must modify the server code. In order to expose this method as a remote procedure callable from the client side, we must define the interface in the WSDL file, in our case, it is GTwitter.wsdl file. First, we add an operation element in the port type section, and define required messages and data types. Then, we generate the stubs source code from this WSDL, and finally, we write our implementation of this method in the implementation source such as GTwitterService.java in our case. After that, we compile the server and deploy the service. When the service is running, we can write our client program to call the new method we implemented.