Note - this feature is not adequately tested, so use at your own risk. Styx based services differ from the other types available within Taverna in that they are reference based rather than value based. For a conventional web service, soaplab installation etc the data required to start the operation is sent from the workflow enactor (so from the user's desktop machine in the default configuration) to the service, then the results from that service are sent back to the enactor. If the next process in the workflow is also on the same machine as that service the data will still have to go back to the enactor then back out - this is clearly not efficient and may become impossible in some cases.
In contrast, Styx based services pass data directly between the services and use the workflow enactor as a control mechanism. This has obvious potential advantages in terms of efficiency and performance at the expense of loosing some information about the running workflow - there is no way get the intermediate results between two styx operations as the data never returns to the enactor.
In the workflow shown above there is a single string constant processor feeding data to the first of two styx services. This data is an actual data value, so the link is made to the 'stringIn' input. This has the effect of creating a stream of data out of the value passed from the SingleString processor and feeding it into the StyxService1.
As there are two styx services adjacent to one another in the workflow the designer can take advantage of the performance improvement derived from streaming data directly between the services. The output 'refStdOut' in StyxService1 is passed into 'refIn' in StyxService2 - the actual data passed here through the enactor is in the form of a URL corresponding to a stream to which the StyxService2 can connect and read data directly from StyxService1. When configured in this mode StyxService1 will complete immediately as far as the workflow engine is concerned - this may well not correspond to completion of the actual service though! One immediate benefit of this is that StyxService2 can start working on the partial results of StyxService1 before that service has completed.
The workflow output requires a value to be passed to it rather than a stream so the user links the output 'stringOut' in StyxService2. If either 'stringOut' or 'binaryOut' are connected to a downstream processor or to a workflow output the processor will not complete immediately and will instead wait, consuming data from the output stream and writing it into a value which is then passed to the next stage in the workflow through the enactor.
This hybrid architecture allows parts of the workflow to take advantage of the high performance and large data handling abilities conveyed by the use of direct streams between services while also benefiting from the simplicity of direct value passing where feasible.