Oracle BPEL Evaluation Results

Evaluation results for Oracle BPEL version 10.1.2 against the workflow control-flow patterns

Pattern

Rating

Motivation
Sequence + Supported by the <sequence> construct or links within the <flow> construct.
Parallel Split + Supported by the <flow> construct.
Synchronization + Supported by the <flow> construct.
Exclusive Choice + Supported by the <switch> construct or links within a <flow> construct.

Simple Merge

+ Supported by the <switch> construct or links within a <flow> construct.
Multi-Choice + Supported by links within a <flow> construct.
Structured Synchronizing Merge + Supported by links within a <flow> construct.
Multi-Merge - Not supported. The language is block structured and it is not possible for two threads of execution to run through the same path in a single process instance.
Structured Discriminator - Not supported. There is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first positive link.
Arbitrary Cycles - Not supported. The language is block structured and cannot capture unstructured cycles.
Implicit Termination + Directly supported for the <flow> construct. For other constructs, each branch must be ended with a <terminate> construct.
Multiple Instances without Synchronization + Supported by the <invoke> construct within a <while> loop.
Multiple Instances with a Priori Design-Time Knowledge + Supported through the use of the <flowN> construct which allows multiple concurrent instances of an activity to be created.
Multiple Instances with a Priori Run-Time Knowledge + Supported through the use of the <flowN> construct which allows multiple concurrent instances of an activity to be created.
Multiple Instances without a Priori Run-Time Knowledge - Not supported. No direct means of initiating additional instances of a multiple activity (e.g. as created by the <flowN> construct) is available.
Deferred Choice + Supported by the <pick> construct.
Interleaved Parallel Routing - Supported by BPEL spec but not implementable in Oracle BPEL.
Milestone - Indirectly achievable by using a <pick> activity within a <while> loop which can only be executed once but solution is overly complex.
Cancel Activity + Supported by associating a fault or compensation handler with an activity.
Cancel Case + Supported by the <terminate> activity.
Structured Loop + While loops are directly supported.
Recursion - Not supported. Recursive composition is possible on an external basis using the <invoke> construct against web services but there is no internal support.
Transient Trigger - Not supported. Messages are durable in form.

Persistent Trigger

 + Supported by the <pick> activity waiting on specific message type.
Cancel Region +/- No means of cancelling arbitrary groups of activities although activities within the same scope can be cancelled.
Cancel Multiple Instance Activity + Supported for multiple activity instances in a <flowN> construct by associating it with a fault or compensation handler.
Complete Multiple Instance Activity - No support for multiple activity instances.
Blocking Discriminator -

Not supported. There is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first positive link.

Cancelling Discriminator - Not supported. As for WCP28.
Structured N-out-of-M Join - Not supported. Similar to the discriminator, there is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first N positive links.
Blocking N-out-of-M Join - Not supported. As for WCP30.
Cancelling N-out-of-M Join - Not supported. As for WCP30.
Generalised AND-Join - Not supported. There is no notion of multiple execution threads through a single path in a process instance.
Static Partial Join for Multiple Instances - No means of.
Cancelling Partial Join for Multiple Instances - No support for multiple activity instances.
Dynamic Partial Join for Multiple Instances - No support for multiple activity instances.
Acyclic Synchronizing Merge + Supported by links within a <flow> construct.
General Synchronizing Merge - Not supported. Process models are always block structured and OR-joins always operate within a <flow> activity.
Critical Section + Supported by serializable scopes.
Interleaved Routing - Supported by the BPEL spec but not implementable in Oracle BPEL.
Thread Merge +/- The correlation facility for invoked activities provides the basis for coalescing distinct threads of control but programmatic extensions are necessary to keep track of when the merge should occur.
Thread Split +/- Achievable through the use of the <invoke> construct in conjunction with the correlation facility but programmatic extensions are necessary if subsequent thread merges are required.
Explicit Termination - Process instances complete when no activity instances remain to complete.

Evaluation results for Oracle BPEL version 10.1.2 against the workflow data patterns

Pattern

Rating

Motivation
Task Data +/- A task must be wrapped into a scope.
Block Data - Not supported.
Scope Data + Directly supported by <scope>
Multiple Instance Data +/- Partial support dependents on the type of the MI task.
Case Data + Bound to outermost scope in the process definition.
Folder Data - Not supported
Workflow Data + Supported via deployment descriptor properties.
Environment Data + Synchronous message interaction <invoke>, <receive>
Task to Task + No data passing; data elements shared between tasks via access to globally shared data
Block Task to SubWorkflow Decomposition - Not supported.
SubWorkflow Decomposition to Block Task - Not supported
To Multiple Instance Task +/- Not supported by all variants of MI tasks.
From Multiple Instance Task +/- For non-direct supported MI task, a certain number of instances should be complete before the data is passed to the next task.
Case to Case - Not supported
Task to Environment - Push-Oriented + Directly supported by means inputVariable of <invoke>
Environment to Task - Pull-Oriented + Direct support via <invoke> and <receive>
Environment to Task - Push-Oriented + Directly support via <receive> and event handlers
Task to Environment - Pull-Oriented + Directly supported through <receive> and <reply>
Case to Environment - Push-Oriented - Not supported
Environment to Case - Pull-Oriented - Not supported
Environment to Case - Push-Oriented - Not supported
Case to Environment - Pull-Oriented - Not supported

