Service Orchestration Functional Specification - Orchestration
$Revision: 18.104.22.168 $
$Date: 2009/10/29 16:50:03 $
This specification focuses on the Process Editor - the multiview Editor allowing the users to edit the business processes in a visual way. The Design View contains a business process diagram in a BPMN-like notation, the Source View contains the source of the underlying BPEL file.
2. Use Cases and Scenarios
2.1. Process Creation
The motivation to create business processes is out of the scope of this specification, it is partly discussed in the overview and also in the Orchestration Project specification. Here we assume that the user wants to create a BPEL business process and further evolve it in the diagram. How the creation of business processes fits into higher level use cases will be discussed elsewhere.
Also the motivation for the use of certain BPEL elements is not discussed thoroughly, we only touch the topic where it's necessary.
...Figure - Blank process BPEL file excerpt.
TODO: Evaluate the following paragraph; suggest a solution.
The user may add any element into the top-level sequence; there is probably no user need to use a different BPEL element in the root of the process; however a user may create or modify the process in the source view or 3rd party tool in such a way and thus this situation needs to be handled.
High level use case: Design of a business process using BPMN-like
notation (BPEL biased
The primary high level use case that is being fullfiled by the Orchestration Designer is the design of a business process. As the BPMN process diagram is a graph consisting of nodes (tasks) and edges (sequential and message flows, flow links), adding a new element to the diagram basically comprehends following user model steps:
- Decide what task to add; and where to add it (or vice-versa).
- Insert the task (activity) into an existing sequential flow.
General Diagramming Scenario - IDE Components Ecology
This high level use case is fulfilled with various features of Orchestration Designer feature set that consists of:
- Orchestration Process Editor (with Source and Design view)
The Business Process Editor is a “multi-view” editor which has two sub-editors, "Design", "Source". Developers use the design view editor to describe the main flow of the process, including all activities, links, and structures. This graphical view may be printed. The source view provides access to the XML source of the BPEL process.
Can be used to navigate within the diagram and also to add and modify elements.
Serves as a repository of the diagram elements.
- Properties Window
Contains additional attributes, which are not visualised on the diagram.
|Figure: Document Editor, Inspector, Palette and Properties windows (Swing/AWT Designer)||Figure: Orchestration Designer features set consisting of Business Process Editor, Inspector (a.k.a. Navigator), Palette and Properties Window (mockup)|
Business Process Editor - Source View
This editor provides simple color coding for BPEL syntax to the extent that BPEL is XML. (i.e there will be no BPEL specific color coding, just the default that applies to any XML source)
The BPEL code is validated against the WS-BPEL 2.0 XML Schema whenever the user saves the process. The validation is limited to the standard validation support provided by XML parsers, i.e. well formedness and valid document. There is no validation above and beyond that provided by default for XML documents.
Validation errors are listed in the Console view.
The source view has validation and error checking above and beyond that provided by the XML well formedness and validation support.
The Undo and Redo actions are accessible in design as well as in the source view of the orchestration designer. Morover, these views share the history stack; i.e. they are executed on a single stack of changes.
In the source view, the behaviour (mostly the granularity of history entries) is consistent with other source editors, in the design view, one stack item can be one of the following:
- All changes done to the model as a result of drag'n'dropping an element from Palette, Project Explorer, Inspector (including the information entered in an optional modal dialog, that may appear after drag'n'drop is performed).
- Modification of one property in a property sheet, if single property editor was used.
- Modification of a group of properties, if the the group property editor was used.
- One relocation.
- One reordering.
- One placement/creation of a flow link.
- One creation of a fault or compenstation handler.
Big Undo/Redo Save Question
An Orchestration Designer user action may result in changes in other files, for example:
- While adding a new recieve activity, a new operation may be added to a WSDL file.
- Some changes in a diagram may induce modifications to the deyploment descriptor file.
2.3. Process Design - Basic Activities
This is the most common use case while designing the business process (along with defining additional attributes). The scenario is quite "given" with the used UI idiom of the diagram and palette.
Some of the tools are taking an approach of providing separate user interactions for adding a task and adjusting the flow lines. However we are taking a different approach (as some of our competitors) and provide a functionality that allows the user to add a task and adjust the surrounding flow lines in one step - we introduce a notion of place holders:
- User picks an element in the palette and initiates Drag'n'Drop interaction from palette to the diagram.
- As the mouse pointer reaches the diagram, placeholders show up. A placeholder is a place in the existing sequential flow, where additional activity can be inserted.
- As the user moves the mouse pointer above a placeholder, it gets highlighted. User
understands that that's the place, where an activity can be placed.
- The user releases the mouse button (finalize the Drag'n'Drop interaction) above a placeholder and new activity is added to the location of placeholder.
- The target of the Drag'n'Drop can be also a container or a
place in the Navigator.
The Palette UI specification suggests three interaction modes with the Palette (drag'n'drop, select and stamp, and double-click on palette item). As only the first approach makes sense in Orchestration Designer, the others will not be implemented.
Discussion about three possible interaction modes with the Palette:
Select and stamp is usefull in cases, where the users need to add lots of activities of the same type at once. That's very usefull while designing a Swing form, however not practical in Business Process modelling. So we dropped this approach in order to optimize implementation cost.
Double-click on palette item needs to specify a default position in the editor.
Note about eager and lazy diagramming:
In the TPR2 time frame, we were also contemplating eager diagramming. In this approach when the Drag'n'Drop is finalized the Property Editor pops up allowing the user to specify attributes for the newly placed activity. This was optimized for "concrete modelling", where the user wants to define the sequential flow and activities including the details. However, based on usability studies and cumbersome design of the eager diagramming, we decided to optimize for "abstract modelling" with "lazy diagramming.
However, this question is still in the air and may be revised in the future. This not only applies to adding an activity from the palette but also adding a case branch or similar elements with a contextual menu action.
Adding a basic activity is simple and follows the scenario defined above. Basic activities are:
For the structured activities, the situation is a little more complex. This is discussed in the following section.
The user wants to remove an activity from the diagram; it may be a basic or a structured activity. In case of structured activity, the user expects all the nested elements to be also removed. This naturally fits to the iterative development (of business processes as well as other artefacts).
- User brings up the contextual menu of the activity and invokes
the "Remove" action.
- The action can be also invoked by pressing the Delete key if the activity is selected.
UC: Change the name of an actitivty
- User may follow the scenario "Modify attributes of an activity"
- Or the name can be also changed in property sheet.
UC: Modify attributes of an activity or other element
There are some activity attributes, which are not visualised on the diagram. These are essential part of the business process. User may want to edit them to specify important part of the business process semantics (e.g. data flow).
- The user invokes "Edit..." action on the activity from the contextual menu or by double click on the element.
- Pressing the Enter key also invokes the "Edit" action if the element is selected.
- User adds a structured activity (wrapper) before or after the activity (basic or structured) that is supposed to be wrapped.
- User relocates the to-be-wrapped activity to the newly placed structured activity by Drag'n'Drop (in diagram or Navigator window).
OTH, we may also consider special wrapping functionality (competition probably does not have it).
The use case of adding a structured activity is a little more complex in comparison to basic activities. Since an empty structured activity does not bring any value, the use case involve a question - what content should be added by default.
'If' Activity Related Use Cases
From BPEL spec:
The if structured activity supports conditional behavior in a pattern that occurs quite often. The activity consists of an ordered list of one or more conditional branches defined by if, elseif elements, followed optionally by an optional else branch. The if and elseif branches of the if activity are considered in the order in which they appear. The first branch whose condition holds true is taken and provides the activity performed for the if activity. If no branch with a condition is taken, then the else branch is taken if specified. If the else branch is not explicitly specified, then an else branch with an empty activity is deemed to be present. The if activity is complete when the activity of the selected branch completes.
Although the first conditional branch is realized with a different construct in the BPEL source, the semantics is not different from the others, so we treat all the conditional branches as equal (with respect to order).
UC: Insert an 'If' structured activity
- User adds the 'If' activity with drag'n'drop (or other) interaction.
- The user brings up the contextual menu of the If activity and invokes "Add Conditional Branch" action.
- New branch is added to the diagram.
Note: The scenario also applies to Navigator.
In the TPR2 timeframe, we also considered eager diagramming approach:
Please note that this paragraph is using old 'Switch' term instead of the 'If' introduced in BPEL 2.0.
- The user invokes "Add a Case Branch" action on the switch element.
- The modal dialog "Add a Case Branch" pops up. User fills in name and condition, may use Condition Builder to build the condition.
- Confirms the dialog with OK button or cancels with Cancel button.
- If confirmed, new case branch is added to the diagram.
- The user brings up the contextual menu of a conditional branch he or she wants to remove and invokes the "Remove" action.
- The action can be also invoked by pressing the Delete key if the conditional branch is selected.
- If the conditional branch is last in the set, the remove action
- If the conditional branch being removed is first (and thus represented with <then> construct in the BPEL source, the following <elseif> branch is refactored into <then> branch (along with the <condition> tag. This however does not have any significant impact on the visualisation (we thread <then> and <elseif> as equal).
UC: Edit the expression of a conditional branch
Scenario is the same as while editing details of a basic activity.
Pick Related Use Cases
UC: Insert a pick structured activity
According to the BPEL specification, a pick activity has to contain at least one onMessage branch and may contain any number of onAlarm branches. In iterative development user may want to add any number of onMessage branches and onAlarm branches (although more then one onAlarm branch may be less frequent case). Based on the cost evaluation of subsequent adding of new activities, the base variant is to add one onMessage and one onAlarm branch by default.
Here is a discussion, why we have chosen to add one onMessage and one onAlarm branches in the default configuration of a newly added Pick activity.
||Does not make sense
||Does not have any value - a
sequence with a recieve would do the same.
||Does not make sense, morover a
sequence with a wait would do the same.
for message (and process it) with a timeout.
||2 or N
for one of the messages and process it.
||2 or N
for one of the messages and process it with a timeout.
||2 or N
quite reasonable (but rather rare) to have one "for" onAlarm branch and
one "until" onAlarm branch. However, it does not make sense to have
more then one "for" onAlarm branches - one of them will always be met
||2 or N
||2 or N
Cost of adding a branch 1, cost of removing a branch 2.
these targets, we count 0 % cost, because they don't make sense.
these target states we cound 100 % cost.
two states have only 50 % cost, because the frequency is low.
lowest total cost is for combination 1:1.
- User drag'n'drops the switch activity to the diagram, as it were a basic activity.
- User brings up the contextual menu of the switch activity and invokes the "Add an onMessage branch" or "Add an onAlarm branch" respectively.
- User brings up the contextual menu of the branch and invokes the "Remove" action.
- If the onMessage branch is the last one, the action is disabled.
UC: Modify pick onMessage or onAlarm properties
- User invokes the "Edit..." action of the contextual menu or hits
the Enter when selected or
double-click on the element.
- User may also achieve changing some of the onMessage branch
properties by creating or changing the message flow.
UC: Insert a flow structured activity
Users may want to insert a flow structured activity to let the BPEL engine execute multiple branches of the sequential flow in paralel. The scenario for adding a flow is equal to adding a basic activity.
- The flow activity always exposes a "required placeholder" for a new top level activity to be added.
- If the activity is supposed to be the only one, the user places the activity to the "required placeholder".
- A new "required placeholder" appears immediatly.
- User places sequence or scope onto the "required placeholder".
- Then any number of activities can be placed to the sequence.
UC: Remove a flow branch, including it's contents
Users may also want to remove all the contents of a single flow branch.
- Remove the top level activity in the flow branch.
- The sequential flow for this flow branch will automatically disappear.
While Activity Related Use Cases
UC: Edit the expression of a case branch
Scenario is the same as while editing details of a basic activity.
RepeatUntil and ForEach Related Use Cases
These elements will not be supported by designer and runtime in the first release.
Variable Related Use Cases
There are two variants of this use case:
- Add a variable and use it in a new activity (or case branch, pick event or fault handler)
- Add a variable and use it in an existing activity (or
case branch, pick event or fault handler), which was not completely or
correctly specified (i.e. variable definition or condition was missing).
- Invoke, reply and recieve activities or onMessage branch of a
pick actiivity or a fault handler (so "nearby" partnerlinks, their
operations and message types are important). These activities are
probably incomplete (variable not specified) in the time of adding a
variable. User has probably mocked up the process, and then is coming
back to precise the logic.
- Assign, wait, while activity and case branches.
|Type of variable
||All simple types defined in
referenced XML Schema files, WSDL files or a XML Schema primitive type:
|<variable name="ncname" type="qname"/>|
||<variable name="ncname" messageType="qname"/>|
||XML Schema element, may be
defined in a XML Schema file or WSDL file.
There are two constrains on the variable name:
- The name of the variable has to be unique within a scope.
- Morover, BPEL specification (page 41) says:
It is not permitted to have variables with same name but different messageType/type/element within an enclosing scope hierarchy. The behavior of such variables is not defined.
Note: The former constrain is checked in competitive products, the latter not.
Scenario 1 (Creating a variable for a recently added nvoke, Recieve or Reply activity):
- User adds a new activity and pops up the properties editor.
- User fills the information for the activity - chooses partnerLink and operation.
- User invokes the "Create Compatible Variable" action, a dialog pops up.
- The user specifies the name of the new variable (default
provided) and chooses where to create the new variable (Local - in the
scope of the activity or Global - in the process)
Scenario 2a (Creating a variable in advance):
- User pops up the property editor for scope or process.
- Navigates to the Variables tab and adds a variable.
User may want to change the name of a variable to improve the quality of the diagram in terms of clarity, readability, corporate policies, etc. While changing the name, user expects the references to be changed as well. User may also want to change the type of a variable - probably within bigger changes if the business logic.
- User brings up the process or scope editor, selects the variable and hits "Edit..." button, which brings up the "Edit Variable" dialog
- This dialog can be also brought up with the "Edit..." cotextual menu action of the variable node in the Navigator window
- If the new name would be in conflict the change is not allowed.
- If the variable is already being used and the new type is not compatible with the usage of the variables, visual feedback is provided (with the common validation UI)
User may want to remove a variable, although the variable may be already in use.
- User brings up the process or scope editor, selects the variable and hits the "Remove..." button.
- The remove action can be also invoked from Navigator.
- If the variable is being used, the places of use are marked within the common validation UI
Assign Activity Related Use Cases
A copy rule may be used to:
- copy data between variables
- copy data between partner links
- copy a constant or expression to a variable
ossible variants of sources and targets - TODO: This needs to be
evaluated and the UI needs to be tuned to provide immediate feedback if
something is wrong.
The following table discusses these possibilities in a greater detail.
|Variable (message type)
||Only variables of compatible
message type (qualified names are the same)
|Variable (simple type)
|Any compatible target (the
source [from] may
be a subtype of target [to]):
|Variable (element type)
||Any compatible variable of the
BPEL spec on page 44:
In the case of variables defined by reference to an element, moreover, both the source and the target MUST be the same element.
||Any compatible Variable
- User brings up the assign activity editor and hits the
"Create..." button. The "Create New Assignment" dialog pops up.
- User specifies the source and target of the copy rule.
- An expression builder is provided to ease the creation of
- User pops up the assign activity editors, selects the copy rule and hits the "Delete..." button.
The use case is fulfiled in a similar scenario to adding a new copy rule - only using the "Edit..." button.
Common Use Cases related to Structured Activities
These use cases are special variants of the use case of adding a new activity into existing sequential flow.
UC: Insert an activity into a switch case branch, pick branch,
while loop or process (on top level within the process)
In these use case, the situation is complicated with the fact that the BPEL specification only allows one activity to be added to the while loop, case branch, pick branch or top level of a process. However, this does not fit in to the user model. Based on usability studies, users don't expect this restriction. They expect to be able to add any number of activities into these constructs.
- If the activity is supposed to be the only one, the scenario is equal to adding a basic activity to a sequential flow
- If the user wants to add more then one activities, they need to be encapsulated with a sequence:
- User adds a sequence.
- User adds basic activity into encapsulating sequence.
TODO: Specify the concept of "implicit sequence" and add a link to it.
UC: Change name of a branch in switch or pick structured activitity.
This use case is not supported by BPEL specification; however user's may want it.
But definetely, something should be done due to usability issue - finding OR-39
There is a globally defined fault name. There may be some data associated with the fault (name); these are passed to the handler in the specified local variable. If the fault name of a catch element is missing, the handler will intercept all faults with the right type of fault data.
UC: Insert a compensate activity
A compensate activity can be only placed in a fault handler or compensation handler, otherwise the scenario is equal to adding a simple activity.
UC: Specify details of a compensate activityTODO-TPR3: A dicussion about the use cases and motivation behind the compensation would be appreciated here.
TODO-TPR3: DnD could be employed also her
UC: Add a throw activity
UC: Add a compensation handler
In general, compensation handler can be placed on a scope or a WS activity.
UC: Add a fault handler to process or scope
- User brings up the contextual menu of a process or scope and invokes "Add Fault Handler" action.
- A new fault handler is attached to process or scope.
- User then pops up the editor for the handler and specify the
UC: Remove a fault handler
- User brings up the contextual menu of the fault handler and
invokes "Remove" action.
UC: Change order of fault handlers
Is this a valid use case? Is it reasonable?
Correlation of Messages
- User selects the process or scope, where he or she wants to
correlate the messages, in the diagram. The related node is selected in
the navigator automatically.
- The user may also select the node directly in Navigator.
- Confirmation may be also done with changing the focus by selecting a different node or window.
- Hitting Esc key cancels the on-place editing.
UC: Create a new property
The scenario is equal to the scenario of creating a new correlation set, with the exception that the action is invoked on the Properties node instead of Correlation Sets.
UC: Create a new property alias
Property alias is a mapping of a property to certain element (XPath) in a set of message types.
- User invokes the "Create Property Alias ..." from the contextual
menu of the Property node in the Navigator.
- A chooser for a message type/part/query pops up (just one big tree).
- User selects a node representing the location of the correlation data and confirms the choice with Ok button.
- A new property alias is created and shown as a child of the property node.
UC: Remove a correlation set, property or property alias
- User pops up the contextual menu of the node representing the object to be deleted and invokes "Remove" action.
- The node is removed.
UC: Add a property to an existing correlation set
- User brings up the contextual menu of a correlation set and
selects the "Add Property". A chooser with available properties pops up.
- User selects a property, confirms the dialog and property is added to the correlation set.
Relocate and Reorder
TODO-TPR3: This section is still partially valid although we don't have free layout anymore (or semiautomatic layout yet).
UC: Reorderi.e. changing the order of an element in a process flow
UC: Relocatei.e. changing the visualisation location of an element (or structure) without changing the semantics
UC: Resize a pool, scope or other container
The tool resizes the containers automatically as needed, when the user
relocates the elements, places new elements or removes existing.
UC: Reroute a Sequential or a Message Flow
UC: Change Visual Attributes of Elementsi.e. at least change color of a note element
2.4. Partner Links
TODO-TPR3: This whole section needs to be clarified and completed within end-to-end WSDL story
UC-DIAG-1: Add a new partner link to an existing partner
This use case may be fullfiled on its own, in a scenario like the following:
- User uses a specific UI widget (button, link, palette element) and enters required information (i.e. partnerLinkType name, role names, portType names). He or she may also choose to create only one port type - consumed vs provided - i.e. one role. In that case, special UI for adding/editing the partner link type and adding/editing a port type would have to be provided.
UC-DIAG-2: Add a new partner link to a new port type
- User uses a specific UI widget (button, link, palette element, web references repository node) and enters required information:
- WSDL location - textfield and/or browse button or D'N'D from Web References
- the user may also D'N'D a partnerLinkType from the WSDL subtree
- partnerLinkType - if it does not exist, there must be an option
to be created
- processRole (myRole)
UC-DIAG-3: Establish a communication with an existing partner or a
partners being developed in the tool.
In UC-DIAG-2, the partner's port types are fixed; no operations can be added or removed to it as the underlying WSDL is a 3rd party artefact. In this use-case, these partners are also developed within the authors organisation (or by the author alone) and the development may iterate across process and partners. Thus new operations may be added to a port type (both consumed or provided), when the user discovers such a need while designing the process.
UC-DIAG-4: Implement the "uknown" partner.
This use-case is out of the scope of this specification. However, it may be related to the functionality covered by this specification. Basic idea is that an "unknown" partner would then become a partner being developed in the tool (UC3).