Service Orchestration Functional Specification - Orchestration
Designer
$Revision: 1.3 $
$Date: 2006/06/20 10:34:50 $
Note: This document contains
hidden
sections. You may show them
using the following links: Reader Notes: Hide
/ Show
| Author Notes: Hide / Show
1. Introduction
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.
Jirka (24/02/2006):
Here we could talk about the top level business process element and
various use cases and scenarios related to it. But maybe, it's not
necessary.
In the beginning the blank
process contains a top-level sequence.
TODO: This top-level sequence may be hidden (not
visualised) and/or the process may be empty (without a top-level
element) and the sequence may be added lazilly - this would lead to an
invalid initial BPEL however.
...
<process>
<sequence>
</sequence>
</process>
...
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.
2.2.
Process Design
#
High level use case: Design of a business process using BPMN-like
notation (BPEL biased
and customized)
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.
Then the users may also want to modify element attributes, which are
not visualised on the diagram.
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.
- Inspector
Can be used to navigate within the diagram and also to add and modify
elements.
- Palette
Serves as a repository of the diagram elements.
- Properties Window
Contains additional attributes, which are not visualised on the diagram.
This is a common pattern used throughout the IDE (e.g.
Swing/AWT
Designer; depicted on the following figure).
 |
 |
| 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.
Jirka (24/02/2006): The validation and
error-handling functionality will be extended for TPR3. This should
also include specification of the behaviour of the diagram, if the BPEL
source is corrupted.
Undo/Redo/Save Functionality
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.
When the user invokes Undo or Redo action, the current view of the
multiview editor remains selected; with one exception: if the stack
item being undone or redone is "relocation", the multiview editor
switches to the design view. In addition, the visual element, text
fragment or place of change should be highlighted or selected after the
execution of undo or redo.
Jirka (24/02/2006): This section needs to be
respecified is agreed with Denis and Alexey in January'06.
Jirka (24/02/2006): The Big Undo/Redo/Save question needs to be
resolved with respect to completion of the WSDL story.
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.
It is questionable, whether Undo, Redo and Save actions should affect
also these side files (Big Undo/Redo/Save). Analogy can be seen in Java
Studio Creator WYSIWYG JSF editor - there are two separate history
stacks: one for the WYSIWYG multiview JSP editor and another one for
the Java backend file. Then Undo and Redo actions are processed
separately on this separate history stacks.
Some
notes about terminology - to be removed?
TODO: Improve the wording of the following text;
supposed to explain BPEL patterns and placeholder terms. Focus more on
defining sequential flow and user model.
---- after all, this section should be probably in the detailed
designer specification, not in this high level one.
A service orchestration diagram consists of a set of BPEL patterns;
each of the BPEL patterns may be represented by one or more BPMN
elements. Some of the BPEL patterns (e.g. switch or flow) may contain
other patterns (nesting). Some of the BPEL patterns can imply
several
links connecting it's BPMN elements and nested BPEL patterns.
Pattern-implied BPMN elements and links can not be removed or modified.
“Process” pattern is always a root pattern of diagram.
Diagraming palette will contain all types of BPEL elements. Element can
be drag-n-dropped from palette to placeholder on diagram.
Placeholder is a element of diagram, which is been highlighted when
some pattern is been dragged over this diagram. Each pattern can define
it's own set of placeholders
Layout manager defines positioning for elements on diagram. Some types
of layout managers allow elements to be moved interactively, another
types define fixed position for elements.
Each BPEL pattern define a BPMN elements which will be a holders for
“incoming” and “outgoing” pins. This pins indicating a points where
this pattern will be connected to a nesting pattern.
Each pattern has a border. Border is drawn using semi-transparent
dashed line. Border has a name tag attached to a upper-left corner.
Group border automatically sized to cover all group elements.
---
Placeholders - to be removed?
TODO: Following topic needs to be discussed.
--- and again, this should be in the detailed designer specification
There are two types of placeholders:
- required: used in structured BPEL patterns, if a nested BPEL activity
is required
- optional: used in the middle of implied sequential flows
The former type may not be needed, if one of the suggestions is
implemented:
- An invalid BPEL file (missing nested activity) as a result of the
orchestration designer is acceptable.
or
- The orchestration editor puts <empty> BPEL activities on
places, where a nested activity is required
Simmilar issue is related to missing case branch in switch pattern (at
least one is required) and onMessage branch in pick pattern. The tool
may:
- Accept/be able to handle invalid BPEL file (with missing case
or onMessage branch)
or
- forces the user to create at least one case branch in switch pattern
and onMessage branch in pick pattern - however this might restrict the
user interaction in an improper way (it's ok to ask the user to specify
the case condition for a new switch; however it may not be ok, to ask
for an incoming message in new pick activity and it's not ok not to
allow the user to remove last case branch or onMessage branch).
The conclusion may be that:
- the tool needs to handle an invalid BPEL file (at least with missing
case or onMessage branches)
- the tools needs to put extra/implied wait actvitiies where nested
activity is required (however, these would not be visualised)
Competitive products note:
Eclipse BPEL designer allows invalid BPEL file (missing branches and
nested activities); it also has two different visualisations for
required and optional place holders.
2.3. Process Design - Basic Activities
UC: Insert an activity to a
sequential flow
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.
Scenario:
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.
- In the end of the scenario, the newly placed element is selected.
TODO: We'll
also add here immediate on-place name editing.
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.
TODO: Add a
link to placeholder specification (and maybe move them to this
specification). That would make sense.
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:
- assign
- empty
- invoke
- recieve
- reply
- wait
- terminate
- throw
For the structured activities, the situation is a little more complex.
This is discussed in the following
section.
UC: Remove an Activity
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).
Scenario:
- 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.
Note:
The same interaction can be also employed in Navigator.
UC: Change the name of an actitivty
TODO-TPR3:
A discussion about names would be essential (including naming of fault
handlers, case
and pick branches and also in regards to implicit sequence).
Scenario:
- User may follow the scenario "Modify attributes of an activity"
- Or the name can be also changed in property sheet.
TODO-TPR3:
On place editing should be designed for TPR3. And also change in
property sheet will affect this scenario.
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).
Scenario:
- 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 may also achieve changing some of the WS activity properties
by creating or changing the message flow.
TODO-TPR3:
This section will be updated with respect to replacing modal Property
Editors with rich content in Properties Window.
TODO-TPR3: A possible scenario would be to
Drag'n'Drop a Variable from Navigator (or diagram if shown) to Rich
Properties Window or Expression/Copy Rule builder.
TODO-TPR3:
We should also evaluate "wrapping" usecases - i.e. user wants to wrap
an existing code in to a switch or so.
Wrapping use-case can be fulfilled by the following scenario:
- 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).
However, this scenario cannot (currently) be done for wrapping a top
most activity. - But this may be allowed by the concept of implicit
sequences.
OTH, we may also consider special wrapping functionality (competition
probably does not have it).
2.4. Process
Design - Structured Activities
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
Scenario:
- User adds the 'If' activity with drag'n'drop (or other)
interaction.
UC: Add a conditional branch to an
'If' activity
Scenario:
- 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.
Scenario (eager):
- 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.
TODO-TPR3:
For TPR3, we may consider adding an else-if branch from the Palette.
UC: Remove a conditional branch from
an 'If' structured activity
Scenario:
- 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
is
disabled.
TODO-TPR3:
The problem is that there is no visual feedback (user may try to hit
Delete key and nothing is happening). We may want to allow a switch
activity without any case branch (for a while).
- The case branch is removed including all it's childs. The action
also removes flow links linked to the elements nested in the branch.
- 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).
Note: This scenario (and use case) is
very similar to removing an activity. It can be also employed in Navigator.
UC:
Edit the expression of a conditional branch
Scenario is the same as while editing details of a basic activity.
TODO-TPR3:
There is a usability problem in this scenario - should be solved with
changing the visualisation and also selection mechanism. And then we
may want to involve Navigator somehow... user may want to use a
particular variable in that expression?
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.
Case
|
onMessage
branches
|
onAlarm
branches
|
Description
|
Frequency
|
0:0
|
0
|
0
|
Does not make sense
|
none
|
1:0
|
1
|
0
|
Does not have any value - a
sequence with a recieve would do the same.
|
very low
|
0:1
|
0
|
1
|
Does not make sense, morover a
sequence with a wait would do the same.
|
none
|
1:1
|
1
|
1
|
Wait
for message (and process it) with a timeout.
|
high
|
2:0
|
2 or N
|
0
|
Wait
for one of the messages and process it.
|
high
|
2:1
|
2 or N
|
1
|
Wait
for one of the messages and process it with a timeout.
|
high
|
1:2
|
1
|
2 or N
|
It is
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
first.
|
low
|
2:2
|
2 or N
|
2 or N
|
dtto
|
low
|
Cost of adding a branch 1, cost of removing a branch 2.
|
Target
State
|
Initial State
|
Cost comments
|
0:0
|
1:0
|
0:1
|
1:1
|
2:0
|
2:1
|
1:2
|
2:2
|
0:0
|
-
|
2
|
2
|
4
|
4
|
6
|
6
|
8
|
For
these targets, we count 0 % cost, because they don't make sense.
|
1:0
|
1
|
-
|
3
|
1
|
1
|
2
|
2
|
3
|
0:1
|
3
|
4
|
-
|
2
|
5
|
4
|
3
|
6
|
1:1
|
2
|
1
|
1
|
-
|
3
|
2
|
1
|
2
|
For
these target states we cound 100 % cost.
|
2:0
|
2
|
1
|
4
|
3
|
-
|
2
|
5
|
4
|
2:1
|
3
|
2
|
2
|
1
|
1
|
-
|
3
|
1
|
1:2
|
1.5
|
1
|
1
|
0.5
|
2
|
1.5
|
-
|
0.5
|
These
two states have only 50 % cost, because the frequency is low.
|
2:2
|
2
|
1.5
|
1.5
|
1
|
1
|
0.5
|
0.5
|
-
|
Total Cost
|
12.5
|
6.5
|
9.5
|
5.5
|
7
|
6
|
9.5
|
|
The
lowest total cost is for combination 1:1.
|
Scenario
:
- User drag'n'drops the switch activity to the diagram, as it were
a basic activity.
UC: Add an onMessage or
onAlarm branch to a pick activity
Scenario
:
- User brings up the contextual menu of the switch activity and
invokes the "Add an onMessage branch" or "Add an onAlarm branch"
respectively.
TODO-TPR3:
For TPR3, we may consider adding a branches from the Palette.
TODO-TPR3: Note that
there may be also usability problem in the similarity with wait and
recieve activities then.
UC: Remove a pick branch
Scenario:
- 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.
TODO-TPR3:
The problem is that there is no visual feedback (user may try to hit
Delete key and nothing is happening). We may want to allow a pick
acitivity without any branch (for a while).
Note: This scenario (and use case) is very similar to
removing an
activity.
UC: Modify pick onMessage or onAlarm properties
Scenario:
- User invokes the "Edit..." action of the contextual menu or hits
the Enter when selected or
double-click on the element.
OR
- User may also achieve changing some of the onMessage branch
properties by creating or changing the message flow.
TODO:
To be a nice guy, I should place a
link to message flow scenarios here.
TODO-TPR3:
This section will be updated with respect to replacing modal Property
Editors with rich content in Properties Window.
TODO-TPR3: There is also usability issue
related to selecting containers, which needs to be resolved.
TODO-TPR3: Design Idea: Creating a message flow does not fix problem
with unspecified details of a web service activity or onMessage branch
because variable may be also missing. Maybe something could be done
with this ...
Maybe something like Java-hints? Offering to create a variable when
creating new message flow? - we need to study what is the general
practice of creating variables.
Flow Related Use Cases
TODO-TPR3:
Think about this: Visualisation and interaction may be different for
createInstance=yes/no
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.
TODO-TPR3:
A discussion of wrapping use case
would be appropriate here.
UC: Create a flow branch for
paralel execution and add activities into it
Users may want to define any number of paralel execution branches in a
flow activity; and within them may want to
have any number of activities.
TODO-TPR3: BUG: Currently the placeholder for
the new flow is on the left, but then, when added, the activity appears
on the right (it'a added as "last").
TODO-TPR3: Current behaviour (scenario) is also inconsistent with
switch and other activities.
Scenario:
- 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.
- If the user wants to place more then one activity into a flow
branch, he or she needs to encapsulate them into a sequence or scope.
- User places sequence or scope onto the "required placeholder".
- Then any number of activities can be placed to the sequence.
There is a usability problem in this
scenario. It also applies to
other
structured activities.
TODO: It would be nice to provide links to
the scenarios that are referenced here but defined.
UC: Remove a flow branch, including it's contents
Users may also want to remove all the contents of a single flow branch.
Scenario:
- Remove the top level activity in the flow branch.
- The sequential flow for this flow branch will automatically
disappear.
TODO-TPR3: The behaviour is inconsistent with
switch and other structured activities - this issue should be resolved
along with its counterpart in the opposite
scenario.
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.
TODO-TPR3: Actually, the visualisation
is a little different. And complicated. And should be changed for TPR3.
RepeatUntil and ForEach Related Use Cases
These elements will not be supported by designer and runtime in the
first release.
TODO-post1.0: Reevaluate this.
Variable Related Use Cases
UC: Add a variable
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).
The user may add a variable to a scope or a process (global
variable). The user needs to decide in what container to add the
variable and what type of variable. This decision is based on existing
activities in the sequential flow as well as future intentions of the
user in
regards to the addition of new activities to the flow. This mostly
involves:
- 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.
The user may choose one of the following types:
Type of variable
|
Description
|
Functional Specification
|
Simple Type
|
All simple types defined in
referenced XML Schema files, WSDL files or a XML Schema primitive type:
http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/datatypes.html#built-in-datatypes
|
<variable name="ncname"
type="qname"/> |
Message Type
|
WS Message.
|
<variable name="ncname"
messageType="qname"/> |
Element Type
|
XML Schema element, may be
defined in a XML Schema file or WSDL file.
|
<variable name="ncname"
element="qname"/>
|
TODO-TPR3: BUG: Currently the IDE only allows
the user to create simple
type variables with a primitive XML Schema type.
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.
TODO-TPR3: The constrains on variable
names need to be revised (within the effort to design validation and
error handling features).
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)
TODO-TPR3: In the "Create Compatible
Variable" case, the user may want to create a variable with a supertype
of a type being used in the operation.
TODO-TPR3: Maybe, the "Create Compatible Variable" action could
be invoked with a diagram "Missing Variable" annotation.
Scenario (UC-AV.1) - Assign activity:
We may want to have something like "Create Compatible Variable" also
for Copy Rule editor. And the same for expression editor? Or not valid
there?
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.
TODO-TPR3: Here is a formal disconnect
between the use cases and scenarios; though the ideas and design is
valid.
TODO-TPR3: We should also discuss how the user chooses the type for the
variable (assumbing that there m
UC: Modify 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.
Scenario:
- 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
- User updates the name and confirms the dialog with Ok button. The
name of the variable is changed as well as all its references.
- If the new name would be in conflict the change is not allowed.
TODO-TPR3: Can there be a multifile
BPEL? If so, the changes need to be propagated to that file as well.
- User may also change the type of a variable
- 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)
TODO-TPR3 or post1.0: Maybe DnD from a window
with XML Schema to a
variable definition would fulfill the use case nicely.
UC: Remove a variable
User may want to remove a variable, although the variable may be
already in use.
TODO: Motivation for this use case should be
provided - without it, it's not a proper use case defintion.
Scenario:
- 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.
- The variable is removed.
- If the variable is being used, the places of use are marked
within the common validation UI
Assign Activity Related Use Cases
UC: Add a Copy Rule
TODO-TPR3: Would be nice to have a discussion
about copy rule 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
TODO-TPR3: Any other options are possible?
* copy a constant or expression to a partner link?
* copy a variable to a partner link?
* copy a partner link to a variable?
Note: We are going to use existing
editor from Alaska here - what are it's capabilities? AI: To be found
out.
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.
From
|
To
|
|
Variable (message type)
|
Only variables of compatible
message type (qualified names are the same)
|
|
Variable (simple type)
Expression (constant)
|
Any compatible target (the
source [from] may
be a subtype of target [to]):
- variable of the same simple type
- XPath within variable of message type or element type
|
|
Variable (element type)
|
Any compatible variable of the
element type.
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.
TODO-TPR3: What does it mean
exactly?
|
|
Expression (constant)
|
Any compatible Variable
compatible
TODO-TPR3: What does it mean exactly
|
|
TODO-TPR3: Ease of use for creating a
constant (XML snippet) is essential.
TODO-post1.0: Enhancement: There may be some relation of Assign and WS
activities with testing ecology (providing some dummy constants instead
of real data or expressions in certain testing scenarios).
Scenario:
- 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
expressions.
TODO-TPR3: There is a usability problem
in here - looking up the variable again and again maybe quite
annoying and time consuming. However, a nice scenario would be to DnD a
variable (which was just created) from Navigator to Expression/Copy
Rule Builder
UC: Remove a Copy Rule
TODO-TPR3: A thought about the use case would
be nice here.
Scenario:
- User pops up the assign activity editors, selects the copy rule
and hits the "Delete..." button.
UC: Modify a Copy Rule
The use case is fulfiled in a similar scenario to adding a new copy
rule - only using the "Edit..." button.
UC: Change order of Copy Rules
TODO-TPR3: This use case should be fulfilled if it is reasonable.
Reordering may be possible in navigator.
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.
Scenario:
- 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.
We observed that this scenario
has usability flaws and we plan to solve this problem by covering the
BPEL specification shortcoming with the concept of "implicit 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
2.5. Fault Handling
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.
Fault Handling - Background Information
The above text as well as the text bellow needs to be clarified.
We need to summarize how the fault handling fits into the user model,
what are the concepts, assumptions and thoughts.
??? How BPEL engines matches the data types, if the fault variable is
(according to the spec) defined locally?
- again, in spec 76:
TODO: - to be discovered in other tools
If the fault has associated fault data, a catch activity specifying a
matching faultName
value and a faultVariable whose type (WSDL message type) matches the
type of the
fault’s data will be selected if present. Otherwise, a catch activity
with no specified
faultName and with a faultVariable whose type matches the type of the
fault data will
be selected if present. Otherwise, the default catchAll handler is
selected if present.
Fault response of an invoke activity -> name and data aspects
defined in the WSDL (BPEL spec 75, last paragraph).
Throw activity -> explicit name and data
some names and associated data types are defined by
BPEL spec, may be added more by platform (need to handle this)
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.
TODO-TPR3: And there are also some further
restrictions on what scope can be compensated. This needs to be
investigated and designed into the UI
UC: Specify details of a compensate activity
TODO-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
TODO-TPR3: A discussion about
parameters of the throw activity should
be conducted.
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
TODO-TPR3: A discussion about the fault
handling in general - and possible use cases and scenarios should be
conducted.
E.g. a reasonable scenario might be "create a fault handler for a
certain throw" - possible also with a DnD interaction - from throw to
fault handler or so ...
And then, maybe
Scenario:
- 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
details.
TODO-TPR3: There are some voices for adding a
fault handler from the palette - we need to evaluate how does it fit
into user model.TODO: Extend this use
cases with event and
compensation handlers, or spec out them as separate use-casesTODO-TPR3-BUG: Current design is a little
more difficult - it requires the user to add a "fault handlers"
container at first and than to add individual "catch" blocks. This is
not necessarry and could be greatly improved!!!
TODO-TPR3-BUG: Also, the catchAll block is shown first, although it is
actually "evaluated" as last.
TODO-TPR3-BUG: The label of Properties Window is "CATCH - Properties",
when a catch is selected. The capitalisation is wrong.
UC: Remove a fault handler
Scenario:
- User brings up the contextual menu of the fault handler and
invokes "Remove" action.
TODO-TPR3: Currently, there is an extra
"fault handlers" container - we should get rid of it or at least
simplify the interaction.TODO: Extend
this use cases with event and
compensation handlers, or spec out them as separate use-case
UC: Change order of fault handlers
Is this a valid use case? Is it reasonable?
Correlation of Messages
User Model - this needs to be
polished/clarified/discussed - Where are the correlations in the user
model?
TODO: Also the use cases in this section need
to be clarified
property - a key for message correlation (key declaration)
propertyAlias - definition of a key in a particular message type ()
messageType - may contain several parts; each part defined with a name
and a XML schema element; defined in WSDL along with operations, which
define input and output messages of a certain messageType
correlationSet - set of properties shared by all messages in the
correlated group
- according to the examples (BPEL spec 50); really a composite key
TODO-TPR3: CURRENT IMPLEMENTATION is WAY
DIFFERENT from the following scenarios - the existing stocked pop up
dialogs need to be replaced with what is specified here.
TODO-TPR3 or post1.0: BETTER VISUALISATION: This whole dependencies and
usage graph of correlation sets, properties, property aliases, message
types activities could be visualised as a nice graph.
----- BUT WE REALLY NEED TO UNDERSTAND THE USER MODEL FIRST! -> i.e.
do some user research
UC: Create a new correlation
set
Note: This use case is related to Navigator -
should it be described there?
Scenario:
- 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.
- User invokes the "Create New..." action on the Correlation Sets
node. A new node appears with a default name and in the on-place
editing mode.
- User specifies the name and confirms it with enter.
- Confirmation may be also done with changing the focus by
selecting a different node or window.
- Hitting Esc key cancels the on-place editing.
TODO: This is quite a new paradigm - is
something similar already used in the IDE?
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.
Note: Wouldn't it be nice to have links from
here to the low level spec (of nodes)?
TODO-TPR3: The specified scenario is not correct - user needs to
specify type!
UC: Create a new property alias
Property alias is a mapping of a property to certain element (XPath) in
a set of message types.
Scenario:
- 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
TODO-TPR3: The impact on objects that refer
to the object that is being removed needs to be discussed.
Note: Maybe, when deleting a correlation set, the user wants it to be also removed from activities.
Scenario:
- 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
TODO: Motivation should be described here.
Scenario:
- User brings up the contextual menu of a correlation set and
selects the "Add Property". A chooser with available properties pops up.
Would a pull down be better here?
- 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: Reorder
i.e. changing the order of an element in a process flow
UC: Relocate
i.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.
Other use-cases
UC: Reroute a Sequential or a Message Flow
UC: Change Visual Attributes of Elements
i.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.
TODO: Question: This use case may be also fulfilled
as a consequence of adding a new message oriented activity, however the
formerly suggested scenario would be prefered as nesting of the
workflows is generally not a good practice (but this needs to be
evaluated).
UC-DIAG-2: Add a new partner link to a new port type
Scenario:
- 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
- New UI element representing the partner link appears (visual
element, row in a table or node in tree)
UC-DIAG-3: Establish a communication with an existing partner or a
set of
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).
