Cibeles

Cibeles is a light-weight state machine that uses Petri-net semantics to describe and execute workflows. Cibeles is currently embedded software, which means that it requires a host application.

Cibeles is licensed as open source under the 3-clause BSD-license.

You can download the latest release of Cibeles from here. The distribution includes pre-built binaries, all the source code and examples (under the junit subdirectory). You will need Maven in order to build from the source. CVS repository is here.

Your comments, bug reports and patches are very welcome. You can write to me.

The input to Cibeles are XML files defining the flow to be executed. The key concepts in the flow definition are activities, processes and transitions.

• The Activity is the basic non-composite unit of a workflow. An Activity keeps in internal STATE that defines whether the Activity has started, is running, or has completed. The start state of an Activity is reached implicitly when its predecessors reach the completed state. An Activity has input and output products/data, called Parameters. Before an Activity can start, all its input parameters must be available (of course this is correlated to the predecessors' state).
• Activities are realized by an implementation. The implementation of an activity is a physical resource, which can be a Java method, a web service, a backend call, an operator request, a call-center request, or even a whole corporate department responsible for approving purchase orders. The implementation must respond to request state changes and state queries issued by the Cibeles engine. The implementation has also input and output data, called resources. Parameters from the Activity must be mapped to resources.
• A Process is the composite version of the Activity. A Process is similar to an Activity, but instead of being realized by an implementation, it is realized by Activities or other Processes. A Process, like the Activity also has input and output parameters. Both Process and Activity are types of the abstract entity Execution Object.
• A Transition defines the links between Execution Objects, regardless of whether they are Processes or Activities. A Transition defines and start Execution Object, an end Execution Object, and zero or more Connections. A Connection is a input/output data mapping: it defines what data must be made available to the end Execution Object from the start Execution Object once the completed state is reached in the start Execution Object. A Connection connects one parameter from the start Execution Object to one parameter from the end Execution Object.

This first implementation of Cibeles supports exclusively Java calls. A set of XML files are used to define the signature of the Java resources. The current implementation allows calling constructors, class methods (static) and object methods. Note that public fields are not supported yet.

The resource implementation uses optimized Java reflection to obtain the methods and constructors to use. Object instances and return types can be mapped to activity parameters. It is possible to create an object in one activity and call a method on that object on the next activity. Our objective in providing this feature was to allow transforming UML sequence diagrams directly to execution workflows.

The current implementation can obtain any Java type, also including Java primitive types, such as int, boolean, float, etc. The only missing type in the resource implementation is the object array, but we should soon provide this too.

A number of people have asked our opinion about the numerous workflow definition languages, and which one of these Cibeles will support in the future.

Business-To-Business (B2B) marketplaces have clearly a huge potential. All the big software vendors are aware of this potential, and they are positioning themselves as the market leaders in this area. Web services solves some of the problems of building a B2B marketplace, but web services are only the top of the iceberg.

The true interoperability of web services, which would allow service aggregation into inter-organizational business processes, require a firm and simple standard.

So if one standard is what it takes to ensure the success of B2B marketplaces, how come there is so many acronyms out there: BPML, ebXML, WPDL, WSFL, BPEL, BPEL4WS, XLANG, WSCI, ... How do differ from each other? How come the same vendors endorse competing specifications? And most importantly, which one should I adopt in my organization?

My advice to you is to look into the products, rather than the standards. Select a product that best fits your needs rather than doing a selection based on the standard. Key products you could look at are COSA, HP Changengine, Forte Conductor, I-Flow, InConcert, MQ Series Workflow, R/3 Workflow, Staffware, Verbe, BizzTalk, and Visual Workflow. The vendors behind these products are Fujitsu, Intalio, SAP, IBM, BEA, SUN and Microsoft.

All these vendors propose new standards as a rewritten form of their product specifications. Each new product release comes with a new product specification, and a new or updated standard to support it.

Among the existing standards, there are three we have taken a closer look at: BPML, WSCI and BPEL4WS.

• BPML stands for the Business Process Modeling Language, authored by Intalio, with support from SAP and Sun, and sponsored by the BPMI.org initiative. BPML is a modern and simplified version of the overly complex WPDL, a standard by the Workflow Management Coalition. BPML includes a rich language for defining business logic and covers many workflow patterns. It supports transactions, persistence, and WSDL activities.
• WSCI stands for the web services choreography interface, submitted as a W3C proposal by Intalio, BEA, SAP and Sun. WSCI "describes the flow of messages exchanged by a web service participating in choreographed interactions with other services". WSCI is not a business process modeling language, and just focus on the choreography aspects between web services.
• BPEL4WS stands for the Business Process Execution Language for Web Services, authored by IBM, and supported by Microsoft, SAP and BEA. BPEL4WS is the result of merging IBM's BPEL language (based itself on WSFL, which originated on MQ Series Workflow), with Microsoft's XLANG language (supported by BizzTalk).

WSFL is very similar to the Cibeles process definition schema. As WSFL has now been superseded by BPEL4WS, we will adopt BPEL4WS in Cibeles. Given the support from IBM and Microsoft, BPEL4WS is likely to become the only standard supported by both J2EE and .NET architectures.

There are still a lot of things required to make Cibeles powerful enough to be able to address the complexities of Business-To-Business (B2B) eCommerce and the management of inter-organizational business processes. We hope to be able to build up Cibeles one day into a full web-services workflow management system.

1. Allow flow definition and resource definition to be in multiple input files.
2. Implement support for object arrays.
3. Create a generic codebase for Java/C#.
4. Write resource definition file generation tool.
5. Provide a configuration API for different implementations of Resource.
6. Provide a syntactic analysis tool (e.g. to detect cyclic patterns).
7. Provide a WSDL resource implementation.
8. Introduce support for inter-operable messaging.
9. Create a host application.
10. Adopt the BPEL4WS.
11. Provide a (web) monitoring interface.
12. Provide a (web) deployment interface.