WSDL services are defined by their WSDL document, an XML format that represents an interface to a Web service. WSDL is the machine-readable description of the operations (functions) and parameters offered by the service. Taverna can handle any Web service with a WSDL interface if you provide a URL to its WSDL file.
A pop up dialog will appear for you to enter the URL of the WSDL document for the service.
After you have imported a WSDL service to your Service Panel, it will appear somewhere under your Available Services. To locate it quicker, you may want to use the Filter at the top of the Service Panel.
The service itself will typically have several operations, all of which will appear in the Service Panel under the node for you service named something like "WSDL @ ...".
You can now add an individual operation of the WSDL service to your workflow by drag and dropping them from the Service Panel to the Workflow Diagram.
Apart from the WSDL service URL, which you have configured as part of the "drag-and-drop-into-workflow" process and cannot modify any more, you can configure certain security options on the service. These security options refer to how you can authenticate to the service when it is invoked as part of a workflow run.
The default option for the service not is to require any user authentication.
Other two options include HTTP username and password authentication or WS-Security username and password authentication. Do not worry if you do not understand these options - your service provider will tell you which one to use. You will also know that a service is secured, for example, if you have a username and password for it.
To set your username and password for the service:
Some WSDL services accept XML content as input or produce XML content as output and can be difficult to invoke without help constructing the XML.
XML splitters can either assemble XML elements or separate elements out of the XML so that users only have to add strings as inputs or get strings as outputs, and Taverna populates the XML or extracts from the XML behind the scenes.
Even though they are called splitters, when used on inputs they are actually assembling the XML. They are only splitting the outputs of a service. This is a legacy term from Taverna 1.x when we did not have assembly of inputs.
For inputs, values are then assigned in the standard manner, and when the workflow is run the splitters reconstruct the XML to then be used when invoking the service.
For outputs, the values can be passed on to downstream processors in the standard manner, and are extracted from the XML resulting from invoking the service.
Not all WSDL services require XML splitters, but most of them do. Some services only need input splitters and others need only output splitters.
To add an XML splitter:
Alternatively, to add an XML splitter:
The default timeout for any WSDL operation in Taverna is 5 minutes. That means that if the operation has not responded after 5 minutes, that particular service call will fail in Taverna. This is in most cases caused by temporary issues with the network or the service endpoint which can be improved by configuring retries. Note that if Taverna is doing implicit iteration over a service, each of these might fail or succeed independently.
However some service operations simply take more than 5 minutes to process the data, due to complexity or load on the server.
To modify the timeout setting for WSDL services you can set the system property
taverna.wsdl.timeout to the desired number of minutes. You will need to edit
Taverna.app/Contents/Info.plist depending on your operating system and set, for instance for 60 minutes:
exec java -Xmx300m -XX:MaxPermSize=140m \ -Dtaverna.wsdl.timeout=60 \ ... # Don't forget the trailing backslash
set ARGS=%ARGS -Dtaverna.wsdl.timeout=60 ... REM Don't forget to start Taverna using taverna-debug.bat
.. <key>Properties</key> <dict> <key>taverna.wsdl.timeout</key> <string>60</string> ..
(See Memory allocation for details on editing these files)
Note that we don't normally recommend setting this property to such a high value. The reason is that long-living silent connections over the Internet can experience fluctuations or packet loss, so that in some cases Taverna will have to wait for the full timeout to notice a short-lived connection failure. However, if your services and network connections are reliable (for instance local in your lab), you might want to experiment with higher values.
If you have control over the service implementation, a solution with an asynchronous job submission pattern would generally be more reliable. This would typically mean to call to a
submitJob operation taking the input parameters, which immediately returns a job identifier. (this can be a number, UUID, etc).
This identifier can be passed to a
getStatus or poll method, which can give job status like
COMPLETE. Finally the
getResults takes the same job identifier, and return the outputs and/or errors. Server-side you can use threads, processes or grid submission systems to perform the work outside the web service calls. You will then also have to build in automatic deletions of old jobs and results.
Note that there is (unfortunately) no agreed standard for the names of these operations and status codes, so in Taverna you will have to connect up these 3 operations instead of a single one, but you could wrap this as a nested workflow. You should configure retries on the individual operations, which could handle network fluctuations (specially important for
getStatus), and looping on the
getStatus service so that the status-call is repeated meanwhile the status is not finished.
See the Loops article for an example of this pattern.