+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
>
> wrote:
>
>> Quoting "Yaron Y. Goland" <>:
>>
>> > 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:]
>>
>> >> *Sent:* Wednesday, May 11, 2005 1:23 PM
>> >> *To:*
>> >> *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:]
>> >>>>Sent: Tuesday, May 10, 2005 11:11 PM
>> >>>>To: ; Trickovic, Ivana
>> >>>>Cc:
>> >>>>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:]
>> >>>>>Sent: 10 May 2005 21:09
>> >>>>>To: Trickovic, Ivana
>> >>>>>Cc:
>> >>>>>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>
>>
>>
>>
>
>
