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


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_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_workgroups.php


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