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


+1

Yaron Y. Goland wrote:

> My understanding of the purpose of the 'external behavior' profile is 
> to describe all actions that a process will undertake that can be 
> viewed externally to the process. The goal being to describe the order 
> in which a process expects to send and receive messages. A key part of 
> describing such a sequence is knowing when the sequence ends. Without 
> the use of the <exit> activity it is significantly more difficult to 
> describe end states, especially ones that represent an exception to 
> the 'expected' execution path.
>
>     Yaron
>
> andrew.francis@mail.mcgill.ca wrote:
>
>> Quoting "Yaron Y. Goland" <ygoland@bea.com>:
>>
>>  > 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.
>>
>> I believe the only BPEL activities that constitute a
>> process's visible behaviour are invoke, receive, and
>> reply. These activities, or more specifically, their
>> associated partnerlinks, messages, and operations, are
>> exposed to an external observer. I believe that
>> all other activities are internal.
>>
>> I believe a step forward would be for the base profile" to
>> state which activities are "visible" and "internal."
>>
>> Cheers,
>> Andrew
>>
>>
>>
>> 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_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>>
>>  >
>>  >
>>  > 
>> ---------------------------------------------------------------------> 
>> 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]