[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]