ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Date Tue, 27 Nov 2007 18:54:50 GMT
On Nov 26, 2007 4:47 AM, Oliver Kopp <oliver.kopp@iaas.uni-stuttgart.de>

> 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", ...

Yep, I have no problem with the notation. Maybe we can find something
prettier than incorrelate and outcorrelate but on principles I think it
could work.

> 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?

Actually a) is the case we're most worried about and I'm pretty sure you can
have an invoke with no inputVariable with executable processes as well. From
the 2.0 spec, in the "Invoking web service operations" section:

"If a WSDL message definition does not contain any parts, then the
associated attributes, inputVariable or outputVariable, MAY be omitted,
[SA00047] and the <fromParts> or <toParts> construct MUST be omitted."

I've seen such processes in the wild and I've actually fixed a bug in ODE
where we would throw a nasty NPE for invokes with no inputVariable. So even
if it's definitely not the common case it's a valid use case and I'd be
worried about ruling it out already at the grammar level.

We've hesitated a lot for the invoke/receive syntax, changing it almost
every time we talked about it :) We've been through (regardless of

// Not so nice because invoke and receive are not consistent but keeps a
simple syntax for invoke and no ambiguity for empty invokes
var = partnerLink.receive(op)
var = partnerLink.op(inVar)

// More consistent with each other but we lose the simple partnerLink.opsyntax
var = partnerLink.receive(op)
var = partnerLink.invoke(op, inVar)

// Most simple syntax but less appealing as the partner link becomes a
"second class" citizen
var = receive(partnerLink, operation)
var = invoke(partnerLink, operation, inVar)

We ended up liking the last one most because as Assaf mentioned it's
consistent with onEvent (whether it's necessary is definitely arguable but
if possible that's always nice to have) and is still very simple. Although I
have to say I personally still kind of like the second one better :)

So what do you think?


> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message