[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]