[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 9 - Proposal for Vote
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. >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]