Workflow to Environment - Push-Oriented

 - Not supported
Environment to Workflow - Pull-Oriented - Not supported
Environment to Workflow - Push-Oriented - Not supported
Workflow to Environment - Pull-Oriented - Not supported
Data Transfer by Value - Incoming + Directly supported by the attributes of <assign> wizard
Data Transfer by Value - Outgoing + Directly supported by the attributes of <assign> wizard
Data Transfer - Copy In/Copy Out + Directly supported by means of two <assign> constructs.
Data Transfer by Reference - Unlocked + No concurrency restrictions for accessing global data
Data Transfer by Reference - With Lock - The serializable scope feature does not work according to its semantics.
Data Transformation - Input - Directly supported by the attributes of <assign> wizard.
Data Transformation - Output - Directly supported by the attributes of <assign> wizard.
Task Precondition - Data Existence - Not supported.
Task Precondition - Data Value + Directly supported via joinCondition evaluation the status of links.
Task Postcondition - Data Existence - Not supported
Task Postconditon - Data Value - Not supported
Event-Based Task Trigger + Directly supported via <receive> and event handlers.
Data-Based Task Trigger - Not supported
Data-Based Routing + Directly supported via links and <switch>

Evaluation results for Oracle BPEL version 10.1.2 against the workflow resource patterns

Pattern

Rating

Motivation
Direct Allocation + Oracle BPEL PM supports this pattern directly. The resources can be specified statically or dynamically. The organization structure, together with resources, their identities, and other characteristics can be specified via JAZN admintool. When adding a task to the process model, the workflow wizard allows specifying a single user, a set of the users, or a group. Each of the task parameters specified by means fo the wizard can be modified later in the designer view or in the corresponding BPEL code.
Role-Based Allocation + Oracle BPEL PM supports this pattern directly. The organizational structure, including the roles assigned to the users, can be specified in the jazn-data.xml and user-properties.xml, the content of which is visible for the designer creating a process model. Specifying one of the existing roles as a task assignee would make a work item visible in the worklists of users with the corresponding role. Note that Oracle BPEL PM makes not distinction between groups and roles.
Deferred Allocation + Oracle BPEL PM supports this pattern directly. It allows specifying a task assignee by means of an XPath expression which is evaluated at run time.
Authorisation - This pattern is not supported by Oracle BPEL. It is possible to assign a work item to a specified role, and this work item can be reassigned to any other user/role. However, it is not possible to (re-)assign a task based on the condition, i.e. to a user having a certain authority.

Seperation of Duties

 - Oracle BPEL does not allow specifying the separation of duties in terms of relationships between tasks, nor it allows the separation of duties based on security mechanisms. Thus this pattern is not supported by Oracle BPEL PM.
Case Handling + Oracle BPEL PM supports this pattern directly. The feature of dynamic assignment using an XPath expression allows specifying that a next task must be assigned to the resource who executed the previous (first) task. In particular, the function ora:getPreviousTaskApprover() can be used for this purpose.
Retain Familiar + Oracle BPEL PM supports this pattern by means of the ora:getPreviousTaskApprover() function during the dynamic assignment an assignee to a task.
Capability Based Allocation + Oracle BPEL PM supports this pattern directly. It allows defining user properties and store them in user-properties.xml file, which become accessible via the function ora:getUserProperty(). This function can be used in the condition associated with the dynamic assignment feature.
History Based Allocation +/- Oracle BPEL PM does not offer the direct support for this pattern, but it allows implementing this feature and accessing it via the properties of the dynamic assignment.
Organisational Allocation +/- Oracle BPEL PM offers an indirect support for this pattern. The organisational structure is stored in the xml format in the jazn-data.xml file, and it can be modified and extended. The relationships between roles are specified via the role-hierarchy tree. The roles defined become accessible via the look-up wizard.
Automatic Execution + Oracle BPEL PM allows specifying tasks which involving the user, but also the tasks which are to be performed automatically. Any of the basic or structured activities offered by Oracle BPEL PM in the BPEL palette are executed automatically. Thus this pattern is directly supported.
Distribution by Offer - Single Resource + Oracle BPEL PM supports this pattern by offering work item to members of a group. A group containing one user allows this user to "acquire" the offered work item.
Distribution by Offer - Multiple Resources + Oracle BPEL PM supports this pattern directly by specifying the name of a group as an assignee of the task. As a result, the task will be offered to all members of a group, and any of the members may acquire it. After the work item has been acquired, not other users may acquire this work item any more.
Distribution by Allocation - Single Resource + Oracle BPEL PM supports this pattern directly. Assigning a user with a given identity statically or dynamically, automatically allocated the work item to this user. This differs from the pattern RP12 where the work item is offered to the user.
Random Allocation +/- Oracle BPEL PM offers no direct support for this pattern. However, the feature of assigning a work item dynamically can be used to support this pattern. For example, a service can be implemented to retrieve resource on the random basis.
Round Robin Allocation +/- Oracle BPEL PM offers no direct support for this pattern. However, the feature of assigning a work item dynamically can be used to support this pattern. For example, a service can be implemented to retrieve resource based on the round-robin algorithm.
Shortest Queue +/- Oracle BPEL PM offers no direct support for this pattern. However, the feature of assigning a work item dynamically can be used to support this pattern. For example, a service can be implemented to retrieve resource based on the shortest queue algorithm
Early Distribution - Oracle BPEL PM offers no support for this pattern
Distribution on Enablement + Oracle BPEL PM supports this pattern directly: as soon as a work item becomes available, it appears in the work list of the assigned resource.
Late Distribution - Oracle BPEL PM does not support this pattern since by any work item requires to have an assignee. Since the work item has to be allocated or offered to a user/role from the moment of creation, the late distribution is not possible.
Resource-Initiated Allocation - Oracle BPEL PM does not support this pattern directly. If a work item is assigned to a set of users of a group, one of the users in the list can "acquire" the task. However, this corresponds to the commence working on it immediately.
Resource-Initated Execution - Allocated Work Item + In Oracle BPEL PM resources are able to commence the execution of a work item available at their own worklists at a time of their own choosing, but before the task has expired. Therefore this pattern is supported directly.
Resource-Initiated Execution - Offered Work Item + Oracle BPEL PM supports this pattern directly. When a user is offered a work item, and the user "acquires" it, he commences work on it immediately.

