OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

   



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]