On Thu, Mar 3, 2011 at 22:26, Alexandre Blondin Massé
<[email protected]> wrote:

> I see that workflows might be translated into XML files, but it would be
> tedious to write workflows this way. In the best case scenario, I'm looking
> for a more readable syntax (such as YAML) that one can edit in a plain text
> file and which would then be converted to the t2flow format, providing
> default values.


We have been working with our next generation workflow format SCUFL2
which should be more accessible for third-party systems than the
current .t2flow (which I'm sorry to say is quite hard to edit or
understand - even for Taverna).  There is an XSD for the t2flow
format, but it's quite verbose and picky about what you need to
include.

Our next format Scufl2 should be much easier to deal with for
third-party libraries and programming languages which are not Java
(although it comes with a standalone JAR library for Java).

See http://www.mygrid.org.uk/dev/wiki/display/developer/Taverna+Workflow+Bundle
for a quick overview - but note as this is still work in progress the
rest of the wiki pages are unfortunately not updated.

A live example is at
https://github.com/myGrid/scufl2/blob/master/scufl2-rdfxml/src/test/resources/uk/org/taverna/scufl2/rdfxml/example.scufl2
(browseable at 
https://github.com/myGrid/scufl2/tree/master/scufl2-rdfxml/src/test/resources/uk/org/taverna/scufl2/rdfxml/example)


I do however believe that Scufl2 is not ideal for hand-editing
workflows in a standard text editor, as I believe you would want to
stay closer to the style of say a Python script, rather than editing
XML and resolving identifiers.

One of the intentions of separating out Scufl2 was to allow
third-parties to develop such alternative formats, where you could add
limitations like "OK, we only deal with a certain type of workflows,
but those you can also write like this, and execute in another engine
like X.".


When making the Scufl2 API, I also quickly made such a text-based
format (called text/vnd.taverna.scufl2.structure) which looks like
this:

https://github.com/myGrid/scufl2/blob/master/scufl2-api/src/test/resources/uk/org/taverna/scufl2/api/io/HelloWorld.txt


Shrinking this to it's minimal definition for a Hello world:

WorkflowBundle 'HelloWorld'
  MainWorkflow 'HelloWorld'
  Workflow 'HelloWorld'
    In 'yourName'
    Out 'results'
    Processor 'Hello'
      In 'name'
      Out 'greeting'
    Links
      'Hello:greeting' -> 'results'
      'yourName' -> 'Hello:name'
      'yourName' -> 'results'
  MainProfile 'tavernaServer'
  Profile 'tavernaServer'
    Activity 'HelloScript'
      Type <http://ns.taverna.org.uk/2010/activity/beanshell>
      In 'personName'
      Out 'hello'
    ProcessorBinding 'Hello'
      Activity 'HelloScript'
      Processor 'HelloWorld:Hello'
      InputPortBindings
        'name' -> 'personName'
      OutputPortBindings
        'hello' -> 'greeting'
    Configuration 'Hello'
      Type <http://ns.taverna.org.uk/2010/activity/beanshell#Config>
      Configures 'activity/HelloScript'
      Property <http://ns.taverna.org.uk/2010/activity/beanshell#script>
        '''hello = "Hello, " + personName;
System.out.println("Server says: " + hello);'''


The scufl2 tools can process this format and 'fill in the blanks'
using defaults. It has indeed been suggested by a colleague to
slightly modify the format to make it valid YAML. A JSON version could
also be suitable for hand-editing and for web clients.

Further 'fill in the blanks' tricks might be helpful - for instance
this example shows how each level of ports can have different names
including Input/OutputPortbindings to do the mapping - but in 95% of
the cases the port names are going to match exactly. In a hand-edited
format it should therefore not be needed with the *PortBindings and
declaring the processor ports, a single AutoPort statement or
something at the top should be enough. When making this format I had
to include these details explicitly as existing workflow definitions
MAY do such a mapping.


You will in the future be able to execute such a scufl2 workflow using
the Taverna 2.4 platform once it's released - but note that this
experimental format has not yet been integrated with the off-the-shelf
workbench or server/command line.


The main reason why hand-editing workflows would be difficult comes to
the nature of Taverna workflows - they tend to use external web
services like WSDL and REST - and it's tricky from a text editor to
predict what will be the port-names coming out of a certain service
definition - given that you even know which service definition to put
in. However, if you do copy-and-paste from existing workflows or just
use local services as in this example, this should not be a problem.

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
taverna-users mailing list
[email protected]
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/about/contact-us/

Reply via email to