Bossa Manifesto

Bossa is a workflow engine written in Java. The engine is very fast and lightweight, without sacrificing functionality. Its main strengths are the very expressive Petri net based notation it uses to define workflows and the powerful resource selection mechanisms it provides. Also, it is free software licensed under the GNU GPL.

Bossa does not require a RDBMS and is very simple to use and to integrate with java applications. Actually, it was designed to be embedded. Therefore, Bossa is organized as a library to be used by server side applications (especially web oriented ones) that need workflow services.

The characteristic that makes Bossa at the same time simple and powerful is the clear separation between workflow logic and application logic. We believe that the application's workflow logic should be abstracted in the same way that RDBMSs abstract the application's data storage and retrieval concerns.

In this white paper we describe the philosophy behind Bossa. We start explaining what we call workflow in the section called “Workflow”. Then, we show how to represent workflows using Petri nets in the section called “Petri Nets and Workflow”. Finally, we describe how an application is designed to use Bossa's workflow services in the section called “Bossa”.

Within any organization, people will interact with each other to get their jobs done. Each one of them may have his or her personal list of tasks to be performed. George has to find potential customers and file entries for them in a database. Then, Gwen will get in touch with the customer. Later, Paul will write a project to the customer, and Alice will review it. We can see here that their work is flowing. Each person does his job and passes something to others so they can do their part.

Workflow is a set of rules that govern the sequence of activities to get a bigger and collaborative work done, involving several participants. Workflow management systems automate fully or partially a workflow.

Usually the term "workflow" is used with more broad meanings. The more common alternate meanings relate to the information exchange between the participants of a collaborative work. Document management systems are usually called workflow systems, mostly because they provide means of information exchange and usually do so in an orderly manner. Groupware systems are sometimes called workflow systems by largely the same reasons, organized information exchange.

We are not claiming that document management and groupware systems are not capable of performing workflow, but we believe that handling documents or messages between users is not necessarily a concern of workflow systems. Workflow systems track activities and helps the right people do the right activity at the right time, without regards to the information being exchanged.

Of course, information exchange is necessary for every collaborative application, but we see it as another concern, as workflow itself is. Applications should leave their data storage needs to a DBMS, their presentation needs to a servlet container, their workflow needs to a workflow management system and their information exchange needs to a document management system.

Bossa aims to provide workflow services in the simplest way possible, without sacrificing any power. Therefore, Bossa is totally oblivious of the type of data that it is being processed, manipulated or exchanged by the application. Bossa only concerns itself with the sequence of activities and with the right people to perform them.

Under our definition of workflow, virtually all conceivable collaborative applications, and even some non-collaborative ones, need workflow services. Since Bossa provides these services in a lightweight and unobtrusive manner, we open the possibility of workflow everywhere.

Before we can talk more about how to model a workflow using Petri nets, we need to briefly explain how a workflow is usually seen by a workflow management system and what a Petri net is.

The abstract definition of a workflow is called a case type. For example, a supplies purchase process that defines how all purchases will be performed in a department is a case type. Case types are composed by tasks connected by routing constructs. For example, an "initial analysis" is a task of the "supplies purchase" case type. After this task is performed, other tasks will be enabled depending on the outcome of the "initial analysis" task, these tasks are connected using routing constructs.

A case type defines all possible executions or instances of a process. A individual instance of a case type is a case. For example, the purchase of a box of staples is a case of the "supplies purchase" case type. In a case the tasks of the case type have two different states: an activated task is a work item, a task in progress is an activity. For example, after the "purchase request" task is completed the "initial analysis" task becomes a work item, that is, it can be performed by some user of the system. If an user actually performs a work item, a non-instantaneous action, the task is an activity until it is completed.

Petri nets are a tool for modeling and analyzing dynamic processes. A Petri net is composed by places and transitions and has a standard graphical representation where places are circles and transitions are squares. Places and transitions are connected by directed edges, forming a directed bipartite graph, that is, following the direction of an edge it is only possible to go from a place to a transition or from a transition to a place. Figure 1 shows the graphical representation of a simple Petri net.

Figure 1. A simple Petri net.

Places and transitions represent the static aspect of a Petri net, the dynamic aspect is represented by tokens. A token is a mark that can only be in places and that changes places according to the firing of the transitions. In classical Petri nets, when a transition fires it consumes exactly one token for each input (places with edges going to the transition) and produces exactly one token for each output (places with edges coming from the transition).

