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.

More on BPEL-J

Stefan Tilkov,

Jean-Jacques Dubray explains why he likes BPEL-J. My problem with the whole approach is that I either want to extract business process modeling information from my implementation source code, in which case I might be tempted to use something programming language-independent, such as BPEL; or I decide that my requirements can only be fulfilled by using a general purpose programming language - which would make me use something like Java, C# or some dynamic language.

The idea of using XML as a syntax for “real” programming languages plainly sucks — all it does is create an illusion of independence of a particular platform, when in reality it’s just obscured badly behind a syntax totally unsuited for the task. Now whatever you think of BPEL, one of its (if not its only) benefit is that it is supposed to be portable across different BPEL engine implementations. Mixing it with Java would make me no less dependent on the Java platform that if I had used Java directly, so I just plainly fail to see the point (you could just as well directly go with the JSR JJ points to).

JJ’s example — if I understand it correctly — would imply that I can mix process execution semantics with things such as accessing a database, which is something that IMO does not belong to this layer at all (and should be hidden behind another service interface).

On April 14, 2004 3:43 PM, Howard Smith said:

My views on BPELJ are documented here: www.bpm3.com/bpelj/ ….. but, I am struck by JJ’s analysis that BPELJ opens up the possibility for “This is not a Hub-and-spoke orchestration, but a collaboration of orchestrated services.” That is precisely what BPMS vendors do already. Typically, one swimlane per BPEL or BPML process, not centrally executed, but choreographed based only on the exchange of information among the service entry points to the processes. And BPMS products will typically support projection of services from existing system so they can be the enactment systems for each swimlane, precisely as JJ advocates. BPELJ neither helps, nor hinders in this respect. It’s just a really bad idea to mix up traditional programming in a process language. BPMS products neatly partition the two, allowing all existing enactment systems to play a role. Take a look at www.bpm3.com/grok/