WO2002046915A2

WO2002046915A2 - Workflow system

Info

Publication number: WO2002046915A2
Application number: PCT/US2001/043064
Authority: WO
Inventors: Christian Sonntag; Pierre Monestie; Thure Etzold; Mahmut Uludag
Original assignee: Lion Biosciences Ag
Priority date: 2000-11-13
Filing date: 2001-11-13
Publication date: 2002-06-13
Also published as: AU2002233926A1; WO2002046915A3

Abstract

A method for executing a task to be carried out by one or more computer systems through a workflow scheme representing said task. The task is represented by a set of workflow items. Each workflow item representing an action. Each workflow item receiving one or more inputs and delivering one or more outputs. Thereby forming a workflow representation of the task. The method includes identifying a workflow item delivering as an output the desired result of the task. The workflow representation is traced to identify all other workflow items which directly or indirectly deliver an output necessary to have a complete input for the selected workflow item. The actions corresponding to all identified workflow items are performed to carry out the task.

Description

WORKFLOW SYSTEM

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION

The present invention relates to workflow systems, and in particular to a workflow system used to perform at least one task on a computer.

DESCRIPTION OF THE RELATED ART

Workflow systems are a common tool. These systems are mainly used in corporations in order to automatize routine actions, such as answering letters, emails, etc. Known workflow systems follow the general approach illustrated in the Figure 1 and discussed below. The workflow is represented by a set of workflow items A1 to A4, where a workflow item corresponds to a certain action to be performed. An input is provided to the first workflow item A1. One example of an input is an incoming letter. In the workflow item , some action is performed. If the input is an incoming letter, then the work flow action could be scanning the letter. The next item, such as A2, may then carry out another action, such as the classification of the letter according to a classification scheme. In step A2, the letter may be classified as a debit note or an order letter. Depending on the classification step A2 then delivers an output to either step A3 or to step A3'. Step A3 may correspond to the processing of a debit note. For example, the debit note may be sent to the accounting department. Then, in subsequent step A4 a confirmation letter confirming receipt of the debit note may be generated. If the letter in step A2 has been classified as an order letter, then the workflow may proceed to step A3'. In this step, the order is delivered to the sales department. Then in step A4, a confirmation letter may be generated confirming the receipt of the order. This letter could also indicate the expected shipment date. Step A4 produces confirmation letters, however, the letter output depends on the input. When the input comes from step A3, a debit not a confirmation letter is generated. If the input is from step A3', an order confirmation is generated. Basically all known workflow systems follow the approach schematically illustrated in Figure 1. Consequently, the workflow scheme processes an input through a series of workflow items, where the individual actions are taken, and produces a result. Therefore, workflow systems have not been applied to applications other than the processing of some input through one or more workflow items.

In particular, workflow systems have not been used for the design of computer programs., since workflow systems rely on a certain input and are designed to handle the input in an appropriate manner. In contrast, the design of computer programs usually relates to the generation of a desired output. Therefore, applying the classical workflow scheme is not suitable for the design of computer programs. The object of the present invention is therefore to provide a workflow system that is suitable for the design of computer programs.

SUMMARY OF THE INVENTION The present invention in one of its embodiments provides a method for executing a computer program to be carried out by one or more computer systems through a workflow scheme representing the program. The workflow scheme is represented by at least one workflow item. The workflow item represents an action. The workflow item receives one or more inputs and delivers one or more outputs. The workflow scheme thus, forms a workflow representation of the task. The method includes selecting a workflow item whose output is the desired result of the task. The workflow representation is traced to select the other workflow items, which directly or indirectly deliver an output necessary to the input for the selected workflow item. The actions corresponding to the selected workflow items are performed to execute the program.

This approach is fundamentally different from classical workflow schemes.

Classical schemes use an input as a starting point and then build a workflow. This workflow processes the input depending which actions need to be performed on the input. In contrast, the present method starts from the desired task result. To such a result belongs a certain workflow item, which has one or more inputs. Those inputs then may be delivered from other workflow items, a users input, or an input from another program. Similarly, if the certain workflow item receives an input from other workflow items, these workflow items can receive their input from the same sources as the certain workflow item.

Using such an organization scheme, a large computational task can be designed and represented by a workflow representation using a goal oriented approach rather than the classical descriptive approach. This approach is particularly advantageous if only a portion of the task is executed to provide the desired result.

