On the Applicability of Workflow Management Systemsfor the Preservation of Business Processes

Rudolf MayerSecure Business Austria

Vienna, Austriarmayer@sba-research.at

Stefan ProellSecure Business Austria

Vienna, Austriasproell@sba-research.at

Andreas RauberSecure Business Austria

Vienna, Austriaarauber@sba-

research.at

ABSTRACTDigital preservation research has increasingly been shiftingfocus from the preservation of data and static objects to in-vestigate the preservation of complete processes and work-flows. Capturing all aspects of a process to be preserved,however, is an extensive and difficult undertaking, as it re-quires capturing complete software setups with potentiallycomplex setups. Further, the process might use externalservices that are not easy to capture and monitor. In thispaper, we therefore investigate the applicability and usabil-ity of using Workflow Management Systems for executingprocesses in a standard environment where the state of theprocess can be closely monitored. To this end, we comparethree popular workflow management systems. We use a sce-nario from eScience, implementing a data analysis process,to evaluate the challenges and implications for establishingsustainable and verifyable eScience processes.

General TermsE-Science, Research Infrastructures, Process Preservation

1. INTRODUCTIONClassical digital preservation has its focus on maintainingthe accessibility of digital objects, such as documents, im-ages or other rather static digital files. This area is well un-derstood and solutions to many former problems exist. Thenext stage of preservation research deals with the preserva-tion of complex systems and composite processes, as theycan be often found in the business and research commu-nity. Such processes are in contrast to static files highlydynamic and require constant monitoring. The process ori-entation can be identified in rather young research areassuch as E-Science and also the discipline of business processengineering. In science, experiments need to be preserved asresearchers need to be able to reproduce and build on topof earlier experiments to verify and expand on the results.It may also proof essential to understand any pre-processingsteps and consequences on the interpretation of results in

any future meta-studies building on top of earlier researchresults. In businesses, preservation of processes can play animportant role e.g. in liability cases, where a company hasto prove that a certain series of steps was executed in thecorrect manner and according to standards, best practicesor laws and regulations. Another motivation are patent liti-gations, when a company would want to demonstrate how acertain invention originated. Therefore, businesses have topreserve their processes for many years and need to rerunthem whenever necessary.

Both areas have in common that they involve large amountsof data and integrate heterogeneous services. These systemsform critical infrastructure. Hence their preservation is anurgent and important quest that needs to be tackled. Thisis a challenging task as these systems are highly complexand consist of many different components, not all of whichare under the influence of one controlling instance.

Processes describe how a certain goal has to be achieved.Scientific and business processes consist of intermediate stepswhich are modelled by the use of workflows. There existworkflow management systems for both domains. These aregeneric software systems that are driven by explicit processdesigns to enact and manage operational business or scien-tific processes, as defined by Aalst[13]. A workflow is definedas “The automation of a business process, in whole or part,during which documents, information or tasks are passedfrom one participant to another for action, according to aset of procedural rules.”[13]. Hence, workflows describe theflow of information through a business process. The sameparadigm has been adapted in the scientific domain, whichlead to Scientific Workflow Management Systems that aidscientists to handle increasingly complex and data drivenexperiments. In order to tackle this increasing complexityand the orchestration of manifold services and systems, theconcept of scientific workflows has received increasing at-tention within the research community. E-Science projectsprofit from the combination of automated processing stepsin workflows in order to perform complex calculations anddata transformations. The advantage of workflows is theircapability of adding structure to a series of tasks. Theycan be visualized as graph representations, where nodes de-note processes or tasks and edges denote information or dataflows between the tasks. This adds a layer of abstraction andhelps to clarify interactions between tasks [2].

Many of today’s data-intensive experiments depend on a

Page 101

number of external service such as Web services, or continu-ously changing third-party libraries and applications. Thesechanges are not always under the control of the researcher,and may happen at a system level beyond the awareness ofthe individual researcher, such as e.g. a new library beinginstalled as part of (automatic) system maintenance. Thismay lead to different results from the workflow, or renderthe workflow not executable altogether. The possibility toreproduce workflows is also a crucial principle in the businessdomain.

Preserving the repeatability of such a process in a changingtechnological environment is therefore a current and emerg-ing topic in Digital Preservation research. Digital preser-vation of business or E-Science processes requires capturingthe whole context of the process, including e.g. dependencieson other computing systems, the data consumed and gen-erated, and more high-level information such as the goalsof the process. In this paper, we investigate the feasibilityof Workflow Management Systems (WFMS) for preservingscientific processes. We propose that the implementation ofa scientific process can be seen as migration strategy, as theoriginal design, structure, meaning and results can be pre-served. We provide an overview on the power of such sys-tems and evaluate the effort to migrate workflows betweendifferent WFMSs.

