ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Kopp" <oliver.k...@iaas.uni-stuttgart.de>
Subject Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Date Tue, 27 Nov 2007 21:49:43 GMT
Hi,

> // 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)

Why not being much more extreme in being not consistent?

var = receive(partnerLink, op)
var = partnerLink.op(inVar)

In our approach, I was not that confident about the empty parameter at the
receive, since the "method" is not called at all, but called by the partner
service. Therefore, I like "receive(partnerLink, op)".

An "invoke" really calls a method at the partner service. Therefore,
"partnerLink.op()" reads fine for me.

> // 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)

This reads IMHO as original BPEL.

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

I think, consistency with onEvent is not a high priority. "receive" itself
should be readable.  O:)

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

After thinking about the insistency, I like following:

var = partnerlink.myRole.op()
var = partnerlink.partnerRole.op(inVar)

or shorter

var = partnerlink.self.op()        // maybe ".me." ?
var = partnerlink.partner.op(inVar)


Con:
 * Receive is a method invocation
 * Not consistent with event
Pro:
 * Nice partnerlink.op syntax
 * No ambiguity
 * No inconsitency between receive/invoke
 * Role distinction in parterLink reflected


> Maybe we can find 
> something prettier than incorrelate and outcorrelate but on 
> principles I think it could work.

var = parterlink.me.op(corr => cset1)
var = partnerlink.partner.op(setCorr => cset2, corr => cset1)

"setCorr", because the value of the correlation set is set (and checked if
it is set).
"corr" for "incoming" correlation. (even if an unset correlation set is set)

But we're still not satisfied with that...

Greetings,

Oliver


Mime
View raw message