Preferably the outputs of the individual workflow items are written into a file, such as a log-file, together with an annotation identifying the individual task or the individual result which has been requested. This makes a system recovery after a power failure easier since only those workflow items for which no results have been yet written into a log-file need to be carried out. The system may refer to the data written in the log-file for the completed workflow items.

Preferably the workflow representation as a whole is divided up into several parts which can be run in parallel, possibly on different computers or in different programming routines. This makes parallelization of a large computational task easy if the large computational task is represented through a workflow according to an embodiment of the present invention.

Further features and the advantages of the present invention will become apparent from the following detailed description in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings incorporated in and forming part of the specification illustrate several aspects of the present invention, and together with the description, serve to explain the principles of the invention. In the drawings:

Figure 1 schematically illustrates a workflow according to the prior art. Figure 2 schematically illustrates a workflow according to a first embodiment of the present invention.

Figure 3 schematically illustrates a flowchart for performing a partial workflow according to a second embodiment of the present invention.

Figure 4 schematically shows the division of a workflow into two partial workflows according to third embodiment of the present invention.

Figure 5 illustrates an exemplary workflow items cross reference list.

Figure 6 illustrates a second exemplary workflow items cross reference list.

Figure 7 provides an exemplary design of a first embodiment of a workflow system. Figure 8 provides a sample of Icarus script for a workflow that may be processed by the system of Figure 7.

Figure 9 provides a sample of XML source code for a second workflow that may be processed by the system of Figure 7.

Figures 10A, 10B, 10C and 10D provide a second sample of XML source code for a third workflow that may be processed by the system of Figure 7.

Figure 11 provides an exemplary design of a second embodiment of a workflow system.

Figure 12 shows an exemplary work flow definition process that may be used in the system shown in Figure 11. Figure 13 illustrates an exemplary workflow flow diagram for a workflow that may be processed by the system of Figure 11.

Figure 14 provides a sample of Java source code for a branching workflow that may be processed by the system of Figure 11.

Figures 15A, 15B, and 15C provide a second sample of Java source code for a second workflow that may be processed by the system of Figure 11.

Reference will now be made in detail to the present invention examples which are illustrated in the accompanying drawings. DETAILED DESCRIPTION DEFINITIONS:

Activity: a unit of execution, an action which has at least one input and at least one output, in some cases a workflow containing a one or more activities may be considered or treated as an activity.

Data type: the specification of data passed between activities Transition: the logical dependency between activities, the link between activities. Database of activities: defined sets, libraries, and/or repositories of activities.

Autonomous data analysis controller: the self supporting execution of activities.

Executable encapsulated process is the executable code for performing any kind of task. Such a process has no knowledge of other executable encapsulated processes. Examples of biological executable encapsulated processes include ClustalW, BlastP, etc.

Execution engine: runs descriptions of activities and transitions between them.

Workflow: a set of activities. In some embodiments the workflow may also include transitions.

Workflow item: a unit of execution, an action which has at least one input and at least one output, in some cases a workflow containing a plurality of workflow items may be considered or treated as a workflow item.

DESCRIPTION

There is a growing amount of data that is publicly or privately accessible.

This data includes structured data, semi-structured data, and unstructured data. A growing quantity of this data is accessible from the internet. Thus, systems that autonomously analyze data are desirable. This is particularly true in the scientific community.

For example, the human genome provides a gold mine of data that must be analyzed to be useful. The ability to automatically or semi-automatically analyze biological data can speed the identification of potential new drugs and may reduce the development cost for new drugs (the cost of identifying potential new drugs is just one of the costs associated with drug development) In principle all kinds of data may be used. One method of automating data analysis uses a workflow. The work flow may have one or more activities or workflow items. If required, transitions may form a link between activities or workflow items. The workflow provides for a flow of data and a flow of logic.

For example, an activity may be a key word search on the internet and a transition could link between different searches depending on the search result or if the result had a particular quality.

Activities or workflows items may be defined separately from the actual definition of the workflow. Thus, an activity or work flow item is defined and/or coded once and is typically independent of the actual context in the workflow. Consequently, the activities or workflow items may be later combined into a variety of possible workflows.

For example, specialists could produce a set of activities. Biologists and/or bioinformaticians could use these activities to create specialized strategies in accordance with their biological knowledge. Activities may be combined without user interference, since the result of an activity may be passed on to the next activity and processed therein automatically. An activity may interface with any other activity through the use of well specified data types. No knowledge of the data types is required from the user as he/she does not directly access the programs, processes, and/or tools that may be called by a particular activity.

