Nick,
Suppose the actual instantiation of a
conformant executable process is meant to occur using a partnerLink that is not
visible in the abstract process, why is it necessary to show any activity, opaque
or otherwise, for instantiation in that abstract process? This could be
made more specific in the export pattern where the starting executable process
has such an instantiation activity but the export projects behavior along an
externally facing partnerLink that is not involved in instantiation.
Satish
From: Nickolas
Kavantzas [mailto:nickolas.kavantzas@oracle.com]
Sent: Friday, August 27, 2004 10:23 AM
To: Trickovic, Ivana;
wsbpel-abstract@lists.oasis-open.org
Cc: 'Monica J. Martin'; Satish Thatte; Rania Khalaf
Subject: Re: [wsbpel-abstract] RE:
My Abstract & Executable BPEL ProcessesUnified note [was Re:
[wsbpel-abstract] Strawman for discussion]
Copying text from my emails to you for the benefit of the others:
Looking
at issue 99, this is about changing the operational semantics of BPEL
processes, so one does not have to specify a lifecycle activity, if desired, at
the beginning of an Abs process.
Now
repeating from my note:
An
Abstract process is a partially specified Executable process, missing
operational details that are required to be concretized when/if mapping the partial specification
to a fully executable program.
Examples of the missing operational details of an Abstract process are:
· Expressions- as used in assign,
switch
· Attributes- as used in receive
for input variables
· One or more Activities- as used
for hiding the lifecycle (receive-start/terminate)
activities, other activities or
sub-processes (a set of two or more activities)
Opaque
placeholders are explicit designators used by a process designer for specifying
the points where the missing operational details are required to be
concretized, when/if mapping a partial specification to a fully executable
program.
So, opq
activity gives you the semantic mechanism to describe the missing operational
details, thus resolving issue 99. I am not sure though how the implicit
omission of details would do that.
IMHO, I
think we must answer a more general question first:
Should/Could
we trace the execution of an AbsProcess?
If yes what are the rules that prescribe the possible traces? Also, are these
rules different from the rules used for tracing the execution of an
ExecProcess?
--
Nick
"Trickovic,
Ivana" wrote:
Monica,
My
statement refers to issue 99 exclusively.
Regards,
Ivana
>
-----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Freitag, 27. August 2004 17:01
> To: Trickovic, Ivana
> Cc: 'Nickolas Kavantzas'; wsbpel-abstract@lists.oasis-open.org; Satish
> Thatte; Rania Khalaf
> Subject: Re: [wsbpel-abstract] RE: My Abstract & Executable BPEL
> Processes Unified note [was Re: [wsbpel-abstract] Strawman for
> discussion]
>
>
>
> > Trikovic: Regarding issue 99: Abstract processes cannot be
> > instantiated and executed - therefore "lifecycle"
activities play
> > little or no role for abstract processes. Also the BPEL
> specification
> > is saying that BPEL executable processes must contain at least one
> > "start activity". So opaque activity is not really
> necessary in this
> > case (issue 99) - the specification is clear about places
> which need
> > to be further specified (or concretised) when mapping an abstract
> > process to an executable process.
> >
> mm1: Is it not true that the abstract subgroup was formed to fully
> understand what the abstract process was and also provide more
> information to determine _if_ the specification is clear about places
> which need to be further specified (or concretised) when mapping an
> abstract process to an executable process? Establishing the scope and
> use of the abstract process may result in changes to the
> assumptions in
> the existing specification, correct? Thank you.
>
>