|
That's a fine point. I guess I consider constraints
imposed on message exchanges by the control flow activities to be externally
visible. So to the extent to which "exit" serves to control message exchanges,
it seems externally visible, but the actual termination of a process instance
seems to me to be private. I admit that I'm not sure how tenable that
distinction is.
- Jim Clune
----- Original Message -----
Sent: Friday, May 20, 2005 11:33 AM
Subject: Re: [wsbpel] Issue 99 - Updated
proposal for vote
All of our current control-flow activities (flow, sequence,
pick, etc.) are legal and expected in this profile. Are you suggesting
that none of these should be in the 'external behavior' profile
either?
Jim Clune wrote:
I think the externally visible aspect of a message exchange ends (by
definition) when messages are no longer being exchanged. The "exit" activity
seems to refer to a private aspect of the process's life-cycle, as there
does not seem to be a message exchange directly associated with this
activity. It seems to me that the rule of thumb should be that any activity
that does not directly involve message exchanges should not be considered
externally visible.
- Jim Clune
----- Original Message -----
From: "Yaron Y. Goland" <ygoland@bea.com>
To: <andrew.francis@mail.mcgill.ca>
Cc: <ivana.trickovic@sap.com>; <dannyv@tibco.com>;
<wsbpel@lists.oasis-open.org>
Sent: Friday, May 20, 2005 10:43 AM
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>
---------------------------------------------------------------------
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
|