Service Oriented Architecture

From BioAssist
Jump to: navigation, search

Contents

MyProxyWebService

The API and Taverna 2 Workbench plugin which comprise MyProxyWebService allow the construction of web services which can run jobs on DutchGrid (and similar Globus grids) on a user's behalf. The authentication data required is passed via SOAP headers to the specialised web service, and the Taverna plugin contains config panels and extra code to allow the entry and submission of this authentication data to the specialised web services in question.

The API provides all the tools you need to process and delegate certificates and pass the authentication information around using SOAP, both a the client and server ends. An example server and client are provided to show how it works.

The Taverna 2 Workbench plugin provides everything you need to use one of these MyProxy-enabled web services from within Taverna.

These documents are aimed at users using Linux/UNIX/Mac OS X environments. MyProxyWebService is as cross-platform as the JGlobus toolkit upon which it is based and these instructions can therefore be adapted by changing the file naming conventions used (e.g. "/home/richard/.globus" on Linux might become "C:\\Users\richard\Documents and Settings\.globus" on Windows, for instance).

The API

The API is intended for those who wish to interact with MyProxy and VOMS and submit jobs from their own code. For those wishing to write simple web services and clients, it may be easier to refer to the web service and client sections of these docs and download and modify the template example code.

Obtaining the code

The source code is maintained in a Subversion repository.

 svn checkout https://gforge.nbic.nl/svn/tavernagrid/MyProxyWebService/trunk/api

Specifying the API as a Maven dependency

In your pom.xml file, in the repositories section, add:

 <repository>
   <id>sara-central</id>
   <url>http://ws1.grid.sara.nl:21501/artifactory-2.0.0/repo</url>
   <snapshots>
      <enabled>true</enabled>
   </snapshots>
 </repository>

Then, in the dependencies section, add:

 <dependency>
   <groupId>myproxywebservice</groupId>
   <artifactId>api</artifactId>
   <version>0.0.1-SNAPSHOT</version>
 </dependency>

Prerequisites

You will need to know the addresses of your MyProxy, VOMS and WMS servers. Note that the address you need is the one that the server thinks and responds as - not necessarily the address it is aliased to. This is because any SSL certificate associated with the server will be from the real address and not the alias. You may find in some situations that this means two or more of these servers share the same URL, differing only by port number. This is perfectly normal.

For DutchGrid users at SARA, these three machines are:

 https://voms.grid.sara.nl:30018/   (for VOMS)
 https://voms.grid.sara.nl:7512/    (for MyProxy - as this is the same hostname as the VOMS server, you only need to download and import just the one certificate which will then work for both of them)  
 https://wms.grid.sara.nl:7443/glite_wms_wmproxy_server     (for WMS)

Once you have the names of your the WMS servers, you need to download its SSL certificate and add it to your local Java keystore. There's a good guide on doing this here. You'll need only to read the two sections of the document that refer to obtaining and installing the certificate. The alias to use in the keystore command should match the hostname of the server.

Now, you'll need to ensure you have your own Grid user certificate and key stored in the standard place, which is usually:

 ~/.globus

as usercert.pem and userkey.pem. You'll also need to create this directory:

 ~/.globus/certificates

and inside it place the certificate(s) of the CA which signed the three certificates you downloaded above. You'll need to ensure that the certificate(s) you place in here all have a filename ending in '.0', as this is a JGlobus requirement. For the DutchGrid, the certificate you need can be downloaded here.

Once you've downloaded the CA certificate(s), it(they) will also need to be loaded into the Java keystore using the same technique as you used above for the VOMS, WMS and MyProxy certificates.

Finally you'll need to know the VOMS DN and VO which you have been given permission to use with your personal certificate. For DutchGrid users at SARA, these are likely to be:

 /O=dutchgrid/O=hosts/OU=sara.nl/CN=voms.grid.sara.nl  (DN)
 lsgrid                                                (VO)

Structure of the code

The code is divided into a number of utility classes living in the "nl.nbic.tavernagrid.proxy" package, with the usefulness of each class depending on what it is you want to achieve. This wiki has one section per utility class explaining what it does. Each class is fully Java-doced and source code commented for your detailed information.

UserCertUtils

