You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Matthieu Riou <ma...@offthelip.org> on 2007/11/05 21:45:47 UTC
Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Hi all,
So we now have 2 proposals for our easier BPEL language specification in the
wiki. Both of them are partial although the intersection covers most of what
needs to be covered I believe:
http://cwiki.apache.org/confluence/display/ODExSITE/BPEL+Simplified+Syntax+%28simBPEL%29
Don't see any conflicting views in the fact that there are 2 proposals, it's
just that those stuff are better thought out f2f and it was fairly easy for
myself, assaf and alex to work on it on one side and Tammo and Oliver on the
other side. Actually the two proposals are surprisingly similar, especially
in their Javascript influences and complement each other nicely. Great minds
think alike.
So now what we should do I think is try to reconcile these 2 proposals so we
can start formalizing a grammar (I actually already have a partial one that
will be fairly easy to tweak to adjust to our choices). The main difference
I see is that in the second proposal (assaf/alex/myself, I'll call it AAM
now on) we've tried to let go of WSDL for environments where it wasn't
necessary. Basically when you're using a Java process engine directly
embedded in your program, you don't really need WSDL, just a callback
interface (and then endpoints, being opaque to the engine, can be implicit).
So there's no declaration of services in AAM and we stick with partner links
(that would then be associated with a service in a deployment descriptor
only when needed). On the other end the first proposal (tammo/oliver, I'll
call it TO now on) is more explicit with service specifications in the
process and also with variable declarations.
Beside this, several things are almost identical. The syntax for invoke /
receive is similar, scope definitions have a lot in common (although AAM
separates error handling and event handling), flow and sequences are
identical (just par vs. flow and seq vs. sequence)
Also in AAM there's nothing about scope links as TO had specified it before
we started thinking of it and we actually liked it (it's actually the
biggest part of TO). Similarly there are a few stuff in AAM that aren't in
TO but that would make sense there as well.
So any opinion on both proposals? What are the parts that you like better?
Tammo, did you have a look at AAM?
Thanks!
Matthieu
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Matthieu Riou <ma...@offthelip.org>.
On Nov 6, 2007 8:52 PM, Dan Kearns <da...@gmail.com> wrote:
> On 11/6/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> Dan, of course you may use JavaScript or Java or whatever to express
> > BPs, but then BP's root-concepts like scopes and concurrency must be
> > based on native language concepts like threads and transaction
> > managers and are neither easy to read nor first-class citizens anymore
> > - which is at least for me the key of such a DSL.
>
>
> That's not the case at all. Calling it a dsl means you are decoupling the
> syntax from the original platform, implementation and constraints.
>
> The question when reusing an existing syntax is how much the resulting
> behavior matches the author's expectations, ie how much learning curve did
> it cut out (vs how much irritation did it add by not being the language it
> resembles).
>
Actually we've been pretty careful at not introducing semantic conflicts
with some Javascript syntax. The thing has a Javascript feeling just to give
a sense of familiarity and be nice to our eyes used to parse
C/C++/Java/Javascript types of syntaxes. But I don't think there's any
chance of somebody looking at a SimPEL program and mistaking it for
Javascript, as a whole it's very different and we certainly won't advocate
it as being Javascript for processes.
>
> > For the AAM proposal, we have no intent of bringing process engines to
> > > JavaScript, but bringing a simpler syntaxt to the process engine, and
> we
> > > just think JavaScript is a good starting point for that.
>
>
> That's fine. I don't want to flog the javascript thing to death, and this
> thread is probably now a good enough example of the danger of making the
> dsl
> *look* like javascript. ;-)
>
Again it derives some syntax elements from Javascript in the same way that
Java derived its syntax from C++. But I don't think there's any chance of
mistaking one for the other, especially with something that starts with
"process foo { ... }". But if you see some constructs that look confusing,
you're more than welcome to point them out and suggest improvements.
Cheers,
Matthieu
>
> -d
>
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Dan Kearns <da...@gmail.com>.
On 11/6/07, Tammo van Lessen <tv...@gmail.com> wrote:
Dan, of course you may use JavaScript or Java or whatever to express
> BPs, but then BP's root-concepts like scopes and concurrency must be
> based on native language concepts like threads and transaction
> managers and are neither easy to read nor first-class citizens anymore
> - which is at least for me the key of such a DSL.
That's not the case at all. Calling it a dsl means you are decoupling the
syntax from the original platform, implementation and constraints.
The question when reusing an existing syntax is how much the resulting
behavior matches the author's expectations, ie how much learning curve did
it cut out (vs how much irritation did it add by not being the language it
resembles).
> For the AAM proposal, we have no intent of bringing process engines to
> > JavaScript, but bringing a simpler syntaxt to the process engine, and we
> > just think JavaScript is a good starting point for that.
That's fine. I don't want to flog the javascript thing to death, and this
thread is probably now a good enough example of the danger of making the dsl
*look* like javascript. ;-)
-d
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
On 06/11/2007, Assaf Arkin <ar...@intalio.com> wrote:
> On 11/6/07, Dan Kearns <da...@thekearns.org> wrote:
> > Maybe I unintentionally implied the whole system would be javascript? I
> > meant just the specification of the process the author would supply.
> >
> > It is possible to write a jacob-like cpu-slicer purely in javascript, and
> > maybe even do out-of-memory persistence in a gears/air type of runtime, but
> > I would assume we want to start on the server-side and use the java Ode
> > implementation. The obvious parallel is how existing javascript programmers
> > use XmlHttpRequest, where they are already trained on passing callbacks and
> > writing event handlers. Check out Prototype's Ajax.Request for an example
> > - the way it is written, serializing the whole context for retries or
> > whatever else is pretty easy.
> >
>
> For the AAM proposal, we have no intent of bringing process engines to
> JavaScript, but bringing a simpler syntaxt to the process engine, and we
> just think JavaScript is a good starting point for that.
I'd like to second that, this also applies for the IAAS approach: a
simplified syntax and readability are the most important motivators.
The result should be a DSL for describing service orchestrations (with
or without Web-*). When using plain javascript, you're again bound on
a specific syntax which has not been built for modeling business
processes. In addition, hacking JavaScript and modeling business
processes (BPs) is inherently different. BPEL is a parallel
programming language with support for long-running transactions,
correlation, defined timing contraints, all that is stuff that is not
in javascript, or at least stuff that Javascript has not been designed
for. I think using JavaScript's easy-to-read syntax as a starting
point or an inspiration for a new (but BPEL-oriented) DSL is a very
good idea. However, the closer our DSL is to JavaScript the more we
seduce JavaScript hackers to think they could write business processes
in JS without knowing the concepts of (W)S-orchestration.
That's why I think DSL and JavaScript should be similar in terms of
readability and self-explanatory but should not be the same because
BPs are somehow different.
Dan, of course you may use JavaScript or Java or whatever to express
BPs, but then BP's root-concepts like scopes and concurrency must be
based on native language concepts like threads and transaction
managers and are neither easy to read nor first-class citizens anymore
- which is at least for me the key of such a DSL.
Cheers,
Tammo
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/6/07, Dan Kearns <da...@thekearns.org> wrote:
>
>
>
> On 11/6/07, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > On 11/6/07, Dan Kearns <da...@gmail.com> wrote:
> > >
> > >
> > > Is there any reason not to attempt to have a process just be a totally
> > > valid
> > > javascript?
> >
> >
> > Because JavaScript the language doesn't have the notion of 'store where
> > you are, come back later'. If you write this in JavaScript:
> >
> > plink1.send(msg1);
> > msg2 = plink2.receive();
> > plink1.send(msg2);
> >
> > the semantics are that of a method call that blocks until the message
> > arrives
> >
>
> Maybe I unintentionally implied the whole system would be javascript? I
> meant just the specification of the process the author would supply.
>
> It is possible to write a jacob-like cpu-slicer purely in javascript, and
> maybe even do out-of-memory persistence in a gears/air type of runtime, but
> I would assume we want to start on the server-side and use the java Ode
> implementation. The obvious parallel is how existing javascript programmers
> use XmlHttpRequest, where they are already trained on passing callbacks and
> writing event handlers. Check out Prototype's Ajax.Request for an example
> - the way it is written, serializing the whole context for retries or
> whatever else is pretty easy.
>
For the AAM proposal, we have no intent of bringing process engines to
JavaScript, but bringing a simpler syntaxt to the process engine, and we
just think JavaScript is a good starting point for that.
Specifically for JavaScript, you have to consider all the ways of using it.
For example, this piece of Rails code:
<% remote_form_for(@post) do |f| %>
...
<% end %>
This one is shorter and easier to understand than instantiating Ajax.Request,
serializing the form, adding a callback function to evaluate
transport.responseText, all within the onSubmit event handler of the form.
So by analogy, we're working closer to Rails helper than Ajax.Request.
The benefit of using json-style notation for the process is that the
> definition becomes serializable so you can swap it out and slap it around: a
> java+rhino implementation could use the Function.toString and eval (or the
> java api for compilation) to do persistence in both directions. Internally
> I'd assume the "script" would be analyzed by the engine to determine which
> stuff turns into bpel, which stuff stays as javascript, which stuff is just
> static config, etc.
>
> So instead of:
> msg2 = plink.receive();
>
> You'd do more like:
> plink.onReceive = function(partner, message) { ... some sequence or
> flow...; };
>
We start with that line of thinking, and tried it out with a couple of
languages. It looks reasonable enough for a statement or two, but
afterwards it violates the first principle of our proposal, which is to come
up with a syntax that makes it easy to read/write process definitions.
Here's a couple of examples. What you want to express:
{
plink1.send(msg1);
msg2 = plink2.receive();
plink2.send(msg2);
}
What it would look like in JavaScript:
function step2(msg2) {
plink1.send(msg2);
}
function step1(msg1) {
plink1.send(msg1);
plink2.onReceive = step2;
}
What you want to express:
{
foo = plink.receiver()
} until (msg.foo == 'foo')
What it would look like in JavaScript:
function receiveFoo(msg) {
if (msg.foo == 'foo')
nextStep();
else
onReceive = receiveFoo;
}
onReceive = receiveFoo;
Assaf
-d
>
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Dan Kearns <da...@thekearns.org>.
On 11/6/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> On 11/6/07, Dan Kearns <da...@gmail.com> wrote:
> >
> >
> > Is there any reason not to attempt to have a process just be a totally
> > valid
> > javascript?
>
>
> Because JavaScript the language doesn't have the notion of 'store where
> you are, come back later'. If you write this in JavaScript:
>
> plink1.send(msg1);
> msg2 = plink2.receive();
> plink1.send(msg2);
>
> the semantics are that of a method call that blocks until the message
> arrives
>
Maybe I unintentionally implied the whole system would be javascript? I
meant just the specification of the process the author would supply.
It is possible to write a jacob-like cpu-slicer purely in javascript, and
maybe even do out-of-memory persistence in a gears/air type of runtime, but
I would assume we want to start on the server-side and use the java Ode
implementation. The obvious parallel is how existing javascript programmers
use XmlHttpRequest, where they are already trained on passing callbacks and
writing event handlers. Check out Prototype's Ajax.Request for an example -
the way it is written, serializing the whole context for retries or whatever
else is pretty easy.
The benefit of using json-style notation for the process is that the
definition becomes serializable so you can swap it out and slap it around: a
java+rhino implementation could use the Function.toString and eval (or the
java api for compilation) to do persistence in both directions. Internally
I'd assume the "script" would be analyzed by the engine to determine which
stuff turns into bpel, which stuff stays as javascript, which stuff is just
static config, etc.
So instead of:
msg2 = plink.receive();
You'd do more like:
plink.onReceive = function(partner, message) { ... some sequence or flow...;
};
-d
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/6/07, Dan Kearns <da...@gmail.com> wrote:
>
>
> Is there any reason not to attempt to have a process just be a totally
> valid
> javascript?
Because JavaScript the language doesn't have the notion of 'store where you
are, come back later'. If you write this in JavaScript:
{
plink1.send(msg1);
msg2 = plink2.receive();
plink1.send(msg2);
}
the semantics are that of a method call that blocks until the message
arrives, which sounds good enough for the trivial case. If you have a lot of
these long-running processes waiting significant amount of time to receive
messages, you'll quickly run out of memory. If you crash, you lose all of
them.
So the alternative is either to come up with a complex framework for
structuring processes, the equivalent of programming against Jacob, which
just replaces one complexity with another, or come up with a syntax that can
handle these kinds of long-lived processes.
Assaf
Using e4x would save having to create new xml-isms, and the
> whole thing would also have the potential side-benefit that it could be
> implemented inside a browser. Imagine a google gears app with embedded
> Ode... that would rock!
>
> Plus, there could be the added irony of combining e4x with json. There
> could
> be a couple of preordained object-literal constructs, and a way to bless
> those things into actual processes, scopes, partners, etc. Some logic
> chunks
> normally handled in bpel might get delegated to javascript, but that
> doesn't
> seem like a big problem.
>
> Random syntax examples:
>
> default xml namespace = "urn:my:process";
> var scope = {
> Sequence: { ... }, // or Flow, etc
> onEvent: function(e) { ...},
> onFault: function(f) { ...}
> };
>
> With e4x, PortTypes and references could be literals if needed:
>
> var epr = <EndpointReference><Address>http://foo/bar
> </Address></EndpointReference>;
> var pt = new QName(x, y);
> var counter_pl = { PortType: pt , Epr: epr} ;
>
> Slight modification of one of the examples:
>
> var ExternalCounter = new Process({
> onReceive: function(my_pl, start_op, msg_in) {
> var resp = <root><count>0</count></root>;
> while(resp.root.count < 10) {
> invoke( {
> Link: counter_pl,
> Operation: partner_start_op,
> Message: <counter>{resp.root.count}</counter>,
> onReply: function(reply) { resp.root.count += reply.counter; }
> onFault: function(fault) { ... };
> } );
> }
> reply(resp);
> }
> });
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Matthieu Riou <ma...@offthelip.org>.
On Nov 6, 2007 10:53 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On 11/6/07, Paul Brown <pa...@gmail.com> wrote:
> >
> >
> > What's the target user experience for EzBPEL? IDE-like with syntax
> > highlighting and error reporting? It seems like we need something
> > along those lines to come out with a net win over XML Schema or RELAX
> > NG-driven editing of XML.
>
>
> Being able to pop up a text editor, write up a process deploy it, send the
> process to someone else, who can then read and understand what it does.
>
> BPEL uses all the glory of XML that makes it obfuscated for people to read
> or write. A variable declaration foo of type ns:bar is easy enough, until
> you need to fish for the in-context namespace declaration to figure out
> the
> QName, find the right import and the read the XML Schema definition to
> understand what the variable looks like. Understanding what operations
> look
> like from the WSDL, just as hard. There are other things made
> unnecessarily
> hard by the whole design of BPEL into something that fits into an XML
> structure.
>
> So the idea is not just to remove the angle brackets around element names,
> or replace them with curly brackets, but to make a language that's humand
> readable without dependency on tooling.
>
To complement on Assaf's point, the goal is readability but that doesn't
preclude syntax highlighting, error reporting and even debugging in an IDE.
It would actually be pretty nice to have it as an Eclipse plugin, I think
they have something that can take a grammar as input.
Cheers,
Matthieu
>
> Assaf
>
>
>
>
> -- Paul
> >
>
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Zubin Wadia <zw...@gmail.com>.
It's not necessarily EzBPEL, but Expressive BPEL :).
Cheers,
Z.
On 11/6/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> On 11/6/07, Paul Brown <pa...@gmail.com> wrote:
> >
> >
> > What's the target user experience for EzBPEL? IDE-like with syntax
> > highlighting and error reporting? It seems like we need something
> > along those lines to come out with a net win over XML Schema or RELAX
> > NG-driven editing of XML.
>
>
> Being able to pop up a text editor, write up a process deploy it, send the
> process to someone else, who can then read and understand what it does.
>
> BPEL uses all the glory of XML that makes it obfuscated for people to read
> or write. A variable declaration foo of type ns:bar is easy enough, until
> you need to fish for the in-context namespace declaration to figure out
> the
> QName, find the right import and the read the XML Schema definition to
> understand what the variable looks like. Understanding what operations
> look
> like from the WSDL, just as hard. There are other things made
> unnecessarily
> hard by the whole design of BPEL into something that fits into an XML
> structure.
>
> So the idea is not just to remove the angle brackets around element names,
> or replace them with curly brackets, but to make a language that's humand
> readable without dependency on tooling.
>
> Assaf
>
>
>
>
> -- Paul
> >
>
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/6/07, Paul Brown <pa...@gmail.com> wrote:
>
>
> What's the target user experience for EzBPEL? IDE-like with syntax
> highlighting and error reporting? It seems like we need something
> along those lines to come out with a net win over XML Schema or RELAX
> NG-driven editing of XML.
Being able to pop up a text editor, write up a process deploy it, send the
process to someone else, who can then read and understand what it does.
BPEL uses all the glory of XML that makes it obfuscated for people to read
or write. A variable declaration foo of type ns:bar is easy enough, until
you need to fish for the in-context namespace declaration to figure out the
QName, find the right import and the read the XML Schema definition to
understand what the variable looks like. Understanding what operations look
like from the WSDL, just as hard. There are other things made unnecessarily
hard by the whole design of BPEL into something that fits into an XML
structure.
So the idea is not just to remove the angle brackets around element names,
or replace them with curly brackets, but to make a language that's humand
readable without dependency on tooling.
Assaf
-- Paul
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Paul Brown <pa...@gmail.com>.
On Nov 6, 2007, at 9:17 AM, Dan Kearns wrote:
> Is there any reason not to attempt to have a process just be a
> totally valid
> javascript? Using e4x would save having to create new xml-isms, and
> the
> whole thing would also have the potential side-benefit that it
> could be
> implemented inside a browser. Imagine a google gears app with embedded
> Ode... that would rock!
Interesting thought, although the Ode core would still have to reside
in a Java container of some kind, but you certainly could implement a
worklist application entirely in JavaScript and use something like
Gears for the local persistence.
I do like the thought that there might be a way to encode a BPEL
process as "totally valid" JavaScript, since that would mean that
existing IDEs and editors would work just fine. FWIW, it's also
entirely worthwhile to consider DSLs that map to BPEL but not
necessarily bijectively or even surjectively. You can imagine, for
example, a language written specifically to implement Globus
applications.
What's the target user experience for EzBPEL? IDE-like with syntax
highlighting and error reporting? It seems like we need something
along those lines to come out with a net win over XML Schema or RELAX
NG-driven editing of XML.
-- Paul
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Dan Kearns <da...@gmail.com>.
On 11/5/07, Matthieu Riou <ma...@offthelip.org> wrote:
> So any opinion on both proposals? What are the parts that you like better?
> Tammo, did you have a look at AAM?
I think the almost-javascript aspect is going to be really confusing - where
can I put a javascript expression? where not?
Is there any reason not to attempt to have a process just be a totally valid
javascript? Using e4x would save having to create new xml-isms, and the
whole thing would also have the potential side-benefit that it could be
implemented inside a browser. Imagine a google gears app with embedded
Ode... that would rock!
Plus, there could be the added irony of combining e4x with json. There could
be a couple of preordained object-literal constructs, and a way to bless
those things into actual processes, scopes, partners, etc. Some logic chunks
normally handled in bpel might get delegated to javascript, but that doesn't
seem like a big problem.
Random syntax examples:
default xml namespace = "urn:my:process";
var scope = {
Sequence: { ... }, // or Flow, etc
onEvent: function(e) { ...},
onFault: function(f) { ...}
};
With e4x, PortTypes and references could be literals if needed:
var epr = <EndpointReference><Address>http://foo/bar
</Address></EndpointReference>;
var pt = new QName(x, y);
var counter_pl = { PortType: pt , Epr: epr} ;
Slight modification of one of the examples:
var ExternalCounter = new Process({
onReceive: function(my_pl, start_op, msg_in) {
var resp = <root><count>0</count></root>;
while(resp.root.count < 10) {
invoke( {
Link: counter_pl,
Operation: partner_start_op,
Message: <counter>{resp.root.count}</counter>,
onReply: function(reply) { resp.root.count += reply.counter; }
onFault: function(fault) { ... };
} );
}
reply(resp);
}
});
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/22/07, Tammo van Lessen <tv...@gmail.com> wrote:
> On 21/11/2007, Assaf Arkin <ar...@intalio.com> wrote:
> > On 11/21/07, Tammo van Lessen <tv...@gmail.com> wrote:
> > > 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?
> >
> > It should have the same binary expressions you can use to join against
> > multiple links, that's just an omission in the write up.
>
> Ok, so is then the signature similar to this (pseudocode)?
>
> join( {link1, link2, link3}, "$link1 and $link2")
Yep, and yes you do need to list the links separate from the condition
(which itself is optional).
Assaf
> Explicitly stating all the links is important to ensure that the join
> must synchronize all 3 links even the actual status of link3 is not
> important (but must be known).
>
> Cheers,
> Tammo
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Tammo van Lessen <tv...@gmail.com>.
On 21/11/2007, Assaf Arkin <ar...@intalio.com> wrote:
> On 11/21/07, Tammo van Lessen <tv...@gmail.com> wrote:
> > 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?
>
> It should have the same binary expressions you can use to join against
> multiple links, that's just an omission in the write up.
Ok, so is then the signature similar to this (pseudocode)?
join( {link1, link2, link3}, "$link1 and $link2")
Explicitly stating all the links is important to ensure that the join
must synchronize all 3 links even the actual status of link3 is not
important (but must be known).
Cheers,
Tammo
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: Partner Links in simBPEL
Posted by Tammo van Lessen <tv...@gmail.com>.
Matthieu Riou wrote:
...
> But (BPEL, WSDL) isn't self-contained. You can't do anything with it outside
> of abstract definitions.
>
> I think we don't agree here and won't go too far by trying to convince each
> other :)
;) The valley is definitely too far away, otherwise this topic would be
a good reason for having some beers.
> So what about trying to find some middle ground and make this
> additional definition optional? We're still at an early stage, maybe
> practice and writing more processes will prove either of us wrong.
>
> So what about something like this?
>
> partnerLink somePL {me: ns::MyPortType, you: ns::PartnerPortType}
Great! Bought ;)
Cheers,
Tammo
Re: Partner Links in simBPEL
Posted by Matthieu Riou <ma...@offthelip.org>.
On Dec 11, 2007 2:15 AM, Tammo van Lessen <tv...@gmail.com> wrote:
> Matthieu Riou wrote:
> > For the particular case of partnerLinkTypes, they don't need to be in
> > the SimPEL document but could be extracted from deployment
> > information that associates partner links with an endpoint or a
> > portType. So you would have something like SimPEL+deploy <-> BPEL. I
> > think it's not an unreasonable requirement and saves us the pain of
> > explain why we have an unnecessary abstraction sitting there for no
> > real purpose.
>
> I think the deployment descriptor is not necessarily the proper place as
> it should IMHO contain only deployment, i.e. EPR related, details. The
> tuple (BPEL/simBPEL, WSDL) should be somehow self-contained. In our
> understanding a partnerLink defined the contract between two parties, so
> this information also belongs the definition of a process. When moving
> this contract binding into deployment descriptors, you could bind
> partner interfaces to service implementations that do not follow the
> contract as intended by the modeller. Therefore its important to
> reference the portType to be used. So it can be put to partnerLink
> definitions or referenced directly together with the operation. Our
> preference is still to stick close to the BPEL spec, so we would opt for
> the partnerlink definition.
>
But (BPEL, WSDL) isn't self-contained. You can't do anything with it outside
of abstract definitions.
I think we don't agree here and won't go too far by trying to convince each
other :) So what about trying to find some middle ground and make this
additional definition optional? We're still at an early stage, maybe
practice and writing more processes will prove either of us wrong.
So what about something like this?
partnerLink somePL {me: ns::MyPortType, you: ns::PartnerPortType}
The colons might look a bit confusing but that's more in line with what
we've defined for correlation.
Cheers,
Matthieu
> Cheers,
> Tammo, Olly
>
>
>
Re: Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)
Posted by Assaf Arkin <ar...@intalio.com>.
Basically a partnerLinkType is an abstraction that names two related
portTypes, so you can then define two partnerLinks the represent each view (
i.e. roles reversed), and given two process definition somehow deduct (and
often be right) that they're related because they share a common
partnerLinkType.
But as far as execution is concerned, declaring a partnerLink directly
achieves the same thing.
Assaf
On 12/7/07, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Dec 7, 2007 9:03 AM, Oliver Kopp <ol...@iaas.uni-stuttgart.de>
> wrote:
>
> > Hi,
> >
> > > I question if we need to keep partnerLinkType alive?
> >
> > If we want to have a 1:1 relation of simBPEL to BPEL, then we really
> need
> > to
> > keep it.
> >
> > We think, it is good to have a more easy language, but this should be
> the
> > second step. First, there should be a bijective mapping between simBPEL
> > and
> > BPEL, so that one can freely choose the syntax one likes.
> >
> > We think that something like simBPEL+ should be born afterwards. There,
> > language extensions such as your security context and anonymous partner
> > links could be brought in. Then, the simple syntax is clearly
> > distinguished
> > from the extensions of BPEL.
> >
>
> I sympathize with the intent but don't agree that compatibility should be
> achieved at *all* cost. Although we should be able to reach a reasonable
> degree of compatibility between the formats. For the particular case of
> partnerLinkTypes, they don't need to be in the SimPEL document but could
> be
> extracted from deployment information that associates partner links with
> an
> endpoint or a portType. So you would have something like SimPEL+deploy <->
> BPEL. I think it's not an unreasonable requirement and saves us the pain
> of
> explain why we have an unnecessary abstraction sitting there for no real
> purpose.
>
> Cheers,
> Matthieu
>
>
> >
> > > It's a modeling artifact, but if we're not aiming for modeling,
> > > do we need the extra indirection?
> >
> > Isn't the introduction of anonymous partner links a new kind of
> modeling?
> > In
> > that case, the modeler has not to think about the concrete partner
> links.
> >
> > Cheers,
> > Olly, Tammo
> >
> >
>
Re: Partner Links in simBPEL
Posted by Tammo van Lessen <tv...@gmail.com>.
Matthieu Riou wrote:
> For the particular case of partnerLinkTypes, they don't need to be in
> the SimPEL document but could be extracted from deployment
> information that associates partner links with an endpoint or a
> portType. So you would have something like SimPEL+deploy <-> BPEL. I
> think it's not an unreasonable requirement and saves us the pain of
> explain why we have an unnecessary abstraction sitting there for no
> real purpose.
I think the deployment descriptor is not necessarily the proper place as
it should IMHO contain only deployment, i.e. EPR related, details. The
tuple (BPEL/simBPEL, WSDL) should be somehow self-contained. In our
understanding a partnerLink defined the contract between two parties, so
this information also belongs the definition of a process. When moving
this contract binding into deployment descriptors, you could bind
partner interfaces to service implementations that do not follow the
contract as intended by the modeller. Therefore its important to
reference the portType to be used. So it can be put to partnerLink
definitions or referenced directly together with the operation. Our
preference is still to stick close to the BPEL spec, so we would opt for
the partnerlink definition.
Cheers,
Tammo, Olly
Re: Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)
Posted by Matthieu Riou <ma...@offthelip.org>.
On Dec 7, 2007 9:03 AM, Oliver Kopp <ol...@iaas.uni-stuttgart.de>
wrote:
> Hi,
>
> > I question if we need to keep partnerLinkType alive?
>
> If we want to have a 1:1 relation of simBPEL to BPEL, then we really need
> to
> keep it.
>
> We think, it is good to have a more easy language, but this should be the
> second step. First, there should be a bijective mapping between simBPEL
> and
> BPEL, so that one can freely choose the syntax one likes.
>
> We think that something like simBPEL+ should be born afterwards. There,
> language extensions such as your security context and anonymous partner
> links could be brought in. Then, the simple syntax is clearly
> distinguished
> from the extensions of BPEL.
>
I sympathize with the intent but don't agree that compatibility should be
achieved at *all* cost. Although we should be able to reach a reasonable
degree of compatibility between the formats. For the particular case of
partnerLinkTypes, they don't need to be in the SimPEL document but could be
extracted from deployment information that associates partner links with an
endpoint or a portType. So you would have something like SimPEL+deploy <->
BPEL. I think it's not an unreasonable requirement and saves us the pain of
explain why we have an unnecessary abstraction sitting there for no real
purpose.
Cheers,
Matthieu
>
> > It's a modeling artifact, but if we're not aiming for modeling,
> > do we need the extra indirection?
>
> Isn't the introduction of anonymous partner links a new kind of modeling?
> In
> that case, the modeler has not to think about the concrete partner links.
>
> Cheers,
> Olly, Tammo
>
>
Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)
Posted by Oliver Kopp <ol...@iaas.uni-stuttgart.de>.
Hi,
> I question if we need to keep partnerLinkType alive?
If we want to have a 1:1 relation of simBPEL to BPEL, then we really need to
keep it.
We think, it is good to have a more easy language, but this should be the
second step. First, there should be a bijective mapping between simBPEL and
BPEL, so that one can freely choose the syntax one likes.
We think that something like simBPEL+ should be born afterwards. There,
language extensions such as your security context and anonymous partner
links could be brought in. Then, the simple syntax is clearly distinguished
from the extensions of BPEL.
> It's a modeling artifact, but if we're not aiming for modeling,
> do we need the extra indirection?
Isn't the introduction of anonymous partner links a new kind of modeling? In
that case, the modeler has not to think about the concrete partner links.
Cheers,
Olly, Tammo
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Paul Brown <pa...@gmail.com>.
On Dec 3, 2007, at 10:18 AM, Matthieu Riou wrote:
> I question whether we need partnerLink declarations at all. The
> first time
> you use one in an invoke, you get a partnerRole, the first time you
> use one
> in a receive, you get a myRole. Binding to a port, portType,
> interface or
> whatever is out of SimPEL and more a deployment thing. What do you
> think?
The only reasons I can think to retain the declaration (rather than
having it be lazy) would be that (1) it's easier for a human to find
the token and (2) it's easier to ensure that you're using the same
token in all cases where you think you are. (The compiler/parser/
translator can just make two passes...)
-- Paul
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Matthieu Riou <ma...@offthelip.org>.
On Dec 3, 2007 10:10 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On 12/3/07, Tammo van Lessen <tv...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > > But reading the process definition, plink.foo is confusing, I can't
> just
> > by
> > > reading determing if it's invoking or receiving without also digging
> > into
> > > the operation definition. And me/partner is just another way of
> saying
> > > receive/invoke, so why not say it directly?
> > Ok, agreed :) The last one in Matthieu's mail look definitely
> > promising as it's pretty close to original BPEL look&feel (receive()
> > and invoke()).
> >
> > What do you think about the partnerLink declaration? We thought about
> > something like that:
> >
> > partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
> > = roleb, init = true]; // init defaults to false
>
>
> I question if we need to keep partnerLinkType alive? It's a modeling
> artifact, but if we're not aiming for modeling, do we need the extra
> indirection? What about specifying partner link directly as my and/or
> partner, and either one can be a port type or a port.
>
I question whether we need partnerLink declarations at all. The first time
you use one in an invoke, you get a partnerRole, the first time you use one
in a receive, you get a myRole. Binding to a port, portType, interface or
whatever is out of SimPEL and more a deployment thing. What do you think?
Matthieu
>
> Assaf
>
>
>
> Cheers,
> > Tammo, Olly
> >
> > --
> > Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
> >
>
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 12/3/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> Hi,
>
> On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > But reading the process definition, plink.foo is confusing, I can't just
> by
> > reading determing if it's invoking or receiving without also digging
> into
> > the operation definition. And me/partner is just another way of saying
> > receive/invoke, so why not say it directly?
> Ok, agreed :) The last one in Matthieu's mail look definitely
> promising as it's pretty close to original BPEL look&feel (receive()
> and invoke()).
>
> What do you think about the partnerLink declaration? We thought about
> something like that:
>
> partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
> = roleb, init = true]; // init defaults to false
I question if we need to keep partnerLinkType alive? It's a modeling
artifact, but if we're not aiming for modeling, do we need the extra
indirection? What about specifying partner link directly as my and/or
partner, and either one can be a port type or a port.
Assaf
Cheers,
> Tammo, Olly
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
On Nov 27, 2007 11:41 PM, Assaf Arkin <ar...@intalio.com> wrote:
> But reading the process definition, plink.foo is confusing, I can't just by
> reading determing if it's invoking or receiving without also digging into
> the operation definition. And me/partner is just another way of saying
> receive/invoke, so why not say it directly?
Ok, agreed :) The last one in Matthieu's mail look definitely
promising as it's pretty close to original BPEL look&feel (receive()
and invoke()).
What do you think about the partnerLink declaration? We thought about
something like that:
partnerLink plink = [type = ns1::plType, myRole = rolea, partnerRole
= roleb, init = true]; // init defaults to false
Cheers,
Tammo, Olly
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/27/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> > var = parterlink.me.op(corr => cset1)
> > var = partnerlink.partner.op(setCorr => cset2, corr => cset1)
> While seeing the ADA-style params again, the ambiguity problem could
> also be solved by explicitly null-ing the inputVariable
>
> var = partnerLink.op(input => empty) //empty is a reserved keyword
>
> instead of "empty", "null" is also fine.
The thing I'm concerned about is ambiguity to the reader, not the process
engine. In most cases the process engine will be able to resolve the
ambiguity simply from not having the same operation available on both ports.
But reading the process definition, plink.foo is confusing, I can't just by
reading determing if it's invoking or receiving without also digging into
the operation definition. And me/partner is just another way of saying
receive/invoke, so why not say it directly?
Assaf
> Just a few thoughts...
>
> Best,
> Tammo
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
Oliver Kopp wrote:
> var = partnerlink.myRole.op()
> var = partnerlink.partnerRole.op(inVar)
...
This is actually a good point. Is there already a solution for
referencing roles? Since roles can have arbitrary names, we need
something to bind them as "myRole" or "partnerRole" - or did I miss that?
...
> var = parterlink.me.op(corr => cset1)
> var = partnerlink.partner.op(setCorr => cset2, corr => cset1)
While seeing the ADA-style params again, the ambiguity problem could
also be solved by explicitly null-ing the inputVariable
var = partnerLink.op(input => empty) //empty is a reserved keyword
instead of "empty", "null" is also fine.
Just a few thoughts...
Best,
Tammo
Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Oliver Kopp <ol...@iaas.uni-stuttgart.de>.
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
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Matthieu Riou <ma...@offthelip.org>.
On Nov 26, 2007 4:47 AM, Oliver Kopp <ol...@iaas.uni-stuttgart.de>
wrote:
> 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
correlation):
// 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?
Cheers,
Matthieu
> 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
>
>
AW: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Oliver Kopp <ol...@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", ...
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
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Assaf Arkin <ar...@intalio.com>.
On 11/21/07, Tammo van Lessen <tv...@gmail.com> wrote:
> 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.
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.
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.
> 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?
It should have the same binary expressions you can use to join against
multiple links, that's just an omission in the write up.
Assaf
> 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
>
--
CTO, Intalio
http://www.intalio.com
Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Posted by Tammo van Lessen <tv...@gmail.com>.
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