Hi, > > o receive/invoke: For dealing with partnerLinks I'm more > > in favour of our approach. [...] > It is, but there's a lot of potential for ambiguity, at least > two cases I can think of: the operation has no relevant input > so you want to invoke it without a variable; when we need to > pass correlation information to the operation, and those can > be used on both receive and invoke.
We think, the ordering of the constructs should match their importance: partnerlink, operation, parameters, correlation. The type is given by the usage. :) Therefore, we think partnerlink.op(param_1, ..., param_n, incorrelate => correlationset), partnerlink.op(param_1, ..., param_n, outcorrelate => correlationset) and partnerlink.op(param_1, ..., param_n, incorrelate => correlationset_1, outcorrelate => correlationset_2) matches that ordering. For receives, we propose: partnerlink.op(correlate => correlationset) We use a variant of the VBA/ADA approach for named parameters and use their syntax for the correlation. correlate could be named "correlate on", ... The only ambiguity our approach IMHO has, is with operations having the same name. x = partnerlink.op() can be interpreted as: a) Synchronous invoke without parameters b) receive (both without any correlation) Since a) is only allowed in abstract BPEL processes and we are targetting executable processes, this should not be an issue. Or did we miss something? On the other hand, I see the point that operations of two different portTypes get mixed with the partnerlink-Prefix (instead of portType as firstly proposed). - That's the downside if we want to use partnerlinks in the process. > Separately, there's the issue of pick and onEvent, and > although we can come up with a nicer syntax specifically for > receive, I think it will help a lot if receive and onEvent > end up looking the same way. receive and onEvent-branches look differently in BPEL, too: The former does not contain any nested activties. Thus, a difference in BPEL4Cords is argueable :) Hope, we didn't miss something. Greetings, Oliver