The return of a result is speeded up dramatically because of the autonomous operation.

Figure 2 provides an exemplary workflow scheme according to a first embodiment of the present invention. The illustrated workflow includes individual workflow items B1 to B6, each corresponding to a certain action. This action may include accessing a database, processing the input or inputs to the workflow item, making decisions based on the input or inputs to the workflow items or the like. Some workflow items may perform more than one action and, in some cases, may contain or call other workflows. In general, the workflow item represents any action that can be performed by a computer system or by a program running on a computer. Figure 2 illustrates some exemplary interactions between workflow items. A workflow item may use a single input, as shown by item B2. Alternatively, the workflow item may have several inputs. Items B4 uses inputs from workflow items B2 and B5, and thus illustrates using multiple inputs. The workflow item may deliver one or more outputs to one or more other workflow items. Item B3 illustrates providing multiple outputs by providing an output to workflow items B4 and B5. Item B2 illustrates providing a single output to item B3.

It will be readily apparent to the skilled person that such a workflow representation may be formed for each task, no matter how complex the task as a whole may be. Usually, computer programs follow a top-down-approach, where individual programming steps process an input to attain a certain output. With the workflow scheme depicted in Figure 2 a fundamentally different approach may be followed, depending on which result a user actually is interested in.

For example, if the user is interested in the result obtained by executing workflow item B4, the system may trace the workflow representation to find the workflow items, which provide direct and indirect inputs for workflow item B4. Initially, workflow items B2 and B3 are identified, since they provide direct inputs to workflow item B4. Thereafter, workflow item B1 is identified as delivering the direct input for workflow item B2. Consequently, work flow item B1 delivers an indirect input for item B4. Thus, the workflow items which need to be used to obtain the result of workflow item B4 have been identified and the task consisting of workflow items B1 , B2, B3 and B4 may be executed or performed.

It should be noted that due to the particular results being requested, namely the output of B4, it is not necessary to perform workflow items B5 and B6. Consequently, certain workflow items in a workflow may be omitted and only the workflow items of a workflow that are necessary to obtain the desired output need to be performed. An example of the process used by the second embodiment is schematically illustrated in the flowchart shown in Figure 3. In Step S1 , the desired result is selected. The workflow item that produces the desired result is identified, in Step

S2. Thereafter, the workflow scheme is traced to obtain all other workflow items that deliver input, either directly or indirectly, to carry out the selected workflow item.

Finally, the partial workflow consisting of the identified workflow items is performed.

The tracing can be carried out as described above, by identifying for each workflow item the workflow items that deliver an input to the workflow item. Iterating this procedure for each identified workflow item leads to a set of workflow items, which form the partial workflow corresponding to the desired result.

In a third embodiment, the workflow can be divided up into partial workflows which are assigned to different processors or different computers. Alternatively, the partial workflows may be assigned to different processing routines for simultaneous performance on a multi-tasking operating system. This embodiment is schematically illustrated in Figure 4.

Figure 4 illustrates two partial workflows 400 and 410 that form workflow 420. The division of workflow 420 into two partial workflows is illustrated by dashed line 430. Partial workflow 400 may be performed on a first processor or computer, and partial workflow 410 may be performed on another processor or computer. Therefore, large tasks can be distributed over multiple processors or multiple processing threads. This use of partial workflows may also enable easier parallelization of the task or program.

Preferably, the output of each workflow item is written into a file, such as a log-file, together with an identifier which identifies the particular workflow item and task, for which it was generated. This file may ease recovery after power failure, since only those workflow items for which no log-file has been generated would require execution. For the other workflow items reference can be made to log-file and the outputs stored therein.

Preferably, the workflow scheme is generated by a graphical editing tool. This tool may provide the user the ability to arrange the individual workflow items and their interconnections by using a mouse, stylus, trackball, keyboard or other input device. In some embodiments, the user may place symbols, icons or other graphical representations of workflow items or connections in the workflow. The workflow items may be preprogrammed, user-programmed, or partially preprogrammed.

The typical preprogrammed workflow item would have predetermined inputs, outputs, and actions. Some preprogrammed workflow items may permit the user to edit or customize one or more of the inputs, outputs, and/or actions. The partially preprogrammed workflow items may have one or more of the input(s), output(s), and/or action(s), preprogrammed and leave at least one of the input(s), output(s), actions, and/or parameters to be programmed or specified by the user. The user programmable workflow items would permit the user to specify and/or program the input(s), output(s), and/or action(s).

