The server is designed to support JMX for management. This allows the use of tools such as jconsole or jvisualvm (with appropriate plugin) to connect to the server so that they can view, chart, and manipulate properties of the server. The exact list of properties is liable to change, but is as follows in this release:
This is the component that interfaces with the external world.
Whether to permit any new workflow runs to be created; has no effect on existing runs.
Count of currently existing runs.
Count of SOAP and REST calls made to the Webapp.
Whether to put submitted workflows in the log.
Whether outgoing exceptions should be extensively logged.
This component is responsible for manufacturing workflow runs and maintaining connections to existing runs. Note that the writable properties typically have sensible values by default.
The names of the currently existing runs.
How many minutes should a workflow live by default?
The full pathname of the script to run to start running a workflow. Must be readable by any user of the system.
The list of additional arguments used to make a worker process.
The mapping of user names to RMI factory IDs.
The full pathname of the Java executable to run.
What was the exit code from the last time the factory subprocess was killed?
How many checks were done for the worker process the last time a spawn was tried. (Larger values indicate problems with system loading.)
The maximum number of simultaneous runs supported by the server. Note that this includes runs that have finished executing but have not yet been deleted.
The full pathname of a file containing a password to use when running a program as another user (e.g., with sudo).
The host holding the RMI registry to communicate via.
The port number of the RMI registry. Should not normally be set.
The full pathname of the JAR implementing the secure-fork process.
The full pathname of the JAR implementing the server worker processes.
How many milliseconds to wait between checks to see if a worker process has registered.
How many times has a workflow run been spawned by this engine.
How many seconds to wait for a worker process to register itself before causing the creation operation to fail.
This is an interface for adding, deleting and otherwise managing user accounts on the server. It does not manage the underlying system accounts, but does allow control over the mapping of users to those accounts. Note that newly created accounts are disabled by default. More information about the mapping process is in the security summary document.
The list of server accounts known about.
Adds the user called nm to the database, with password pw. If cpl is true, set the local user account to be the same as the user name, otherwise use a default set at system configuration time. The user will be a non-admin and disabled by default.
Remove the user called nm from the database.
Get a description of the user called nm from the database.
Set whether the user called nm is an admin or not (according to the boolean, ad).
Set whether the user called nm is an admin or not (according to the boolean, en).
Set what the user called nm will be mapped to as a local user to lu (which must be the name of an account understood by the local system).
Set the password for the user nm to be pw. This implementation stores the value directly in the database.
The server also supports a RESTful administration interface on its
http://«SERVER:PORT»/taverna-server/admin resource (a sibling to the main RESTful
http://«SERVER:PORT»/taverna-server/rest resource and the Atom feed on
http://«SERVER:PORT»/taverna-server/feed). This interface is only available to users who authenticate with
admin permissions. Currently, there is no rendering of the interface in a form that is suitable for use from a normal web browser; this is expected to change in future versions.