Classical Petri nets are not enough for modeling the more sophisticated routing constructs a case type demands, so we use colored Petri nets. The discussion of classical and colored Petri nets is well beyond the scope of this document. Briefly, in a colored Petri net, each token has a color and the firing of a transition consumes and produces a number of tokens as a function of the token color, while in classical Petri nets they consume and produce exactly one token for each edge. To represent how many tokens a transition consumes and produces we use weighted edges, where a weight is an integer expression. Then, when a transition fires it consumes a number of tokens equal to the weight of the edge for each input and produces a number of tokens equal to the weight of the edge for each output.

A Petri net workflow representation maps places to possible states of the case execution, transitions to tasks and tokens to the current case state. Figure 2 shows the "supplies purchase" case type as a Petri net.

Figure 2. A purchase department case type.

Let's briefly analyze a task of the "supplies purchase" case type. Task "b" is the "initial analysis" task. It has inputs coming from the place "B", the "waiting initial analysis" place, with a constant weight of 1. This means that whenever there is one or more tokens in place "B" the task "b" is a work item and able to fire.

The tasks (transitions) in a case type don't fire at random as in classic Petri nets, but they are performed by a resource. Task "b" can be performed by the resource "sales - $a", this means that only the users of the "sales" group minus the users that performed task "a" can perform (fire) this task once it is activated. Resources are defined by set expressions (with exclusion, union and intersection operators) using user groups and the "$" special groups of users that performed a task.

Task "b" has as outputs the places "C", "D" and "E". Place "C" is the "waiting revision" place and has output weight "!SOK". Place "D" is the "waiting director approval" place and has output weight "SOK && DIR". Place "E" is the "waiting file approved purchase" place and has output weight "SOK && !DIR". Here we start exploring the specific way Bossa defines a case type. Each of the output expression is a JavaScript expression that will be evaluated to an integer using case variables set during the case execution.

According to actions performed by the resource, the application will set appropriate values of the case variables. After task "b" if the purchase request does not pass the initial analysis the variable SOK will be set to false. If it passes the initial analysis SOK will be true and DIR will be set to true or false if the director approval is necessary or not. So, when the task "b" fires one token will be removed from the place "B" and one token will be placed in either places "C", "D" or "E" depending on the values of the case variables.

The task "b" represents what is usually called in workflow modeling an and-split. In Bossa we are not restricted to common workflow routing constructs. Using edge weights and case variables we can route the case tokens with great power and flexibility.

Now that we presented what workflow is and how to model case types using Bossa's Petri net notation, we can talk some more about what Bossa is and how to use it.

Simply stated, Bossa is a workflow engine organized as a library in Java. This means that Bossa is not a stand alone server, but a set of Java classes that can be used to create a private workflow engine embedded in Java applications. Thus, Bossa does not concerns itself with several problems server processes must deal with, such as: connections, sessions, authentication, etc. It relies on the application to handle these problems. The application in turn will probably use some framework, such as an J2EE application server, to help in providing these services. This gives the designer greater freedom to build its application with any technology he has available or enjoys using.

To the Bossa engine, users are known as resources and are only identified by a string id. Bossa uses this id to place the resource in resource groups and to test if a resource is present in a resource expression. Bossa does not registers users, authenticate users or store any information, such as name or address, about the users. Bossa will present the work items a resource can perform, but will not check if the resource really can perform the work item. It is the responsibility of the application to authenticate and authorize its users and map them to Bossa's resources.

Associated with each active task (work item) there will be the case id and the task id. Bossa stores no other data about a work item and does not know how to actually perform a work item. Specially, it will not present information relevant to the work item execution, it will not execute the work item's business rules and it will not persist its execution. The application is responsible for these activities, using the best tools available. It must choose what to do using the work item data and, after completion, it notifies Bossa the work item is complete.

The expected way an application that uses Bossa should work is similar to this: the application will create a Bossa instance, it will register case types and resources if necessary. After this setup, the application will receive and authenticate its users as it desires, then it may ask Bossa the work items available to a user, the application will choose one among the possible work items (possibly asking the user) and will inform Bossa the user will work on it. Only the application knows how to assist the user in the completion of this work item and, after the work item is completed (or canceled), the application will notify Bossa of the outcome, setting case variables if necessary.

In this white paper we explained the philosophy behind Bossa and gave a very brief description of how to model workflows using Petri nets and how to integrate the Bossa workflow engine into an application.

The Bossa project is still new and we do not yet provide documentation as comprehensive as we would like. For the time being, besides this document, the best source of information is the API HOWTO, the full Bossa API documentation and the source code itself (specially the tests and examples).