Before deploying the war file, the database first needs configuring. This is defined within the war file in the file WEB-INF/classes/META-INF/persistence.xml. The war file must first be unzipped to modify this file. Many modern GUI zip tools allow you to edit zipped files without physically unzipping the file.

By default this is set to use an embedded version of the Apache Derby database. All that needs configuring is the path to which the database will be installed when the war file is deployed. This is configured in the section:

<property name="hibernate.connection.driver_class"
 value="org.apache.derby.jdbc.EmbeddedDriver" />
 <property name="hibernate.connection.url"
 value="jdbc:derby:/tmp/remoteTavernaDB;create=true"
/>

The path /tmp/remoteTavernaDB should be changed to somewhere more suitable. The directory will be created and is where all the data is stored.

The remotetaverna.war can now be deployed within a web application containter such as Apache Tomcat. Once the application is deployed and started, it is initially necessary to configure the Remote Execution Server.

First you must add an admin user and provide a password. At least one admin user is required to use the application, and others can be added later if necessary. You should also check that the Base URL is a valid URL and is accessible by the intended Taverna users. Finally you will need to define the location of the Taverna Home. This needs to be a writable directory and is where libraries required for Taverna to run will be downloaded. If the directory does not exist it will be created. The installation is now complete.

Once the Remote Taverna Execution application is up and running some further administration is recommended. First users should be added. Users can be added by following the Add User link. This is only accessible to an admin user. These are the users that will be submitting workflows through the Remote Execution plugin from Taverna.

Through the System Configuration link it is recommended to set the upper memory usage value. This is the amount of memory allocation for each workflow invocation. This should be set according to the available memory on the server. Caution It is possible to have more than one worker. A worker is associated with a separate process that is responsible for invoking a workflow. Each worker is allocated the memory specified by this setting. If there is more than one worker defined then it needs to be considered that the total memory usage may rise to the sum of the memory allocated to all workers.

Registration should only be enabled if you know and trust the users that can access the application. You should read and understand the Security conciderations before enabling this.

This application is only intended to be used internally on a local network and shared between trusted local users. Its important to remember that Workflows submitted may contain local processors or Beanshell scripts that can access the local file system, access network facilities or start new processes. For this reason it is highly recommended that it is not deployed such that it is externally visible on the internet unless it is installed in a highly secure environment, such as within a chroot jail or a virtual machine. We suggest you seek expert advice before doing this.