After the workflow representation itself has been generated, a user may assign to the user programmed or partially preprogrammed workflow item(s), input(s), output(s), and/or action(s). For this purpose, there may be provided a pop- up window where program code can be inserted directly, or input and output parameters can be defined.

Figure 5 illustrates a workflow items cross reference list. While optional, this list may simplify complex workflow construction. Complex workflows may include: complex organization of workflow items and/or activities; and/or complex organization of variables. In Fig. 5, the individual workflow items are listed in a table. This table associates inputs and outputs for each workflow item. The inputs and outputs can refer to the names of variables, or they may refer to other workflow items. For example, input X2ι could refer to workflow item 1.

If a cross reference list is available, then tracing a partial workflow may be easier. This list could enable easier identification of the workflow item that provides the desired output. The inputs necessary for this workflow item which correspond to outputs from other workflow items may be also traced using this list. From those workflow items, the tracing can go further to determine which inputs are needed for those workflow items and to which other workflow items those inputs correspond. The structure of a workflow can be generated by a graphical user interface that enables a user to define individual workflow items, and to define the links and/or connections between workflow items. Consequently, the user defines from which workflow item a particular workflow item receives its input(s), and to which workflow item the particular workflow item delivers its output(s).

Alternatively, the cross references for each workflow item could refer to other workflow items to which the individual workflow items are linked such that they either need an input from the other workflow item or that they deliver an output to the other workflow item.

Fig. 6 provides an example of an embodiment using a cross reference list where each individual workflow item is associated with the workflow item(s), from which it receives its inputs and to which it delivers its outputs. This cross reference list may be generated by a graphical user interface in such a manner that boxes, symbols, icons or workflow representations can be linked to each other by lines or arrows. For example, an arrow originating from item 1 and targeting item 2 would mean that item 1 delivers its output to item 2. With such a workflow structure the workflow as a whole is fully defined, and yet the partial workflow that provides a user-specific output can be identified and performed.

Figure 7 provides an example of a first embodiment of a work flow system. The workflow system 100 in this example is integrated into a database search application. The search application illustrated is SRS (produced by Lion Bioscience AG). The workflow engine 130 is a part of the SRS data integration system 160. Workflows 170 can be either defined in XML (examples provided in Figures 9 and 10 A-D) or in Icarus (the standard data definition language of SRS)(example provided in Figure 8). XML workflows need to be registered (there is an API function for this purpose) before they are used. The SRS API allows workflows to be executed either synchronously or asynchronously by submitting them to a batch queuing system. While executing a workflow 170 the- engine 130 may refer to SRS 160 to perform queries of a database 180 or launch applications 190 or 192. The workflow engine 130 may also call Java applications 192 and the Java applications may use SRS API functions to perform SRS queries. When an SRS application generates data the results are indexed using the SRS executable "srsbuild". Figure 8 provides a first example for a biological workflow that provides sequence alignment data. This example was created as an Icarus script and was designed to be used in the workflow system 100 illustrated in Figure 7. The workflow illustrated in Figure 8 contains three activities, each generating a single output. The input to this workflow is a set that contains query sequences to be used by the homology-search activity. The default output of the workflow is

"alignment" data. The workflow continues to the default output if no other output is requested when the workflow is executed.

The first activity, a homology-search, is a single step activity. Using the parameters of the workflow, this activity executes the application BLASTP for the workflow input-set. BLASTP is a publicly available computer program. The result is a set of similarity hits. The step's inputs and parameters are linked to inputs and parameters used by BLASTP.

The second activity, a filtering activity, receives the output of the homology- search activity as its input. The filtering activity iterates over the list of similarity objects (input data) and screens them on the basis of the sequence match-length. This activity thus returns a filtered list of sequence objects (output data). The third activity, an alignment-activity, receives the filtered list of sequences, and returns an alignment object. This activity executes the application CLUSTALW and loads the result set from CLUSTALW into an object using the specified loader. CLUSTALW is also a publicly available biological computer application. Figure 9 provides a second example for a biological workflow that provides type sequence data. This example was created in XML and was also designed to be used in the workflow system 100 illustrated in Figure 7. The only activity named as "blastact" executes the biasdb application with this input sequence. It returns the results of the application using the 'loader' "biasdb". Figure 10 provides a third example for a biological workflow. This example was also created in XML and was also designed to be used in the workflow system 100 illustrated in Figure 7. Figure 10 illustrates an XML workflow that is more complex that the work flow shown in Figure 9.