This class provides methods to load user certificates from the default .globus location, or from any other specified location. Both methods require the passphrase as a parameter to unlock the certificate's keyfile in order to be able to load it.

The certificates returned by this class can then be passed to VOMSUtils to have VOMS data added to it before delegation to WMS using WMSUtils. If using MyProxy, the unmodified certificate should be delegated to MyProxy using MyProxyUtils, and only after it has been retrieve from MyProxy should the VOMS data be added using WMSUtils before delegation to WMS.

VOMSUtils

This class allows VOMS data to be embedded into copies of user certificates provided by UserCertUtils, including expiration times. The modified certificates returned can be delegated to MyProxy using MyProxyUtils.

A cache is maintained of modified certificates generated by recent requests to prevent the overhead of having to repeat the same job.

MyProxyUtils

This class provides tools for both client and server tasks relating to MyProxy. At the client end, it takes a VOMS-enabled user certificate from VOMSUtils and delegates it to the MyProxy server. The username/password can be randomly generated by the user (it's a good idea to use the Java UUID tools for this), and are then passed to the server end via web service SOAP headers.

At the server end, MyProxyUtils provides methods to retrieve the delegated certificate from the MyProxy server using the username/password passed to the server via the web service SOAP headers.

Like VOMSUtils, a cache is maintained of recent requests to prevent the overhead of repeated unnecessary delegations.

SOAPUtils

SOAPUtils contains methods for creating and parsing the special additional SOAP headers required to make use of the MyProxy-enabled web services built using this API (see web server and client sections below). It also contains utility methods for making calls to such services and retrieving the results.

The default namespaces and names for the custom headers are defined in this class. If you're not using the tools from this class to construct SOAP envelopes, and you want to use the default namespaces and names in your client and server code, you'll need to refer to the static constants in this class to find out what they are.

The class makes use of instances of HeaderWriter and HeaderParser objects to perform the SOAP header manipulations. These are described below.

HeaderWriter

This interface defines the behaviour of a class which performs the insertion of SOAP headers. It comes with one default implementation which makes use of the Apache AXIOM toolkit.

HeaderParser

This interface defines the behaviour of a class which performs the parsing of SOAP headers. It comes with two default implementations; one which makes use of the the JAXWS toolkit via the WebServiceContext, the other which uses pure XML parsing with SAX and XPath.

WMSUtils

WMSUtils provides everything you need to submit a job to the WMS grid manager, monitor its progress, and retrieve results or failure messages. Crucially it also includes a method for delegating to the grid the user certificate retrieved using MyProxyUtils and modified using VOMSUtils (or directly from VOMSUtils if not using MyProxy).

Setting up a web service

Note that although template example code is provided for both synchronous and asynchronous web services, it is highly recommended always to use the asynchronous approach. This is mostly because the JGlobus toolkit upon which this is based is not thread-safe, which means that it can only ever serve one web service call at a time. If it's busy running a long synchronous job for someone, then it can't serve any other calls until that job is complete. However using the asynchronous method, it is possible to interleave requests for submission, monitoring and retrieval of jobs such that they do not block each other for excessively long periods of time.

The example service contains a single class, called Hello, inside the "nl.nbic.tavernagrid.proxy" package. The class contains both synchronous and asynchronous implementations of a "Hello World" style service using /bin/echo - if you're running a non-Linux machine you might need to change this command before it will work.

The example code has hardcoded server names etc. for DutchGrid/SARA users, and also has hardcoded user names. If you're running this elsewhere, or you're not me, you'll need to change them.

Obtaining the code

 svn checkout https://gforge.nbic.nl/svn/tavernagrid/MyProxyWebService/trunk/ws-server

The web service code is designed to be downloaded as template source code then modified for your own purposes. Therefore it is not available as a Maven repository artifact.

Prerequisites

The web service code prerequisites are the same as those for the API (see above), plus two more.

Your /dev/urandom device must have lots of entropy. The /dev/urandom device on the machine running the service needs to be providing sufficient amounts of randomness. If it isn't, then attempts to call services will result in 'randomStream == null' errors on the client side. The following command should return >= 3500 immediately before attempting to deploy the service, or start up an application server containing an existing service:

 cat /proc/sys/kernel/random/entropy_avail

If you don't get >= 3500, you'll need to restart the application server itself, not just stop/redeploy/restart the service.

To increase the value returned, do a Google search for increasing the urandom entropy on your particular OS.

You'll also need to have a Tomcat server to serve the service from (this has been tested with version 6.0), and the Tomcat server must have HTTPS enabled with a valid SSL certificate. There's a good guide to getting this sorted here. You'll probably need to generate your own new SSL certificate for Tomcat, unless you plan on purchasing an official one from the likes of Verisign, so ignore the bits of the docs about importing existing certificates. (Your Grid certificate is NOT an SSL certificate, so don't try to use it for this!).

The service works by making use of annotations to get the web service context injected into it, and to auto-generate the WSDL. This is a JAXWS feature. The service makes use of the Axis2 framework, which complies with the JAXWS standards. You could potentially swap Axis2 for CXF or any other JAXWS compliant framework without having to modify any of the source code.

An example asynchronous server (recommended)

In the example code, you'll find a trio of methods called "startSayHello()", "checkSayHello()" and "getSayHello()". Stepping through the code of each will demonstrate the various steps involved in publishing and running an asynchronous service.

startSayHello():

  1. Declare the signature for the WSDL endpoint by using annotations on the Java method. The WSDL endpoint will have the same name as the method, and have parameters of the same names and types as the method.
  2. Parse the SOAP headers and retrieve/delegate the MyProxy certificate to the grid:
    1. Specify the location of the CA signing authority certificate, which by default in this code is at ~/.globus/certificates (see prerequisites above).
    2. Use SOAPUtils to parse the MyProxy information from the header.
    3. Use MyProxyUtils to retrieve the certificate.
    4. Create a proxy to the certificate using VOMSUtils.
    5. Store this information, including the proxy, by creating a GridSessionDetails bean.
    6. Pass the GridSessionDetails bean to WMSUtils in order to delegate the certificate to the grid.
  3. Create a job description JDL for WMS.
  4. Submit the job to WMS and obtain a job ID.
  5. Return that job ID to the caller as the result of the SOAP call. The caller can then use this job ID to pass to checkSayHello() and getSayHello() in order to check on progress and retrieve results/errors from the job later.

checkSayHello():

  1. Declare the signature for the WSDL endpoint by using annotations on the Java method. The WSDL endpoint will have the same name as the method, and have parameters of the same names and types as the method.
  2. Parse the SOAP headers and retrieve/delegate the MyProxy certificate to the grid (same as startSayHello() above).
  3. Check the job status on the grid using the job ID.
  4. Return the job status as thte SOAP response. The various possible responses are listed as static constants in the WMSUtils class.

getSayHello():

  1. Declare the signature for the WSDL endpoint by using annotations on the Java method. The WSDL endpoint will have the same name as the method, and have parameters of the same names and types as the method.
  2. Parse the SOAP headers and retrieve/delegate the MyProxy certificate to the grid (same as startSayHello() above).
  3. Find out where the job's output was sent to on disk.
  4. If the job completed OK, return the STDOUT of the job as the response.
  5. Otherwise, if the job failed or is still running, throw an exception (which becomes a properly formed SOAP error) containing the STDERR of the job (which may be empty if it is still running).

An example synchronous server (not recommended)

In the example code, you'll find a method called "sayHello()". Stepping through the code will demonstrate the various steps involved in publishing and running a synchronous service:

  1. Declare the signature for the WSDL endpoint by using annotations on the Java method. The WSDL endpoint will have the same name as the method, and have parameters of the same names and types as the method.
  2. Parse the SOAP headers and retrieve/delegate the MyProxy certificate to the grid (same as for the asynchronous server, above).
  3. Create a job description JDL for WMS.
  4. Submit the job to WMS and obtain a job ID.
  5. Wait for the job to complete and obtain the completion status.
  6. Find out where the job's output was sent to on disk.
  7. If the job completed OK, return the STDOUT of the job as the response.
  8. Otherwise throw an exception (which becomes a properly formed SOAP error) containing the STDERR of the job.

As all this is performed in a single call, it can take quite some time to complete (in the order of minutes, depding how busy the grid is). As the JGlobus toolkit upon which this is based can only handle one call at a time, it is best where possible to avoid providing synchronous services, and to only provide asynchronous ones, in order to avoid long delays to other users waiting to use the service to submit their own jobs for processing.

