OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: =?utf-8?Q?Issue_44_=E2=80=93_Summary_so_far=E2=80=A6?=



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
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]