Figure 11 illustrates an example of a second embodiment of a workflow system. The second embodiment is independent of the database search application and may be considered a stand-alone application. The illustrated work flow system 200 uses an XML editor 210 or a graphical workflow editor 220 to create and/or edit workflows and/or transitions between activities. Other editors may also be used. These editors enable a user to assemble a workflow from activities stored in a respository 230, library, or database and then save or store the workflow in the repository 230, library, or database. The graphical editor 220 may allow a biologist/bioinformatician with little computer knowledge to assemble and execute new data mining strategies using the repository 230. Once created the workflow may be considered and treated as an activity. Thus, the user may create complex and/or nested workflows that may be required for handling complex data analysis. The execution engine 240 or run-time engine processes (processes, executes, runs, or performs) the workflow. While processing the workflow the engine 240 parses the workflow and obtains the activities in the workflow from the repository 230. The engine 240, then processes the activities in the order provided by the workflow. In some embodiments, activities may be processed in parallel if the activities are independent. However, if a second activity requires data from a first activity then these activities would not be processed in parallel.

The execution engine 240 performs each activity and provides a transition between activities at workflow run-time. In some embodiments the transition may be contained in the activity. While performing an activity, the engine 240 may call applications 290 directly or indirectly through a database search application 260. The database search application illustrated is SRS (produced by Lion Bioscience AG). The engine 240 may also initiate database queries using the database search application 260. Preferably, the database search application 260 serves as a portal to a plurality of databases. The execution engine 240 handles the data, transition, and logic house keeping for the workflow. Thus, the engine 240 will save or store the data output from one activity for use by a second activity. In some embodiments, the engine 240 may convert data from one format to a second format as part of the transition process. When activities use compatible data types, this conversion process would not be needed. Other transitions between activities, however, may be required or desired. In some embodiments the transitions serve as links between activities. The engine 240 also provides direction, execution, flow, and/or permits branching in the workflow logic.

One embodiment of the workflow editor 220 may permit the user to build a workflow from activities with compatible inputs and outputs. Compatible activities could be highlighted or incompatible activities could be inactivated or inaccessible in editor 220

A second embodiment of workflow editor 220 could permit the any activity combination. The execution engine 240 could then provide a transition between the activities. Alternatively, a transition engine could be added that would handle transitions between activities.

The typical activity forms a wrapper for an executable encapsulated process or pre-existing and/or pre-programmed software tool. Examples of these processes or tools used in biology include, but are not limited too, BlastN (compares nucleotide sequences), BlastP (compares protein sequences), Clustal W (provides multiple sequence alignment), What If (predicts three dimensional structure from one or more sequences), Signal P (predicts protein secretion), and Genscan (predicts genomic structure). These processes and tools are often written for use in mainframe or super computer environments where speed and efficiency are desired due to the large data processing requirements. The wrapper provides an interface between the user, program, and/or workflow and the process or tool. The wrappers may be written in any programming or scripting language.

Many of the processes and tools are public domain. Some are written in simple languages and others are written using a biologist's nomenclature. Some of the processes and tools, however, are not written to software engineering standards. Thus, its not easy to take these processes and tools and put them together on a higher level. By configuring the workflow on the higher level, the method for obtaining results can be simplified.

Figure 12 illustrates an example of one workflow definition process that may be used in workflow system 200. This process uses an activity class that that has an interface specification 235. The use of a specification 235 reduces the transition overhead at run-time. The order and transitions, if any, between activities are provided in the workflow description 237. The activities referenced in the description 237 are typically found in a repository 230. In Figure 12, the workflow description is provided in XML. In other embodiments the description may be provided in Java or other programming or scripting language. The description 237 is provided to the execution engine 240 for processing as discussed above. Thereafter, the results of the workflow are displayed, printed, or otherwise output at results 250.

The exemplary activity class shown in Figure 12 has two fields that define the input and output parameters. Additional fields may be used to include additional input and/or output parameters. A method specifies the executable encapsulated process or pre-existing and/or pre-programmed software tool, program or application that the activity calls.

Figure 13 illustrates a flow chart for a workflow. This workflow obtains a predicted three dimensional structure for a protein as the default result. The results of the first and second activities may obtained if requested by the user. The first activity calls Blast-P to compare the input sequence to the sequences in the database identified. The multiple sequences output are provided as an input to the second activity.