The success of preservation activities have to be evaluated.Hence it is required to identify and examine all involved com-ponents and the data exchanged between them. This can beachieved by the use of provenance data, which describe thelineage of data and the causal relationships between inter-mediate steps. Most WFMSs provide the possibility to gen-erate such provenance data automatically. Therefore thesesystems are valuable for the preservation of processes. Inthis paper, we first outline which information is importantto be captured. We will then investigate the suitability ofsuch automatically recorded provenance data in a case-studyof a scientific experiment in the data mining domain.

2. WORKFLOWS AND WORKFLOW MAN-AGEMENT SYSTEMS

In both domains - science and business - workflows allow toprecisely define the involved steps, the required context andthe data flow between components. The modelling of work-flows can be seen as an abstraction layer, as they describethe computational ecosystem of the software used during aprocess. Additionally, they provide an execution environ-ment, that integrates the required components for perform-ing a process and executing all defined subtasks. This ab-straction supports the preservation process as there is moreinformation about the execution details available. Hence weexamine the feasibility of scientific workflow systems for thepreservation of scientific processes.

Different scientific workflow management systems (SWMS)exist that allow scientists to combine services and infras-tructure for their research. The most prominent examplesof such systems are Taverna [9] and Kepler [5]. Vistrails [11]is another workflow management system prominent espe-cially in visualisation, but will not be covered in detail here.Workflow management systems are also prominently used toexecute business processes. We will look at the open-source

system Activiti.

2.1 Taverna WorkbenchTaverna Workbench1 is an open source project that allows todesign and run workflows. It is a general purpose workflowengine that can be used for various applications. It is writtenin the Java programming language and distributed under theGNU Lesser General Public License (LGPL2).

Taverna allows to orchestrate various services and to modelthe data flow between its components in order to automatea process. Therefore Taverna is widely used in the scientificcommunity and used for modelling data centric experiments.It provides a graphical user interface that allows scientiststo design and execute their experiments in a convenient wayand to visualize the data flow of an experiment. An exampleof such a workflow is given in figure 1.

Taverna is a service oriented workflow engine and allows tosolve tasks by using either local or remote services. Localservices include basic file operations, format conversions andmany different tools. Remote services include predefinedWeb services from various domains, such as bioinformaticsor chemistry. It is also possible to implement custom servicesusing the Taverna Java Application Programming Interface(API). Services can also be implemented via scripting lan-guage; Taverna to this end supports the language beanshell,which is based on the Java programming language.

Taverna uses ports to exchange data between the services:each service can have several input and output ports, whereone output port serves as input for a subsequent service.The workbench has an integrated support for scalars andlists, which includes implicit iteration over arrays of data.Looping over data elements is also integrated and allows theusage of control and synchronization points. In its basicconfiguration, Taverna simply passes down data tokens in adownstream fashion to the next connected service.

2.2 The Kepler ProjectThe Kepler scientific workflow system[6] is a general purposeapplication suite for managing, orchestrating and executingscientific workflows. Kepler is an open source project, dis-tributed under BSD license3 and written in the Java pro-gramming language. It provides a graphical interface whichenables scientists to design and execute experiments, bylinking various services each fulfilling a subtask of a work-flow. Kepler inherited the graphical user interface and theactor-centric view of workflows from the Ptolemy II4 project,which is a framework for designing embedded systems andthe communication between components.

Actors are used to model individual steps during the exe-cution of an experiment; they can perform relatively simpletasks as format conversions, displaying data or reading a filefrom a Web server. There also exist more complex actorsthat invoke specialized grid services, utilize domain specificdatabases or execute external services. It is also possible

1www.taverna.org.uk/2www.gnu.org/licenses/lgpl.html3http://www.opensource.org/licenses/bsd-license.php4http://ptolemy.eecs.berkeley.edu/ptolemyII/

Page 102

to develop custom actors by implementing desired featuresin Java using the Kepler API, and instantiate them withinthe Kepler system. Further more, python scripts can beexecuted as well, which reduces the development effort andenhances the flexibility, as no detailed knowledge about theKepler API is needed.

Actors use Ports for communicating and exchanging datawith each other; each Port can either serve as input, outputor both to an actor. Ports connect Actors by using chan-nels, which models the data flow and logical sequence of in-termediate steps within the workflow. Actors are thereforeroughly comparable to services in Taverna.

