1 of 1 people found this helpful
Hi Michael Harper,
Generally there are two ways you can use / implement JBPM:
1. Embedded, Embed it in your application, so you can call all the API directly from application.
2. Use it as service, Deploy it as war file in server like JBOSS AS, the War has to provice API like REST API so that all other application can interact with it.
I believe each implementation has its own advantages and disadvantages.
by the way, I use it as a service because it is shared by multiple application.
Thank you Thomas
I was looking at using it as a service as well. Where I was getting a little lost is because is was trying to set up a minimum configuration i.e a war the required jbpm libraries with my own database, and as you say some restful services to expose access to processes. In doing this I couldn't help thinking that I was missing a point and not using elements of the demo installer as I should be, but then if that's the case, it would be nice to see to have an outline of how all the peices fit together, jar packages, jboss-web.xml, web.xml elements so I had a better Idea of what I was doing.
If what we have to do is analyse the demo and effectively create our own version for production then just being told I had to do that would settle my nerves :-)
Hi Michael Harper,
You are correct about the demo, the demo shows a sample on how jbpm can be implemented. Of course if you want to use jbpm as a service then jbpm-gwt-console-server that comes with the demo is a good reference.
You can even use it and customize just part that you need to behave differently. Or you can even create your own jbpm-gwt-console-server like application.
We have decided to diagram the process in BPMN2.0 notation but at this stage we proceed with a JBPM implementation.
The reasons are;
a) This is a project on behalf of clients for a government project and we feel there is an unaceptable level of risk mainly in the support and documentation areas.
b) We can implement the project using traditional approaches and the JEE stack, and given the risk, we would need a bigger advantage through the use of JBPM, to encourage us to go though the pain of setting it up in it's current state.
Like I said we are documenting with a view to one day being in a position to use JBPM so I'm not knocking the project. In a less risky project we might be tempted to throw caution to the wind.