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


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]