The workflow is orchestrated by a so-called director, whichis the component responsible for arranging the timing ofthe data flow. There exist different directors for variouspurposes, such as sequential, dynamic or parallel executionof actors.

2.3 ActivitiActiviti is a workflow and Business Process Management(BPM) Platform, based on the Business Process ModellingNotation (BMPN) 2.0. It is available as open source soft-ware and written in the Java programming language, main-tained by a consortium of companies offering cloud and Javasolutions.

Unlike Taverna or Kepler, it doesn’t provide an integratedGUI. Instead, the design of the workflows is enabled by anBPMN 2.0 editor which can be installed as an extension tothe Eclipse Integrated development environment (IDE). Allthe elements available in BMPN 2.0 can thus be used todesign the workflow. For execution of the workflow, Activ-iti can be run as a web-application on a Java ApplicationServer, or as a stand-alone Java application.

Of the BPMN 2.0 elements, most importantly, tasks rep-resent processing steps in the workflow. These tasks areassociated via simple sequence flow connections to definethe order of execution. Control flow can be modelled withgateways, such as for parallel or exclusive processing. Thereis no explicit definition of data exchanged, as it is done viaPorts in Taverna or Kepler. Rather, a global state of datavariables is kept in a key-value map.

Implementation of tasks is enabled by Java classes, or script-ing languages that support the Java Scripting Platform,which includes among others JavaScript, Python, Ruby, andGroovy. Both are straight-forward with convenient integra-tion into the BPMN editor. User interaction tasks, whichplay a more important role in business processes than inscientific experiments, can be implemented via forms; theseenable the user to input data, e.g. as workflow input param-eters. Unlike the scientific workflow management systemsof Taverna and Kepler, Activiti doesn’t provide a library ofpre-defined tasks to use; however, in the implementation onecan draw on the many libraries available to Java and all thescript languages supported.

3. CASE STUDY - SCIENTIFIC DATA MIN-ING PROCESS

In this section we discuss the implementation of a typicalE-Science process with the workflow management systemsintroduced above. The specific process used in our casestudy is a scientific experiment in the domain of data min-ing, where the researcher performs an automatic classifica-tion of music into a set of predefined categories. This typeof experiment is a standard scenario in music informationretrieval research, and is used with many slight variationsin set-up for numerous evaluation settings, ranging from ad-hoc experiments to benchmark evaluations such as e.g. theMIREX genre classification or artist identification tasks [7].

The experiment involves several steps, which can partiallybe parallelised. First, music data is acquired from sourcessuch as benchmark repositories or, in more complex settings,online content providers, and in the same time, genre assign-ments for the pieces of music are obtained from ground truthregistries, frequently from websites such as Musicbrainz.org.Tools are employed to extract numerical features describingcertain characteristics of the audio files. In the case of theexperimental set-up used for the case study, we assume amore complex set-up where an external web service is usedto extract such features. This forms the basis for learninga machine learning model using the WEKA machine learn-ing software, which is finally employed to predict genre la-bels for unknown music. Further, several scripts are used toconvert data formats and other similar tasks. The processdescribed above can be seen as prototypical from a rangeof eScience processes, consisting both of external as well aslocally available (intermediate) data, external web servicesas well as locally installed software used in the processing ofthe workflow, with several dependencies between the variouscomponents.

This scientific experiment has so far been executed by plug-ging together a number of Java programs, writing their datainto intermediate files, and scripts implemented in the Linuxshell to provide serial and parallel execution. This set-updoes not provide a high degree of resilience to technologicalchanges: the fact that both source data as well as groundtruth data are provided externally does not allow the rep-etition of any experiment with comparable results. Depen-dencies on software and libraries installed in the experimentplatform, that will usually change with frequent system up-dates further limit repeatability and re-executability. Thisis further threatened by the fact that the logic of extractingthe numeric descriptors is encapsulated in an external ser-vice that may update its functional description at any pointin time, potentially without providing any information on aservice version update.

The scientific process as it is implemented and executed atthe moment is exposed to a number of threats. For once,the process is not very well documented, e.g. the exact in-put and output parameters of each step are not defined, aswell as the sequence of execution of the scripts. It is alsodependant on the shell of a specific operating system. Evenif e.g. the operating system and version is the same, localconfiguration of the default shell can vary for example on theLinux system, and thus scripts might be not be executable.Monitoring of the process execution is difficult, as there isno direct support available from the shell to capture inputand output parameters. Finally, shell scripts might not be

Page 103

Figure 1: Scientific workflow modelled in the Taverna Work-flow engine

