Service Orchestration Functional Specification - Orchestration Designer

$Revision: $
$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

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.
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.

  • The source view has validation and error checking above and beyond that provided by the XML well formedness and validation support.

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.
- 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)
- 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.


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).

    • 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).
    • 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).

    • 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

    • User adds the 'If' activity with drag'n'drop (or other) interaction.

    UC: Add a conditional branch to an 'If' activity

    • 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

    • 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.

    onMessage branches
    onAlarm branches
    Does not make sense
    Does not have any value - a sequence with a recieve would do the same.
    very low
    Does not make sense, morover a sequence with a wait would do the same.
    Wait for message (and process it) with a timeout.
    2 or N
    Wait for one of the messages and process it.
    2 or N
    Wait for one of the messages and process it with a timeout.
    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.
    2 or N
    2 or N

    Cost of adding a branch 1, cost of removing a branch 2.

    Initial State
    Cost comments
    For these targets, we count 0 % cost, because they don't make sense.
    For these target states we cound 100 % cost.
    These two states have only 50 % cost, because the frequency is low.
    Total Cost

    The lowest total cost is for combination 1:1.

    • 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

    • 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

    • 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

    • 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.
      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.

    • 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.

    • 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
    Functional Specification
    Simple Type
    All simple types defined in referenced XML Schema files, WSDL files or a XML Schema primitive type:
    <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.

    • 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.
    • 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.


    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).

    • 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.
    • 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.

    • 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

    • 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

    • 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?
    • 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.

    • 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.

    • 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.

    • 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

    • 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)
    • partnerRole
  • 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).

    Project Features

    About this Project

    SOA was started in November 2009, is owned by slunegov, and has 95 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
    Please Confirm