XFLOW Process Management System

What is XFlow?

XFlow is a pure J2EE platform for building, executing and managing business processes and workflows. It is a basis for building collaborative applications as well as integrating processes across an enterprise. XFlow has a small footprint but is extremely powerful. It is designed to be easy to use from the development, deployment and management standpoints.

XFlow runs within an EJB and servlet container. JBoss 4.0 (with bundled Tomcat) is the container used in this implementation. The architecture supports distributed and parallel processes within an organization's firewall as well as across organizational boundaries.

XFlow is designed for scalability, extensibility and ease of integration with security models and legacy processes. XFlow's service-oriented architecture supports both a simple Java API as well as a web-service (SOAP/HTTP) interface.

The following diagram shows a conceptual view of XFlow:


Any application or component may be a participant process in XFlow. A participant process is associated with a specific node in a workflow graph. A process receives work items from the XFlow server in its inbox, performs work on the item and returns the item back to the server for routing to other participant processes. Processes communicate with the XFlow server via a client API or via web-services. Examples of participant processes can be any one of the following:

Features

Here are the main key features of XFlow:

1. Executes and manages workflows across local and distributed processes.
2. Enables process collaboration within a workflow.
3. Support for n-level workflow hierarchies.
4. Rule-based routing of work items
5. Work items may be Java objects or XML
6. Parallel flows
7. Meta-data can be associated with work items.
8. Meta-data can be associated with a process definition.
9. Versioning of workflow models
10. Synchronous and Asynchronous interfaces
11. Ability to view workflow states anytime, anywhere.
12. Pluggable authentication/authorization security modules
13. Event publishing

Forthcoming features in the pipeline include:

1. GUI Workflow Model Editor
2. GUI Dashboard/Admin Console
3. Timeouts and Escalations
4. Complex routing rules
5. Work Item routing history
6. JMX support
7. XA Transactions

Architecture

The following diagram shows an overview of the XFlow architecture:



The heart of the XFlow system is the XFlow Processor. The XFlow Processor is a Message Driven Bean that runs in an EJB container. An advantage of Message Driven Beans (MDB) is that they can be pooled and load-balanced, a boost for scalability. The processor listens for XFlow requests, services them and returns XFlow responses. XFlow requests and responses are serialized Java objects in the XFlow protocol package. Communication between the client and the MDB is synchronous over JMS.

Clients may also use web-services to communicate with the XFlow server. On the server-side, Axis is used to intercept the web-service requests and pass them on to the XFlow Processor. In this case, XFlow requests and responses are encapsulated as SOAP messages flowing over HTTP.

The XFlow processor uses the services of four main components:

1. XFlow Rules: This component is responsible for evaluating routing rules. It uses reflection for evaluating XFlow rule expressions and Jaxen for evaluating XPath expressions. The former is used when the payload of a work item is a Java object and the latter is used when the payload is XML.

2. XFlow Graph: The graph component is used to manage workflow models. A workflow model is represented as a directed graph.

3. XFlow Security: The security component provides user authentication and authorization services. It supports plug-ins of external security modules.

4. XFlow Events: The events component is used to publish significant workflow events in the system which may then be captured by any application that registers interest in these events. For example, an application could be a data-warehouse or a reports system.

Deployment View

The following diagram shows the deployment view of XFlow.



In our reference implementation, The XFlow Processor is deployed in the JBoss EJB container and XFlow web services are deployed in Tomcat. The diagram shows two types of clients:

1. An XFlow web-services client using SOAP/HTTP
2. A regular XFlow client using serialized Java/JMS.

The web-services client is shown to be communicating over a fire-wall and the regular client within the firewall. Although this is the typical case, you could have deployment scenarios where clients use web-services exclusively regardless of where they are located or scenarios where XFlow clients send JMS messages across a firewall.

One advantage of using a regular XFlow client is that work items can be asynchronously delivered to the client. A web-services client must poll for work items from its inbox.

Finally, a JDBC-compliant persistent store is used by the XFlow Processor to store workflow models, inboxes and workflow states.
In this implementation, we use Hypsersonic SQL embedded within JBoss.