Issue - 23 - proposed resolution (add rationale) for TC

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello,

here is my proposed resolution to the Issue 23, for discussion on the upcoming TC, as announced by Duane:

Short Description:

  There are some semantic requirements in the BPEL1.1 spec, which can be modeled with implicite links. 
  I have raised the following two "issues" in my original mail, and will suggest a combined solution:

   a) a sequence can be expressed as a flow, with additional links (not trivially)

   b) instead of searching for ready activities with no destination links (in a flow) the 
	runtime engine can optimize this search by linking from the flow activity to all 
	its included ready activities while parsing the process definition


First the easy part: I admit that part of the issue (b) is out of scope for the specification, since it is
only a possible runtime optimization, which may not apply to all implementation architectures. Therefore
I decide to resolve this part of the issue as "no need to do anything".

Part (b) of the issue however was discussed in some threads on the mailing list, and I feel we have some consence on this issue. Initially it was mentioned by me, because it was confusing (for me) to analyse the speciication and find two constructs (sequence vs. flow), which can basically express the same sematic. In fact, sequence is just a short notation for flows. Looking at our sample Implementation, I can see that this requires (some) additional code to support both constructs. Therefore I questioned this redundancy in the Spec.

There has been discussion to 

1) remove sequence (or even all?) constructs, which are short notation
	- to make the spec less ambiquos, therefore remove the risk of interoperability issues
	- and to allow faster implementation of the spec

2) keep the seuqence notation, as it might
   - allow modelling tools to better express the intend of the modeller
   - allow analysis tools to easier parse the overall structure of the process
   - allow backward compatibility (no unneeded change)
   - allow expression of sequences, which are otherwise not at all trivial.

(For the last point I remind everybody of the great mail from Ram Jeyaraman which was in detail explaining, what you have to do to replace a sequence with a flow, preserving link sematics).

I feel, that we agree, that the additional costs for the seuqnece implementation is far outweighted by the beneftis of solution (2). But since my concern about "beeing confused by this redundacy" is still valid, I propose the following trade-off:

Add a comment, rationale or normal text (whatever is preferred by the editing team) to explain it:


-- old --
12.1 Sequence (p.58)

A sequence
...
  </sequence>
-- /old --
-- add --
Rationale: the structured activity 'sequence' is a natural way of expressing sequential processing. It is therefore present in the Specification, even when it is possible to achieve the exactly same semantic with an structured flow, which has some additional links to preserve sequential processing semantics. It is important to emphasize, that transforming an sequence, with additional conditional links into a flow is not trivial, thats one of the reasons for having both constructs in BPEL. [For Information purpose only, you can check out the sample transformation on http://].
-- /add --


There are 3 Key points to decide on:

a) are we willing to keep the sequence activity, even if it can be replaced by flow with additional links
b) do we want to add a rationale, to clearify this redundancy in the spec
c) are we willing to enhance the spec with references to samples or whitepapers?


Personally I think we can directly vote on point a) and b) and should briefly discuss point c) as it is a general discussion, if we want to make the spec formal or "helpful". Perhaps point c) is something for an additional implementators guide?

Greetings
Bernd