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>
>
>
>
