Hi!

Taverna 2.x and the Taverna Platform (the API on which the Taverna
Server is based) are currently two separate pieces of software.

The Taverna Platform [1] is a branch of the code-base of the workflow
engine (t2core), which has not yet been integrated into the Taverna
Workbench 2.x (the graphical interface for designing and running
workflows).  The main reason for this has been that we wanted to mature
the Platform and try it in other projects before committing to use it
from the Workbench.

The primary motivation for building the Taverna Platform was to make it
easier to use Taverna code from other software, and to make it easier to
extend Taverna. Additionally we wanted to solve some of the issues we
and third party developers have had with classloaders and our plugin
system Raven. Raven has been used by Taverna since Taverna 1.5 up to and
including 2.0.

The platform replaces the old Raven system  (which was very closely
related to Maven) with a new plugin-based solution (Raven 2) which makes
the classloaders behave more like in a normal Java program, while
keeping the separation between individual plugins. This means that in
the Platform it would not be a problem if different activity/service
implementations co-exists and depend on different/conflicting versions
of dependencies such as Axis or JAXB.  There are however industry
standard ways to do this.

As part of the Platform work, some of the APIs of the core workflow
libraries had to be modified. As the platform is a fair amount of new
work, introduces a new plugin/discovery system, and in addition had some
unfinished pieces (such as activity implementations), we could not yet
commit to moving the Taverna workbench to use the Taverna platform.

After the release of Taverna workbench 2.0 important additional work for
the graphical user interface was identified.  We therefore started the
user interface-centric work towards the upcoming Taverna workbench 2.1,
but based on the pre-platform branch of t2core and Raven, which are
largely unchanged since Taverna 2.0.

The main new features of the 2.1 workbench will be GUI enhancements for
service discovery, workflow editing, workflow invocation, reduced memory
footprint (supporting larger data values) and support for
provenance/intermediate values. Taverna Workbench 2.1 Beta 1 release is
imminent.

We have now had time to evaluate the Platform in projects and done a
review of the codebase. One of these projects using the Platform is the
Taverna Server, which allows remote execution of Taverna 2 workflows
through a RESTful interface (in the same way as the Taverna Remote
Execution Service did for Taverna 1). A beta version of Taverna Server
will be released in June, and is currently used by the Shared Genomics
project.

This upcoming Taverna Server is built upon the second beta version of
the platform (p0.1b2) , which we will also release during this summer.
The work remaining for doing this release of the Platform is mainly to
update the documentation, examples, JavaDocs and Maven archetypes to use
the new versions. This version of the platform completes support for
activity types like BioMoby, Soaplab and nested workflows.

The platform has also successfully been used by a student to build a
prototype portlet for executing workflows.

Based upon this combined experience, we are planning to continue
maintaining the majority of the Platform, e.g. the Platform API,
although some minor modification might become necessary for later
versions, such as for plugin definitions.

We have however identified that some of the back-end components of the
Platform would require extensive future maintenance from the project
team. Our main goal is to continue to provide Taverna as a top class
workflow environment, and we can't really justify spending too much
developer time on maintaining bespoke code for which industry standard
efforts could be used.

An example of this is the Raven 2 plugin system which could be replaced
by a standard system that would thus be less onerous to support. This
approach would also offer a better sustainability path for the project.

Thus the long-term plan if for us to replace the Platform Plugin system
(Raven 2) with Spring Dynamic Modules [2] which uses OSGi [3] (which is
used famously in Eclipse [4]).

We have not yet decided on which OSGi implementation we will go for, but
they do seem to be quite interchangeable (Eclipse Equinox, Knopflerfish,
Apache Felix). Moving to OSGi would require additional modifications to
the core and the workbench.

This change to the Platform vs. using Raven 2 would take additional time
and may impact plugin providers who are using the current Platform
system, but we think that in the long run from a support and compliance
perspective this is the right decision for the project.

Your comments on this strategy are most appreciated and expected.

Best Regards,
The myGrid Taverna Team.




[1] http://www.mygrid.org.uk/tools/developer-information/taverna-platform/
[2] http://www.springsource.org/osgi
[3] http://www.osgi.org/
[4] http://www.eclipse.org/equinox/


-- 
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 as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
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

Reply via email to