persistently stored, but just typed and executed on the shell,and lost upon ending that shell session.

Even though individual of these aspects might be resolvedwith different means, migration of the process to a workflowmanagement system seems to be a holistic approach towardsthe digital preservation process.

3.1 Implementation in TavernaThe implementation in Taverna required the migration ofscripts and commands, that would have been executed withthe shell of the operating system, to scripts in the Taverna-supported language (beanshell). These scripts were mainlyused for performing format migrations for converting outputdata into the desired input format for the following tasks.The first step of the workflow could be solved by using ser-vices shipped with Taverna. We queried a directory list ofa Web server containing the music files to be classified. Af-ter the server returned the HTML document containing theURLs of the files, a beanshell script was required to parse theactual locations of the files and for preparing a list. Conse-quently, the files had to be fetched from the collected URLs.This was achieved by modifying a provided Taverna serviceslightly to adapt it from images to MP3 files.

The next step (Base64 encoding) could be accomplished withan unmodified Taverna service, but had to be followed by acustom encoding beanshell for ensuring URL safety of theencoded files. The now correctly encoded files are passed toa REST-Web service in the following step. Taverna providesa ready to use REST invocation service, that has to be fedwith the according file and an authentication voucher. Afterthe service processed the files, a custom beanshell script wasused for merging the single feature vectors to combined file.

The resulting file was then converted to the so called ARFFformat, by using a beanshell script which invokes a thirdparty library. This Java library had to be provided to theTaverna classpath in advance of the execution, and the usageof the library has to be explicitely specified in the beanshellservice using it. After this has been achieved, the API of thislibrary can be addressed via beanshell as if it were regularJava. The final step was again solved by using a beanshellscript and an external library, which performs the actualclassification.

The implementation in Taverna is fairly straight forward, asit allows to use the power of Java by a simplified scriptinglanguage. The library of existing local and remote services isextensive, and these services can easily be adapted to meetrequired specifications. Another advantage of Taverna isthat the design, adaptation and execution of scientific exper-iments is integrated completely into the workbench, whichreduces the installation and administration effort.

3.2 Implementation in KeplerKepler also provides scripting capabilities for Python, specif-ically by Jython5, an implementation which runs inside theJava Virtual Machine (JVM) and thus does not require ad-ditional software packages to be used. Nevertheless, as thethird party libraries used in the process are written in Java,we were hinted at implementing the required actors in Javaas well. This however is a serious overhead compared tobeing able to use the third-party library directly from bean-shell as in Taverna. To implement the custom actor, oneneeds to set up the Kepler development environment. Thebuild process is documented well, but requires several stepsuntil the actual development of actors can be achieved.

The workflow implemented in Kepler is depicted in figure2. A dynamic dataflow (DDF) director is used as there areseveral loops in the workflow. The first actor activated inthe workflow is the Web Service. As invoking the service re-quires several steps, we encapsulated the internal logic intoa so called composite actor. A composite actor itself con-tains a sub-part of the workflow and is used for reducing thecomplexity of the overall workflow, by hiding certain partsfrom the overview.

Although Kepler ships with a large amount of ready to useactors, it was necessary to implement several custom actorsfor e.g. Base64 and URL encoding on our own. The capabil-ities of wrapping existing actors, as it is enabled in Taverna,without modifying their source code is limited. Also the im-plementation of standard dataflow controls such as loops andconditionals requires many small intermediate steps, whichrender the overall process hard to read, interpret and under-stand.

3.3 Implementation in ActivitiAfter setting up the development environment in the EclipseIDE, the implementation of the workflow in Activiti is ratherstraightforward, as task definition in the BPMN diagramand implementation of these classes are conveniently inte-grated. Even though Activiti does not provide a library

5www.jython.org/

Page 104

Figure 2: The Music Process Workflow designed in Kepler

Figure 3: The Music Process Workflow designed in Activiti BMPN 2.0

of commonly repeating task implementations, the straight-forward usage of Java as task implementation language al-lows to draw on the rich set of third-party libraries for com-pact implementations. Some steps, such as the fetching offiles and encoding thereof, have been implemented with inJavascript. Fetching the genre assignment ground truth,calling the feature extraction REST service, converting thedata format and performing the classification were solved asJava task implementations.

4. VALIDATION AND VERIFICATION OFPROCESS EXECUTION

