The new (rock-solid) service API
When making the transition from jBPM3 to jBPM4, the most remarkable change is probably the new service API.
In jBPM3, it was not always clear where to look for a certain operation. Some operations were found on the JbpmContext, or on the GraphSession, or on the TaskManagement interface, or yet some other class. So there definitely was an API, but the growth of jBPM both in Slocs and adoption in the past years have transformed it into a maze for many people who wanted to learn jBPM.
In jBPM4, the jBPM team has drastically moved away from these shackles of legacy and has chosen a simpler approach with a less steep learning curve: the service API. Every jBPM story (webapp, standalone, shared BPM server, etc.) starts with a ProcessEngine. As the name implies, the ProcessEngine is the key for doing the actual BPM stuff. But like the engine of your car, you need components to control and guide your engine (gears, brakes, etc) or the engine will do nothing. So basically what you’ll do is create a process engine from a given jBPM config (jbpm.cfg.xml) and acquire from it the services.
Note: the Query API which I discussed in part 2, is also accessible through these services.
The services are designed such that every practical jBPM use case is covered by it. All the API services are tested by us at our QA lab against several databases (HsqlDB, MySQL, PostgreSQL and Oracle for the moment, but we’ll expand this very soon), different Java versions (jdk 5 & 6) and JBoss AS versions. So when you use this new API, you can be sure it is stable as a mountain goat (is this a valid expression?).
But jBPM-power users shouln’t be afraid that this ‘easier’ jBPM API leads to less power. The service API is in fact an abstraction on top of the CommandService facade approach, which was already in the more recent versions of jBPM3. In fact, every service operations translates into a Command, which is executed in the well-known try-catch-finally block of jBPM. Take a look at the source of DefaultCommandService if you want to know more. You can easily retrieve the CommandService to get access to the full power of the jBPM engine:
processEngine.get(CommandService.class)
Power users will know what to do with it 😉
Stay tuned for the next post, where I’ll show you how easy it is to create a Hello World process with jBPM4 and the service API.
Very good series… ;-).
Can’t wait for other posts…
-Jeff
I have downloaded and installed the jbpm 4suite.
I’m new to it.
I saw jbpm demo at jboss.org and found that Jpdl designer looked more user friendly in Jbpm version 3.
I’m really looking forward to know how to get started with jBPM.
Your posts are needed ASAP!!!
ilawise26: the designer in jBPM4 will have more features than the one in jBPM3, but indeed the latest CR1 release was still lacking some features.