RE: [wsbpel] Issue - 76 - Mandating either Pessimistic or OptimisticStatic Analysis

[Harvey Reed <hreed@sonicsoftware.com>]

Bernd,

As you know, I recently circulated a spreadsheet of assumptions, like static
analysis. If the spec assumes that certain static analysis is happening,
then we should document them and be consistent.

So far you are the only one who submitted any. Hopefully we can encourage
the group to think hard and add to the list. The spreadsheet is attached.

If he group does not want the spec to assume static analysis, then we should
ban the phrase "this will be caught with static analysis" in all of our
discussions.

++Harvey



-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] 
Sent: Tuesday, October 21, 2003 6:10 PM
To: Wsbpel@Lists. Oasis-Open. Org (E-mail)
Subject: RE: [wsbpel] Issue - 76 - Mandating either Pessimistic or
Optimistic Static Analysis

Yaron personally I see it is obvious for a process designer to design for
the pessimistic case. On the ther hand, it would be a realy high burden to
mandate Engines to implement static checking, especially since the checks
are not well defined (yet).

On the other hand, I feel happy with putting required checks in the spec.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, October 21, 2003 7:23 PM
To: Wsbpel@Lists. Oasis-Open. Org (E-mail)
Subject: [wsbpel] Issue - 76 - Mandating either Pessimistic or
Optimistic Static Analysis


<process>
   ...
   <variables>
      <variable name="inmessage" type="inmessagedef"/>
      <variable name="outmessage" type="outmessagedef"/>
   </variables>
   ...
   <sequence>
      <receive variable="inmessage".../>
      <switch>
         <case condition="bpws:getVariableProperty(inmessage,randomvalue) >
3">
            <assign><copy><from>...</from><to variable="outmessagedef"
part="one"/></copy></assign>
         </case>
      </switch>
      <reply variable="outmessagedef".../>
   </sequence>
</process>

Depending on the value of the randomvalue property in the incoming message
the reply activity could cause a bpws:uninitializedVariable fault to be
raised.

The spec does not currently mandate any particular behavior in regards to
the static analysis of this program. Therefore this program could be
accepted by BPEL engines that use optimistic analysis and rejected by BPEL
engines that use pessimistic analysis. This ambiguity prevents real
portability since there is no way for a programmer to know ahead of time
what kind of BPEL engine their program will be run on.

To solve this portability problem that BPEL TC needs to mandate that all
BPEL engines use consistent behavior in applying static analysis. The two
most common choices for the TC to adopt is either to mandate optimistic or
pessimistic static analysis behavior.

Optimistic analysis is defined as meaning that a BPEL engine MUST accept any
BPEL definition so long as there exists at least one possible execution path
that will not cause any errors that can be detected using static analysis.

Pessimistic analysis is defined as meaning that a BPEL engine MUST reject
any BPEL definition which has at least one possible execution path that will
cause an error that can be detected using static analysis.

	Thanks,
		Yaron

   


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.

OASIS WS BPEL Global Assumptions.xls