Preserving workflows entails the requirement of validatingtheir intermediate results and the overall output of a processexecution. Preservation is only then considered a success, ifall identified significant properties are equal before and afterthe preservation. The challenge of keeping workflows acces-sible is caused by the dynamic nature of processes. Externalcomponents such as Web services and third party librariesare beyond the influence of workflow designers and users.These components might change at any point in time with-out prior announcement. Hence, they are critical threatsto long term accessibility of workflows. In order to detect

these changes, it is necessary to monitor the workflow andthe intermediate results they produce. This is a crucial re-quirement, as otherwise the reproducibility of workflows isat risk.

Measuring changes in significant properties is a difficult task.The authors of [3] propose a framework for evaluating whethertwo versions of a digital object are identical. The frameworkconsists of several steps, that allow to identify significantproperties of digital objects and examine their equivalenceafter an emulation process. These steps include the descrip-tion of the original environment and the identification ofexternal resources, that are beyond the influence of a sys-tem and influence the object to be preserved. The authorsstress that there are different levels, at which objects can becompared with each other. This is also true for workflows.After a workflow has been preserved, the new environmenthas to be tested if it behaves the same way as the origi-nal. Thus test data needs to be used in order to extract andcompare the significant properties of the workflow, i.e. if thereaction is identical to the data in both, the original and thepreserved environment. The focus of [3] is on emulation asa preservation strategy. The underlying concepts can never-theless be applied for other preservation strategies as well,

Page 105

that is for instance migrating a workflow, and specifically itscomponents, between different workflow engines.

When preserving processes, the data flow and the causal re-lationships between involved services can be seen as signifi-cant properties. Descriptions of this information is thereforerequired in order to compare intermediate results with eachother. Most workflow management systems use the conceptof provenance data to answer questions about execution anddesign details. Hence provenance data can be used for directcomparison of workflows across workflow engine boundaries.

4.1 Provenance DataProvenance data describes the lineage of data and providesevidence about execution details, involved services and theirintermediate results. A taxonomy of provenance techniquesused in various WFMS was introduced in [12]. This tax-onomy allows to categorize different systems based on thepurpose of recorded provenance, their focus, representation,storage and dissemination. A further distinction betweenprovenance systems can be achieved by the locus of dataprocessing control as identified in [1]. The authors distin-guish between command line based data processing, scriptand program based data processing, query based processing,service based processing and workflow management systemsbased processing. Depending on the type of data process-ing, different provenance data can be collected.Provenancedata captured during process execution is thus an importantaspect that must be captured as process context.

The recorded provenance data can be utilised to verify whetherthe new version of the process still renders the same results.To this end, as the evaluation framework suggests, one canautomatically reapply the inputs and verify the recordedoutputs, similar to what would be performed in automatedsoftware testing.

The provenance data can further be used for implementing awatch service for software and external service dependencies,e.g. by periodically executing the process with all historicrecordings of previous executions, either as a complete pro-cess, or for each process step individually.

4.1.1 Provenance Capturing in TavernaTaverna is capable of capturing the data exchanged betweenthe process steps as provenance data, and stores it in a rela-tional database (Apache Derby). Taverna records all invo-cations of the workflow and its individual steps, along withthe data exchanged and timing information. The data canbe exported in the Taverna-specific format Janus [8]; thealso available Open Provenance Model format [10] containsonly information of the invoked process steps, but not theactual data, and no information about execution time.

An example of the provenance data recorded for the twoprocess outputs, the percentage of correctly classified in-stances, and the detailed classification results, are given inListings 1 and 2 (note that some unique identifiers, such asURLs as namespaces, and identifiers for the workflow andspecific data elements, have been abbreviated for space rea-sons).

Listing 1: Example provenance data of Taverna for the pro-cess output ClassificationAccuracy (cf. Figure 1). The firstRDF Description element defines the output port Classifica-tionAccuracy, the second element contains the actual valueof “80.0”.

<rd f : Desc r ip t i on rd f : about=”{nsTaverna }/2010/workflow/{idWF}/ proce s so r /

Mus icClas s i f i ca t ionExper iment /out/C la s s i f i c a t i onAccu ra cy”>

<janus : ha s va lu e b ind ing rd f : r e source=”{nsTaverna }/2011/data/{ idDataGrp}/ r e f /{ idDataPort0}”/>

<r d f s : comment rd f : datatype=”{nsW3}/2001/XMLSchema#s t r i n g”>

Cla s s i f i c a t i onAccu ra cy</rd f s : comment><janus : i s p r o c e s s o r i n p u t rd f : datatype=”{nsW3}/2001/

XMLSchema#boolean”>f a l s e

</janus : i s p r o c e s s o r i n pu t ><janus : h a s po r t o rd e r rd f : datatype=”{nsW3}/2001/

