On 15 March 2016 at 08:07, Thilina Manamgoda <[email protected]> wrote:
> I have gone through the tutorials Service invocation plugin > <http://dev.mygrid.org.uk/wiki/display/developer/Tutorial+-+Service+invocation+plugin> > and Service discovery plugin > <http://dev.mygrid.org.uk/wiki/display/developer/Tutorial+-+Service+discovery+plugin>. Great! Did you find any issues while doing so? > So in order to bring CWL workflows to the Taverna i have to implement Service > discovery plugin > <http://dev.mygrid.org.uk/wiki/display/developer/Tutorial+-+Service+discovery+plugin> > for CWL right ?. Yes, the TAVERNA-880 task is basically to implement a service discovery plugin for CWL. The Service Invocation tutorial would be more relevant for TAVERNA-878. It could be that to test your UI, to be able to drag a CWL Tool into a workflow, you need to have a "dummy" Activity similar to the one in the tutorial, even if it doesn't actually do any actual invocation when it is run. That is, it would be a placeholder. > 1. SCULF2 workflows are saved as workflow bundle document . Correct.. except it's a ZIP file of XML files, not a single document :-) > 2. Service discovery plugin > <http://dev.mygrid.org.uk/wiki/display/developer/Tutorial+-+Service+discovery+plugin> > Service > Description is java bean and it's build using corresponding workflow > bundle document . It's a java beans (in the Configuration), but as the tutorial is according to Taverna 2.5 you will later need to update your Service Discovery code for Taverna 3, where you will use the Taverna Language SCUFL2 API - which is a java bean approach to the Workflow Bundle. (those beans are then saved to the Workflow Bundle ZIP file, but that is already handled). The beans are different though, the Taverna 2.5 beans have a Configuration subclass per activity type, e.g. a ToolConfiguration - while in Taverna 3 the Configuration class is not subclassed (instead it declares a type URI), and all the actual configuration is in the linked JSON object - which content would vary per configuration type. > 3. Activity has the logic of workflow .For example let's say service is > addtiion of two numbers . Then two numbers are input and the addition is > inside the Activity class . Exactly, the Activity is the thing that actually 'happens' in a box in the workflow. The rest of the workflow is basically connections, iterations and controls. > 4.Activity class is also configured (build) using corresponding workflow > bundle document . Yes. When a WorkflowBundle is set to run, the Taverna Engine will select the corresponding Activity subclass based on its type URI, instantiate it, and then configured it with a JsonObject (which exists as a JSON file if the Workflow Bundle is saved as a ZIP file.) There are different types of activities depending on what kind of invocation they are doing, e.g. a RESTActivity that can do HTTP calls (the configuration says which URI and headers), the ToolActivity can execute a local or SSH command line (the configuration says which command/host), or the BeanshellActivity can run a Beanshell script (the configuration contains the script). There are thus different configuration types, and a corresponding JSON Schema that says which keys and value types to expect for a given type. The imagined CWLActivity (TAVERNA-878) will be either a new kind of activity, or just an alternative configuration of the ToolActivity - as basically a CWL Tool is a command line that in theory may be executed using the correct "docker run" syntax. In Taverna 3 it is possible to have different kinds of configuration for the same activity, the ToolActivity could be changed to recognize both its existing "classic" Tool configuration and a new "CWL tool" configuration. If you are interested in this execution logic, then it is probably worth having an early stage investigation in the beginning of your GSOC project to see to what extent the existing execution logic of the ToolActivity can run a docker command line - e.g. experimenting in the 2.5 Workbench and adding a Tool that executes a tool as in the CWL Tool description, and then you would be able to see the configuration mapping in a way. (But it could be that this reveals that say the data handling of CWL Tools is different to how the Tool activity handles input and output files - in which case a new CWLActivity would be a better approach). As you write up your project proposal now, you should have some rough estimates and time plans. Doing both TAVERNA-878 (activity) and TAVERNA-880 (discovery) could be too much for the short duration of GSOC, so if you are interested in both I would suggest to do one of them only minimally. > *5. when designing a CWL * Service discovery plugin > <http://dev.mygrid.org.uk/wiki/display/developer/Tutorial+-+Service+discovery+plugin> > i > Have to implement dummy Activity class for CWL . Yes, with a "dummy activity" I mean one that can't actually execute anything, it might just always say "Hello" on the output so that you can see in the workbench that you have added something from your CWL Service Discovery plugin. Also when you do this in Taverna 2.5 you need to have an actual Activity subclass to add to the workflow - this is a problem in 2.5 in that you couldn't build workflows with activities your local Taverna didn't know how to execute. In Taverna 3 the workflow building is done with plain java beans from the Taverna Language API, and those don't know anything about execution, and so there it would be possible to build workflows with activities that only run elsewhere (e.g. build a workflow in Windows even though its activity can only run in Linux). Alan - do you think in Taverna 2.5 phase we could let the CWL Discovery plugin add a DisabledActivity instance and then chuck the configuration JSON inside the XML? Would not then that XML be saved directly to the .t2flow? It would be a bit cheating.. but then this would be cheating anyway, and also it would mean it would both save from Taverna Workbench 2 and load in Taverna 3. (We would need to add a translator on the Taverna Language side though). > It should have logic to > execute cwl-runner with corresponding tool and inputs and get the output . Executing cwlrunner from Taverna (configured with a CWL workflow rather than a CWL tool) could be an interesting thing - that would be a way to include a CWL workflow as a nested workflow in Taverna. However I think that would be a different approach, so I've tracked that as a new Jira task https://issues.apache.org/jira/browse/TAVERNA-938 This could be some kind of intermediate approach you could explore if you want, as you can execute any cwl tool by generating a one-step cwl workflow and run cwlrunner. However then the user would need to have cwlrunner AND Taverna installed, so it would be more of an intermediate solution, which would however be great for demonstration purposes - and mean that your GSOC work would be usable without waiting for the other tasks. Personally I am also going to try to work on the CWL support during this spring/summer - so whatever tasks are not picked by an accepted GSOC student would be something I would try to do - however I wouldn't want the students to have to rely on this arriving in time, as your GSOC evaluation (which determines if you get paid!) should be independent of other concurrent work, including different GSOC students. That doesn't mean you can't collaborate and discuss solutions on this list - I would hope you do! Just don't build other people's work into your project proposal like a blocker. You are asking the right questions! Feel free to ask if you need help with your project proposal! -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
