Have you ever wondered why Business Process Management (BPM) ‘engines’ need a separate runtime server ? Why is a plain JVM not sufficient as a runtime server for business processes ?

 

The best way to see the problems that BPM solutions try to solve is by identifying the problems with the current generation of Object Oriented (OO) programming languages. Current generation of programming languages is lacking a two crucial features :

• no support for long running processes
• no visual representation

The limitations of the JVM

 

Let’s look at those features a little closer. First of all support for long running processes. Consider all requests handled by a server related to the processing of one order. Typically, there are quite a few. So there is a relation between the different requests to the server. A first request might be from a customer that creates a new order via the public web application. A second request might be from a employee that verifies and approves the order for further processing. The third request might be a response from the warehouse to confirm the stock availability and so on.

 

With support for long running processes, we mean that we want to be able to write a piece of software that covers this whole scenario, including the wait states and how requests and execution of software is combined. Let’s call that kind of software that expresses a long running process and includes wait states “executable business processes”.

 

The basis of OO programming languages is that they allow a programmer to express a sequence of instructions. That is very good to serve requests. Meaning, a request comes into the server, then the software executes as fast as possible to perform the request. And when the server has completed the request, the server waits for a next request.

 

But OO programming languages cannot express programs that span wait states. It is impossible to write an instruction as for instance: “wait for an asynchronous message from another system” or “wait for that user to complete this task”. Ok… yes, it is possible to write that kind of instruction, but the problem is that the execution cannot be persisted by the programming language during the wait state. So if your thread is blocked in such a wait-instruction and you reboot the server, you have lost your execution. To be precise: programming languages don’t support persistence of the execution during wait states.

What do BPM engines add to plain OOP ?

 

So the first goal of BPM solutions is to support the specification of executable business processes that can include wait states. This capability brings the specification of software much closer to the requirements that originated from optimizing business processes with IT. Without a BPM solution, the state of the overall process and the relation between different automated functions would have to be managed by the programmer in each request manually.

 

The second goal of BPM solutions is support a graphical view for the executable business processes. This is important because it creates a common language between the business analyst and the technical developer. Furthermore, it gives the programmer an extra technique to structure software.

Another technique to structure software

 

Structured programming added abstraction, Object Oriented Programming (OOP) grouped data with code and Aspect Oriented Programming (AOP) groups crosscutting logic. Those are all techniques to structure our software. Structuring software in a proper way can lead to considerable cost and time savings.

 

All of those techniques attempt to lower the complexity of software development. Since the cost of software development grows exponentially with the complexity, it becomes clear that all techniques to structure software are important. BPM solutions give the programmer the ability to structure the software around a graph.

Conclusion

 

The conclusion of this is that OO programming languages are not suited to specify long running processes that include wait states. BPM engines provide developers with a process language that can express long running processes.

 

The runtime part of a BPM system keeps track of the state of every process execution on a persistent storage such as a database. The net result for developers is that they are given another technique to structure their software around the business requirements.

 

So developers can spend more time trying to understand the requirements of the problem domain, rather then finding a technical solution for managing the state of each business process manually.