Thanks Stian. I'll do a bit of investigation around the points you raise before I reply - in case I miss anything obvious!
On Thu, 2009-05-21 at 10:40 +0100, Stian Soiland-Reyes wrote: > 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 -- Richard Holland, BSc MBCS Finance Director, Eagle Genomics Ltd T: +44 (0)1223 654481 ext 3 | E: [email protected] http://www.eaglegenomics.com/ ------------------------------------------------------------------------------ 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
