Added by Rory Newton, last edited by Rory Newton on 2010-02-04  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

RAPID is software developed by Jos Koetsier and Jano van Hemert at the National e-Science Centre in Edinburgh for OMII. It allows users to create JSR-168 portlets by writing a single XML file. These portlets are currently used to submit jobs to a grid. The generated portelts can be used in a number of portlet containers including Liferay, Gridsphere and Pluto. More information about what RAPID currently does and how it works can be found here.

Using the experience gained by the developers of RAPID it has been proposed that a version of RAPID will be developed that can generate portlets to run Taverna workflows. In order to get a better understanding of what the system would look like and how it would work I went to Edinburgh to speak to the RAPID developers. The areas discussed were as follows:

  • How does RAPID currently submit jobs to a grid.
    • This is done by declaring a grid job in the RAPID XML file (which is used to generate the portlet).
    • How the job is defined depends on what grid system is being used (Condor, PBS, GridSAM or SunGrid Engine).
    • Each of the different grid systems are known as RAPID plugins.
    • Where the job is to be submitted on the grid is also defined as well as the portlet interface to allow the end user to submit variables with the job.
  • How Taverna works
    • Going through tutorials so that they were more familiar with Taverna and what it does
  • Taverna Server
    • Taverna server is the most likely way that the workflows coming from a RAPID portlet would be executed (command line tool?)
    • REST interface should make it relatively easy to implement but until the development starts it is hard to tell
  • Architecture - there were a number of architectures and functionalities discussed
    1. A workflow is already uploaded to the server and a RAPID XML is written based on that
    2. A workflow is uploaded to the Taverna server at the same time as uploading the portlet to a portal server
    3. Be able to ?manipulate? the workflow file so that how the workflow runs can be specified at the interface - eg. using a different gene database

The initial implementation would concentrate on (1.) with (2.) and (3.) being later additions.

One of the main things that Jos and Jano require are use cases so that they know who is most likely to use RAPID Taverna and how they would use it. I will collar Paul for this as well as the work for NeISS. Jano is also going to contact Marco to see how he would use RAPID Taverna.