jBPM 3.1, an open source workflow and BPM engine, has been released. It includes a graphical designer for Eclipse as well as a web application for process participants.

jBPM is based on a simple principle called 'Graph Oriented Programming.' The basic ideas behind jBPM were coded in less than 120 lines, in the following classes:

• Node.java
• Transition.java
• Execution.java
• Action.java

These are explained in detail in the user's guide, 'Graph Oriented Programming'. The sources are also linked from the documentation.

On top of this new model, we already have support for three languages:

• jPDL: a language with clean Java integration and superb task management features.
• BPEL: (alpha stage) a service orchestration language based on WSDL and XML.
• Pageflow: In JBoss SEAM, we have a simple graph based approach (with Eclipse plugin support) for defining pageflows.

Major updates include:

• Asynchronous continuations (see user's guide, in 'Asynchronous continuations')
• Configuration framework (see user's guide, in 'Configuration')
• Task instance variables (see user's guide, 'Task Management' section 'Task controllers')
• Externalized the hibernate queries: (see user's guide, 'Customizing queries')
• Added support for JSF-like expressions in actions and assignments: (see user's guide, 'Expressions').
• TaskInstanceFactory replaced the task instance class configuration (see user's guide, 'Task Management' section 'Customizing task instances')

Other resources:

• Download
• User Forum
• User Guide
• Javadocs

Anyone can compare JBPM with Shark?

http://shark.objectweb.org/

It seems that Shark workflow have more function but it is too difficult to quick start. ;-(

In my thesis (software engineering) i have developed a workflow grid solution with xpdl, owls and agents...integration with wsdl and globus will arrive soon. It is fantastic...(1 year of work). Scripting language is tcl. Soon i will publish it. (i hope within april...)


John Slave

About 12-15 month ago, when our project required integration of workflow, we decided to use Shark after comparing it to other WF-engines (among them jBPM). Shark seemed to be the most "mature" and to have a active community. I didn't follow development of jBPM in detail since that time, maybe nowadays it catches up with Shark, especially since it belongs to JBoss

Anyone can compare JBPM with Shark? http://shark.objectweb.org/It seems that Shark workflow have more function but it is too difficult to quick start. ;-(

I looked at both Shark and jBPM a couple of years ago (both have probably come a long way since).

If I recall correctly, Shark had it's own home-baked server/container at the time, which I think was a horrific thing to do and put me off of it immediately. Why in the world would someone want to create their own server for an application?

jBPM had a powerful metaphor for handling workflows, which is very intuitive to pick up and understand (it definitely set the baseline for me with regards to describing workflows).
At the time I checked, it had dependencies on a database, and also had some strange UI stuff hardcoded into workflow infrastructure code, which was strange.
I would assume however that both of these thing have been fixed a long time ago..

Hi,

Anyone can compare JBPM with Shark? http://shark.objectweb.org/It seems that Shark workflow have more function but it is too difficult to quick start. ;-(

2 years ago we started RUNA WFE
Our goal was to build simple end used workflow solution (we are about to release our 2 release, yes it's self advertisement ;-)


We evaluated Shark,WFMOpen,OpenBusinessEngine,OpenWFE,Bonita and jBPM.

OpenBusinessEngine was almost dead for that moment, now this project is closed and I omite its evaluation details.

Standard:
Shark, OpenBusinessEngine and WFMOpen were WFMC standard based engines.
OpenWFE, Bonita and JBPM had their own languages.
We did not consider WFMC XPLD as a plus since it was not widely used.


Code quality.
WFMOpen had most clear code among the others.
Shark code was clear but it relayed on dozen of enhydra projects and was too complicated.
Bonita, OpenWFE, jBPM were ok, simple and clear.

Community
OpenWFE, jBPM,Shark have the widest community at that moment (and as far as I know the situation remains).
Bonita, WFMOpen have very small community.

Licence
jBPM was published under Apache licence.
OpenWFE was published under BSD.
Bonita,Shark were published under LGPL.
WFMOpen was published under GPL

Project Activity
jBPM,OpenWFE and Shark were most active projects (OpenWFE is still one of the most active project on sourceforge).

We wanted a small, mature, easy to maintain engine with commercial friendly licence ;-)

We chose jBPM.

Hope you find this small engine comparison useful.
Feel free to ask for details.

Regards,
Vitaliy

what is the criteria for comparing workflow engines? Can anyone compare Twister with ActiveBEPL and jBPM?

Recently attended a presentation on the new Windows Workflow tool. As a Java developer , I was both impressed and worried.

• I was impressed, because it is a very good , very visual tool, that comes very close to letting Business people (with little technical knowledge) design workflows in a 'drag and drop' manner.
  
• I was worried, because while Microsoft's involvement will push workflow further into the mainstream, I wasn't aware of any Java tool as slick as the Windows Workflow. (Yes I'm aware that slickness does not equal technically better, but too often these decisions are made on looks alone!)
  

I'm downloading the latest version of JBPM as we speak, I'm hoping that it will come close to what is in the next version of Visual Studio.
Blog Post on Windows Workflow V Java

Paul

Very well spotted. Windows workflow foundation is indeed the only technology that is in fact *very* similar to what i call Graph Oriented Programming.

The vision is definitely very close. It struck me that they ended up with a very similar architecture as well. From a slickness standpoint, i believe that we are still ahead (we started with GOP 5 years ago, they only started about 8 months ago). Of course, you'll find more bells and wistles in WWF.

Last time i was in seattle, we couldn't find a good time slot to meet James Conard. I really would like to meet those folks to see how much of the background we actually have in common.

We (the java community) shouldn't be worried. All we have to do is adopt Graph Oriented Programming as the model and jBPM as the implementation :-)

More serious: The model of WWF and Graph Oriented Programming is very similar. I am quite convinced that most developers will have a model along those lines on their repertoire soon. Just as they know the relational model in the context of DBs.

What i would like the java community to do is to challenge Graph Oriented Programming. We already proved that we can support jPDL, BPEL and pageflow on top of Graph Oriented Programming. I have already lots of ideas about many more application domains in which graph based execution languages make sense. I'm also convinced that any graph based execution language can be developed on top of Graph Oriented Programming.

Looking forward to any type of feedback.

regards, tom.

Good to see that we'll have the same functionality as WF (and more) in Java (I think the Microsoft guys are touchy about calling it 'WWF' for trademark reasons).

Another question. I recently wrote an O'Reilly article on one of the related JBoss projects the Drools / JBoss rules engine.

Just to get the difference between jBPM and Drools / JBoss Rules straight in my head:

- Workflow tends to be 'wide' where Rule Engines tend to be 'deep'.

- Workflow is wide as the flow is spread over different people / actors and over time.

- Rule Engines are 'deep' as they apply simple rules to solve complex problems, but in general the rules are applied 'all at once'.

Some of the confusion (in my head at least) comes from the fact:

- It is possible to implement workflow using a rules engine, much as it is possible to write your own workflow using Java. Of course , you don't get the graphical designer that JBpm has.

- Both JBoss Rules (Drools) and JBoss Workflow (jBPM) see to 'externalize' part of the solution outside of Java. By stepping outside of Java to use an XML / Graphical based approach, it makes the solution easier to configure and understand.


Paul, FirstPartners.net

see my comment on Paul Brown's blog: http://www.firstpartners.net/blog/technology/uncategorized/2006/02/21/jboss-workflow-jbpm-and-jboss-rules-drools/

regards, tom.

ps. after choosing the name Graph Oriented Programming, i discovered that TLA was also taken... it seems that all good workflow acronyms are touchy :-)

Graph Oriented Programming looks interesting but it does seem to be a new name for doing what Petri Nets have been able to do for some time.

Could someone from the project explain the difference?

Regards
Kit

Short answer: Petri nets can be considered as a graph based execution language and hence it can be implemented using Graph Oriented Programming.

Longer version:

In today's software development we use many languages:
* programming languages like java, ruby and scripting languages
* IoC configurations
* Hibernate mappings
* Pageflow language (e.g as part of the webapp framework configuration)
* Service orchestration language like BPEL
* Workflow language like jPDL
* ...

All of these could be considered as domain specific languages. One category of these languages are the graph based execution languages like e.g. BPEL, jPDL, pageflow,... Graph based execution languages are languages that can be vizualized as a directed graph and that represent some kind of execution. On this topic, I recommend Martin Fowler's pieces DomainSpecificLanguage and Language Workbenches. Imho, those two articles give a look into the future of software development.

Graph Oriented Programming is a simple foundation to implement all graph based execution languages. It's an implementation technique that is based on OO programming.

Petri nets is also a graph based execution language. So hence it can also be implemented on top of graph oriented programming.

regards, tom.

oh... and one more thing. We believe that different environments and different goals require different process languages.

Developers tend to be skeptic about using process languages for Business Process Management (BPM). And for good reason. Many of the process languages are being promoted for BPM, but they are not suitable.

For example, we think that petri nets and BPEL are unsuitable for general BPM.

Petri nets are good for applying math calculations to a petri net. But in muy humble opinion, it is very difficult to model a typical business process as a petri net.

BPEL is a very good technology for writing a new webservice as a function of other webservices. One of the main benefits is that you don't have to translate between the XML format and objects in your OO-programming language because BPEL is XML based by nature (interface and process variables). Also BPEL implementations have to cope with wait states (receive activity) and a BPEL process is always displayable as a graph (it's even a tree). But that doesn't make it suitable for BPM.

BPM needs a separation between the business analysts concerns and the developers concerns. Business analysts must be in charge of 'the picture' while the developer must be in control of all the technical implementation aspects. That was the goal behind the jPDL process language that we have created.

regards, tom.

Thanks for the input, Tom. Oh and I forgot to say congratulations on the new release!

You say petri nets could be implemented using GOP. The funny thing is, when I read the article on GOP, my first though was that it should be the other way round.

For instance, GOP relies on having an Execution state per thread, whereas PNs model concurrent processes implicitly within one state (1 state having multiple tokens, each can be considered an "instruction pointer"). I worked on a BP engine that used a similar model to GOP, and having also worked with PNs, I have to say I find the PN model much more capable and easier to implement.

I take your point that PNs are more difficult for the analyst to work with. But I think this can be dealt with by the mapping between the actual PN model and what it looks like on screen (ie. a flow of actions on screen can be represented by the functionally equivalent PN underneath. The user needn't see a PN on screen).

But anyway, I wish jBPM much success.
Kit

An GOP execution is equal a PN token. In fact, in the jBPM implementation it's called a token. But because i thought that the name 'execution' would make it easier for developers to learn about it, i took that name in the Graph Oriented programming description.

You can try to implement a workflow engine in terms of a petri net. Basically, when you create a process languages you define a set of process constructs (what you refer to as 'what the user sees'). When choosing petri nets as your base, you'll be defining the process constructs in terms of petri-net-macros.

In the Graph Oriented Programming approach, you'll be writing a piece of java code to define the process constructs. That has been proven much more flexible to me.

PN is only a theoretic model. Graph Oriented Programming also defines process execution is linked to plain OOP execution. The plain Java thread is used as the host thread for executing the process. By default, the process is executed synchronous. But (as i will add shortly to the GOP extensions description) also asynchronous continuations can be supported.

regards, tom.

Tom,

Congratulations on the release.

I wanted to follow up on a comment you made regarding BPEL vs. BPM/GOP. You mentioned that one of the important aspects of BPM is the ability to bridge the gap between the analyst (picture) and the developer (code behind each activity).

If you extend this idea to not only the initial design stage but more towards the iterative changes that businesses will want to make to processes, you will notice that you not only need the states but also richer information about what activity needs what data. At that point, you will need to create a variable system and extend the definition of each node to determine what data is read and what data is written.

If you were to further extend the GOP process definition language from graph-only to have blocked exception management and unstructured event handling, GOP would start to look very similar to BPEL.

In the meantime, people that currently endorsed BPEL, will enhance it so that it includes enough metadata/annotations so that it can be displayed in a more business friendly fashion (we call this, for example, BPEL outline view - and it is very similar to JavaDoc or Microsoft Word Outlining) (similar to your mega-state concept but in an orthogonal way to the process definition through the use of annotations).

So rather than BPEL vs. GOP, these 2 things might actually converge towards the same end state.

-Edwin

Thanks !

I don't see it as BPEL versus GOP either. It's BPEL and GOP. So i don't think they will converge.

GOP is a technique to implement graph based execution languages in an object oriented programming language.

BPEL is one specific graph based execution language targetted at a specific environment: an ESB.

So its GOP *and* BPEL as we show by having a BPEL implementation on top of GOP.

Graph Oriented Programming does not intent to support *all* features that can be usefull in any graph based execution language. Instead, GOP is the intersection of common parts in all graph based execution languages. GOP can be extended to support blocked exception management and unstructured event handling.

GOP is an implementation technique. IMHO, it will replace other implementation techniques for graph based execution languages like:
* message queue based implementations
* code generation based implementations

In the section Advanced Graph Oriented Programming Extensions i will be describing the most common and powerfull extensions that you will need on top of Graph Oriented Programming. Other implementation techniques such as message queues and code generation will not be able to support all the extensions that i mention there. If you know of any feature or capability in those two impl techniques that can not be supported on top of GOP, please let me know.

Could it be that your BPEL outline view idea actually comes down to implementing a new process language in terms of BPEL underneath ? In that respect, it would be the same as we do, but in our case, we do it on top of Java (or in any OO programming language).

Our main difference is in the fact that we go for a multi process language approach because we believe that different environments (like e.g. service orchestration, workflow in plain java environment, pageflow,...) require different process languages. And if i understand you correctly, your approach is that BPEL should be used for all purposes. Is that a correct summary ?

regards, tom.

Tom,

The first picture in the "Chapter 4. Graph Oriented Programming" is very helpful in terms of describing your vision for GOP.

I agree with the value of a Java GOP framework for building other graph-oriented domain specific languages (BPEL, JSF, etc.)(although I think that it would be valuable to add blocks, exceptions and events to that core...And if you were looking at going that direction, we might be able to help).

What is not necessarely clear is 1) what is the relationship with the comment you made regarding BPM/Business Analyst and 2) if people will want to continue to program at the lower level GOP/jBPM APIs when BPEL matures to support BPMN/Business View notations and the SCA model emerges, bluring the line of ESB-style development and application development. I guess time will tell!

Again kudos for the release! It is pretty amazing that a single person can pull this through!

-Edwin

Tom,
Regarding annotations, the idea is to simply be able to annotate a BPEL process with "milestones and macro activities".

For example:

<process>
     <scope>
        <annotation>
             <property name="activity">Get Rating</property>
             <property name="cost">....</property>
             <property name="...">...</property>
        </annotation>
        ..any implementation..
     </scope>
     ....
</process>

Thanks to these annotations, you can create different views of the process for different audiences (analyst/outline, implementation, documentation, user/status, etc...). This is how we are looking at bridging the gap between very high level analyst tools like IDSSheer, Proforma and the BPEL process definition. The key benefit is that it is not an import/export pattern (which kills iterative development) but a view/zoom-in zoom-out pattern.

-Edwin

annotations definitely makes sense. i agree, far better then the inpractical import/export.

we have thinking about something similar. but i'm not yet sure about how to differentiate between design-time annotations and runtime annotations. some of the annotations are only needed in the authoring/documentation views. while others are needed in the runtime engine.

in oracle's bpel impl, which annotations are loaded into the runtime engine ? all, none or some ?

regards, tom.

Annotating a BPEL process with extensibility elements opens up a lot of intriguing possibilites. One use is fine grained transactions demarcation, in coordination with a web services transaction manager. Other use is including hints for informed selection of partner services a la semantic web. The problem is that these annotations are necessarily propietary, unless they are taken to a standards committee which will take months if not years.

Anyway, it is nice to see people in the industry thinking of annotations as a way to separate the distinct concerns of the same business process.