XMLSchema#long”>0

</janus : ha s po r t o rde r><rd f : type rd f : r e source=”http :// pur l . org /net / taverna /

janus#port”/></rd f : Descr ipt ion>

<rd f : Desc r ip t i on rd f : about=”{nsTaverna }/2011/ data/{idDataGrp}/ r e f /{ idDataPort0}”>

<r d f s : comment rd f : datatype=”{nsW3}/2001/XMLSchema#s t r i n g”>

80 .0</rd f s : comment><janus : h a s p o r t v a l u e o r d e r rd f : datatype=”{nsW3}/2001/

XMLSchema#long”>1

</janus : h a s po r t va l u e o rd e r ><janus : h a s i t e r a t i o n rd f : datatype=”{nsW3}/2001/XMLSchema

#s t r i n g ”>[ ]

</janus : h a s i t e r a t i o n ><rd f : type rd f : r e source=”http :// pur l . org /net / taverna /

janus#por t va lu e ”/></rd f : Descr ipt ion>

Listing 2: Example provenance data of Taverna for the pro-cess output DetailedClassificationResults (cf. Figure 1). Thefirst RDF Description element defines the output port De-tailedClassificationResults, the second element contains theactual value, one entry for each file tested, with the actualclass, the predicted class, and the confidence of the classifierin the prediction.

<rd f : Desc r ip t i on rd f : about=”{nsTaverna }/2010/workflow/{idWF}/ proce s so r /

Mus icClas s i f i ca t ionExper iment /out/De t a i l e dC l a s s i f i c a t i o nRe s u l t s ”>

<janus : ha s va lu e b ind ing rd f : r e source=”{nsTaverna }/2011/data/{ idDataGrp}/ r e f /{ idDataPort1}”/>

<r d f s : comment rd f : datatype=”{nsW3}/2001/XMLSchema#s t r i n g”>

De t a i l e dC l a s s i f i c a t i o nRe s u l t s</rd f s : comment><janus : i s p r o c e s s o r i n p u t rd f : datatype=”{nsW3}/2001/

XMLSchema#boolean”>f a l s e

</janus : i s p r o c e s s o r i n pu t ><janus : h a s po r t o rd e r rd f : datatype=”{nsW3}/2001/

XMLSchema#long”>0

</janus : ha s po r t o rde r><rd f : type rd f : r e source=”http :// pur l . org /net / taverna /

janus#port”/></rd f : Descr ipt ion>

<rd f : Desc r ip t i on rd f : about=”{nsTaverna }/2011/ data/{idDataGrp}/ r e f /{ idDataPort1}”>

<r d f s : comment rd f : datatype=”{nsW3}/2001/XMLSchema#s t r i n g”>

1 2 : Hip−Hop 2 : Hip−Hop 0.667 (3 .359461)2 2 : Hip−Hop 2 : Hip−Hop 0.667 (3 .294687)3 1 : C l a s s i c a 1 : C l a s s i c a 0 .667 (2 .032687)4 3 : Jazz 3 : Jazz 0 .667 (2 .536849)5 1 : C l a s s i c a 1 : C l a s s i c a 0 .667 (1 .31727)6 1 : C l a s s i c a 3 : Jazz + 0.667 (3 .46771)7 3 : Jazz 1 : C l a s s i c a + 0.333 (2 .159764)8 2 : Hip−Hop 2 : Hip−Hop 0.667 (3 .127645)9 3 : Jazz 3 : Jazz 0 .667 (3 .010563)

10 2 : Hip−Hop 2 : Hip−Hop 0.667 (4 .631316)</rd f s : comment>

Each listing contains two RDF Description elements, wherethe first one defines the output port, and contains as a sub-

Page 106

element the identifier of the element containing the actualvalue, which is the second Description element in both list-ings. With the identifiers used in the rdf:about attributes, itis possible to uniquely identify the process step (and itera-tion, if the step is looped over) the data originates from.

4.1.2 Provenance Capturing in KeplerThe Kepler SWMS provides a dedicated module for record-ing provenance information[4]. When this software compo-nent is loaded, a specialized actor called Provenance Recorderis available. This actor is used for monitoring the processexecution and storing metadata about the workflow persis-tently. The provenance module stores provenance data bydefault in the relationl database HyperSQL (HSQLDB6).It is integrated directly into the provenance module andcan be queried by using the Database Manager providedby HSQLDB. Kepler stores detailed metadata about everyexecution of a workflow. This covers actors, ports, param-eters, relations and additional information about the work-flow, such as user names and context information. The Ke-pler provenance system also stores the data used during theexecution, which allows the detection of changes within theresults.

