Process Description Schema

Twister will heavily rely on the BPEL4WS specification for process description. We feel that this specification is mature enough and enjoys enough market support to become the equivalent of WSDL for workflow systems.

The first releases of Twister won’t support 100 per cent of the BPEL specification but a smaller subset of features. We feel that the most important point is to release as quickly as possible a fully functional solution and that not all elements of BPEL are necessary for a lot of needs. But the supported perimeter will be extended later on until we reach a 100 per cent compliance.

The main features that are going to be left out in the first increments are compensation and abstract business process specific constructs. We feel that it’s still little bit early for a large acceptation of public business processes so we rather concentrate on private executable processes and extend later on the process engine to abstract processes.

Web Services

As Twister will have to be published as a Web Service and will also have to discuss with other Web Services, we are going to use Apache Axis to provide these functionalities. In later versions we could rely on J2EE 1.4 to provide the same functionalities but still plan to support both solutions.

The default web container will, of course, be Apache Tomcat.

Server Environment

A workflow engine needs to run like a daemon, always ready to listen to new incoming messages. This daemon capability will mainly be provided by the web server and the servlet container.

We could later on, if there is such a need, provide additional communication interfaces for Twister services, like RMI.

Twister process designer, process engine and work list manager will also be provided with JMX MBean wrappers as it’s the standard for Java components management.

Persistence

Twister will use Hibernate as its persistence framework. Entity beans are not well suited for a process engine as the implementation needs a lot of genericity and therefore requires inheritance.

The use of Hibernate will make Twister relatively database agnostic, supporting all databases supported by Hibernate. However Twister will be developed using MySQL and tested on both MySQL and Oracle. An XML database like Apache Xindice could also be used if there is a need to locally save parts or whole of a process definition, or a WSDL description.

Additional Service

A runtime interpreter is necessary to evaluate the expressions and assignments of the process description. The process engine will rely on it to execute processes following the description and decide appropriate flow routing.

The interpreter we’re going to use is Jython but an additional layer will have to be built to support XPath expressions and BPEL constructs and also to persist the interpreter state.

A scheduler is also necessary to support time-constraint activities, specific schedulers will be used until all application servers implement a standard scheduling service.

Testing

All Twister components will be strongly tested, providing a lot of atomic tests as well as complete testing scenarios. All our tests will be using the JUnit framework. Our testing process follows Continuous Integration principles.

Development Environment

We are using Apache Maven for compilation, distribution, dependency management and documentation generation and publishing as well as for all those little things Maven do so well. Of course, CVS is our source management system.

Our development process is mainly inspired from eXtreme Programming and Agile methodologies.

As we don’t want to reinvent the wheel, Twister will use a wide variety of other Open Source products and projects but a particular attention will be t aken to ensure the ease of installation, configuration and deployment. We’re conscious that a complex piece of software using other complex pieces of software can get very tricky to get familiar with and will therefore provide comprehensive installation, configuration and deployment instructions as well as several out of the box distributions.

Graphical User Interface

The development of a graphical tool to create BPEL process descriptions is not planned right now. It could, in the future, if no suitable tools are created but our priority right now is the process engine. Processes can still be written directly in XML (for the heroes) or using nice tools like Altova XMLSpy or BPWS4J plug-in for Eclipse.

However the work list manager will be provided with few JSPs (probably using Apache Struts) to provide a simple front-end to manage work items.