Passing files from server to grid and back

For passing files between the service and the grid and back (NOT to/from the client!), it is possible to use the sandbox features of WMSUtils.

To pass files in, you must designate a folder as a sandbox for the job. Only files in this folder can be sent to the job, and it cannot have any subfolders/subdirectories.

Then, place the files into the folder, and after creating the JDL for the job, register each input file you need against the JDL by using the addInputFilename() method in WMSUtils. The filenames must be relative to the sandbox folder, not relative to any other location (e.g. if your input file is /home/richard/sandbox/test.txt then the filename must be just test.txt, without including any of the path above it).

Lastly, when submitting a job, the WMSUtils method submitJob() that includes a File parameter must be used, where that File parameter describes the location of the input sandbox.

When the job gets run, the environment on the grid will contain all the files you submitted in this manner inside the working directory of the command that is run on the grid.

Output files work in a similar manner, except the output sandbox is created for you. Before submitting the job, register each expected output filename (relative to the working directory of the command run on the grid) using the addOutputFilename() method in WMSUtils. On completion, calling getJobOutput() in WMSUtils will create the output sandbox directory and populate it with the output files.

Install in Tomcat

To install your service in Tomcat, first compile it into a WAR file by typing from inside the main ws-server folder:

 mvn package

Then, deploy it to Tomcat as you would any other web service. There's docs on how to do that here, you'll probably want to use the graphical interface it mentions rather than try and do it by hand.

That's it! After a few seconds, your service will be available by suffixing the 'ws-server' endpoint to the end of your Tomcat URL. An example of where this has been done already can be seen at:

 https://ws1.grid.sara.nl:21503/ws-server/

with the service itself appearing at:

 https://ws1.grid.sara.nl:21503/ws-server/HelloService

Customising

You'll notice after having deployed the service that it has the same name as the class it was defined in, with the word Service appended. All you have to do to change the service name is to rename the class to something else. If you want to change the services it provides, rename and modify the method signatures inside the class. It's that easy!

Calling a web service

Note that although template example code is provided for both synchronous and asynchronous web services, it is highly recommended always to use the asynchronous approach. Any good implementation of the web service part of this toolkit will only provide asynchronous methods anyway. This is mostly because the JGlobus toolkit upon which this is based is not thread-safe, which means that it can only ever serve one web service call at a time. If it's busy running a long synchronous job for someone, then it can't serve any other calls until that job is complete. However using the asynchronous method, it is possible to interleave requests for submission, monitoring and retrieval of jobs such that they do not block each other for excessively long periods of time.

The example code has hardcoded server names etc. for DutchGrid/SARA users, and also has hardcoded user names. If you're running this elsewhere, or you're not me, you'll need to change them.

Obtaining the code

 svn checkout https://gforge.nbic.nl/svn/tavernagrid/MyProxyWebService/trunk/ws-client/

Prerequisites

The client code prerequisites are the same as those for the API (see above).

It also requires you to store the SSL certificate from the Tomcat server that is serving your web service, in the same way as you stored the certificates from your WMS server in the API prerequisites section above.

An example asynchronous client (recommended)

In the example code, you'll find a method called "doWebServiceCall()", which is called from the (very simplistic) main method. Stepping through the code will demonstrate the various steps involved in calling an asynchronous service:

  1. Load the user certificate from the usercert.pem and userkey.pem files on disk (in this case the passphrase to unlock them is supplied as a command line parameter).
  2. Set up the connection parameters for MyProxy.
  3. Set up the server details for VOMS.
  4. Decide on a suitable length of time to delegate the certificatae for.
  5. Optionally VOMS-enable the certificate (not done in this example).
  6. Delegate the certificate using MyProxyUtils.
  7. Use SOAPUtils to obtain and construct an OMFactory, which is used to construct the parameters to send to the SOAP method call. As this is an asynchronous client, we want to call the asynchronous startSayHello method in the demonstration service.
  8. Construct the method call and parameters.
  9. Call the asynchronous methods startSayHello/checkSayHello/getSayHello in a single utility call using the SOAPUtils asyncCall() method.
  10. The response is passed back from SOAPUtils and can be parsed as required.

An example synchronous client (not recommended)

