On 12/02/2015 02:14, Bill Smith wrote:
The FAQ says that that there is no standard way to run a workflow as
a web service, but elsewhere I find documentation on REST and SOAP
interfaces, and these interfaces seem to underly the Web
Demonstrator. I can’t seem to find other examples, however, or
comprehensive documentation.
Can anyone give me the complete picture and, I hope, links to some
code that I can work through?
There's no standard way, but there are some very common patterns. :-)
Almost all workflows of any interest take an appreciable amount of time
to execute, and so are not processed in their entirety during a single
web service call. Instead, they almost universally use one of the
asynchronous service patterns. At a very high level, these are:
1. Notify on Termination
Send the work together with a service address that will have a
message sent to it when the work has finished processing.
2. Poll for Termination
Send the work and immediately receive a token that may be used to
check on the status of the processing (including whether it is
done).
Naturally, these are not incompatible with each other; a particular
service might support both. However, the first pattern is most common in
server-to-server processing, and the second is most common in
client-server processing.
The translation of these high-level concepts into low-level ones is
something else. There's no standard at all for what the actual messages
on the wire (whether SOAP or REST) look like. There are standards in
some subject domains (e.g., WPS in the geospatial domain, BES for grid
computing) but they're incompatible with each other and there's no
general solution. (In particular, notification messages vary a lot and
are problematic for client code anyway due to common firewall policies,
and polling responses have nearly infinite variation.)
Let's veer more on topic for this list. :-D
Taverna Server implements the second model above. The Taverna workflow
model (as embodied in Taverna workflows) does not select any of the
models, or any particular implementation, but can interact with any of
them; it supports marking a sub-workflow as having a repetition
condition based on an output of that sub-workflow, which makes doing
polling pretty easy. This means that Taverna workflows (which you can
run by various mechanisms) can invoke these various asynchronous services.
Yes, you can have workflows that run workflows remotely. I've done that.
It's easy.
We can do some examples, but you'll need to be more specific about what
you're talking about. The solutions here are all highly domain specific.
Donal.
