Contents (hide)
  1 Research
   1.1 Internal Activity
   1.2 Send-Recieve
   1.3 Receive-Process-Reply
   1.4 Regarding Parameters
   1.5 Regarding Errors
  2 Prosero (implementation)
   2.1 Meta-Model
   2.2 GUI
   2.3 Parameters

Constructs

Research

We are familiar with BPMN elements, as specified by the spec[x]. There are about 20 elements.

Such richness of elements allows: TODO: edit
Pros:
  • writing complex and accurate processes.
Cons:
  • rich pallet that is very large. May be difficult for the analyst. Too complex.
  • errors of (practically) any kind.

So, to give a limited and useful number of BPMN elements, we suggest these three building-blocks:

Can they work?
What about processes that cross several lanes? See here.

Internal Activity

Parameters

  • Maximal Duration
  • Failure modes (one by default)
  • Resources 1,..,n
  • Relevant external events

Errors

  • Time-out
  • Failure-Mode 1,…, Failure-Mode n
  • Unavailable resource (1,…,n)
  • External event 1,…,External-event n

Parameters → Errors

  • Maximal Duration → Time-out
  • Failure modes → Failure-Mode
  • Resources
  • Relevant external events → External event

images/constructs/internal.jpeg

Send-Recieve

Parameters

  • Maximal Duration
  • Number of retries (default 1)
  • Security
  • Non-repudiation
  • Synchronous/asynchronous

Errors

  • Time-out
  • Send failed
  • Send rejected
  • Incompliance with security/non-repudiation

Parameters → Errors

  • Maximal Duration → Time-out
  • Security → Incompliance with security
  • Non-repudiation → Incompliance with non-repudiation

images/constructs/send-receive.jpeg

Discussion - is it not better to change Send-Recieve to Send-Recieve-Process?
Pros:
  • Intuitive - send receive is really about pulling information and then using it.
Cons:
  • There can be sequence-flows with multiple send receive and then a single process.
Blog comments on this this discussion

Receive-Process-Reply

A Receive-Process-Reply element is always the top-most element. It is a wrap of the whole process, adding the possibility to handle errors that occurred in the process. Once the construct has been activated/trigerred, there won't be a place in the process sequence-flow where the process wait for another message without sending a request first.

Parameters

  • All activity arguments for process
  • Maximal duration for send
  • Number of retries
  • Security
  • Non-repudiation
  • Synchronous/asynchronous
  • Message type: query, notification, verify, update
  • Log update required
  • Commitment level

Errors

  • All activity errors for process
  • Time-out send
  • Receive rejected: format (item/list)
  • Receive rejected: authorization
  • Receive rejected: authentication
  • In-compliance with security/non-repudiation
  • Send failed
  • Send rejected
  • Query failed (item/list)
  • Verify failed (item/list)
  • Update failed (item/list)

Parameters → Errors

  • activity arguments → activity errors
  • Maximal duration for send → Time-out send
  • Security → In-compliance with security
  • Non-repudiation → In-compliance with non-repudiation
  • Message type Query → Query failed
  • Message type Verify → Verify failed
  • Message type Update → Update failed

images/constructs/trigger-process-reply.jpeg

Discussion - is it not better to change Receive-Process-Reply to Trigger-Process-Reply?
Pros:
  • Any external event, not necessarily a message, may trigger the process.
Cons:
  • Any external event can be ultimately viewed as generating a message.
  • "Message" is more intuitive to the analyst than "Trigger". I'm note sure…
Blog comments on this this discussion

Regarding Parameters

Currently, BPEL engines do not support all the parameters we suggest. For example, the engine has timeout definition of its own, and does not accept it as a parameter.
But when we look at the BPMN activities not as web-services (e.g. "send" is a secretary calling someone), then parameters like Number of retires and Time Duration are understandable.

Current conclusion, parameters are valid and useful even if they are currently disregarded when translating to an executable language. We hop that in the future they will be considered.

Parameters for Send

Some parameters seem to belong to the Send activity. Meaning, maybe the model should connect them to the send rather than to the construct. But that's not likely, since it changes the BPMN model. The constructs are on top of the model so they can use these parameters.

Regarding Errors

Prosero (implementation)

Orchestration
Our BPEL engine is an Orchestrator.

Using the existing BPMN elements to create the constructs, will look like this: building-blocks.JPG

TODO: Support the three constructs with their error conditions - first in the Meta-Model and then in the GUI

Q: Do we want to give the analyst constructs elements or just template elements

Careful
Pavel warns that to much wrapping (such as while wrapping an invocation flow) will make the BPEL unreadable and unmanageable.
Remember that the BPEL design (translated from BPMN) will go through some minor maintenance and editing (and only then deployed to BPEL run-time).

The implementation will require changing the BPMN-to-BPEL engine.

Meta-Model

See in prototype / tools / prosero / modeling / bpmn The model itself is: org.eclipse.gmf.bpmn / model / bpmn.ecore

To use eclipse.gmf, your Eclipse environment should include the Eclipse plug-ins: Graphical Editing Framework, Eclipse Modeling Framework runtime.

The meta-model is the BPMN meta-model, by the specification. For example, the subprocess hierarchy:
  1. BPDObject
  2. FlowObject
  3. Activity
  4. Task
  5. SubProcess

We need to build our constructs on SubProcess.

GUI

Parameters

Q: should parameters be used as functional (or NFP) preferences in the matching process?