In the example code, you'll find a method called "doWebServiceCall()", which is called from the (very simplistic) main method. Stepping through the code will demonstrate the various steps involved in calling a synchronous service:

  1. Load the user certificate from the usercert.pem and userkey.pem files on disk (in this case the passphrase to unlock them is supplied as a command line parameter).
  2. Set up the connection parameters for MyProxy.
  3. Set up the server details for VOMS.
  4. Decide on a suitable length of time to delegate the certificatae for.
  5. Optionally VOMS-enable the certificate (not done in this example).
  6. Delegate the certificate using MyProxyUtils.
  7. Use SOAPUtils to obtain and construct an OMFactory, which is used to construct the parameters to send to the SOAP method call. As this is a synchronous client, we want to call the synchronous sayHello method in the demonstration service.
  8. Construct the method call and parameters.
  9. Call the synchronous method sayHello in a single utility call using the SOAPUtils syncCall() method.
  10. The response is passed back from SOAPUtils and can be parsed as required.

An example direct client (avoiding web services)

If you'd like an example of doing things directly without going via a webservice, take a look at the "doDirect()" method in the same class. It follows much the same structure as the web service itself, except it interacts directly with the grid.

Passing files to the service

This is not yet possible to do directly or by reference. If you need to pass files in to the service, you'll need to do it in the same way as for any other SOAP call. Some good options are outlined here.

Running the client

First you'll need to compile it, by typing from within the main ws-client folder:

 mvn package

Then, type:

 java -jar target/ws-client-0.0.1-SNAPSHOT.jar async "MyPassphrase"

substituting "MyPassphrase" for the password you use to unlock your Grid user certificate with.

The above all is for an asynchronous call. Change "async" to "sync" to try out the synchronous code (not recommended). Change "async" to "direct" to try out the direct method.

Customising

Just change the endpoint from which the service is getting the WSDL from, and change the names of the methods and parameters you are calling. The rest of the code stays the same!

Using the Taverna 2 Workbench plugin

Note that this plugin is for the workbench only, not the platform. In future the workbench may migrate to use the platform engine, in which case the plugin will have to be modified to suit.

Obtaining the code

You shouldn't need to refer to the plugin source code, but if you'd like to explore it, it can be found here:

  svn checkout https://gforge.nbic.nl/svn/tavernagrid/MyProxyWebService/trunk/wsdl-mpx-activity/

The code is divided into three sections:

  • At the top level you have the three plugin XML files which are needed on a web server for Taverna 2 Workbench to be able to automatically load the plugin from a URL.
  • Underneath you have the two halves of the plugin - the main plugin code which performs the work (wsdl-mpx-activity), and the Taverna 2 Workbench GUI modifications which interact with it (wsdl-mpx-activity-ui).

Publishing the plugin

You shouldn't need to do this unless you write your own version of the plugin, but to publish it, you need to place on a web server all three XML files from inside the top level of the code folder that you checked out above.

All three files should go into a folder together on the web server. The URL for that folder can be anything you like, and it is this folder URL that you should enter into Taverna when adding a new plugin site (see below). Taverna will look for the pluginlist.xml file within that folder, and use it to determine which other XML files it needs to load.

Specifying the plugin as a Maven dependency

You shouldn't need to extend the plugin, but if you do write other plugins which refer to this plugin as a dependency you'll need to add the following to your repositories section in your pom.xml file:

 <repository>
   <id>sara-central</id>
   <url>http://ws1.grid.sara.nl:21501/artifactory-2.0.0/repo</url>
   <snapshots>
      <enabled>true</enabled>
   </snapshots>
 </repository>

Then, in the dependencies section, add (for the main component):

 <dependency>
   <groupId>myproxywebservice</groupId>
   <artifactId>wsdl-mpx-activity</artifactId>
   <version>0.0.1-SNAPSHOT</version>
 </dependency>

If you'll be extending the UI component you'll need this instead:

 <dependency>
   <groupId>myproxywebservice</groupId>
   <artifactId>wsdl-mpx-activity-ui</artifactId>
   <version>0.0.1-SNAPSHOT</version>
 </dependency>

Prerequisites

You must have a copy of the Taverna 2 Workbench installed and running!

You'll also need to know your MyProxy server address, and your VOMS server address, and your VOMS VO and DN. See the API code prerequisites above for more information on these.

