RE: [wsbpel] Issue - 99 - New issueTriggering activities for abst ract processes

["Satish Thatte" <satisht@microsoft.com>]

But why exclude assign?  Or for that matter any of the basic activities?  The best thing is to just say "you don't need a start activity for an abstract process" and let the author of the process do what makes sense to them.  If they want to wait at the start then that may not make sense to us but why bother to ban it?  Ban things only when they create semantic nonsense -- for instance reply at the beginning.  But banning reply separately is not needed since we already say in 11.4 that 
 
"Moreover, a reply activity must always be preceded by a receive activity for the same partner link, portType and (request/response) operation, such that no reply has been sent for that receive activity. The semantics of a process in which this constraint is violated is undefined."

________________________________

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Thu 3/4/2004 9:24 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 99 - New issueTriggering activities for abst ract processes



yes, that helps me a lot.  thanks.

----- Original Message -----
From: "Trickovic, Ivana" <ivana.trickovic@sap.com>
To: <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org>
Sent: Thursday, March 04, 2004 6:50 AM
Subject: RE: [wsbpel] Issue - 99 - New issueTriggering activities for abst
ract processes


Danny,

The idea is to allow any activity to be used at the beginning of a BPEL
abstract process. What does it mean "any activity"? Syntactically a bpel
process (either executable or abstract) includes exactly one activity; for a
complex control flow the <process> element must encompass a complex
activity, such as <sequence>, <flow>, etc. Therefore, "any activity" really
refers to "basic" activities (<empty>, <invoke>, <receive>, <reply>,
<assign>, <wait> and <terminate>). For abstract processes some of these
activities at the beginning of the process do not make sense. From my point
of view the following activities do not make sense: <empty>, <reply>,
<assign> and <wait>. Activity <terminate> is only available in executable
processes. The two remaining activities are <invoke> and <receive>. So, the
proposal is to allow activities <receive> AND <invoke> to be used at the
beginning of abstract processes.

I hope this short clarification helps.

Regards,

Ivana

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Mittwoch, 3. März 2004 18:51
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 99 - New issueTriggering activities for
> abstract processes
>
>
> the problem description makes perfect sense to me, but i
> don't understand
> the proposal.  can you elaborate further?
>
> ----- Original Message -----
>
> Description: The current version (BPEL4WS v1.1, May 2003)
> specifies that
> each process (either executable or abstract) must contain at least one
> "start activity" (start activity is either a receive activity
> or a 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 makes less sense for BPEL abstract
> processes. Because of
> this restriction, the abstract process of the party that
> initiates a message
> exchange must be extended and a start activity must be
> introduced (also
> additional WSDL elements, such as port types, messages, must
> be defined as
> well as partner link type). But how the initiating process is
> started is an
> implementation detail and does not have to be included in the
> BPEL abstract
> process since it is not part of the "business protocol".
>
> Submitter's proposal: Allow the invoke activity to be used as
> the start
> activity for abstract processes.
> Changes: 3 Mar 2004 - new issue
>
>
>
> --------------------------------------------------------------
> --------------
> ----
>
> To comment on this issue, please follow-up to this announcement on the
> wsbpel@lists.oasis-open.org list (replying to this message should
> automatically send your message to that list), or ensure the
> subject line as
> you send it starts "Issue - 99 - [anything]" or is a reply to such a
> message.
>
> To add a new issue, see the issues procedures document (but
> the address for
> new issue submission is the sender of this announcement).
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.