In a first post called "Activiti BPMS: neither fish nor fowl", Alex Neihaus (VP Marketing, Active Endpoints) starts with the coolest picture I've seen in a while:
The rest of that post is rather poor in terms of facts. He says
we’ve got no issue with the jBPM team moving to greener pastures to try and rescue a moribund open source project
The term moribund (means "in terminal decline") is hilarious if you know that jBPM had 25000 downloads per month. I don't know of any other BPM System being used as much. Further on, despite what is insinuated, we agree with the next part:
Above all, BPM is a management discipline. As our CTO Michael Rowley is fond of saying, BPM can be done with pens, whiteboards and Post-It notes.They probably didn't take the time to go through our website. In our very first FAQ "What is BPM?" in which we clearly distinct between BPM as a management discipline and BPM as software engineering:
BPM as a management discipline is the responsibility of every strategic executive manager. It's to ensure that the organization performs well in their core business processes. ... This means analyzing, documenting and improving the way that people and systems work together. As part of that work, it's useful to work with models and diagrams. ... Important to note that these models are used for people to people communication. ...
BPM as software engineering means that executable business processes will be executed by a BPM System (BPMS). ...
The attention continues with Michael Rowley adding more argumentation in "Activiti BPM: is a process microkernel the way to go?" Michael start with
The idea of the process virtual machine is simple and appealing
So far so good.
The idea is that all of the hard work of developing a process engine can be put into a layer that is more general and abstract than any process definition language. Then, when anyone wants to create a process engine based on a new language, it is a simple matter to map the concepts of the new language onto the constructs of the PVM and voila: a new process engine!
Exactly! We did it for jPDL, BPEL, SEAM Pageflow, XPDL and now BPMN 2.0.
The link to Linus Torvalds microkernel stuff doesn't have any substance and it's pure FUD. Active Endpoints only makes a core piece open source (ActiveBPEL, GPL) and for which the actual product contains commercial licensed software:
You can use the ActiveBPEL engine under GPL v2 by downloading it from this website. Alternatively, you can acquire a Commercial License to Active Endpoints' ActiveVOS Enterprise product by contacting Active Endpoints.
For such company to use Linus Torvalds as part of their argumentation is actually ironic.
Then Michael aimes his guns on the Process Virtual Machine (PVM)
A traditionally developed BPMS will be on top of an application server and a database. The application server is on a JVM, which is on an operating system, which often is on top of a virtual machine. Every layer adds value but it also adds cost ... Is the cost/benefit tradeoff right for a PVM layer?
I’d say no.
I'ld say yes. In Activiti, the PVM actually runs BPMN 2.0 natively. So it's removing a level of indirection, rather then introducing one. The PVM itself is transparent. So if there is an error, you get a the error in the context of a BPMN 2.0 process. The structure of the PVM process is a 1-1 match with the structure of the original process. Same goes for all the other languages we ever built on the Process Virtual Machine.
Let's compare this to the alternative strategy proposed by Michael Rowley: BPMN to BPEL translation. Historically, BPEL is actually a graphical language and it was long time promoted as a real BPM language that business people could draw. Over the last 2-3 years, there has grown a general consensus that BPEL is capable, but not suited for BPM. More precise, BPEL might be good at orchestrating web services, but it is a clumsy way of doing BPM.
Then comes BPMN. I speculating that their engine architecture is not that flexible. Because now their solution is to translate BPMN into BPEL. Translating from one graphical language (BPMN) to another graphical language (BPEL) is adding an unecessary level of indirection. The BPEL still needs to be interpreted by an engine. And when then an error occurs, you get a BPEL error, not a BPMN error. And secondly, the translation step from BPMN to BPEL is very problematic to say the least. So I can understand that they are not at easy with our new Activiti project running BPMN 2.0 natively.
The general tone of the posts try to imply that Activiti is only for developers. But that's just one aspect of our new project. Developers form one important target group to which we want to bring BPM capabilities. Alfresco ECM customers is another very important group. Both groups will benefit from our practical approach to facilitating collaboration between business people, IT folks and system operators.
So in my opinion, the only way I can interpret this attention is as pure FUD from a scared vendor. We're honored with so much recognition in our very first week ;-)
The microkernel-debate was about the architecture of operating systems. It had nothing to do with the GPL or other licenses.
ReplyDeleteAndreas Kuckartz
I realize that Michael was referring to the architecture and not the license. The architectural analogy between the PVM and the OS microkernel is non existent and hence I think it's FUD.
ReplyDeleteThe comment on the Active Endpoint licensing was intended separate from that. I just think it's ironic for Active Endpoints to build up the microkernel argument waiving with Linus Torvalds when Active Endpoints and Linus differ so much on (the separate) license topic.
Rereading, I indeed did not separate those two properly.
Your link to AE's open source offering is accurate but you should know that the download is for an older version of the software that doesn't support WS-BPEL 2.0.
ReplyDeleteI maintain a more recent version of their open source code at code.google.com/p/bpel-g. It's still GPL to comply with the original license but at least it's WS-BPEL 2.0 compliant.
Admin,
ReplyDeleteThat's interesting. Do you know why AE would not want the BPEL 2.0 compatibility?
What's your motivation to maintain the google project? Are the plans for your project to feed back into AE? Or do you plan to keep it separate?
regards, tom.
I can't speak to their motivation but at one point the open source release was only a few months behind each commercial release. The last open source release (5.0.2) supported WS-BPEL 2.0 as well as the BPEL4People 1.0 white paper. The current open source version is pinned at 2.1 and only supports BPEL4WS 1.1.
ReplyDeleteThere's no need to fold my code back into their trunk since they've already progressed beyond it. All I've added is support for JDK 1.6, maven build, JMX, and ServiceMix - none of which is on their radar.
As for my motivation, I work in the defense research sector and grew weary of continually patching or working around issues in Apache ODE and wanted a fully compliant WS-BPEL engine. Having previously downloaded the AE 5.0.2 open source release, I decided to resurrect the project. I know the code well from having worked there and it's exactly what I needed. The GPL license is fine for my research.
I'll check out Activiti since I like the idea of a unified modeling and execution language. Hopefully you have time to code in between flame wars with Alex ;)
You state you mapped different languages to the PVM model (jPDL, BPEL, SEAM Pageflow, XPDL and now BPMN 2.0). Where can we find the result of that? The activiti forums speak of work that is in progress or even not yet planned.
ReplyDeleteFor web services specifically, can activiti be used to orchestration?
BPEL
http://forums.activiti.org/en/viewtopic.php?f=3&t=22
XPDL
http://forums.activiti.org/en/viewtopic.php?f=3&t=184
Hi Anonymous,
ReplyDeleteIn the past, at various stages and in various branches/implementations, the PVM principles have been used to implement those languages mentioned.
In Activiti our primary goal is not to support all those languages on the PVM. Instead we clearly chosen to work out BPMN 2.0 as our main language. Nevertheless, the PVM is just a good process engine design. And the pluggability is there if people want to use it.
At this moment, PVM is still being shaped for easier pluggability. Mainly to simplify usage of different persistence technologies.
Our first priority is to have an executable BPMN 2.0 engine. Secondary is that we expose a stable API to use the PVM. At this moment the PVM API's can not be considered stable and are only available in .impl. packages indicating it is internal stuff.