You'll also need to know where your Globus certificate and private key files live - this is usually ~/.globus.

Loading the plugin into Taverna 2

The Taverna 2 Workbench plugin site can be found at http://ws1.grid.sara.nl/plugins/.

If you already know how to add plugins to the Taverna 2 Workbench, then the above URL is all you'll need. Don't forget to add BOTH of the plugins available from this URL, as although they might appear to install OK, you won't get full functionality unless you install both.

If you don't know how to add plugins to Taverna 2 Workbench, here's a brief guide:

  1. Start up Taverna.
  2. From the main Taverna window, open the Advanced menu on the menubar and choose Software Updates.
  3. In the window that appears, click the Find New Plugins button, and in the new window that appears, click the Add Plugin Site button.
  4. Enter the URL from above, and give the site any name you want - something memorable so that you recognise it in future, such as MyProxy Plugin, would be good. Click the OK button.
  5. Back in the Plugin Sites window, a new section should have appeared listing two new plugins - wsdl-mpx-activity and wsdl-mpx-activity-ui. Each will have a checkbox beside them. Check the checkboxes, then click Install. The plugins will be downloaded and installed.
  6. Close the Plugin Sites window, and the Plugin Manager window. At the time of writing there was a bug in Taverna which required you to restart Taverna at this point before the plugins would load and start working. This may or may not have been fixed by the time you read this - if the steps below about creating profiles etc. don't work because you can't find the menu items then this bug will probably still exist and so you will need to restart Taverna.

Concepts

The plugin revolves around the concept of security profiles, and associating each MyProxy-enabled web service with a specific security profile. The security profile consists of all the information you would normally need to submit a job to the Grid on the command line - e.g. your certificate details, and the addresses of your MyProxy and VOMS servers, and your VOMS DN and VO.

When adding a MyProxy-enabled web service to Taverna, you need to select a security profile to use with that service. The plugin will then transparently associate all necessary data with the service and transmit it in the service's SOAP headers whenever the service is called.

All this only works if you have also delegated your certificate to MyProxy to enable the Grid service to run jobs on your behalf. Each security profile therefore has a Delegate button which can be used for this purpose, and this must be done before any workflow containing a MyProxy-enabled service referring to that security profile can be run.

Apart from the association of security profiles with web services, the remainder of the process of incorporating web services into your Taverna workflow is identical to that with any other normal WSDL-based web service. Whatever works for the standard WSDL activity in Taverna will work with this as well.

Creating a security profile

From the main Taverna window, use the File menu in the menubar and choose the Preferences option. The Preferences dialog will open. On the left of the dialog is a list of preference types. Click on MyProxy to select the MyProxy security profile manager.

The profile manager allows the creation of a number of security profiles. To create a new one, type its name into the Profile dropdown box at the top. Don't click Load - this is for existing profiles only. As your profile doesn't exist yet, it won't do much!

Fill in the rest of the form with your usercert.pem and userkey.pem details, and the location of your MyProxy and VOMS servers (see the API section above to find out more about these).

Don't fill in the Delegation Time or Passphrase boxes until you're ready to delegate the certificate to MyProxy. Although the Delegation Time field will be saved with the profile for your convenience, the Passphrase field will never be saved and needs to be reentered every time you use it.

Click the Apply button to save the new profile.

Editing/deleting an existing security profile

From the main Taverna window, use the File menu in the menubar and choose the Preferences option. The Preferences dialog will open. On the left of the dialog is a list of preference types. Click on MyProxy to select the MyProxy security profile manager.

Choose the profile you want to edit or delete from the dropdown menu, and hit the Load button. Make the necessary changes if you're editing it, and hit Apply. Or, if you're deleting it, hit Delete.

Delegating certificates to MyProxy

From the main Taverna window, use the File menu in the menubar and choose the Preferences option. The Preferences dialog will open. On the left of the dialog is a list of preference types. Click on MyProxy to select the MyProxy security profile manager.

Choose the profile you want to edit or delete from the dropdown menu, and hit the Load button.

