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 99 - Updated proposal for vote


The semantics of the <exit> activity is that it immediately terminates a
process instance within which the activity is performed. This semantics
does not make sense for the publicly visible behavior because it leads
to dangling interactions (there is no way for the partner(s) taking part
in the message exchange to conclude what happened and what needs to be
done as the next step in the interaction). However, the <exit> activity
may be interpreted as a kind of failure statement and it must be ensured
that none of the participants in the message exchange can reach the exit
activity (there is no sequence of messages that leads to the exit).
Otherwise, the participants should change their behavior accordingly.
Because of different semantics for the executable processes and publicly
visible behavior (AP 1.1) it has been decided to disallow the <exit>
(former <terminate>) activity in the publicly visible behavior in order
to avoid any ambiguity. 

Regards,

Ivana
 

>-----Original Message-----
>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>Sent: Tuesday, May 17, 2005 7:04 PM
>To: Trickovic, Ivana
>Cc: Danny van der Rijn; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote
>
>The use of exit in publicly visible behavior is that it is an 
>unambiguous way of saying that no further action in the communication 
>can occur. Reaching the end of the process has similar 
>semantics but in 
>many cases a 'sudden' end may be needed. For example, if my 
>process has 
>a 'kill yourself' message on an event handler then the body would 
>contain an <exit> to indicate that no further communications can occur.
>
>	Yaron
>
>Trickovic, Ivana wrote:
>> Currently the <exit> activity is only available for 
>executable processes (+ the 
>> common base and all future profiles, according to the 
>resolution for issue 82) 
>> and it is forbidden for "publicly visible behavior" (called 
>AP 1.1). What would 
>> be the semantics of <exit> in a description of publicly 
>visible behavior?
>> 
>>  
>> 
>> Regards,
>> 
>>  
>> 
>> Ivana
>> 
>>     
>---------------------------------------------------------------
>-----------------
>>     *From:* Danny van der Rijn [mailto:dannyv@tibco.com]
>>     *Sent:* Wednesday, May 11, 2005 1:23 PM
>>     *To:* wsbpel@lists.oasis-open.org
>>     *Subject:* Re: [wsbpel] Issue 99 - Updated proposal for vote
>> 
>>     Sounds like we need a new issue allowing the appearance 
>of exit (and all
>>     other activities) in abstract processes?
>> 
>>     Trickovic, Ivana wrote:
>> 
>>>Indeed, issue 99 is considering only the AP 1.1 profile (the publicly
>>>visible behavior) and does not deal with other profiles, including
>>>process
>>>templates. So, statement "... the <exit> activity is limited to
>>>executable
>>>processes" is probably misleading. I would suggest to change it to
>>>"...the
>>><exit> activity is forbidden in BPEL abstract processes 
>describing the
>>>publicly visible behavior"
>>>
>>>Regards,
>>>
>>>Ivana 
>>>
>>>  
>>>
>>>>-----Original Message-----
>>>>From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] 
>>>>Sent: Tuesday, May 10, 2005 11:11 PM
>>>>To: ygoland@bea.com; Trickovic, Ivana
>>>>Cc: wsbpel@lists.oasis-open.org
>>>>Subject: RE: [wsbpel] Issue 99 - Updated proposal for vote
>>>>
>>>>I agree with Yaron. As I understood the resolution of 82, ALL 
>>>>constructs
>>>>of
>>>>BPEL could appear in abstract processes. It's only the profiles that
>>>>would 
>>>>apply a restriction. The profile for !abstract processes
>>>>to define publically visible behaviour" (which is what the ap 1.1
>>>>profile 
>>>>would be, I think) may forbid exit. Profiles for templates 
>(whereever
>>>>they
>>>>get published) would likely allow it.
>>>>
>>>>(actually, given the relation of executable:abstract, disallowing a
>>>>construct in a profile is equivalent to requiring it to be
>>>>opaqued/omitted, if 
>>>>we move from exectuable to abstract)
>>>>
>>>>Peter
>>>>
>>>>    
>>>>
>>>>>-----Original Message-----
>>>>>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>>>>>Sent: 10 May 2005 21:09
>>>>>To: Trickovic, Ivana
>>>>>Cc: wsbpel@lists.oasis-open.org
>>>>>Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote
>>>>>
>>>>>
>>>>>Why do we limit exit to executable processes? When did we 
>>>>>agree to that? 
>>>>>I honestly don't remember. I don't see a good reason to 
>exclude exit 
>>>>>from abstract processes since this would negate the ability to use 
>>>>>abstract processes as templates which was a required use 
>case in our 
>>>>>compromise on 82.
>>>>>
>>>>>Otherwise I'm happy with this text.
>>>>>
>>>>>	Thanks,
>>>>>
>>>>>		Yaron
>>>>>
>>>>>Trickovic, Ivana wrote:
>>>>>      
>>>>>
>>>>>>Per our discussion we had last Wednesday, here is an 
>>>>>>        
>>>>>
>>>>>updated proposal 
>>>>>      
>>>>>
>>>>>>for issue 99. There is a separate issue (issue 82.3) serving as a 
>>>>>>placeholder for refactoring the original definition of abstract 
>>>>>>processes (AP1.1) and the work required to produce profile 
>>>>>>        
>>>>>
>>>>>for AP1.1. 
>>>>>      
>>>>>
>>>>>>Nevertheless, based on the proposal for issue 82 and the 
>>>>>>        
>>>>>
>>>>>current text 
>>>>>      
>>>>>
>>>>>>of the specification the following text should be incorporated.
>>>>>>
>>>>>>
>>>>>>11.4 Providing Web Service Operations
>>>>>>-------------------------------------
>>>>>>Reword first two sentences of the second paragraph to:
>>>>>>In addition, receive activities play a role in the 
>lifecycle of AN 
>>>>>>EXECUTABLE process. The only way to instantiate AN 
>>>>>>        
>>>>>
>>>>>EXECUTABLE process 
>>>>>      
>>>>>
>>>>>>in WS-BPEL is to annotate a receive activity with the 
>>>>>>        
>>>>>
>>>>>createInstance 
>>>>>      
>>>>>
>>>>>>attribute set to "yes" (see Pick for a variant).
>>>>>>
>>>>>>
>>>>>>Section on AP1.1 (probably section 15.2 according to the 
>>>>>>        
>>>>
>>>>resolution 
>>>>    
>>>>
>>>>>>for issue 82):
>>>>>>
>>>>>>        
>>>>
>>>>------------------------------------------------------------
>----------
>>>>    
>>>>
>>>>>>--
>>>>>>----------
>>>>>>Include the following text:
>>>>>>
>>>>>>The receive activity plays a role in the lifecycle of executable 
>>>>>>processes. It is required that executable processes must 
>>>>>>        
>>>>
>>>>contain at 
>>>>    
>>>>
>>>>>>least one receive activity (or pick activity) that receives 
>>>>>>        
>>>>>
>>>>>a message 
>>>>>      
>>>>>
>>>>>>and is annotated with the createInstance attribute set to 
>"yes" to 
>>>>>>indicate that the occurrence of that activity causes a new 
>>>>>>        
>>>>>
>>>>>instance of 
>>>>>      
>>>>>
>>>>>>the process to be created. This restriction, however, is 
>>>>>>        
>>>>>
>>>>>relaxed for 
>>>>>      
>>>>>
>>>>>>BPEL abstract processes describing the publicly visible 
>>>>>>        
>>>>
>>>>behavior of 
>>>>    
>>>>
>>>>>>services executable processes implement since they do not 
>>>>>>        
>>>>>
>>>>>reveal the 
>>>>>      
>>>>>
>>>>>>internal implementation. For example, how the process is 
>>>>>>        
>>>>>
>>>>>started could 
>>>>>      
>>>>>
>>>>>>be an implementation detail and does not have to be 
>>>>>>        
>>>>
>>>>included in the 
>>>>    
>>>>
>>>>>>description of the publicly visible behavior. Any basic activity, 
>>>>>>except activities <reply> and <exit>, may appear at the 
>>>>>>        
>>>>>
>>>>>beginning of a 
>>>>>      
>>>>>
>>>>>>BPEL abstract process. Please note that the <exit> activity 
>>>>>>        
>>>>>
>>>>>is limited 
>>>>>      
>>>>>
>>>>>>to executable processes, and a <reply> activity must always be 
>>>>>>preceded by a <receive> activity. Therefore these two 
>>>>>>        
>>>>>
>>>>>activities are 
>>>>>      
>>>>>
>>>>>>explicitly excluded.
>>>>>>
>>>>>><<end>>
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Ivana
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>        
>>>>>
>>>>>-----------------------------------------------------------
>----------
>>>>>      
>>>>>
>>>>>>To unsubscribe from this mail list, you must leave the 
>>>>>>        
>>>>>
>>>>>OASIS TC that 
>>>>>      
>>>>>
>>>>>>generates this mail.  You may a link to this group and all 
>>>>>>        
>>>>>
>>>>>your TCs in 
>>>>>      
>>>>>
>>>>>>OASIS
>>>>>>at:
>>>>>>
>>>>>>        
>>>>>
>>>>>https://www.oasis->
>>>>>      
>>>>
>>>>open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>    
>>>>
>>>>>-----------------------------------------------------------
>----------
>>>>>To unsubscribe from this mail list, you must leave the OASIS 
>>>>>TC that generates this mail.  You may a link to this group 
>>>>>and all your TCs in OASIS
>>>>>at: 
>>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>>>>>      
>>>>
>>>>oups.php 
>>>>
>>>>
>>>>    
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail.  You may a link to this group and all 
>your TCs in OASIS
>>>at:
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workg
>roups.php 
>>>
>>>
>>>  
>> 
>>     
>---------------------------------------------------------------
>------ To
>>     unsubscribe from this mail list, you must leave the 
>OASIS TC that generates
>>     this mail. You may a link to this group and all your TCs 
>in OASIS at:
>>     
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>


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