Enhydra Shark Evaluation Results
All tests for Enhydra Shark are done with Graph Conformance setting "Not blocked". This setting corresponds probably to the Conformance Class Declaration (p22) in XPDL according to which the following apply:
"FULL-BLOCKED - The network structure is restricted to proper nesting of SPLIT/JOIN and loops.
LOOP-BLOCKED - The network structure is restricted to proper nesting of loops.
NON-BLOCKED - There is no restriction on the network structure. This is the default."
Evaluation results for Enhydra Shark version 2 against the workflow control-flow patterns
Pattern |
Rating |
Motivation |
| Sequence | + | Enhydra Shark implements sequences through transitions between activities. (Shark, Wil) |
| Parallel Split | + | Enhydra Shark supports parallel split through |
| Synchronization | + | Enhydra Shark supports synchronization through |
| Exclusive Choice | + | Enhydra Shark supports exclusive choice through |
| + | Enhydra Shark supports simple merge through an activity node to which a transition restriction <Join Type = "XOR"> is defined. (Shark, Wil). | |
| Multi-Choice | + | Enhydra Shark supports this pattern through a parallel split on an activity/a routing activity (i.e. transition restriction <Split Type = "AND">) with conditions specified on the leaving transitions where several of the conditions may evaluate to true simultaneously [Wil]. XPDL also offers an OR split, however such a construct is not implemented in Enhydra Shark. |
| Structured Synchronizing Merge | - | Enhydra Shark does not directly support this pattern. Shark provides a workaround solution in which the behaviour is achieved by introducing an XOR split for each outgoing branch of the corresponding OR-split where a choice is made between executing this branch or not. Each XOR-split has a corresponding XOR-join and all these XOR-joins are linked to an AND-join which achieves the required synchronization (See Figure 1) |
| Multi-Merge | - | Enhydra Shark does not support multiple merge. If an activity (sub-flow, in Shark solution) is used to synchronize two transitions, it is enabled once or twice depending on the completion order of the activities to be merged and the merging activity (sub-flow). See Figure 2. |
| Structured Discriminator | - | Enhydra Shark does not directly support this pattern. A work around implementing the behaviour of the pattern is proposed in (Shark), see Figure 3. |
| Arbitrary Cycles | + | Enhydra Shark supports arbitrary cycles. A loop can have multiple entrance and exit points. |
| Implicit Termination | + | Enhydra Shark supports Implicit Termination supports Implicit Termination. Enhydra Shark does not explicitly notify the user of process completion. The process instance is logged with the status closed.completed. |
| Multiple Instances without Synchronization | + | Enhydra Shark supports this pattern through a loop launching new instances of the multiple instances task as sub-flows (i.e. subprocesses). Setting the Subflow Execution attribute to "Asychronous" ensures that the sub-flows can run in parallel and any synchronization of them wil not take place. |
| Multiple Instances with a Priori Design-Time Knowledge | - | Enhydra Shark does not support this pattern. Multiple instances of a task can be spawned through a loop which invokes a sub-flow in every iteration of it. However these sub-flows can not be synchronized, as the sub-flow execution setting has to be set to "asynchronous", so that the start up of the instances shall not be blocked. A work around is to replicate the numberr of instances to be created in parallel flows. |
| Multiple Instances with a Priori Run-Time Knowledge | - | Enhydra Shark does not support this pattern. Multiple instances of a task can be spawned through a loop which invokes a sub-flow in every iteration of it. However these sub-flows can not be synchronized, as the sub-flow execution setting has to be set to "asynchronous", so that the start up of the instances shall not be blocked. |
| Multiple Instances without a Priori Run-Time Knowledge | - | Enhydra Shark does not support this pattern. |
| Deferred Choice | - | Enhydra Shark does not support this pattern. There only are two split types: XOR and AND. The default choice is XOR. |
| Interleaved Parallel Routing | - | Enhydra does not support this pattern. The Ad Hoc construct present in XPDL is not implemented in Enhydra Shark. |
| Milestone | - | Enhydra Shark does not support this pattern. The notion of state is not present in the tool . |
| Cancel Activity | - | Enhydra Shark does not support this pattern. At design time it is not possible to indicate cancellation of activities. (At run time, the options under Activity Management console, among them "terminate activity", are not enabled in the evaluated version of Shark.) |
| Cancel Case | + | Enhydra Shark does not support cancel case during design time. However, it supports cancel case during run-time. A case can be cancelled through the administration console by selecting "Terminate" for a specific instance. The case's status is logged as closed.terminated. |
| Structured Loop | - | Enhydra Shark can achieve the behavior of structured loops, but any dedicated construct for this is missing. |
| Recursion | + | Enhydra Shark supports recursion. A workflow can invoke itself by means of subflow. |
| Transient Trigger | - | Enhydra Shark supports transient triggers through Deadline on activities. Deadlines can be put on routing activities, which will then act as waiting states for a process expiring at the defined time point. However, we did not manage to get the deadline functionality working. (The example provided by Enhydra on Deadline expiration did not work in our tests.) Another typical example of transient triggers is activities denoting email reception. Enhydra Shark provides a set of Tool Agents. A Tool Agent defines the interface to a data source or an application in the operational environment. A MailToolAgents is dedicated for implementing the connectivity needed for sending and receiving mails. However, in the evaluated version of the tool, the MailToolAgent did not work. |
| - | Enhydra Shark does not support Persistent Triggers. In order to receive a trigger (such as a deadline expiration or a mail reception), a flow needs to be executing a specific task that can handle that trigger. This behaviour corresponds to the notion of transient trigger. | |
| Cancel Region | - | Enhydra Shark does not support this pattern. At design time it is not possible to define cancellation of regions, nor of block activities or sub-flows. (At run time, in the evaluated version of Shark, the options under Activity Management console, among them "terminate activity" which could be used for termination of block activities as of sub-flows as special cases of regions, are not enabled.) |
| Cancel Multiple Instance Activity | - | Enhydra Shark does not support this pattern. |
| Complete Multiple Instance Activity | - | Enhydra Shark does not support this pattern. (The options under Activity Management console, among them "complete activity", are not enabled in the evaluated version of Shark.) |
| Blocking Discriminator | - | Enhydra Shark does not directly support this pattern. |
| Cancelling Discriminator | - | Enhydra Shark does not directly support this pattern. |
| Structured Partial Join | - | Enhydra Shark does not directly support this pattern. A work around based on the solution proposed in (Shark) for Structured Discriminator can be constructed. XPDL defines a Complex Join construct, which is however not implemented in Enhydra Shark. |
| Blocking Partial Join | - | Enhydra Shark does not directly support this pattern. |
| Cancelling Partial Join | - | Enhydra Shark does not directly support this pattern. |
| Generalised AND-Join | - | Enhydra Shark does not directly support this pattern. A workflow can not be in a non-safe state. |
| Static Partial Join for Multiple Instances | - | Enhydra Shark does not support this pattern. |
| Cancelling Partial Join for Multiple Instances | - | Enhydra Shark does not support this pattern. |
| Dynamic Partial Join for Multiple Instances | - | Enhydra Shark does not support this pattern. |
| Local Synchronizing Merge | - | Enhydra Shark does not directly support this pattern. (Structured Synchronizing merge, which is a simpler form of this pattern, is not supported.) |
| General Synchronizing Merge | - | Enhydra Shark does not directly support this pattern. (Structured Synchronizing Merge and Local Synchronizing Merge, which are two simpler forms of this pattern, are not supported.) |
| Critical Section | - | Enhydra Shark does not support this pattern, as there is no mechanism for limiting concurrent execution of a set of activities. |
| Interleaved Routing | - | Enhydra Shark does not support this pattern. (The Ad Hoc construct is present in XPDL 2.0 and hence not implemented in Enhydra Shark which supports XPDL 1.0). |
| Thread Merge | - | Enhydra Shark does not support this pattern. |
| Thread Split | - | Enhydra Shark does not support this pattern. The attribute Quantity present in XPDL for a transition is not implemented in Enhydra Shark. |
| Explicit Termination | - | Enhydra Shark does not support this pattern. |
Evaluation results for Enhydra Shark version 2 against the workflow data patterns
Pattern |
Rating |
Motivation |
| Task Data | +/- | Enhydra Shark does not support task data. (Only workflows can have data elements.) It is, however, possible to define Java Script procedures as tasks. In such procedures local data (e.g., loop counters) can be defined. Hence, due to the programmatic extension needed, task data is considered as partially supported. |
| Block Data | + | Enhydra Shark does support block data through sub-flow variables, which are local for a sub-flow. (They are not visible to the calling process.) It is also possible to define block activities. However, variables in block processes are global for the entire workflow. |
| Scope Data | - | Enhydra Shark does not support scope data. |
| Multiple Instance Data | + | Enhydra Shark supports shared implementation of tasks (through subflows). |
| Case Data | + | Enhydra Shark supports case data through workflow level variables and package level variables. |
| Folder Data | - | Enhydra Shark does not support folder data (as global data is not supported). Variable values are not visible outside a case. |
| Workflow Data | - | Enhydra Shark does not support global data. Workflow variables are indeed available on a pack level (a package contains one or several workflows). However, these variables contain Case Data, i.e. their data values are not shared between several cases. Hence the purpose of Workflow variables is mainly to reduce the amount of variable definitions within a package. |
| Environment Data | +/- | Enhydra Shark supports environment data through the use of Tool Agents. A Tool Agent provides an interface to a data source or an application in the operational environment. One tool agent, e.g. JavaScriptToolAgent (providing connectivity to the local Java script interpreter), is available with the default installation; hence this pattern is considered to be supported. |
| Task to Task | + | Enhydra Shark supports this pattern through case variables. |
| Block Task to SubWorkflow Decomposition | + | Enhydra Shark supports data interaction to sub-process decomposition. There are two ways to define a sub-process: through the introduction of a block activity or through the introduction of a sub-flow. A block activity is embedded within the main workflow definition and shares the same global data as its embedding workflow. A subflow is an independent process, which can be invoked by any workflow in the same package. Data is passed to it through parameters. |
| SubWorkflow Decomposition to Block Task | + | Enhydra Shark supports data interaction from sub-process decomposition. There are two ways to define a sub-process: through the introduction of a block activity or through the introduction of a sub-flow. A block activity is embedded within the main workflow definition and shares the same global data as it embedding workflow. A subflow is an independent process, which can be invoked by any workflow in the same package. Data is passed to it through parameters. |
| To Multiple Instance Task | - | Enhydra Shark does not support this pattern as it lacks (multiple instances) task data. |
| From Multiple Instance Task | - | Enhydra Shark does not support this pattern as it lacks (multiple instances) task data. |
| Case to Case | +/- | Enhydra Shark does not support case to case data interaction directly. Such interaction can be realized through use of an external database; However, it is not possible to target the data to a specific instance, as instances are not aware of the existence of concurrent instances. Hence only the more general form of interaction from a case to all other cases is supported. |
| Task to Environment - Push-Oriented | +/- | Enhydra Shark supports partially data passing to the Environment - push oriented. The support is partial because the predefined Tool Agents can not be mapped (due to functionality limitations in the tested version) to the applications that implement the desired functionality. (A Tool Agent supplies an Enhydra Shark's interface towards different software. E.g. MailToolAgents, SOAPToolAgent, and RuntimeApplicationToolAgent, implement the connectivity needed for sending and receiving mails, invoking web-services, and starting locally available applications.) It is theoretically possible to implement the corresponding behavior in JavaScript through JavaScriptToolAgent. In contrast to the other ToolAgents the JavaScriptToolAgent is available with the default installation in the tool and it is automatically mapped to the local JavaScript interpreter (hence no additional mapping is required). |
| Environment to Task - Pull-Oriented | +/- | Enhydra Shark supports this pattern partially. See the comment for pattern 15. |
| Environment to Task - Push-Oriented | - | Enhydra Shark does not support this pattern. It is indeed possible to implement a ToolAgent that acts as an event listener. However, the actual behaviour of an event listener corresponds to the pattern Environment to Task-Pull, as the listener watches for updates. |
| Task to Environment - Pull-Oriented | - | Enhydra Shark does not support this pattern. |
| Case to Environment - Push-Oriented | - | Enhydra Shark can be configured to export all its persistence data to an external database, such as Oracle, DB2, mySQL. This is done through Tool Agents. However, in the evaluated version of the tool, the predefined Tool Agents implementing this connectivity are not available. Therefore, any support for this pattern is considered to be missing. |
| Environment to Case - Pull-Oriented | - | Enhydra Shark can be configured to use an external database such as Oracle, DB2, mySQL for its persistence. Through a Tool Agents, a case can pull data from the defined storage. However, in the evaluated version of the tool, the predefined Tool Agents implementing this connectivity are not available. Therefore, any support for this pattern is considered to be missing. |
| Environment to Case - Push-Oriented | - | Enhydra Shark does not support this pattern. |
| Case to Environment - Pull-Oriented | - | Enhydra Shark does not support this pattern. |
| - | Enhydra Shark does not support this pattern. | |
| Environment to Workflow - Pull-Oriented | - | Enhydra Shark does not support this pattern. |
| Environment to Workflow - Push-Oriented | - | Enhydra Shark does not support this pattern. |
| Workflow to Environment - Pull-Oriented | - | Enhydra Shark does not support this pattern. |
| Data Transfer by Value - Incoming | +/- | In Enhydra Shark, data is passed to sub-flows through parameters. Parameters are not used for passing data between any other kinds of activities (as data is global for a workflow) hence the support for this pattern is ranked as partial. |
| Data Transfer by Value - Outgoing | + | In Enhydra Shark, data is passed from sub-flows back to its calling process through parameters. Parameters are not used for passing data between any other kinds of activities (as data is global for a workflow) hence the support for this pattern is ranked as partial. |
| Data Transfer - Copy In/Copy Out | + | Enhydra Shark uses the "copy-in" technique when invoking sub-processes. The values of variables are copied to sub-process variables through 1) specified parameters; or 2) local copies of the global variables. When the invocation is synchronous, after completion, the sub-process copies its variable values back to the calling process, which is done through parameters (the local variable copies are not exported back to the global process variables). If the invocation is asynchronous, the variable values are not copied back to the calling process (even if the data transfer is specified through parameters). In this way concurrent data update problems are avoided. Enhydra Shark also uses the "copy-in" technique when transferring data between activities and between activites and block activities. When completed an activity copies back its value to the global variable. When two activities that have copies of the same variables run concurrently and update the variable values, the updates are not visible for the concurrently running activity (as the variable copies are received at enablement). |
| Data Transfer by Reference - Unlocked | - | Enhydra Shark does not support this pattern. |
| Data Transfer by Reference - With Lock | - | Enhydra Shark does not support this pattern. |
| Data Transformation - Input | + | Enhydra Shark supports this pattern. Transformation are written in JavaScript. A JavaScriptToolAgent which is mapped to the local JavaScript interpreter is then used. |
| Data Transformation - Output | + | Enhydra Shark supports this pattern. Transformation are written in JavaScript. A JavaScriptToolAgent which is mapped to the local JavaScript interpreter is then used. |
| Task Precondition - Data Existence | - | Enhydra Shark does not support this pattern. There is not any way to specify task preconditions. Only Transition Restrictions of type AND or XOR Join can be specified. |
| Task Precondition - Data Value | - | Enhydra Shark does not support task preconditions. As tsk preconditions can be specified for tasks with multiple incoming arcs, transition conditions on the incoming transitions alone would not be enough for capturing the full semantics of the precondition. |
| Task Postcondition - Data Existence | - | Enhydra Shark does not support task post-condition on data existence. Test for null values behaves as follows: |
| Task Postconditon - Data Value | +/- | Enhydra Shark does not fully support this pattern. It only validates the type of the output data items. |
| Event-Based Task Trigger | - | Enhydra Shark does not support event-based task triggers. The receipt of a mail is an example of such trigger. Due to the fact that the MailToolAgent is not available in the evaluated version of the tool (nor are any other but the JavaScriptToolAgent available), any support for this pattern is considered to be missing. |
| Data-Based Task Trigger | - | Enhydra Shark does not support data-based task triggers. Deadline triggers are the classical example for this pattern. Even if deadlines could be specified for activities, any deadline expiration did not occur during execution. |
| Data-Based Routing | + | Enhydra Shark supports this pattern. Both exclusive and multi choice are supported. |
Evaluation results for Enhydra Shark version 2 against the workflow resource patterns
Pattern |
Rating |
Motivation |
| Direct Allocation | + | Enhydra Shark supports direct allocation. A Participant in the workflow model can be mapped directly to a specific User defined in the process manager. |
| Role-Based Allocation | + | Enhydra Shark supports direct allocation. A Participant in the workflow model can be mapped to a Group User containing a number of users. |
| Deferred Allocation | + | Enhydra Shark does not support deferred allocation. It is implemented using variables. A Performer variable can be specified for an activity and its value set during runtime. |
| Authorisation | - | Enhydra Shark does not support this pattern. |
| - | Enhydra Shark does not support this pattern. | |
| Case Handling | - | Enhydra Shark does not support this pattern. |
| Retain Familiar | - | Enhydra Shark does not support this pattern. Theatrically, the extended attribute "AssignToPerformerOfActivity" (together with some engine configuration) should give the possibility to specify that the performer of an activity shall be assigned a subsequent activity. In practice, we did not achieve the desired behaviour. |
| Capability Based Allocation | - | Enhydra Shark does not support this pattern. Enhydra has the capability to import organizational structure information from an LDAP server. However, it is not clear how these facilities can be used for capability-based allocation. |
| History Based Allocation | - | Enhydra Shark does not support this pattern. |
| Organisational Allocation | - | Enhydra Shark does not support this pattern, as any organizational model can not be captured (or referred to) in the tool. |
| Automatic Execution | + | Enhydra Shark supports automatic execution through Tool Activities. |
| Distribution by Offer - Single Resource | + | Enhydra Shark supports distribution to a single resource by supporting mapping of a Participant in the workflow model to an individual User to whom the work items are offered. |
| Distribution by Offer - Multiple Resources | + | Enhydra Shark supports distribution to a single resource by supporting mapping of a Participant in the workflow model to a Group User to whose participants the work items are offered. |
| Distribution by Allocation - Single Resource | - | Enhydra Shark does not support this pattern. It only supports offering and not allocation of work items. |
| Random Allocation | - | Enhydra Shark does not support this pattern. It only supports offerings and not allocation of work items. |
| Round Robin Allocation | - | Enhydra Shark does not support this pattern. It only supports offering and not allocation of work items. |
| Shortest Queue | - | Enhydra Shark does not support this pattern. It only supports offering and not allocation of work items. |
| Early Distribution | - | Enhydra Shark does not support early distribution. |
| Distribution on Enablement | + | In Enhydra Shark when a work item is created, it is immediately distributed to someone. |
| Late Distribution | - | Enhydra Shark does not support this pattern. |
| Resource-Initiated Allocation | - | Enhydra Shark does not support this pattern. In order to be initiated a work item first needs to be allocated, a state which does not exist in Enhydra Shark. |
| Resource-Initated Execution - Allocated Work Item | - | Enhydra Shark does not support this pattern. In order to be initiated a work item first needs to be allocated, a state which does not exist in Enhydra Shark. |
| Resource-Initiated Execution - Offered Work Item | + | Enhydra Shark supports this by resources ticking the work items they intend to perform. Selected work items become becomes automatically started, their start time is set and they become invisible for the remainder of the resources in a group (if any). |
| - | Enhydra Shark does not support this pattern. | |
| Resource-Determined Work Queue Content | - | Enhydra Shark does not support this pattern. |
| Selection Autonomy | + | Enhydra Shark supports this pattern. |
| Delegation | - | Enhydra Shark does not support this pattern. |
| Escalation | - | Enhydra Shark does not support this pattern. The notion of deadline is present for limiting the duration of an activity, but the deadline never expires. (The provided example did not work as expected and we did not succeed in activating the deadline functionality.) |
| Deallocation | + | Enhydra Shark supports this pattern directly. If a work item has been assigned to a set of users of a group, one of the users in the list can "accept" the task. At anytime before the task expires or it has been completed, the user can "release" the task to the set of users/group the task was originally assigned to. Any changes in data will be lost. This is because, on commencement, a work item only receives a copy of the data values necessary for it and any data is not copied back until the work item is completed. |
| Stateful Reallocation | - | Enhydra Shark does not support this pattern. The Reassign button in the Work list Console is currently not enabled. |
| Stateless Reallocation | - | Enhydra Shark does not support this pattern. The Reassign button in the Work list Console is currently not enabled. |
| Suspension/Resumption | - | Enhydra Shark does not support Suspension/Resumption of a work item. In the evaluated version of the tool a "Suspension" and a "Resumption" button for a work item are displayed but not enabled for use. In Enhydra Shark a whole case can be suspended and resumed. In such a situation all work items available for the case are suspended (and resumed). They still appear in the work list(s), but they are not possible to allocate/start (when trying to do that a wrong error message is displayed, i.e. "the work item is allocated to another resource"). |
| Skip | - | Enhydra Shark does not support this pattern. |
| Redo | - | Enhydra Shark does not support this pattern. |
| Pre-Do | - | Enhydra Shark does not support this pattern. |
| Commencement on Creation | - | Enhydra Shark does not support this pattern. "Automatic" can be selected as a Start Mode for an activity (the default start mode is "Manual"). However, in runtime the work items of an Automatic activity do not get automatically started. (They need, similarly to the instances for Manual activities, to be manually started by selecting them from the corresponding work list.) |
| Commencement on Allocation | - | Enhydra Shark does not support this pattern. When a work item is accepted (i.e. allocated, which is done through ticking it in a work list), it is automatically started which is shown by setting its start time. However, the selection (and hence the start) is done by a resource and not by the system. |
| Piled Execution | - | Enhydra Shark does not support this pattern. |
| Chained Execution | - | Enhydra Shark does not support this pattern. |
| Configurable Unallocated Work Item Visibility | - | Enhydra Shark does not support this pattern. |
| Configurable Allocated Work Item Visibility | - | Enhydra Shark does not support this pattern. |
| Simultaneous Execution | - | Enhydra Shark does not support this pattern. |
| Additional Resources | - | Enhydra Shark does not support this pattern. |
Figure 1 Synchronizing Merge (Enhydra's solution)
Figure 2 Multiple merge. Non-deterministic behaviour.
The following execution scenarios were tested. (Note that depending of the execution order S1 is enabled once or twice).
A,B,C,D,S1
A,B,S1,C,D,S1
Figure 3 Structured Discriminator (solution proposed by Enhydra)
It is for the moment not possible to define a user in Enhydra who does not belong to the admin group and who has the authority to login in the process engine (the engine crashes if you try to do that).