Fill in the Delegation Time field with the amount of time you want to delegate the certificate to MyProxy for. Note that you can choose the time units in the dropdown to the right of the field. The Delegation Time controls how long the certificate will remain valid for after delegation - any operations which require the certificate after this time has expired will fail. The time starts counting down from the moment the certificate has been successfully delegated to MyProxy. The values you enter here will be stored for later reuse with this security profile if you hit the Apply button.

Enter the password you use to unlock your Grid user certificate into the Passphrase box. This will not be stored with the security profile under any circumstances, and will need to be reentered every time you come back to this profile in the security profile manager dialog.

Hit the Delegate button. A message will appear confirming successful delegation, or if it fails to delegate it will attempt to explain why so that you can correct the values you entered and try again.

An example asynchronous service (recommended)

In the main Taverna window, use the Activities menu option in the menubar and choose New Activity, then "WSDL with MyProxy". It will ask you to enter the location of the WSDL for your MyProxy-enabled service (you could use the example web service server outlined earlier in this document to try it out). It will also ask you to select from a list of possible security profiles to use with the service.

If you haven't yet created any security profiles, you can type any name in here, but you must make sure you create a profile with that same name before you attempt to run any workflow that uses a service from this MyProxy-enabled WSDL.

From this point on, the asynchronous service behaves like any normal WSDL-based web service in Taverna, except instead of one call you need to make three inside your workflow, including a conditional loop on the check step and a coordination from the check step to the get step. You'll need to add XML splitters to the input and output of each call to be able to pass data in and out of them.

In the example asynchronous service, the first call would be startSayHello() which returns a job ID. You would then pass that job ID as the input to two second calls, checkSayHello() and getSayHello(). getSayHello() should coordinate from checkSayHello(). checkSayHello() should have a loop enabled in the advanced options, looping until the output parameter contains the string "DONE", and click the customize button to add "Thread.sleep(5000);" to the end of the code segment to induce a pause between check attempts. The output of getSayHello() would contain the results. All methods need suitable XML splitters on the input and output to be able to pass values correctly between them.

An example synchronous service (not recommended)

In the main Taverna window, use the Activities menu option in the menubar and choose New Activity, then "WSDL with MyProxy". It will ask you to enter the location of the WSDL for your MyProxy-enabled service (you could use the example web service server outlined earlier in this document to try it out). It will also ask you to select from a list of possible security profiles to use with the service.

If you haven't yet created any security profiles, you can type any name in here, but you must make sure you create a profile with that same name before you attempt to run any workflow that uses a service from this MyProxy-enabled WSDL.

From this point on, the synchronous service behaves like any normal WSDL-based web service in Taverna. In the example service the synchronous method is called sayHello() and you'll need to add XML splitters to the input and output to be able to pass data in and out of it.

Running a workflow that contains a MyProxy-enabled web service

The process is identical to any other WSDL activity in your Taverna workflow, except that you must remember to delegate the certificate from the associated security profile(s) before you start running the workflow.

Other resources

Delegating a certificate from the commmand-line

The demonstration tool mpx-delegate allows you to delegate your MyProxy certificate in a single call from the command line. It uses Java 6 features and so will only compile/run on systems that have Java 6 or newer.

Obtaining the code

 svn checkout https://gforge.nbic.nl/svn/tavernagrid/MyProxyWebService/trunk/mpx-delegate/

Prerequisites

None, other than knowing your user certificate and key location and passphrase, and knowing the address of the MyProxy server you wish to delegate to.

Running the tool

First you'll need to compile it, by typing from within the main mpx-delegate folder:

 mvn package

Then, type:

 java -jar target/mpx-delegate-0.0.1-SNAPSHOT.jar

It will prompt you for your private key passphrase in order to unlock your certificate and key. It will then load the certificate from the default location, delegate it to the default SARA MyProxy server, and inform you of the username and password to use with MyProxy to retrieve it later. The default delegation is for 1 hour.

You can pass some command-line arguments to customise the delegation:

  • --cert|-c to specify your user certificate location if it is not in the default ~/.globus/usercert.pem
  • --key|-k to specify your user key location if it is not in the default ~/.globus/userkey.pem
  • --server|-s to specify an alternative MyProxy server to the SARA default one.
  • --username|-u to specify a username for the delegated MyProxy certificate.
  • --password|-p to specify a password for the delegated MyProxy certificate.
  • --timeout|-t to specify an expiry time in seconds for the delegated certificate.