This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

SimPEL

Stefan Tilkov,

According to Paul Brown, Matthieu Riou, Tammo van Lessen and others are working on a sort of compact syntax for BPEL (check out an example usage here).

Two things I’m wondering: (1) Can Ode orchestrate plain RESTful HTTP interactions? (2) How about using a language that supports internal DSLs and allows for easy access of Java libraries?

On December 30, 2007 3:00 PM, Tammo van Lessen said:

It seems to get around ;) Hopefully the WSDL crowd is coming up with something similar.

There is also a work-in-progress wiki page (it is currently a bit out-dated but contains some additional information). The major goal of SimPEL is to provide a more readable syntax for BPEL, without angle brackets and with way more convenient variable assignment mechanisms (E4X-like). However, at least for this first basic SimPEL version, we try to stick on BPEL concepts so that a (more or less straightforward) translation between SimPEL and BPEL is still possible.

Regarding (1): Not yet. Assaf has written a proposal for a RESTful BPEL variant (1, 2) but it’s not been implemented yet. Regarding (2): BPEL is mainly used to define long-running processes, whose instances may be hibernated until some events or messages arrive. It is also very likely that a huge number of process instances are running in parallel. I don’t think a common scripting language interpreter can handle such a scenario. But ODE’s pi-calculus engine can ;)

On December 30, 2007 3:06 PM, Stefan Tilkov Author Profile Page said:

Thanks for the answer. Regarding 2: I was thinking of combining the Ode engine with an existing interpreter - i.e. the handling of a huge number of long-running, incomplete, parallel processes would be done by the engine, and this would be exposed as an API to Ruby. The Ruby DSL would get “translated” into API calls, with the benefit of having an existing interpreter and a full language to escape to if necessary.

On December 31, 2007 11:27 PM, Jean-Jacques Dubray said:

Stefan:

It is interesting to see such an initiative. Just a couple of years ago, there were so many people that were still fighting the idea that BPEL and BPML were “just a programming language” with very interesting properties such as:

“BPEL is mainly used to define long-running processes, whose instances may be hibernated until some events or messages arrive. It is also very likely that a huge number of process instances are running in parallel. I don’t think a common scripting language interpreter can handle such a scenario [you bet]”

Now, wsper (http://www.wsper.org) provides a much broader programming model than SimPEL. wsper is also resource oriented.

The problem with BPEL as a programming language (with an XML syntax or not) is that it is just an orchestration language receiving/sending messages in the pure pi-calculus sense. This is a very poor way to think in terms of what an orchestration language can do. If you associate the concept of resource with orchestration, you get a much more powerful and meaningful programming language.

JJ-