System Determined Work Queue Content

 - Oracle BPEL PM does not impose a default ordering of the work items in the resources work queue, thus offering no support for this pattern.
Resource-Determined Work Queue Content + Oracle BPEL PM supports this pattern directly. The user is able to format the work items listed in his worklist based on the task id, priority and other parameters. In addition, Oracle ships a JSP based sample worklist application that can be customized to list specific content on the worklist application.
Selection Autonomy + Oracle BPEL PM supports this pattern directly. The user can select and act on any of the task displayed in his work list.
Delegation + Oracle BPEL PM supports this pattern directly by means of "reassign" action. As such, a manager can delegate a task to reportees. Similarly, the process owner or a user with BPMWorkflowReassign privileges can delegate a specific task to any other person in the organisation.
Escalation + Oracle BPEL PM supports this pattern directly by allowing escalation of a task to the manager for further action. The escalation continues until a certain user, a certain level (number of escalations to a 'manager'), or a certain title is reached. The escalation feature works correctly if a task has been assigned to a specific user, however if a task has been assigned to a role or a group, Oracle BPEL PM does not seem to know an upper level where a task should be escalated to.
Deallocation + Oracle BPEL PM 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 "acquire" the task. At anytime before the task expires or before a user has updated the task, the user can "release" the task to the set of users/group the task was originally assigned to.
Stateful Reallocation + Any work item can be "reassigned" to a new set of users/group. If the user has updated a task, after the reassignment the data provided by this user is visible to the new assignee, i.e. the state data is not lost.
Stateless Reallocation - Oracle BPEL PM does not allow task rollback, thus offering no support for this pattern.
Suspension/Resumption + Oracle BPEL PM supports this pattern directly. "suspend" and "resume" are available actions in the worklist application.
Skip + Oracle BPEL PM supports this pattern directly. As such any work item can be "withdrawn" by the task creator or the administrator. However, there is also possibility to model a user-action "skip", which marks a work item as completed and passes the flow of control to the subsequent task.
Redo - Oracle BPEL PM offers no support for this pattern.
Pre-Do - Oracle BPEL PM offers no support for this pattern.
Commencement on Creation - Oracle BPEL PM offers no support for this pattern since a resource needs to "accept" or "acquire" a work item from the worklist in order to start the execution.
Commencement on Allocation - Oracle BPEL PM offers no support for this pattern since a resource needs to "accept" or "acquire" a work item from the worklist in order to start the execution.
Piled Execution - Oracle BPEL PM offers no support for this pattern.
Chained Execution - Although Oracle BPEL PM offers the "continue task" pattern which allows one workflow to be continued with another workflow, the transition between the workflows is not automatic and requires a work item to be selected for the worklist. Therefore, Oracle BPEL PM offers no support for this pattern.
Configurable Unallocated Work Item Visibility - Oracle BPEL PM offers no support for this pattern, since any user can see all unallocated work items and there is no option to limit the visibility of unallocated items.
Configurable Allocated Work Item Visibility - Oracle BPEL PM offers no support for this pattern, since any user can see all allocated work items and there is no option to limit the visibility of allocated items.
Simultaneous Execution + Oracle BPEL PM supports this pattern partially by allowing a resource to work with multiple browsers related to a single worklist, and thus enabling and executing several work items simultaneously.
Additional Resources + Oracle BPEL PM supports this pattern directly. It offers an "adhoc" pattern which allows assigning the task to any other user run-time and "request for more information" from other users and have them submit information for tasks.