Issue - 9 - Proposal for Vote

["Yaron Y. Goland" <ygoland@bea.com>]

I get twitchy when standards tell people how to implement parts of their 
product that can be reasonably construed as 'user experience'. Taking 
Assaf's example if an engine was intelligent enough to look at a process 
definition and say "This process can't do anything useful, I refuse to 
execute it" we certainly don't want the engine to have to officially 
violate the standard in order to do that.

At the same time however it is important that BPEL programmers be able 
to rely on some common assumptions if they are to have any hope of 
portability. Therefore I think the spec's language should define the 
common assumption but recognize that in the end engines are going to do 
what they need to do in order to provide the best user experience.

I think the easiest way to fix things is to change the MUST in my 
previous proposal to a SHOULD.

Our spec, as is the norm in our industry, refers to RFC 2119 in order to 
define certain key words like SHOULD. The definition provided there for 
SHOULD is:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

I think that definition exactly covers the types of scenarios Assaf 
refers to. The general assumption a BPEL programmer can make is that any 
engine they run on will use optimistic analysis. If an engine uses 
anything else then the engine developer will understand that they are 
violating the assumptions that most BPEL programmers will have but in 
their case feel the change is compelling enough to be worth doing.

I think that's a reasonable compromise in this situation.

I therefore modify my proposal as follows:

Section 5:
From: BPEL4WS takes it as a general principle that compliant 
implementations MAY choose to perform static analysis to detect and 
reject process definitions that may have undefined semantics. Such 
analysis is necessarily pessimistic and therefore might in some cases 
prevent the use of processes that would not, in fact, create situations 
with undefined semantics, either in specific uses or in any use.

To: BPEL4WS takes it as a general principle that compliant 
implementations MAY choose to perform static analysis to detect and 
reject process definitions that may have undefined semantics. Such 
analysis SHOULD be performed optimistically, that is, assuming the 
process has no syntactic errors then if there exists at least one 
execution path from each start activity in the process that can complete 
successfully then the process MUST be accepted for execution.


	Thanks,

		Yaron

Assaf Arkin wrote:
> A situation I don't want to end up with. A process has two paths for 
> execution. One path is executed when the order has been accepted by the 
> supplier, and static analysis indicates that is has undefined semantics. 
> The other path is executed when the order has been rejected, promptly 
> ending the process, and static analysis indicates it then executes to 
> completion. The process will result in no orders ever being completed, 
> yet an implementation must execute it.
> 
> I propose that instead we suggest three separate cases:
> 
> 1. if static analysis reveals there are only successful paths of 
> execution, must accept process
> 2. if static analysis reveals there are no successul paths of execution, 
> must reject process
> 3. if static analysis reveals there are successful paths of execution, 
> or a non-zero probability of them being successful paths of execution, 
> may accept process
> 
> an implementation can be pessimistic in determining only 1 or 2, of 
> optimistic in determining 1, 2 and 3, and leaving the decision up to the 
> discretion of the implementation or the user.
> 
> Assaf
> 
> Yaron Y. Goland wrote:
> 
>> Section 5:
>> From: BPEL4WS takes it as a general principle that compliant 
>> implementations MAY choose to perform static analysis to detect and 
>> reject process definitions that may have undefined semantics. Such 
>> analysis is necessarily pessimistic and therefore might in some cases 
>> prevent the use of processes that would not, in fact, create 
>> situations with undefined semantics, either in specific uses or in any 
>> use.
>>
>> To: BPEL4WS takes it as a general principle that compliant 
>> implementations MAY choose to perform static analysis to detect and 
>> reject process definitions that may have undefined semantics. Such 
>> analysis MUST be performed optimistically, that is, assuming the 
>> process has no syntactic errors then if there exists at least one 
>> execution path from each start activity in the process that can 
>> complete successfully then the process MUST be accepted for execution.
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>>
>>
>