Comments RE: Issue 82 - Adding requesting clarifications

[<andrew.francis@mail.mcgill.ca>]

Quoting Satish Thatte <satisht@microsoft.com>:


RF>How about :
RF>"The semantics of an abstract process are therefore
RF>derived from the range of executable BPEL processes
thatRF>a particular abstractprocess represents."

ST> I think the real point is that the constructs used
ST>in abstract processes derive their semantics from
ST>the semantics of executable processes. Completion is
ST>simply one way in which this semantics is realized.

I feel the opening passage of Issue 82 is more a reflection
on how to implement abstract processes, than what they
fundamentally are. The assumption seems to be thatabstract
processes are reverseengineered from executable
processes.

Issue 82 would be clearer if it were better at making
distinctions between what I believe are three important
relationships concerning abstract processes.

1) The relationship between the language used to
describe WS-BPEL abstract processes and the WS-BPEL
language. An analogy would be the typical object
oriented language feature uses to define abstract classes
(i.e., use of word "abstract", etc.)
2) The relationship between the executable process and
the abstract process from which it was derived. An analogy
would be in an object oriented language, the subclassing
of an abstract class and subsequent instantiations.

3)The relationship between the executable process
(or instantiation) derived from the abstract process,
and how that executable process interacts with the
processes referenced by the abstract process. An analogy
would be a protocol defining the interaction between a
server and one or more clients.

Given the aforementioned, my problem with the opening
passage is as follows: if abstract processes are "factories"
(relationship 2) that produce executables, then how can one
say that abstract processes are derived from the executable?
This is counterinitutive. The typical programmer is used
to terms like "subclasses derived from abstract classes,"
not the other way around.

However, the opening passage makes more sense if the
"executable" Issue 82 discusses, is not the
executablediscussed in (2), but theexecutable discussed in (3).
Then it is not so much a case of "representation" but an
issue of "interaction."

Cheers,
Andrew