Decoupling BPM and messaging

I was reading a post by John Reynolds asking why Java programmers hate BPM. The response from The Java community is mixed between "programmers don't hate BPM, they hate coding in XML" to BPM is a tool for managers, not programmers.

Here's my own take on why programmers hate BPM. My answer is, programmers don't hate BPM< they hate BPEL due to its complexity. Now why is that? after working with BPEL for a couple of years now, besides the usual "writting xml is not programming" reason (which I totally agree BTW) I suspect that there is a more sinister evil behind BPEL: mixing concerns which may or may not be congruent with each other. Specifically, mixing coordination and messaging.

Heck, one of the reason why the abomination that is BPELJ was introduced was to facilitate the transfer of Java objects through BPEL without going through XML serialization.

I really think the reason GRAFCETs are very successful in the heavy industry (for e.g. coordinating large scale manufacturing) is because GRAFCET is a pure boolean system (0 or 1). No messages are going through a GRAFCET. Now, this does not mean that messages are inexistant, they do, just outside of the so called "BPM".

This really facilitates GRAFCET design a whole lot. All the BPM needs to do now is, given the state and condition (which are boolean) of the BPM, an action is either fired or not.

I was wondering if "Boolean BPM" is not what is needed to do away with BPEL and allow for a simpler language like the GRAFCET to be used. (need to investigate this idea further). I wonder how this would effect, say, long running transactions within a BPM.

Note: I do a see a tendency towards this "Boolean BPM" ( especially in this discussion ). Several Jbossian were touting the new Drools rule engine integration into BPMs. Now, rule engine is very much a boolean system. So, maybe my thoughts are not that far off :)