This component provides facilities to manage the various services available to the workflow designer and allows the user to manage service libraries, create instances of a service in the form of a processor within the workflow, search services and other such functionality.
Services are shown in a hierarchical view. The exact semantics of this hierarchy vary by service type; soaplab, for example, has some concept of service categories so the view for a soaplab server shows the top level installation, then child nodes corresponding to the various categories and finally leaf nodes corresponding to actual services:
Biomoby services are located by accessing a central moby repository. In this case the hierarchy is constructed from a root node specifying the repository, then child nodes for each site hosting services and leaf nodes for each individual service:
In general all service types follow this pattern, the leaf nodes are always individual services with other nodes representing some kind of containment.
A special case is that of workflow nodes - these are nodes representing entire Taverna workflows but in addition may be expanded to show copies of the services within those workflows, effectively allowing the user to reuse components from another workflow without having to figure out where the component was originally found. An example of this is shown below:
The primary function of the service panel is to allow users to create new processors within the current workflow. This can be accomplished either through drag and drop or through the context menus available by right clicking on the nodes in the service panel.
Any node representing a service may be dragged from the service selection panel into the AME. This also applies to nodes representing entire workflows in which case the workflow will be created as a nested workflow processor. The effect of a drop into the AME varies by location. If the node is dropped into area 1 in the diagram below it will be created as a new processor. If, however, area 2 is the target the effect will be to create a new alternate to the processor node the service was dragged onto.
As an alternative, new processors may be created by right clicking on the service to be used; this shows the following options:
Selecting 'Add to model' will create a new processor with the same name as the service node. If this name is unavailable the workbench will append a number to it until it is, creating processor names such as 'getDot1' rather than 'getDot'. If the 'Add to model with name...' is selected a dialogue is shown allowing the user to explicitly name the processor (processors may be renamed at any time from the AME by double clicking on their names there). The 'Add as alternate to...' submenu allows the user to specify that the new processor should be created as an alternate to the selected pre-existing processor in the workflow.
As processor names often do not correspond to the names of items in the service panel it can be helpful, especially when debugging a non functional workflow, to find out which node in the service panel would have produced a specific processor in the AME. To do this simply drag the processor node from the AME into the tree area of the service panel, the node corresponding to the service of which the processor is an instance will be selected and displayed in red if found. Some nodes, most noticeably beanshell scripts and string constants, may not be found correctly, this is due to the way they are represented within the services panel but for the majority of cases this approach works.
An additional option appears in the context menu when right-clicking on a workflow node. This 'Import workflow...' option allows the user to import the entire contents of the workflow specified in the same way as if it had been loaded from the AME. Rather than being created as a nested workflow processor the workflow is loaded alongside any existing processors. To avoid name collisions (all processor names must be unique within a given workflow) the user can in addition specify a prefix string which is prepended to all processor names in the new workflow. The dialogue to set the prefix is shown when the 'Import workflow...' option is selected. Pressing return without entering any text will be interpreted as 'no prefix'.
The service panel may be searched by regular expression. For convenience the text box in the toolbar allows the user to enter a fragment of a service name and use either the return key or the search icon to the right of the text box. As the user types all matching services are shown highlighted in red, when the search is activated by return key or search button the tree is collapsed then re-expanded to show all nodes matching the specified search. This is particularly useful if the user knows exactly what he or she is looking for. The image below shows the search in action:
Some types of service support a level of self description. Services based on soaplab, Biomoby and Nested Workflows can all provide textual descriptions of the operation the service performs. In order to fetch these descriptions the user can select the 'Fetch descriptions' option from the context menu on any node in the service panel other than the root. This will then start fetching descriptions in the background and adding them to the service panel as and when they are found. Descriptions are fetched for all nodes below the selected one in the tree, including the selected node itself. So, the user can fetch descriptions for a single operation, soaplab category, entire biomoby installation etc:
The service panel may be populated with available services in several distinct ways:
The context menu for the root node in the service panel labelled 'Available Processors' can be used to add single 'scavengers' to the tree. A scavenger in this context is a part of Taverna's code which allows it to find services. There are a variety of options the user can select:
The scavengers operate as follows:
BioMoby scavenger This scavenger asks the user for the location of a Moby Central repository. It uses this repository to determine all available hosts and their services and adds the tree thus created to the service panel.
API consumer This allows the import of pre-prepared Java APIs. This is used in conjunction with Java libraries augmented with annotations created by the API Consumer tool (see that tool's documentation for more information). This allows the import of existing component systems such as caBIG, BioJava, JUMBO, CDK etc.
WSDL scavenger This scavenger asks the user for the location of a Web Service Description Language (WSDL) file on the web. It inspects this file to pull out all appropriate operations and adds them as WSDL based service nodes to the services panel.
BioMart service allows the user to specify the location online of a Biomart service. By default Taverna will load the public Ensembl+MSD+Vega+DbSNP registry hosted at the EBI and Sanger Institute in the UK.
Workflow scavenger This allows workflows to be added as services and asks the user for the URL to a single XScufl definition file. It adds the workflow as a node in its own right and also adds each processor within the workflow as a child node before adding the workflow node to the services panel.
Soaplab scavenger This scavenger asks the user for the root URL of a soaplab server. It interrogates the server to get all available application categories then for each category creates a list of services in that category.
Collect from web Asks the user for an initial URL, uses this to start a web crawl looking for XScufl definitions and WSDL files. If it finds any it will add them below a top level 'web crawl starting from...' node in the service panel. This scavenger runs in the background as it can potentially take a considerable amount of time to complete.
Collect from model This option enables the inspection of the current workflow (shown in the AME) and infers the existence of any services the workflow uses. For example, if a workflow uses one operation from a soaplab installation this operation will notice that and add a new soaplab scavenger which will then contain all the other operations that the server supports. This is an explicit version of the implicit functionality enabled by the 'watch loads' checkbox.
If the 'Watch loads' checkbox in the Available Services toolbar is selected the current workflow will be watched. Any time a new service is added the services panel will initiate a new 'Collect from Model' operation. This means that a user can import all the services a particular workflow uses by simply loading the workflow then resetting it.
Although most services are only useful when composed into workflows there may be occasions where it is handy to invoke a single service directly. Specific cases are where the service is providing some controlled vocabulary such as a list of valid database names, or where the node is actually a complete workflow as in the diagram under the 'Drag and Drop' section below. Any service node within the tree may be called directly by right clicking on it and selecting 'invoke' from the context menu:
The behaviour differs slightly depending on whether the node selected is a single service (as in the example above) or an entire workflow. If a service is selected this service will be inserted into a trivial workflow containing workflow inputs and outputs corresponding to the service inputs and outputs. In the case of a workflow the workflow is run directly. In either case the enactment engine is used to run the new workflow so the various input specification behaviours are the same as those used when running the main workflow from the workbench.
XScufl definitions or directories may be dragged onto the toolbar area of the Available Services window. This initiates a file traversal looking for XScufl files, and can be used to load a library of workflows from the local file system. In a sense this is the file equivalent of the 'Collect from Web' option in the context menu. If a directory is dropped a corresponding hierarchy in the tree is created, all leaf nodes are workflows and their child processes:
The service panel can be preloaded with services by specifying various defaults in the mygrid.properties file (see the default services section).