Actually, my impression about the scope of the issues are:
- Issue 99 is about the "base version" of abstract process.
- 82.2 subissue to track the details of AP 1.1 profile ?
Regards,
Alex Yiu
Danny van der Rijn wrote:
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
|