The second activity performs a multiple sequence alignment of the sequences input using Clustal W. The output of this activity is the multiple sequence alignment that is input into the third activity.

The third activity uses the multiple sequence alignment to generate a predicted three dimensional protein structure using What If. The predicted structure is then output as the result.

Figure 14 provides a workflow example that may be created using the workflow system shown in Figure 11. This workflow illustrates a branch between activities. In this example the first activity generates a random integer. A branching activity compares the random number to zero. Depending on which branch is taken "less than 0" is printed when the random number was less than zero or "more that 0" is printed when the random number was greater that zero. This example was created in the Java programming language. In this example, the activities comply with an interface specification. In some embodiments, the use of an interface specification is optional. However, the use of an interface specification can insure compatibility between activities in the workflow. In this example, Java objects are used to pass data between activities.

Figures 15A, 15B, and 15C provide a biological workflow example that may be created using the workflow system shown in Figure 11. This example was also created in the Java programming language. A process flowchart for this example is provided on Figure 15A.

The illustrated workflow is intended to detect duplicate sequences in a sequence database. The main workflow retrieves all the sequences from the database; runs the sub-workflow on each sequence; and then outputs the result. The sub-workflow compares a selected sequence to the sequences in the database and outputs the score of the most similar sequence except itself.

The first activity passes the sequence to multiple activities. This activity eliminates the need to reenter the sequence when needed for other activities.

The second activity takes the sequence and uses BlastN to compare the sequence to the sequences in the database. This activity outputs a list of scoring profiles.

The third activity extracts the highest scoring profiles from the list of scoring profiles. This activity outputs a list of high scoring profiles.

The forth activity removes the sequence from the list of high scoring profiles. The output of this activity is also a list of high scoring profiles (without the sequence being compared).

The fifth activity keeps only the sequence with the top score. Thus, the output of this activity is the database sequence that is the nearest match to the sequence being compared. The sixth activity is a branch activity that compares the score of the sequence with the top score to an minimum result. In this example, the score is must be more that 95 percent.

The seventh activity causes no sequence ID to be output if the top scoring profile was less than or equal to 95 percent. The eighth activity causes the sequence ID to be output when the top scoring profile was greater than 95 percent. In summary, numerous benefits have been described that result from employing the concepts of the invention. The description of the the invention has been prepared for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications and variations are possible in light of the above teaching. The embodiment was chosen and described in order to best illustrate the principals of its invention in its practical application to enable one of ordinary skill to utilize the various embodiments with various modifications as they are suited to the particular use contemplated. It is intended that the scope of invention be defined by the claims appended hereto.

Claims

CLAIMS We claim:

1. A method for executing a task to be carried out by one or more computer systems through a workflow scheme representing said task, wherein said task is represented by a set of workflow items, each workflow item representing an action, each workflow item receiving one or more inputs and delivering one or more outputs, thereby forming a workflow representation of said task, said method comprising: identifying a workflow item delivering as an output the desired result of said task; tracing the workflow representation to identify all other workflow items which directly or indirectly deliver an output necessary to have a complete input for said selected workflow item; and carrying out the actions corresponding to all identified workflow items to thereby carry out the task.

2. The method according to claim 1 , wherein said workflow representation is used to parallelize tasks, thereby enabling the workflow being partly executed on different computer systems or by different routines.

3. The method according to one of claims 1 or 2, further comprising: providing a graphical editing tool for generating the workflow representation of said task.

4. The method according to one of claims 1 to 3, further comprising: writing the result of each workflow item into a file, together with an annotation identifying the task to which it belongs.

5. The method according to one of claims 1 to 4, further comprising: in case of a re-run of said task being necessary, re-executing only those workflow items which have not yet been executed, and for those workflow items which already have been executed referring to the corresponding files into which the results have been written.

6. An apparatus comprising means for carrying out a method according to one of claims 1 to 5.

7. A computer program comprising computer-executable instructions for carrying out a method according to one of claims 1 to 5.

8. A method for executing a task to be carried out by one or more computer systems through a workflow scheme representing said task, the method comprising: representing said task by at least one activity, each activity representing an action, each activity receiving one or more inputs and delivering one or more outputs; performing each of the at least one activity; and outputting the result.

9. The method of claim 8, wherein the action is an executable encapsulated process.