RE: [wsbpel] Issue 44 - Summary so far.

["Marin, Mike" <MMarin@filenet.com>]

To keep things clean, I will remove proposal two from issue 44, and let
keep issue 52 for calling yourself. That way there is only one proposal
for issue 44 as follows:

Issue 44 - Proposal: Just remove the portType from the invoke activity
and use the portType that corresponds to the partnerRole in the
partnerLink. This covers most if not all the use cases. With the only
exception of a process that wants to call itself, which is discussed by
issue 52.

--
Regards,
Mike Marin

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, August 19, 2003 11:55 AM
To: Marin, Mike; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 44 - Summary so far.

Hum... maybe I shouldn't have created Issue 52 and instead should have
kept it part of Issue 44? I thought Issue 44 would just address the
issue of removing the portType and that issue 52 would address how to
deal with calling yourself. Because, given your summary below, clearly
52 (http://lists.oasis-open.org/archives/wsbpel/200308/msg00158.html)
should be a 3rd option.

> -----Original Message-----
> From: Marin, Mike [mailto:MMarin@filenet.com]
> Sent: Monday, August 18, 2003 5:40 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue 44 - Summary so far...
>
>
>
> This issue deals with the fact that in the current syntax the Invoke
> activity requires a partnerLink and a portType. However the
> partnerLink
> refers to a partnerLinkType, which also includes the
> portType. Therefore
> the portType in the Invoke is redundant. So far, there is no
> disagreement on this analysis.
> 
> There are two possible solutions (or proposals):
> 
> 1- (proposal 1): Just remove the portType from the invoke activity and
> use the portType that corresponds to the partnerRole in the
> partnerLink.
> This covers most if not all the use cases. With the only
> exception of a
> process that wants to call itself, in which case you will
> need to create
> another partnerLink (using the same partnerLinkType) and use
> it instead.
> So, in this case you end with two partner links.
> 
> 2- (proposal 2): Remove the portType from the invoke activity, but add
> an optional role. When the role is specified, it must
> correspond to one
> of the two roles defined in the partnerLink. If the role is not
> specified the partnerRole in the partnerLink should be assumed.
> 
> With this second proposal, in most cases the syntax will look exactly
> the same as with the first proposal. But, if a process needs to call
> itself, instead of adding a partner link, it just adds a role to the
> invoke activity.
> 
> Both solutions are similar and better than the current
> syntax. The only
> real difference is the optional role on the invoke activity
> to preserve
> the functionality currently specified, but that seems to be uncommon.
> 
> Regards,
> Mike Marin
> 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>