On Wed, May 20, 2009 at 10:42, Richard Holland <[email protected]> wrote: > Anyhow... the workflow description language is one part of the equation, > which would be very useful to solve. Scripting or hand-editing isn't > quite so important here - what's important is the interoperability > between different workflow engines. Taverna gets halfway there by > allowing workflows to be constructed, saved, and reloaded later, but the > resulting XML is still Taverna-specific. I'm imagining something generic > enough that I could do 'Save as...' from Taverna, and later load the > same file into another toolwithout any problems, e.g. Pipeline Pilot > (heaven forbid!), or vice versa.
Part of the problem is that there are different workflow languages, so things possible in a Taverna workflow are not necessarily easy to express in a Pipeline pilot workflow or the other way around. In particular you will run into such issues if you are trying to go between a dataflow-oriented workflow language (like Taverna) to a control-oriented one (like BPEL). So where on this axis should the intermediate language lay itself..? If it is to be useful it would have to support a subset that they can each both load and save. That would mean that only certain workflows can be saved to this intermediate language, but that could be an approachable solution. For instance, you could say that it would not be allowed to include BioMart queries in a workflow that is to be saved in an intermediate language, if the intermediate language only support WSDL services. Likewise you will see issues in disagreements over what is 'really' the ports of a service. For instance now Taverna uses XML splitters to form and parse complex types for WSDL services - other languages might do this differently. In a future Taverna we want to get rid of those XML splitters and instead do this as a configuration on the WSDL service, similar to how you configure BioMart to say which input ports and output ports you want. It is possible in the Taverna workbench to add your own implementation of the workflow opening/saving, and I started on one yesterday to save a workflow as an RDF/N3 graph of the workflow. However, even this would still be pretty Taverna-specific - for instance separating between processors and services, assuming implicit iteration w/iteration strategies, etc. The question is if it's desirable to open this intermediate workflow format and run it, or simply get it as some kind of abstract dummy workflow where the user would have to fill in the actual services, scripts, etc. If you are expecting full editing of the format you'll quickly run down the BPEL path and end up with something that is very difficult to deal with as a user. > The other part of the equation is an engine other than Taverna to run > these generic workflows in (should the developer/user not want/be able > to have Taverna/Java installed on their machine, or they want to embed > the execution inside a non-Java bit of software, e.g. a Perl script). Again you will run into issues with different service implementations, for instance most Taverna workflows will include a beanshell script (often in the form of a local worker) - which is a scripting language that is very similar to Java. A Perl script would have trouble evaluating this. There are alternative implementations for SCUFL (the Taverna 1.x format) like MOTEUR - http://modalis.polytech.unice.fr/softwares/moteur/installing_moteur > Do other workflow execution engines exist that have APIs for other > non-Java languages? Most probably :-) It's possible to control Taverna workflow execution from other languages like Perl, Python and Ruby - one way would be to use the Taverna command line for executing workflow, another would be to use the remote execution service and it's REST interface - but the actual workflow would still run in a Java execution of Taverna. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ taverna-hackers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/taverna-hackers Developers Guide: http://www.mygrid.org.uk/usermanual1.7/dev_guide.html FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq
