Declarative Process Definitions
I have debated this issue multiple times, and the fact that it came up again in two distinct discussions today prompted this blog entry:
Whether it’s workflow, orchestration, business process management, or a similar concept under some local name familiar to you, one always seems to end up looking for a flexible, accessible way to define how data flows from one processing node to another. In an XML-centric world, you’ll think about XML documents that get transformed, separated into parts, aggregated again; and your search for the ideal solution always seems to follow a series of steps that look something like this:
- You start out thinking this is just a simple static configuration issue, and cook up your own little XML language.
- You discover that it’s a little more than plain configuration and you need some control structures, and start adding one after the other.
- You find out that this sucks and start looking for some standard that fulfills your needs.
- After endless debates, you end up with some open source or commercial solution based on some half-baked standard that you just can’t seem to really like.
To avoid going through all of this every single time, it helps to think about what, exactly, it is that you want to achieve. For all of the approaches above, you’ll need some engine capable of interpreting (or executing) your configuration (or process definition). Now let’s just say you pick the JVM as your engine, and Java as your process definition language — what exactly do you lose? Not dynamic enough? When was the last time you changed a process already in deployment without serious consideration? Even so, pick Jython, or Groovy — now what is the difference? How about using some other scripting language?
Call me a heretic, but I believe that every time somebody tries to sell you some XML-based, pseudo-declarative language it is either a) Turing-complete or b) sucks. And I have not yet seen convincing arguments that this would be different for BPEL.
Its a reasonable critique of the limits of declarativeness you’ve got there. Where would you out Ant in terms of (a) and (b)? We try very hard to not do proper workflow (no fault handling, no iteration), because we dont think people should be using Ant outside its role as a build tool. Does that make it suck? Only if you are trying to use it outside its envelope of intentional use.
Stefan:
the problem of modeling “processes” in different contexts (pageflow, workflow, BPM, , multi-agent/service/party conversation,…) is not that simple.
a) processes can be very dynamic (a user can decide to change on the fly the course of a process definition)
b) you must clearly identify whether you are describing the behavior of a participant in a process or the process itself. I have always argues that BPEL is well suited for the former and for instance WS-CDL / ebBP are well suited for the later.
c) critical concepts such as “State” or “Entity” are still missing from most models, not to mention that models are often incomplete (e.g. BPEL does not support users, it does not support B2B semantics though it is royally self-qualified as a “Business Process” standard.
It is clear to me that programming languages will have to evolve to include new concepts such as message, inbound/outbound interfaces (a.k.a contract), service, converstation/contract… I don’t know if you saw it but I had posted a while ago a “service definition” using a programming syntax (and not XML). Overall, I think it is time to capitalize on 10 years of metamodeling and use that knowledge to evolve programming languages.
Run time should support contract enforcement and dehydration/hydration at a minimum.
Cheers,
JJ-
For me it comes down to the value proposition of a declarative language as compared to just using a general purpose language (presumably plus tailored libraries). The number one on my list is the abstraction provided. If the abstraction gives me a way to think only about the problem domain and discuss that problem with a domain expert without having to explain general purpose language syntax to her then I’ve gained something.
Assuming the language is turing complete then it won’t be totally trivial, but it can likely be shaped to elide more of the crud that goes along with implementation-oriented languages around getting the libraries in, initializing them etc.
I’m very happy if the two views are isomorphic (i.e. I only need a translator to get to an implementation). In practice , I think you often want some extra configuaration data annotated onto your declarative language to make a successful deployment - I’d prefer a separate annotation language so I can focus on one concern at a time. If I’m starting in the implementation language then I need full-on aspect orientation to achieve that. I’m incined to think that generating from an annotated model is a bit simpler to get right than than aspect weaving, but it is an interesting debate.
Steve, I’m not intimately familiar with the Ant versions above 1.4.x, so I’m sure I’m up-to-date. But to me, Ant’s main benefit was the normalized task model — replacing the command line interfaces used from within make with something more appealing (and more logical) to Java developers. As to the syntax, I agree that Ant’s build file syntax (as of 1.4.x) is so simple that it qualifies as a decent XML application (and not a programming language).
I know, though, that when I used Ant I always had to do at least a little bit by e.g. embedding a little JavaScript (with Rhino) or similar stuff to achieve my goal. Which makes me think that maybe having a decent library and framework in conjunction with a full-featured programming language and its associated syntax might be more powerful. How about Groovy build files accessing Ant taks? What would that look like?
JJ, I believe your comments are similar to Paul Brown’s (at http://blogs.fivesight.com/pbblog/index.php?p=110) in that they highlight what the value add of an orchestration engine is. I believe we also agree that this is not really tied to the syntax or its pseudo-declarativeness … and that it’s the programming languages that should evolve.
Gareth, you basically make an argument for DSLs — which I understand and agree with. Obviously, though, the goal of this approach is to say the same with less words - and that does not really seem a convincing argument in many XML-oriented cases ;-)