Our application is a stand alone war file (a spring + wicket based application). My first idea was to start with the old jBPM3 stack
because we have jBPM3 knowledge. Then I evaluated jBPM5 and liked it pretty much. Moreover it seemed that this will be the
supported product in the near future.
So our current approach is to start up the the jBPM knowledgebase and the Human Task Service in a servlet context listener , and
use it from our service layer. A typical page flow:
1. The user retrieves a Task list from the engine (the list of probably persisted process instances, where the current user is the potential ownner of the actual task)
2. The user selects (claims) a task
3. We generate a wicket form based on the process varibles (and relating domain entities)
4. The user specifies some input, and selects the next transition (this will be a generated button bar with the available transitions)
5. The submit button's event handler signals the process instance with the specified transition
At least this is how I would do it with jBPM3 TaskManagement API.
My understanding is that with the current methods, I have to create a TaskServer and KnowledgeBase instance in the ServletContextListener, cache a TaskClient in the user's session and use it to interact with the TaskServer.
The only downside is that we have to use a socket server or JMS to achieve this. I would be quite happy with a non-standard (that is non WS-HT
like) solution, that enables us to interact with the TaskServer in a blocking way (in VM API calls).