RE: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues

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

Hello:

> I believe the distinction is not so much between wide and
> narrow as between a completely vs incompletely defined
> notion of abstract process, either singular, as you seem
> to prefer, or plural.

[from archives/wsbpel/200412/msg00023.html]

>If an abstract process is meant to fully represent the
>>externally observable behavior of a complete executable
>process along a set of partnerLinks, then the permitted
>>executable completions of this abstract process cannot>allow the addition of web services interactions using the
>partnerLinks mentioned in the abstract process, even as
>>replacements for opaque activities.
I believe an important point missing, or not stressed
in Peter's proposal is that an abstract process defines
an important invariant: the protocol. The protocol
controls the public visible behaviour (i.e., traces).

If my interpretation of Satishe's passage is correct,
the  abstract process (more specifically its control
flow constructs) defines the contract for the invocation
order of invoke, receive, and reply activities. Since
partnerlink is required on invoke, receive, and reply are
required attributes, this is tantamount to saying that
the abstract process defines the invocations order of
partnerlinks.

Consequently one is not allowed to write a derivative
concrete BPEL process that adds, omits, or changes the order
of partnerlinks defined in the abstract process since
this changes the protocol.


Cheers,
Andrew