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
