[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 99 - New issueTriggering activities for abst ract processes
Satish,
Indeed, I was more "conservative". I also tried to eliminate things that do not add any value to the abstract process definition ("business protocol"); for example an <empty> activity or a <wait> activity at the beginning of an abstract process. I agree that activity <assign> should not be excluded (since it is allowed for abstract processes). I also agree that we should only ban things that semantically do not make sense; otherwise we have to do that consistently for all features/elements.
Regards,
Ivana
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Samstag, 6. März 2004 08:08
> To: Danny van der Rijn; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 99 - New issueTriggering activities for
> abst ract processes
>
>
> 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/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/le
> ave_workgroup.php.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]