Service Orchestration Functional Specification - Orchestration Navigator

$Revision: 1.1.1.1 $
$Date: 2009/10/29 16:50:03 $

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

  • Label: Process TODO: or rather the name of the process?
  • Tooltip: none
  • Contextual menu actions
    Add                    >  
    --------------------
    Go To Source (Alt+O)

    Add submenu:
    Add                    >  Variable...
    Correlation Set...
    Message Exchange...
    -------------------
    Event Handlers
    Fault Handlers
    Notes:
  • "Event Handlers" and "Fault Handlers" is disabled if process already has an event or fault handler.

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

  • Label: Variables
  • Tooltip: none
  • Contextual menu actions:
    Add Variable 
    --------------------
    Go To Source (Alt+O)

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:
  • Edit ...
  • Delete ...

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:
  • Edit ...
  • Remove ...

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:
  • Edit ...
  • Delete ...

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:
  • Edit ...
  • Delete ...

Node: [o] otherwise

  • Label: otherwise
  • Tooltip: none
  • Contextual menu actions:
  • Delete ...

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:
  • Edit ...
  • Delete ...

Node: [f] flow

  • Label: <flow.name>
  • Tooltip: none
  • Contextual menu actions:
  • Edit ...
  • Delete ...

Node: [l] link

  • Label: <link.name>
    TODO: Add source and target to the label
  • Tooltip: none
  • Contextual menu actions:
  • Edit ...
  • Delete ...

Node: [a] while

  • Label: <while.name>
    TODO: Add condition
  • Tooltip: none
  • Contextual menu actions:
  • Edit ...
  • Delete ...

Node: [f] catch

  • Label: Catch
    TODO: Add (faultVariable, faultName:= ?localpart? + ?namespaceUri?)Tooltip: none
  • Contextual menu actions:
  • Edit ...
  • Delete ...

Node: [f] catchAll

  • Label: catchAll
  • Tooltip: none
  • Contextual menu actions:
  • Delete ...

Node: [h] compensationHandler

  • Label: compensationHandler
  • Tooltip: none
  • Contextual menu actions:
  • Delete ...

 

#

Node: [k] partnerLink

  • Label:
    <partnerLink.name>
  • Tooltip:
    Partner Link <partnerLink.name> myRole=<myRole> partnerRole=<partnerRole>
  • Contextual menu actions:
  • Edit ...
  • Delete ...
  • 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:
    • Add Import ...
  • 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
    • Shortcut: Delete
  • 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

    • Contextual menu actions:
    • Open
    • Remove Import
    • Shortcut: Delete

    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:
    • Edit ...
    • Delete ...



    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.




    Project Features

    About this Project

    SOA was started in November 2009, is owned by slunegov, and has 96 members.
    By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
     
     
    Close
    loading
    Please Confirm
    Close