What I need is: - serialize a workflow XML with all information it contains into and from a Java class object without Taverna dependencies (so that the saved XML will be functionally identical with the original one) - serialize a workflow into and from SQL (with all information it contains) in a manner independent on workflow format as much as possible - serialize workflow inputs and outputs in the same way as workflows (XML<-->Java<-->SQL) and converting them to be compatible with T1 and T2 API
George Stian Soiland-Reyes wrote: > Hi! > > We're working on making the new SCUFL2 workflow language. > > This will be a simplification of the current .t2flow serialisation, > but will also come with an API. > > We're basing this new workflow definition language on what we have > learnt are the best features of Scufl (from Taverna 1) and .t2flow - > Scufl was quite easy for third party suppliers to generate or parse > (for instance myExperiment generates the Taverna 1 diagrams from > scratch using Ruby code that parses the scufl), while .t2flow allowed > to specify all the finer grained details possible in the new Taverna 2 > engine - but this also made it a bit too verbose. > > These are early days, so we'll figure out what the language should be > and what the API should look like. Paolo Missier has done good work in > making a proposed UML model [1] of the new language, which we can then > use as the basis for figuring out the XML serialisation, but also the > Java beans of the API, and possibly also RDF and JSON versions. > > In my spare time I've tried to tie together some simple Java beans > implementing this UML model, and I've now checked this into > Subversion. [2] - these beans are not complete yet, have no > integration with Taverna code, and the API can only serialise to RDF > currently. (To test out Sesame/Elmo annotations on beans). > > I might come back with code examples so we can discuss what the API > should look like. The current tests only builds a workflow from > scratch - also note that scufl2-rdf is not yet connected to scufl2-api > and can be considered an early version of the scufl2-api. (API wise > there are pulls in different directions, for instance we want to make > it easy to inspect a workflow, but also to construct one. If more > information is needed for inspection, this could make it more tricky > to construct.) > > The API should minimally be able to: > > * Work independently, without any Taverna dependencies, runtime or > plugin system > * Load .t2flows > * Save as .scufl2 (undetermined yet what this format is - most > likely XML and/or RDF inside a Research Object .zip) > * Inspect an existing workflow to tell: > a) Processors > b) Connection between processor/workflow ports (and conditional links) > c) Activities/Services (ie. 'WSDL' method 'fish' from endpoint > 'http://asdkljasdkjasdkj') > d) Annotations > * Allow modification and creation from scratch of such workflows > > The API should be rich enough so that you could use it to generate the > workflow diagram - ie. what the myExperiment does already in Ruby. > > > Optionally: > * Load scufl 1 .xml from Taverna 1 > * Save as backwards compatible .t2flow or even scufl 1 if possible > * Exposed as a RESTful service > > > However, the API should also be lightweight, so it will not do tasks > better done by Taverna engine (t2core): > * Determining if a workflow definition is valid (checking for loops, > invalid iteration strategies etc) > * Perform the actual execution of the workflow > > Other tasks are also better suited for the main Taverna code base, as > they require various plugins or other considerations: > * Discovering available services/methods > * Find input/output ports of a given service definition > * Determining what configuration can be done for a given service > * Merging workflows > > > If you talk about a client/server architecture, you can picture these > (RESTful?) services: > > * Taverna engine: execute workflow and manage data/provenance > * Taverna inspection: check workflow definition validity, calculate depths, > etc > * Taverna service descriptions: Find available services, specify > possible service definition, determine ports for service definition > * Taverna editing: Workbench-type activities, Undo/redo, merge > workflows, workflow refactoring > * Taverna diagram: Generate workflow diagram in various formats and > configurations > > (The last two of these should be possible to implement using mainly > the Scufl2 API.) > > A client could then use the Scufl2 API and a selection of these > services - and still be able to implement what would look like the > current Taverna workbench. The client could be written in a non-Java > language, and use the Scufl2 serialisation schema/ontology directly > with the help of whatever XML/RDF/JSON support is available for its > language - this should give the same functionality but without a few > convenience methods. > > > We're very interested in hearing about potential use cases for what > such a SCUFL2 language and API could be used for. Feel free to add > your comments! > > > [1] http://www.mygrid.org.uk/dev/wiki/display/developer/SCUFL2 > [2] http://taverna.googlecode.com/svn/unsorted/scufl2/trunk/ > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