All information stored within HSQLDB can be queried byusing standard SQL, and from a Java program via an API.The OPM export feature completes the provenance datamanagement of Kepler; in contrast to Taverna the exportedOPM XML file contains time stamps and allows to derivethe execution sequence easily.

Listing 3: A Kepler OPM XML snippet

<wasGeneratedBy><e f f e c t id=” a2”/><r o l e value=”output”/><cause id=” p0”/><time>

<noLaterThan >16:26:17.333+02:00</ noLaterThan><noEarlierThan >16:26:17.333+02:00</ noEarlierThan><c lockId> c1 </c lockId>

</time></wasGeneratedBy>

Listing 3 depicts an example of an exported OPM file. Itcontains references to the actor that generated the output( p0) and refers to the the output of this event ( a2), usingauto-generated identifiers to refer to these elements.

4.1.3 Provenance Capturing in ActivitiActiviti refers to provenance data as (process execution) his-tory, and allows to configure recording on several levels ofdetail. Similar to the other systems, the data is stored ina relational database (H27), which can be queried to re-trieve information about the process and task invocations.As there is no explicit input and output of process steps(ports in Taverna and Kepler), rather the global state ofdata in the process execution is stored, than specific param-eters for a specific task invocation. Activiti also does notprovide an export into e.g. the OPM format.

6www.hsqldb.org/7http://www.h2database.com

5. COMPARISON OF WORKFLOW MAN-AGEMENT SYSTEMS

We identified a number of criteria important for the migra-tion and execution of processes workflow management. Asummary of these criteria is provided in Table 1.

Regarding setup of the design and execution platform, Ke-pler and Taverna provide a straightforward installation rou-tine, while Activiti requires a bit more work with preparingthe Eclipse IDE and plugins.

All systems evaluated in this paper allow to implement theprocess with the use of the Java programming language,even though the complexity of doing so differs greatly; bothKepler and Taverna require the programmers to develop themodules outside the workflow management system and thento register their services and actors, respectively, with theengine. Implementing tasks in Activiti benefits from theinitial setup of the Eclipse environment.

The systems differ greatly when it comes to the support ofscripting languages for fast and simple tasks. Here, Activ-iti provides the widest range of languages, and is in theorynot limited, as long as the language conforms with the JavaScripting Platform. If there are a lot of legacy scripts thatwould need to be preserved, Activiti would thus seem to bea prime choice. It seems vital that other systems would al-low such a wide range of implementations as well. Still, thiswill also raise the complexity of preserving the actual pro-cess as components in many different languages may need tobe preserved, together with their operational infrastructure(compiler, interpreter, runtime environments, etc.). Keplerprovides Python, and Taverna Beanshell scripting capabili-ties. The latter further provides a large library of servicesthat can be used to quickly perform common tasks, and al-lows to easily alter these template implementations.

All systems allow to record provenance data during the pro-cess execution, which enables for validation. Kepler andTaverna provide various types of exports of this data, in theOpen Provenance Model (OPM) and custom formats, andare more detailed on the single processing steps, as input andoutput ports of each process step are clearly defined. Thisseems to be an important aspect for detailed validation andwatch activities. Activiti could be easily augmented by anexport into the OPM, and input and output parameters fora processing step could, for a specific process execution, bededuced from the change in global variables.

6. CONCLUSIONSThe preservation of complete (business) processes is startingto be understood as a new challenge in digital preservationresearch. Scientific processes need to be preserved to allowlater verification of results, and business process preserva-tion can play an important role when it comes to liability orpatent infringement litigations.

However, process preservation is inherently difficult – to-day’s processes are executed inside complex software ecosys-tems, and composed of a myriad of services. Capturing thissoftware setup and its configuration is only one step – with-out being able to validate the process execution, we cannot

Page 107

Table 1: Features of Workflow Management SystemsEngine Implemen-

tationScript Lan-guage Support

Designer Sup-port

ExecutionEngine

ProvenanceCapturing

ProvenanceExport

Taverna Java Beanshell(Java)

Standalone Integratedwith designer

Database(ApacheDerby)

OPM & Janus

Kepler Java Python Standalone Integratedwith designer

Database(HSQLDB)

OPM

Activiti Java JavaScript,Python, Ruby,Groovy, ...

Via EclipseIDE

Web applica-tion or Javaprogram

Database (H2DB)

-

guarantee that the preserved process is still the same whenre-executed at a later time.

