jBPM 5 RFC - nobody gets left behind

I have posted my thoughts and evaluation of the jBPM 5 RFC posted last week, see the jbpm-dev list (may take a bit to appear).

I think the theme should be 'Nobody gets left behind' when working towards the jBPM future.

======================================
UPDATE: (seems to be something wrong with mailinglists, not posted yet so adding here)

Posted 23 April 2010:
============
I have been watching the replies and seeing what the jBPM core
community developers would be saying before responding with my own
thoughts on this topic.

My background with jBPM is not well documented here in the forums or
mailing lists. I have been using jBPM in an enterprise environment
over the last three years or so as both a developer and lead
developer. It started on the jBPM v3.1.x community versions and later
migrated to the current supported jBPM v3.2.x. I also have had
personal meetings with Tom, Joram and Koen discussing jBPM 3 and jBPM
4, be that development questions, use cases from customers or just my
experiences deploying enterprise solutions into production
environments. One award winning case was published
(http://www.schabell.org/2009/11/2009-silver-winner-for-europe-financial.html)
on the implementations we did with jBPM v3.

Looking at the various sections presented by Kris in the design
overview https://community.jboss.org/wiki/jBPM5RequestforComments, I
will run through each section and give my thoughts:

Architecture:
=========
This picture is clear and concise, providing a pretty good idea of
what the overview is. I miss JBoss Rules / BRMS as a block in the
Connections side. I feel that Rules is just as important as JBoss ESB
and you need to provide this to push your own products. On a side
note, the roadmap needs to come ASAP to provide clarity where the
focus is. You will see below in my evaluation, there is a focus needed
on the core functionality to make something that can make it into a
product.

Core process engine:
===============
When I look at this component I see many of the existing jBPM 4 branch
as being a strong candidate to be leveraged along with whatever the
Drools project has completed. Would be great if they could/would
compliment each other. I am very happy to see the PVM being the
leading theoretical foundations for the BPM suite. Three items are of
some note:

1) process instance migration is mentioned as if it is about stateless
processes. I do not see how you can manage this at all. If you show me
a process you think you can migrate, I bet I can break it.

2) process instance migration could and should be a target for moving
from one version of jBPM to the next.

3) jPDLv3 -> BPMN2 process definition conversion tooling is a must and
I was pushing this before the split, with project space already setup:
http://anonsvn.jboss.org/repos/jbpm/projects/migration_tool (current
leads are more than happy to have someone to help on this conversion
tool, great place to get your feet wet in open source!)

Finally, this part of the project should have about all the attention
available to ensure a speedy delivery. This is what is needed to offer
customers a path into the future of BPM.

Human Tasks:
===========
Following a standard makes lots of sense. I do see this as a bit of an
external project when related to the console and form editor. First
order of business is having them available.

Process repository:
==============
I would assume that this component could also leverage the efforts of
ModeShape project maybe? Keep work to a minimum by conforming to what
they recognize as an artefact. Seems also to fall into the category of
nice to have but not yet essential to initial releases.

BPM Console:
==========
Looks like this can and should leverage the jBPM 4.x work, the GWT
console project, along with whatever Drools project can / has to
offer. This is nice to have stuff.

Eclipse-based process tooling:
======================
To leverage jBPM 4.x existing tooling and Drools project tooling. The
extra bits mentioned are again fine for later releases.

Web-based process tooling:
====================
Is Oryx / Signavio one team? I was under the impression that Drools
went one way and jBPM project another... who will win now and what are
the criteria to be judged?

Simulation:
========
Very advanced feature that is nice to have (would make Product sales
easy to visualize and demo's very slick) but nothing to focus on in
the initial releases I would think. This could be an apart
sub-project.

BAM / BI:
======
This is a very interesting one, how to provide without dictating what
a person is to get/use/have in the BAM/BI area. It should be about
facilitating and ease of customization. Also an apart sub-project and
not important for the initial releases.

Usability:
=======
Strange mix of stuff here; Domain-specific processes (what for? why?
let's get normal process engine out there first?), install scripts
(already there?), continuous integration (leverage existing setups?),
documentation (has always been outstanding, should not slip), OSGI
(what for?).

Integration:
========
Every item mentioned here in this section needs to have a block in the
architecture overview picture. Very good to leverage and use our own
projects. Make that the easiest path.

Final thoughts, I see many panic reactions on the lists/forums with
regards to jBPM 4. Looking at this overview Kris provides, I expect
much of the jBPM 4 will function as some sort of base line for further
development. DroolsFlow will play a role and if more projects are
leveraged then this overview of a BPM suite on functionality is
achievable. I think the first steps need to be to ensure that
customers are taken from jBPM3 to jBPM5. plan this from the beginning.
Rule #1: nobody gets left behind.

jBPM v3.2 custom exception framework example now available

In December of last year I posted on a project of mine called a custom exception framework. I have been working on this for the last few months and have now put together a running unit testing example to demonstrate the final results and committed this to the jBPM projects directory.

The idea is that you are now able to use a single exception handling process (see image provided) to provide all your processes with exception processing. There are only two options in this framework, a human task to allow fixing your processes problems by hand or a retry option to allow for automated continuation based on settings you define.

Currently the unit test demonstrates only human task fixing of a single node failure, but I will continue to work on this. I plan to complete a state node failure and demonstrate the Retry option.

The project includes maven dependency handling (see the pom.xml) and you can start in the readme.txt file included at the root level of the project.

Fedora 12 Eclipse Subversion plugins missing javahl

I tend not to use the integrated Fedora 12 Eclipse packages as I want more control over my Eclipse or JBoss Developer Studio (JBDS) and Java versions. I have many Java JDK's installed and can use them easily with the alternatives setup from Fedora 12.

What I keep running into is that the local subversion packages provide Java HL in the /usr/lib64/* location and the Eclipse or JBDS Subclipse plugins are looking for them in /usr/lib/*, so how to correct this?

// adding the pointer to my javahl libs in eclipse.ini file 
// as follows to make use of the Fedora 12 native rpm javahl
// package installed libs:
//
-Djava.library.path=/usr/lib64

Now my subversion tooling in Eclipse / JBDS works without complaining...