Skip navigation
2005

 

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.

 

Many developers are still sceptical about the benefits Business Process Management (BPM) systems and workflow engines. BPM visionaries and management executives seem unable to pass their enthusiasm about BPM to developers. In a couple of blogs, I will show what the essence is of this technology and how developers can take advantage of it. In this first blog, we’ll sketch the context of BPM and what it brings to the table for developers. Then, in the next post, we’ll show the limitations of the JVM that BPM solutions are trying to resolve. Further blogs in this series will clear some of the myths and misunderstandings about BPM.Especially the relation between BPM and integration is often misunderstood (even by many of the BPM vendors:-). Also, we'll cover BPM in relation to other buzzword technologies like SOA, ESB, Orchestration, and BPEL.

Opinions on BPM systems

 

Opinions on the necessity of BPM systems vary from “It’s always necessary... I couldn’t write software without it” to “up to now, I was able to implement my requirements without a BPM system so I don’t see why I would need one”. So I think it’s time to learn about what BPM is, what the typical myths are and how developers can benefit from it.

 

First, let’s look at the most cited pros and cons. The most often heard benefit is business process agility. But for a typical developer this gets interpreted as “PR-fluff”. In this series of blogs I want to show that there are actually some real benefits for developers as well.

 

Most often heard disadvantages are:

  • “I don’t know it, so I don’t like it” ok... let’s do something about that with these blogs
  • “I just have simple workflow requirements, a workflow or BPM engine is overkill for me” This is because BPM systems tend to be a pain to integrate in simple web- and other applications. Also there is this myth that BPM has to be build on top of XML and web services technology. Working with WSDL, XML and web services is indeed not very light-weight, but what a few people seem to know is that the BPM features can be offered in a plain Java environment *without* any dependency on WSDL and related service oriented technologies. It is a matter of focus. In JBoss jBPM we chosen resolute for simplifying BPM on the Java platform. Offering all of the BPM features in an easy accessible way for the Java developer, ranging from the simplest applications, over common web applications all the way up to a high-throughput, clustered server solution.

 

To put all of this in the right perspective, we are going to start with a look at what BPM is and in which context it can have significant advantages for Java developers.

BPM Introduction

 

Explaining Business Process Management (BPM) makes more sense if we start with providing a working definition of a business process : A business process is a recurring procedure in an organisation to achieve a goal.

 

Without explicit management, business processes tend to grow organically. New procedures have to be created or invented. Mostly, this is done informally, without documenting or thinking about it. Basically, people that are concerned with the goals of the organisation, do a set of activities in order to reach the organisation goals. When many of those activities start to be done frequently, we can speak of a procedure.

 

After procedures are formed, small local changes occur quite frequently. Many small local changes to procedures can lead to overall inefficiencies. BPM can now be defined as the effort to improve the efficiency of an organisation by examining and improving the procedures that are used to reach the organisation’s goals.

IT can improve efficiency of business processes

 

In this section, we’ll explain how the above definition relates to the process management and workflow software packages that can be found in today’s market.

 

In current midsize and large organisations, there is a large amount of information that needs to be processed to execute the business processes. So the big opportunity is to make this processing much more efficient with proper use of IT technology.

 

Developing software for supporting business processes in *not* different from any other software development. So what is then the purpose of the BPM and workflow solutions out there, all with graphical designers and special runtime servers ?

 

Current Object Oriented Programming (OOP) languages are not very suited for defining long running processes. For example the handling of an order through an order processing system. There are many different automated steps in processing one order through the system. In traditional OOP, the state of the order has to be managed manually. What this means is that the developer must add a field in the database that reflects the current state of the order. This state must then be checked and updated in every request related the order. Especially when multiple concurrent paths of execution are involved, this can be complex to think about and hard to debug.

Developers should care

 

Managing the state of long running processes is the key feature why Java developers should care about BPM systems. It abstracts the state management from the business logic and relieves the developer from a tedious and error-prone job. With this capability the developer can structure the software around the overall process (e.g. the order process). This brings the software design much more in sync with the software requirements.

 

Another reason why developers should learn about the BPM technology is the automatic audit trail logging that is included in all the BPM engines. These audit trails provide detailed information about each step in each process. These process logs plus the statistics that can be derived from those logs gets a programmer from the BPM system as an extra. Note that the statistics are highly valued by managers since it allows them to detect bottlenecks and inefficient steps in the processes.

 

The next blogs in the series will dive deeper in the missing features of OOP languages and how we can make the BPM feature set easily available to Java developers.

 

regards, tom.

Filter Blog

By date: