ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tammo van Lessen" <tvanles...@gmail.com>
Subject Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Date Wed, 21 Nov 2007 10:08:47 GMT
Hi all,

> So any opinion on both proposals? What are the parts that you like better?
> Tammo, did you have a look at AAM?

I finally got the time to look at your simbpel proposal. Sorry for the delay...

Great work! And interestingly both proposals are indeed very similar
;) I'm perfectly happy with merging the best concepts of both and
since AAM is way more complete, its probably the best starting point.

Anyhow, I have a few comments/questions:

 o receive/invoke: For dealing with partnerLinks I'm more in favour of
our approach. I think indicating whether its a receive or invoke is
not explicitly necessary, instead it can be derived from it's usage
context. E.g.,:
   partner.test(x); // invokes operation "test" on partnerLink
"partner" with inputVariable x
   y = partner.test(x); // invokes operation "test" on partnerLink
"partner" with inputVariable "x" and outputVariable "y"
   y = partner.test(); // a receive activity on operation "test" on
partnerLink "partner" with outputVariable "y"
This is in my opinion more intuitive at the same level of expressivity.

 o How do you identify the role of a partnerLinkTypes in partnerLinks?

 o Links: Great idea. Shouldn't the join method support more than one
link? I'd just drop the "link" parameter and would allow accessing
links directly in the expression language (like in BPEL). Then its
possible to synchronize more than one blocks. Or did I get something
wrong?

In general I'm a bit confused about which one of the approaches for
links is more intuitive. The signal/join stuff is IMHO more the
hackers approach (QT coders will love it), the other one is more
declarative, although I'm not sure whether it better w.r.t to
readability... What about considering both and letting the users
decide?

Cheers,
  Tammo

-- 
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de

Mime
View raw message