These two concerns are a bit relaxed when defining and ex-ecuting the process in a dedicated workflow engine, whichprovides a layer of abstraction to the original software setup.It also allows to closely monitor, and thus evaluate, the pro-cess execution. In this paper, we therefore described a num-ber of popular workflow management systems, and describedhow they can be used to migrate a scientific experiment pro-cess. Efforts for migrating a workflow to a workflow man-agement system might be significant; therefore, flexibility inthe implementation is a prime aspect.

With the migration of a process to a workflow managementengine, we can mitigate a few concerns that can hamper thepreservation of this process. First, the migration to work-flow engines has the benefit of requiring a clear and formaldefinition of the processes, which might not be present be-fore. Thus, we obtain documentation and detailed descrip-tions on the process. Further, we can evaluate and monitorthe execution of the processes closely, which enables verifi-cation that a process is still executed unchanged. Finally,the migration to a workflow management system in gen-eral is a step of abstraction from a specific software setup.The requirements and interfaces to operating systems or andsystem libraries are greatly reduced, and dependencies onthird-party libraries are generally explicitly defined.

The migration does not prevent external elements such asthe webservice employed in our case study from becomingobsolete. Thus, contracts and service level agreements haveto be agreed on with the providers of these services to main-tain and migrate their services if needed. Then, using previ-ously recorded provenance data, we can verify whether theseservices still behave as before.

7. ACKNOWLEDGMENTSPart of this work was supported by the projects APARSENand TIMBUS, partially funded by the EU under the FP7contracts 269977 and 269940.

8. REFERENCES[1] R. Bose and J. Frew. Lineage retrieval for scientific

data processing: a survey. ACM Comput. Surv.,37(1):1–28, Mar. 2005.

[2] J. Freire, D. Koop, E. Santos, and C. T. Silva.Provenance for computational tasks: A survey.Computing in Science and Engg., 10(3):11–21, May

2008.

[3] M. Guttenbrunner and A. Rauber. A MeasurementFramework for Evaluating Emulators for DigitalPreservation. ACM Transactions on InformationSystems (TOIS), 30(2), 2012.

[4] The Kepler Project. Getting Started with KeplerProvenance 2.3, August 2011.

[5] B. Ludascher, I. Altintas, C. Berkley, D. Higgins,E. Jaeger, M. Jones, E. A. Lee, J. Tao, and Y. Zhao.Scientific workflow management and the keplersystem. Concurrency and Computation: Practice andExperience, 18(10):1039–1065, 2006.

[6] B. Ludascher, I. Altintas, C. Berkley, D. Higgins,E. Jaeger, M. Jones, E. A. Lee, J. Tao, and Y. Zhao.Scientific workflow management and the keplersystem: Research articles. Concurr. Comput. : Pract.Exper., 18(10):1039–1065, Aug. 2006.

[7] Music Information Retrieval Evaluation eXchange(MIREX). Website.http://www.music-ir.org/mirex.

[8] P. Missier, S. S. Sahoo, J. Zhao, C. A. Goble, andA. P. Sheth. Janus: From workflows to semanticprovenance and linked open data. In Proceedings ofthe International Provenance and AnnotationWorkshop (IPAW2010), pages 129–141, Troy, NewYork, USA, June 15–16 2010.

[9] P. Missier, S. Soiland-Reyes, S. Owen, W. Tan,A. Nenadic, I. Dunlop, A. Williams, T. Oinn, andC. Goble. Taverna, reloaded. In M. Gertz, T. Hey, andB. Ludaescher, editors, SSDBM 2010, Heidelberg,Germany, June 2010.

[10] L. Moreau, J. Freire, J. Futrelle, R. E. Mcgrath,J. Myers, and P. Paulson. Provenance and Annotationof Data and Processes, chapter The Open ProvenanceModel: An Overview, pages 323–326. Springer-Verlag,Berlin, Heidelberg, 2008.

[11] C. Silva, J. Freire, and S. Callahan. Provenance forvisualizations: Reproducibility and beyond.Computing in Science Engineering, 9(5):82 –89,sept.-oct. 2007.

[12] Y. L. Simmhan, B. Plale, and D. Gannon. A survey ofdata provenance in e-science. SIGMOD Rec.,34(3):31–36, Sept. 2005.

[13] A. van der Aalst, A. Hofstede, and M. Weske. Businessprocess management: A survey. In M. Weske, editor,Business Process Management, volume 2678 of LectureNotes in Computer Science, pages 1019–1019. SpringerBerlin / Heidelberg, 2003. 10.1007/3-540-44895-0 1.

Page 108