Paul Gallagher's blog "Pipes - Web 2.0 Wake-up Call for BPEL?" gives a very example nicely what we call a graph based execution language. And the best part is that he puts the Yahoo Pipes langauge in perspective with BPEL, paving the way for me to explain why its crucial for future workflow engines like our JBoss jBPM to support multiple process languages.
The only languages often associated with workflow, BPM and orchestration are BPEL, XPDL and BPMN. Of those, only BPEL defines exact execution semantics and hence it is called an executable process language. jPDL is another executable process langauge. Where BPEL is targetted to a web services / ESB environment, jPDL is targetted at a standard Java environment.
Similar to Java being referred to as a general purpose programming language, I refer to BPEL and jPDL as a general purpose process languages. But over the last years, with the more widespread adoption of jPDL, we get a lot of requests to create limited dialects of jPDL for specific purposes. For example approvals in a document management system or tracing of laboratorium experiments.
JBoss jBPM is designed as a platform for process languages. After we had put BPEL, jPDL and SEAM pageflow on one base framework called The Process Virtual Machine, we realized that we could build all these kind of languages on the same base technology. The componentization that we introduced supports this very well already.
As such, Yahoo Pipes are another nice example of a graphical process langauge.
Martin Fowler and Neal Ford recently introduced the notion of Language-oriented programming. The idea is to "build software around a set of domain specific languages”.
The more we realize how big the category of graph based execution languages actually is, the more excited that we get. With our new Process Virtual Machine technology underway, we are not far from building out a complete language workbench focussed only on graph based execution languages.
More concrete, based on the Process Virtual Machine we're building a complete software development kit for developing your own graph based execution language, including runtime, console and designer. You'll be able to code the runtime behaviour of process constructs in plain Java. Also included will be a mechanism to add designer forms, XML serialization and persistence of the process constructs. We see a lot of use cases for easy customization of general purpose process languages like jPDL.
Typically I don't really know how to start explaining the concept of how jBPM is becoming a language workbench for graph based execution languages. Thanks, Paul for providing this example and giving me an opportunity to explain the strategic direction of JBoss jBPM.