In this article, the following key points will be covered:

• Common development process
• Decoupling processes from our applications
• Graph Oriented Programming
  • Modeling nodes
  • Modeling transitions
  • Expanding our language
• Implementing our graph-oriented solution in Java
• Wait states versus automatic nodes
• Executing our processes

Let’s get started with the main cornerstone behind the framework. This article will give us the way to represent our business processes using the Java language and all the points that you need to cover in order to be able to represent real situations.

Graph Oriented Programming

We will start talking about the two main concepts behind the framework’s internal implementation. The Graph Oriented Programming (GOP) approach is used to gain some features that we will want when we need to represent business processes inside our applications. Basically, graph oriented programming gives us the following features:

• Easy and intuitive graphical representation
• Multi-language support

These are concepts that jBPM implementers have in mind when they start with the first version of the framework. We are going to take a quick look at that and formulate some code in order to try to implement our minimal solution with these features in mind.

Starting with GOP as a bigger concept, you will see that the official documentation of jBPM mentions this topic as one of the most important concepts behind the framework. Here, we will reveal all of the advantages that this approach implementation will give us. Basically, by knowing GOP, we will gain complete knowledge about how processes are represented and how they are executed.

Therefore, a common question here is, why do we need a new approach (GOP) for programming our processes when we have already learnt about the object-oriented programming paradigm?

Common development process

In order to answer the previous question, we will quickly analyze the situation here. To achieve this, we need to understand the nature of our processes. We will also analyze what kind of advantages developers gain when the business process information is decoupled from the rest of the application code.

Let’s clarify this point with a simple example. Imagine that we have to build an entire application that represents the stages in the “Recycling Things Co.” example previously presented. The most common approach for a three-tier application and development process will be the following:

This is a traditional approach where all the stages are iteratively repeated for each stage/module of the application.

One thing that we can notice here, and which happens in real software projects, is that the business analyst’s description will be lost in the design phase, because the business analyst doesn’t fully understand the design class diagrams as these diagrams are focused on implementation patterns and details. If we are lucky and have a very good team of business analysts, they will understand the diagrams. However, there is no way that they could understand the code. So, in the best case, the business analyst description is lost in the code—this means that we cannot show our clients how the stages of their processes are implemented in real working code. That is why business analysts and clients (stakeholders) are blind. They need to trust that we (the developers) know what we are doing and that we understand 100 percent of the requirements that the business analysts collect. Also, it is important to notice that in most of the cases, the client validates the business analyst’s work—if changes emerge in the implementation phase, sometimes these changes are not reflected in the business analyst’s text and the client/stakeholders never realize that some implementation aspect of their software changes.

Maybe they are not functional changes, but there are sometimes changes that affect the behavior of the software or the way users will interact with it. This uncertainty generated in the stakeholder causes some dependency and odd situations where the stakeholder thinks that if he/she cannot count on us (the developers and architects team) any longer, nobody will be able to understand our code (the code that we write). With this new approach, the client/stakeholders will be able to perceive, in a transparent way, the code that we write to represent each business situation. This allows them (the stakeholders) to ask for changes that will be easily introduced to reflect everyday business requirements. Let’s be practical and recognize that, in most situations, if we have the application implemented in a three-tier architecture, we will have the following artifacts developed:

Database model

That includes logic tables to do calculations, UI tables to store UI customizations or users’ data about their custom interfaces, domain entities (tables that represent the business entities, for example, Invoice, Customer, and so on), and history logs all together.

Business logic

If we are careful developers, here we are going to have all of the code related to a logical business processes method. In the case of the example, here we will have all the stages represented in some kind of state machine in the best cases. If we don’t have a kind of state machine, we will have a lot of if and switch statements distributed in our code that will represent each stage in the process. For example, if we have the same application for all the branches of a company, this application will need to behave differently for the main office’s employee than for the ‘just finished’ warehouse employee. This is because the tasks that they are doing are very different in nature. Imagine what would happen if we want to add some activity in the middle, probably the world would collapse! Developers will need to know in some depth how all the if and switch statements are distributed in the code in order to add/insert the new activity. I don’t want to be one of these developers.

User interfaces

Once again, if we are lucky developers, the process stages will not be represented here, but probably many if and switch statements will be dispersed in our UI code that will decide what screen is shown to each of the users in each activity inside the process. So, for each button and each form, we need to ask if we are in a specific stage in the process with a specific user.

Decoupling processes from our applications

By decoupling the business process from these models, we introduce an extra layer (tier) with some extra artifacts, but this helps us to keep the application simple.

This new paradigm proposed here includes the two Business Process Management (BPM) roles in all the development and execution stages of our processes (business analysts and developers). This is mainly achieved through the use of a common language that both sides understand. It lets us represent the current process that the business analysts see in the everyday work inside the company, and all of the technical details that these processes need, in order to run in a production environment. As we can see in the next image, both roles interact in the creation of these new artifacts.

We don’t have to forget about the clients/managers/stakeholders that can validate the processes every day as they are running them. Also, they can ask for changes to improve the performance and the current way used to achieve the business goal of the process.

On comparing with the OOP paradigm, class diagrams here are commonly used to represent static data, but no executional behavior. These newly created artifacts (process definitions) can be easily represented in order to be validated by our clients/stakeholders. One of the main advantages of this approach is that we can get visibility about how the processes are executed and which activity they are in at any given moment of time. This requirement will force us to have a simple way to represent our business processes—in a graphicable way. We need to be able to see, all the time, how our production processes are running.

Graph Oriented Programming on top of OOP

Here, we will discuss the main points of the Graph Oriented Programming paradigm. With this analysis, we will implement some basic approach to understand how we use this paradigm on top of the Java language in the next section.

In order to do that, we need to know the most important requisites that we have to fulfill in order to achieve the goal which integrates, maintains, and executes our business processes in real-world implementation:

• Easy and intuitive graphical representation: To let the business analysts and developers communicate smoothly and to fully understand what is happening in the real process.
• Must give us the possibility of seeing the processes’ executions in real time: In order to know how our processes are going on to make more accurate business decisions.
• Could be easily extended to provide extra functionality to fulfill all of the business situations.
• Could be easily modified and adapted to everyday business (reality) changes. No more huge development projects for small changes and no more migrations.

Implementing Graph Oriented Programming on top of the Java language (finally Java code!)

With these requisites, presented in the previous section, in mind, we are able to implement a simple solution on top of the Java language that implements this new approach (called the Graph Oriented Programming paradigm). As the name of the paradigm says, we are going to work with graphs—directed graphs to be more precise.

A graph can be defined as a set of nodes linked to each other as the following image shows us:

If we are talking about directed graphs, we need to know that our nodes will be linked using directed transitions. These transitions will be directed, because they will define a source node and a destination node. This means that if we have a transition that has node A as the source node, and node B as the destination node, that transition will not be the same as the one that has node B as the source node, and node A as the destination node. Take a look at the following image:

Like in the object-oriented programming paradigm, we need to have a language with specific set of words (for example, object) here. We will need words to represent our graphs, as we can represent objects in the object-oriented paradigm. Here we will try to expand the official documentation proposed by the jBPM team and guide the learning process of this important topic. We will see code in this section and I will ask you to try it at home, debug it, and play with this code until you feel confident about what is the internal behavior of this example.

Let’s get started first with the graph definition and with some of the rules that the graph needs to implement, in order to represent our business processes correctly.

Up until now, we have had two concepts that will appear in our graph oriented programming language—Node and Transition. These two concepts need to be implemented in two separate classes, but with a close relationship. Let’s see a class diagram about these two classes and make a short analysis about the attributes and methods proposed in this example.