Service Orchestration Functional Specification - Orchestration
Navigator
$Revision: 1.6 $
$Date: 2006/07/27 07:04:16 $
Note: This document contains hidden
sections. You may show them
using the following links: Reader Notes: Hide
/ Show
| Author Notes: Hide / Show
1. Introduction
Orchestration Navigator is a multiview navigator providing an
overview of the process being edited in the Orchestration Designer or
selected in the Project Explorer. It is leveraging and the design is
based on previous Navigator applications specified in the following
documents:
Release note: In a release following NetBeans
5.5, the Navigator window will be renamed to Inspector. However, we
keep
using Navigator in this spec as our current implementation is based on
NetBeans 5.5.
2. Use Cases and Scenarios -
Navigation
UC1: User wants to get an overview of the process and understand
its internals
UC2: User wants to quickly navigate to (i.e. select in editor) a
known element with a certain name
UC3: User wants to quickly navigate to an element with an expected
location in the sequential flow structure
UC4: Navigate into source
TODO: Should have "Go To Source" action in
logical view?TODO: should also think
about navigation to XML schema and WSDL
3. Use Cases and Scenarios -
Process Editing
The navigator can be also used to edit the business process. Scenarios
related to adding or removing diagram elements are very similar to
those in the diagram (design view) - with the exception that the drop
targets or contexts for contextual menu are within the Navigator. These
use cases and scenarios are discussed in the
Process Editor specification;
here is a summary:
Besides these use cases with counterparts in design view, there are
also use cases that have more different scenarios in Navigator. These
are:
TODO: And if we proceed with simplified rich
property editors in the Properties Window, the use cases will be
exclusively fulfilled in the Navigator.
TODO: There are also some other use cases.
TODO: Where necessary, we should describe low
level design for these scenarios.
3. Specification
Navigator Structure - XML View
The content of the XML View is identical to the Navigator provided for
a generic XML file, which is specified in a
different
specification.
Jirka
2006-04-03: These are a couple of proposals for new Navigator
structure, with imports and multiple wsdl files taken into account.
Note: Navigator Filters may better
fulfill the use cases related to
variables and correlation sets. E.g. user selects scope in the diagram
and sees the variables defined in that scope immediatly.
Navigator
Structure - Logical View (Filters)
[P] Process
| -- [S] sequence* Note: Or any other top level activity, with its childs according to the structure in the BPEL process
| -- [v] variable* Filter: these nodes may be hidden with a filter
| -- [c] correlationSet* Filter: these nodes may be hidden with a filter
| -- [p] property* Filter: these nodes may be hidden with a filter
| -- [a] activity*
| -- [a] activity*
| -- [f] catch* (faultVariable, ?localpart?, ?namespaceUri?)
| -- [a] activity*
| -- [f] catchAll?
| -- [a] activity*
| -- [h] compensationHandler
| -- [a] activity*
| -- [e] eventHandler*
| -- [a] activity*
[k] partnerLink*
[I] Imports
| -- [W] WSDL file*
| -- [t] partnerLinkType*
| -- [p] property*
| -- [a] propertyAlias*
| -- [S] Schema file*
If-Then-Else Variants
Current Implementation
| -- [i] if Note: condition attached here
| -- [t] then Note: this node is useless
| | -- [a] activity*
| -- [e] elseif? Note: condition attached also here
| -- [a] activity*
| -- [l] else Note: no condition here
| -- [a] activity*
Icons: [i] - like switch, [t] - TO BE DESIGNED?, [e] - like case, [l] - otherwise
Simplified Design (oversimplified)
| -- [f] if
| -- [a] activity*
| -- [a] elseif
| -- [a] activity*
This would be sufficient, but the problem here is that a container for the whole activity is missing.
Simplified Design - II (improved)
| -- [i] if
| -- [c] cond1 Note: condition attached here
| | -- [a] activity*
| -- [c] cond2? Note: condition attached also here
| | -- [a] activity*
| -- [o] otherwise
| | -- [a] activity*
This simplified design:
* eliminates unnecessary 'information noise' in distinction between
'primary' and 'other' conditions - only the order is important.
However, 1st condition (if) is in the same relationship to 2nd
condition (elseif) as to 3rd (elseif)
* brings the reordering posibilility (is this an important use case?)
A big question is - how many conditions are most frequently defined in
an if element? If it is just one, then the following mockup maybe
better:
| -- [i] if Note: condition attached here
| -- [a] activity*
| -- [e] elseif? Note: condition attached also here
| -- [a] activity*
| -- [l] else Note: no condition here
| -- [a] activity*
Navigator
Structure - Logical View (Object Aspect)
This is the specification of the tree structure in Logical View of
Orchestration Navigator. Abstract names of nodes are used, concrete
labels as well as actions and tooltips are specified in next sections.
Regular expression markup is used to denote multiple occurences of
nodes.
Note: The star symbol (*) means that
the element may appear zero or multiple times.
[P] Process
| -- [V] Variables
| -- [v] variable*
| -- [S] scope*
| -- [v] variable*
| -- [S] scope*
| -- [V] Correlation Sets
| -- [c] correlationSet*
| -- [p] propertyRef* Note: This is a reference to a property
| -- [S] scope*
| -- [c] correlationSet*
| -- [p] propertyRef* Note: This is a reference to a property
| -- [S] sequence* Note: Or any other top level activity, with its childs according to the structure in the BPEL process
| -- [a] activity*
| -- [a] activity*
| -- [f] catch* (faultVariable, ?localpart?, ?namespaceUri?)
| -- [a] activity*
| -- [f] catchAll?
| -- [a] activity*
| -- [h] compensationHandler
| -- [a] activity*
| -- [e] eventHandler*
| -- [a] activity*
[k] partnerLink*
[I] Imports Note: this node contains all the imported web resources as its childs, ordered alphabetically
| -- [W] WSDL file* Note: contextual menu action to open the file being imported in an editor
| -- [t] partnerLinkType* Note: if [i] is a WSDL file, it contains Partner Link Types and Properties as its childs
| -- [p] property*
| -- [a] propertyAlias*
| -- [S] Schema file* Note: tooltip of [W] and [S] contains namespace URI
Navigator Structure - Logical
View (Structure Aspect)
This is the specification of the tree structure in Logical View of
Orchestration Navigator. Abstract names of nodes are used, concrete
labels as well as actions and tooltips are specified in next sections.
Regular expression markup is used to denote multiple occurences of
nodes.
[P] Process
| -- [v] variable*
| -- [c] correlationSet*
| -- [p] property* Note: Referenced property does not have any children.
| -- [a] activity* Note: Activity node can be one of the following:
| -- [a] invoke
| -- [c] correlationSet* Note: Referenced correlation set does not have any children.
| -- [c] catch*
| -- [a] activity*
| -- [c] catchAll?
| -- [a] activity*
| -- [h] compensationHandler?
| -- [a] activity*
| -- [a] receive
| -- [c] correlationSet* Note: Referenced correlation set does not have any children.
| -- [a] reply
| -- [c] correlationSet* Note: Referenced correlation set does not have any children.
| -- [a] empty
| -- [a] assign
| -- [o] copyRule+
| -- [a] wait
| -- [a] compensate
| -- [a] throw
| -- [a] terminate
| -- [a] sequence
| -- activity*
| -- [a] scope Note: The contents of scope node is the same with Process node except properties and partner links
| -- [a] switch
| -- [s] case*
| -- [a] activity*
| -- [o] otherwise?
| -- [a] activity*
| -- [a] pick
| -- [e] eventHandler*
| -- [a] flow
| -- [a] activity*
| -- [l] link*
| -- [a] while
| -- [f] catch* (faultVariable, ?localpart?, ?namespaceUri?)
| -- [a] activity*
| -- [f] catchAll?
| -- [a] activity*
| -- [h] compensationHandler
| -- [a] activity*
| -- [e] eventHandler*
| -- [a] activity*
| -- [p] property*
| -- [s] propertyAlias*
| -- [k] partnerLink*
| -- [o] operation*
Nodes Details
The following sections contain description of nodes appearance and
behavior.
Contextual menu action description consists of several parts. First is
the label, second is the key accelerator, optionaly some further
description may be included. Some parts of labels in gray color, which
is same as in Java files Navigator. Most of the nodes are supposed to
be labeld with the name of activity.
If a name is not specified, then the name of the activity type is used
(as is in the palette). In case of Web Service activity, the name of
the operation may be also used, if name of activity is missing.
Default contextual menu
actions, which are activated on double click or Enter key press, are
shown in bold text. If not stated otherwise,
Edit ... actions bring up
relevant Edit dialog. All
Delete actions
have Delete key accelerator and
they pop up a dialog asking a question in a form "Are you sure you want
to delete <name>?". If name is not available, it is replaced with
"selected <type>".
All
Insert actions have
Insert key accelerator.
The icons for the nodes are summarized in the
icons
summary.
Node: [P] Process
Node: [a] Scope
- Label: <name.scope>
- Tooltip: Scope <name.scope>
- Contextual menu actions (same as in diagram)
Add >
Rename
Delete (Delete)
--------------------
Go To Source (Alt+O)
Add submenu:
Add > Variable...
Correlation Set...
Message Exchange...
-------------------
Event Handlers
Compensation Handler
Termination Handler
Fault Handler
Notes:
The "* Handler(s)" item is disabled if process already has the handler.
Node: [V] Variables
Node: [v] Variable
- Label:
<variable.name> <variable.type.nonfullyqualifiedname>
(in case of simple or element type)
<variable.name> <messageType.name.nonfullyqualifiedname/>
(in case of message type)
- Tooltip:
Variable <variable.name> <variable.type.fullyqualifiedname>
(in case of simple or element type)
Variable <variable.name>
<variable.type.nonfullyqualifiedname> (in case of message type)
- Contextual menu actions:
Node: [c] correlationSet
- Label: <correlationSet.name>
- Tooltip: Correlation Set <correlationSet.name>
- Contextual menu actions:
- Edit ...
- Add
Property ...
- Delete ...
Node: [c] correlationSet (referenced)
- Label: <correlationSet.name> initiate=yes|no, pattern=in|out
Note: Attributes are only present if they are specified in
the source.
- Tooltip: Correlation Set <correlationSet.name>
- Contextual menu actions:
Node: [a] invoke
- Label: <invoke.name> out=<outputVariable> in=<inputVariable> partnerLink=<partnerlink.nonfullyqualifiedname>
operation=<operation.name>
- Tooltip: Invoke <invoke.name> out=<outputVariable>
in=<inputVariable>
partnerLink=<partnerlink.fullyqualifiedname>
operation=<operation.name>
- Contextual menu actions:
- Edit ...
- Add Correlation Set ...
- Delete ...
Node: [a] receive
- Label: <invoke.name> variable=<variable.name>
partnerLink=<partnerlink.nonfullyqualifiedname>
operation=<operation.name> createInstance=yes|no
- Tooltip: Receive <invoke.name>
variable=<variable.name> createInstance=yes|no
partnerLink=<partnerlink.fullyqualifiedname> createInstance=yes|no
- Contextual menu actions:
TODO: ....
other activities
Node: [a] assign
- Label: <assign.name>
- Tooltip: none
- Contextual menu actions:
- Edit ...
- Add Copy Rule ...
- Delete ...
Node: [o] copyRule
- Label: <to> = <from>
- Tooltip: none
- Contextual menu actions:
- Edit ...
- Add Copy Rule ...
- Delete ...
Node: [a] if
- Label: <if.name>
- Tooltip: none
- Contextual menu actions:
- Edit ...
- Add Conditional Branch ...
- Delete ...
Node: [s] conditional branch
- Label: <condition.expression>
- Tooltip: none
- Contextual menu actions:
Node: [o] otherwise
- Label: otherwise
- Tooltip: none
- Contextual menu actions:
Node: [p] pick
- Label: <pick.name>
- Tooltip: none
- Contextual menu actions:
- Edit ...
- Add onMessage ...
- Add onAlarm ...
- Delete ...
Node: [e] eventHandler
- Label: "onMessage" + <onMessage.operation> |
"for" + <onAlarm.for> | "until" + <onAlarm.until>
TODO: This needs to be revised
- Tooltip: none
- Contextual menu actions:
Node: [f] flow
- Label: <flow.name>
- Tooltip: none
- Contextual menu actions:
Node: [l] link
- Label: <link.name>
TODO: Add source and target to the label
- Tooltip: none
- Contextual menu actions:
Node: [a] while
- Label: <while.name>
TODO: Add condition
- Tooltip: none
- Contextual menu actions:
Node: [f] catch
- Label: Catch
TODO: Add (faultVariable, faultName:=
?localpart? +
?namespaceUri?)Tooltip: none
- Contextual menu actions:
Node: [f] catchAll
- Label: catchAll
- Tooltip: none
- Contextual menu actions:
Node: [h] compensationHandler
- Label: compensationHandler
- Tooltip: none
- Contextual menu actions:
#
Node: [k] partnerLink
- Label:
<partnerLink.name>
- Tooltip:
Partner Link <partnerLink.name> myRole=<myRole>
partnerRole=<partnerRole>
- Contextual menu actions:
- Child nodes: PartnerLink node exposed all the operations of one
or both roles as its childs (roles distinguished with the icons -
recieve or invoke style)
Node: [o] operation
- Label: <operation.name>
- Tooltip:
Operation <operation.name> role=<role>
- Contextual menu actions: none
- DnD: same as with on-diagram element
Node: [I] Imports
- Contextual menu actions:
- The childs of this node are WSDL file and Schema file. Their
labels and order comply with the structure in type choosers.
Node: [W] WSDL file
- Contextual menu actions:
- Open
TODO-postTPR3: Add a partner link type ...
TODO-postTPR3: Add a property ...
- Remove Import
- DnD behaviour:
If a WSDL file or a related import element is DnDed onto a diagram, a
partner link may be created prepopulated with the infromation
introspected from the WSDL. The scenario and conditions are described
in the following pseudo-code:
#
A partner link is created for the first partner link type that meets
the following:
* It defines two roles.
* One of the roles refers to a portType, which has a binding and also
port in a service for that binding.
Notes for WSDL forward generation
* DnD a partnerLinkType on the diagram or process node adds a partner
link.
Node: [S] Schema file
Node: [t] Partner Link Type
- Drag'n'Drop source - if a Partner Link Type is dropped on the
diagram or process node in the navigator a partner link is added
TODO: if partner links nodes are shown as siblings to process nodes,
does it make sense to drop partner link types onto process nodes to
create a new partner link?
Node: [p] property
- Label: <property.name>
TODO: Add type?Tooltip: None TODO: full name of the type?
- Contextual menu actions:
- Edit ...
- Add Property Alias ...
- Delete ...
Node: [a] propertyAlias
- Label: <propertyAlias.name>
TODO: there is no name. So shoult it
rather be messageType, part, QueryTooltip: None
- Contextual menu actions:
5. Filters
TODO - Out of Scope for Coke - Needs more clarification.
The Navigator contains filters allowing the user to:
- Show / Hide Variables
- Show / Hide Sequences
5. Navigator Behaviour
Basic Behaviour
Here is a list of events, how the navigator reacts to them and what is
the impact on other windows.
| Event |
Impact |
Editor opened
|
When the editor is opened first
level of the tree is expanded (i.e. all children of the process node
are visible). |
| Editor View switched (i.e. User is looking at the
BPEL Diagram view and changes this to source view or vice versa) |
Navigator switches to a related View and a node related to
selected component or section is selected. i.e. Navigator view should
change to match the Editor view (Diagram + Logical view or Source + XML
view)
|
| Navigator
View switched |
Nothing . User is allowed to switch the Navigator view from
Logical to XML and vice versa. This should not change the Editor view
at all. |
| Node selected (single click or keyboard navigation
if focus is in Navigator) |
Related component is selected in editor; focus remains in
Navigator. The Editor view should not switch from Diagram to Source or
vice versa. This will allow mix and match selection. (i.e. user can
select element in Navigator Logical view while Editor is open to source
view. The Source view would just reposition the current line of source
editor . This could have value in allowing user to simply navigate the
source via the logical view.
|
| Node
"activated" (double click or Enter key press if focus is in Navigator) |
Related component in editor is selected; if there is a default
contextual menu action on the node it is invoked.
Navigator node double click selection in XML view should
cause Editor to switch from Diagram view to Source view.
Navigator node double click selection in Logical view should
cause Editor to switch from Source view to Diagram view.
|
| Component in editor selected. |
Related node is selected in the Navigator, but the Navigator
view is not switched. Focus remains in editor.
This is the converse of the Node selected use case described
above.
For example what if they wanted to keep the Source editor and
the logical view open together. The
user can select element line of code in the Editor's source view. If
the Navigtor is currently open to the Logical view, then the logical
view node which corresponds to the selected source should be selected.
Conersely, if the user has the Diagram view open at the same time as
the XML view in the Navigator, they should be able to select a Diagram
element and see the XML view synchronize its selection.
|
Property Sheet always shows information related to
selected node in Navigator.
Drag'n'Drop
The user can also use
Drag'n'Drop
to:
- Change order of
- case branches
- error or event handlers
- copy rules
- Relocate activities.
- Change scope definition of variables and correlation sets.
Note: * it would be great if Navigator could be used to
DnD
variables,
properties or anything ... to diagram, or editors (which are
modal so far)...
The visual feedback, while DnD interaction is performed, is identical
to the one in Project Window.
Quick Search
Quick search function works as specified in Java file Navigator.
