[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 44 - Summary so far.
+1 > -----Original Message----- > From: Marin, Mike [mailto:MMarin@filenet.com] > Sent: Tuesday, August 19, 2003 12:11 PM > To: firstname.lastname@example.org; email@example.com > Subject: RE: [wsbpel] Issue 44 - Summary so far. > > > > 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:firstname.lastname@example.org] > Sent: Tuesday, August 19, 2003 11:55 AM > To: Marin, Mike; email@example.com > 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: firstname.lastname@example.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: email@example.com > > For additional commands, e-mail: firstname.lastname@example.org > > > > > >