Would you like to fly with a spaceship that was assembled by service people?
This might never happen, but if we ever build a spaceship based in
SOA, I'm not sure if I would like to go on bord. It would probably look
very good on paper, but it would definitively not work without some
minor or major "hiccups". Once in the deep space, one might run into a
SLA violation and you probably would experience some disintegration of
your spaceship.
This is, admittedly, a bit of a polemic description, but you can find
some grain of truth in this statement. However, why should we build
systems that are based on a fuzzy notion like services (see last post)
and with heavy weight xml artifacts which difficult to understand (for
humans) and even more difficult to use? So far, the tooling is not
exactly what one wishes for and the creation of workflows appears to be
a tedious and thus error prone task.
A way to look at things is to reason what one wants to do in the first
place with services. Well, it's simple: we all wish to invoke a service
with some input and expect some output. We want to make decisions,
based on some expressions, either to invoke a service or not. The data
that we base our decisions on can be the result that we get from other
services (output) or user input. We also need some kind of support for
the creation of loops and a place to store the result of service
invocations (variables).
That's basically it. I'm aware of all those fancy concepts like
compensation handling and so on. However, in my opinion this makes
things unnecessary complicated and I dare say that some of this appears
"academic" and not exactly useable in practice. Yes, there is always
space for some PhD thesis that discusses a very specific detail of
workflows :-).
What I question is the approach of creating workflows like full fledged
languages with heavy semantics and lots of features. In my opinion, we
can build workflows with simpler mechanisms and exploit existing script
based approaches. The use of Groovy scripts is an example for this (see
links)
I'm aware that this might appear to be yet another way of simply embedding service invocations in java (groovy being a super set of java), but it has some advantages over existing workflow approaches. Groovy is a dynamic scripting language which allows run time modifications and don't we all crave for runtime changes based on contextual information :-)? Of course there is much to do, but I think this could be a interesting direction which needs more and deeper investigations.
So would I fly with a spaceship that is programmed in Groovy? Probably not, but one can never know for sure :-).
- Martin Treiber
References/Links
Why BPEL is not the holy grail for BPM
Flow diagrams, turing machines and languages with only two formation rules
