JWT Proposal

Java WorkFlow Toolbox Project (JWT)

Introduction

The JWT project is a proposed open source project under the Eclipse Technology Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. It is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.technology.jwt newsgroup.

Overview

The JWT project aims to provide both build-time and runtime generic tools for workflow engines. It will initially be composed of two tools, WE (Workflow Editor) and WAM (Workflow engine Administration and Monitoring tool). JWT also aims to provide generic APIs for defining and administrating business processes, in order to achieve named genericity.

WE will be a visual tool for creating, managing and reviewing process definitions. Straightforward and simple, WE will let users quickly create workflow process definitions, check and store them for further use. Once a process definition is proved valid, it can be imported/referenced into new ones, thus shortening the time and effort needed to define the workflow process. WE provides several views: for business managers to change the control flow of a process, for technical experts to invoke services, or others.

WAM will be used to deploy and test a workflow in a workflow engine so to handle an engine's process definition external repository, to load some process definitions into a specific Workflow Engine, unload it, update it, instantiate it, monitor the Workflow Engines processes, perform mappings among participant definitions and real users, and among application definitions and tool agents.

Background

State of the commercial BPM tooling market

Companies typically loose productivity and effort because of their IT system being inefficient or not adapted to the existing and reality-grounded business processes. Since companies want to get increased control over their IT systems, they adapt them to their business needs rather than the opposite. This is sometimes called "business driven development" or "top-down approach".

Some major ISVs such as WebMethods, SeeBeyond and others propose a complete galaxy of development and runtime tools that enable this strategy. These tools allow a company to simply define its business processes and map the different activities of the processes to existing technical services or applications. Therefore such tools - and indeed such a strategy - obviously resonate with integration problematics.

However, they have limitations. First, these proprietary tools only have one graphical representation and generate one output format. Second, they can only interact with one specific workflow engine. Third, the fact that these tools are proprietary, closed source projects implies that the diffusion and adoption of the technology is very limited and the benefits of the business driven development are still largely unappreciated.

Evolution of BPM in light of the new information system architecture and integration standards

The arrival of new standards like the JSR 208 (the Java Business Integration, JBI), SDO (Service Data Objects) or SCA (Service Component Architecture) not only means that existing products will change again, but that the time is right for opening up the field and welcome such a new, generic framework that is adaptable to any specific requirements.

The Java Business Integration (JBI) specification proposes a standard solution to integration problems for Enterprise Service Buses (ESB). In such a service platform, the orchestration services are critical proponents in allowing discrete messages to be routed in the context of the global business process. Business process engines providing such orchestration services are already being integrated in JBI solutions (as shown by open source ESBs like Apache ServiceMix? or Objectweb Petals), in a way that is hence bound to be increasingly standardized and tightly linked to run-time and even build-time tools.

On the other side, the SCA specification builds on the SOA philosophy so as to describe a model for assembling composite applications, and therefore encompasses a set of steps that are required in order to deploy most of SOA-style information system architectures. There is a natural complementarity between the SCA-specified architectural model and the vision of information system-wide business dynamics enabled by BPM, and that is exemplified in top-level tooling platforms that, like Eclipse STP or the recent SCOrWare? proposal made by several Objectweb members (including INRIA, Amadeus, Open Wide), aim at easing the development and deployment of SOA and SCA architectures. That's why both SOA models and tooling platforms will concur to better and more standardized BPM tooling.

What JWT proposes

The goal of the JWT project is to develop a set of tools that help to develop, deploy and test workflows. JWT is not just another modeling tool and workflow engine, but provides an adaptable framework for different graphical representations and XML notations, as well as different workflow engines.

The JWT tooling suite is a natural member of top-level tooling platforms that, like Eclipse STP, can be used to ease development targeting integration platforms such as ESBs. Both single users and ISVs can use such set of tools either for direct use or for building a complete development software stack for their integration platform. In such light, one of the natural goals of JWT is good integration with the Eclipse STP platform.

Description

Workflow Editor (WE)

WE will be a tool for the modeling of process definitions. The final output of this process modeling phase is an XML file which can be interpreted at runtime by any workflow engine compliant with the XML format of the process definition. WE will provide four core features :

• Different graphical representations of the process definition

• Export of process definitions to several XML-formats

• Import of valid XML process definition and its graphical representations: process can be defined in several formats (mostly based on XMI) and the graphical figures can be described in an abstract way.

• Additional features easing the development of business processes, like business process validation, business process reuse (in conjunction with the WAM's Process Repository) and semantic matching. Partners of JWT are currently working on several semantic process matching algorithms and procedures which will be included in WE.

WE can be subdivided into two different layers : the graphical representation layer and the grammar definition layer. The intent behind this is to :

• be able to plug in several views for the same workflow definition file: for example, a business manager might want to see other details than an IT expert. Additionally it might be necessary to have one view for the certification of ISO 9000, one for ITIL, and others. Having several pluggable graphic representation will allow us to expose simplified, business oriented user-friendly views of the same workflow definition. Note that Amadeus will contribute on the extensibility mechanism allowing business-specific activities and integrate business specific representation views in the scope of the SCOrWare? project.

• be able to plug in several different grammars for the same representation: this is of particular interest when a graphical representation (such as BPMN or UML) can support different grammars. For example, BPMN can support both XPDL and BPEL. WE will be able to support not only XPDL and BPEL but other proprietary notations (e.g. jPDL from JBoss jBPM) or future standards as well.

As process definitions and graphical representations can vary, we propose to build a generic, extendable framework that enables several representations and grammars to be implemented and plugged in, thanks to a common, pivotal business process definition metamodel. The list of generatable process definitions as well as viewable graphical representation will be extensible.

Workflow engine Administration and Monitoring tool (WAM)

The WAM aims to provide tooling for managing business processes independently of the underlying workflow engine. In order to achieve that, the WAM will rely on a generic workflow engine administration API, whose definition is at the heart of the project.

Building on this API, the WAM intends to implement the following functionalities :

Process definition management :

• Repository Management : The repository management displays all available files in the engines package repository. This is the place where you can manage the repository of the engine. You can upload a new package file from your local machine into the repository or delete one from the it.

• Package Management : The package management displays all packages that are loaded into the engine. It enables you to load and unload packages to/from engine, as well as to update some already loaded packages.

Process execution management :

• Process Instantiation Management : Lets you view the package-process definition tree of the loaded packages. The graphical workflow representation will be used to show the state of execution of the instantiated process.

• Process Monitor : Lets you manage process instances like suspend, stop, view process or activities.

Process runtime resources mapping :

• User Management : Lets you manage the users of the process engine by defining new ones, deleting existing ones or changing their properties.

• Application Mapping : Lets you map a package and its process applications to the real applications handled by a tool agent.

User-oriented process management :

• Worklist Management : Lets you perform the work items of the instantiated processes. As an admin user, you can perform your work items, and you can see work items from others. Also, you have a possibility to re-assign the work item from one user to another.

• "Desktop Business Process" tooling : this is more of a simple, generic use case implementation allowing standalone, desktop-integrated business processes for common end user tasks such as flight booking. Its aim is to provide a ready-to use application out of the box and to open up the BPM field to end user needs.

Fulfilling these requirements will be achieved by :

• Defining a simple, but extensible API for each of the requirements topics, as said before. These APIs will allow vendors to make their own implementation to get their workflow engine managable. JWT will provide default or stub implementations for them, allowing progressive integration of a workflow engine model in the WAM. A generic API to start and stop a workflow engine is the most critical of them, and will be the first step to achieve for the WAM.

• Defining specific workflow engine models, in a similar approach to the one used for J2EE server model in the JST project. These workflow engine models could then be used by end users to define their own engine in their own specific environment. As soon as a workflow engine has been defined by a user, it would be possible to deploy a process definition to this engine. JWT will provide such a model for a specific workflow engine (which will have to be chosen, but will probably be XPDL compliant).

Use cases and demonstrators

As said above, these comprise :

• Dedicated views for business-specific use cases

• "Desktop Business Process" standalone applications

• Various other contributions foreseen by JWT partners

Architecture

JWT's architecture will be based on an MDA approach and will address the several business-specific extensions problematics through the DSL paradigm. The Eclipse framework and libraries will be used in order to provide the required tools. Note that additionnally, Obeo SA (the creator of the Open Source DSL platform Acceleo) will contribute its MDA / DSL expertise to JWT.

Here are some elements furthering and depicting what has been outlined above :

WE Architecture

The WE will allow to plug any process XML-based grammar in the JWT Workflow Model framework and display its graphical representation.

The principles of mapping processes to representations will be based on the Workflow-Model API. This API will identify commonly used entities within a workflow definition model, their relationships and attributes following their XML grammar and map them to a common, pivotal process definition metamodel. This workflow model will be our pivot model which supports all other views.

As a starting point JWT will provide support only for a single grammar and a single representation. Their choice have to be validated, but BPMN and XPDL are strong candidates.

The WE architecture is shown in the following picture :

WAM Architecture

The WAM aims to manage the definition process into a workflow engine. In order to be workflow-engine agnostic, it will allow to define a workflow engine based on a workflow engine model.

This JWT workflow engine model will be first developed as an extension of the basic start / stop / deploy API over BPM engines used in WAM towards a meta-model for the easy adoptation of new server types allowing more extensive server management features.

As a starting point JWT will provide support only for a single workflow engine. Its choice will have to be consistent with the available WE grammar implementation.

The WAM architecture is shown in the following picture :

internal://8059584eb6efbe6c84c37685838caa00.png

Extension points

The strategy to build the JWT project features will be "divide and conquer". Things will be split as much as possible into separate working groups and plugins in order to parallelize work, boost development and provide the ability for other groups or vendors to further extend and customize the functionality in a well-defined manner. In WE as well as between WE and WAM, there will be an architectural decoupling. WE and WAM will, at least, be two separate plugins, but presumably it will take the form of this list of plugins:

For the WE

• Workflow graphical representation

• Workflow grammar definition

Concretely, the WE will take the form of a MultiPageEditor(Workflow Editor) and a wizard composed of :

• Graph view : composed of two graphical viewers. It allows to graphically model processes and activities

• Source view : represents the XML file which it the result of graphical edition.

• Outline view : gives an overview of process' activities.

• Attribute view : based on property view, used to edit entities attributes.

• Entities Property view : based on property view, used to edit the entities properties.

For the WAM

• Workflow engine model

• Workflow monitoring tool :

o Repository Management

o Package Management

o Process Instantiation Management

o Process Monitor

o User Management

o Application Mapping

o Worklist Management

Thus concretely, the WAM plugin will be composed of :

• A workflow engine model in the run menu and the launcher

• The graph view of WE for displaying the state of process instances

• Several views to represent worklist, user management, process instanciation management, application mapping, repository management. These views will have to be defined in detail in the scope of the project.

Integration Points with Other Eclipse Projects

Given the scope of the project, the JWT project will interact with and leverage the following existing Eclipse projects:

• WST (Web Standard Tools)

• GEF (Graphical Editing Framework)

• EMF (Eclipse Modeling Framework)

• GMF (Graphical Modeling Framework)

• STP (SOA Tools platform) has been created at the end of 2005 to provide tooling around the Service Oriented Architecture paradigm, according to the SCA (Service Component Architecture) specification. Therefore JWT's integration with STP is important. Along its primary founders (Iona, IBM, Sybase and BEA), Objectweb is involved as a member of the Project Management Committee, and through the involvement in STP the work at JWT and STP can be aligned easily. Moreover, JWT has been recognized as a natural friend project of BPM-themed STP subprojects, such as STP BPEL and STP BPMN, with whom collaboration will be as thorough as possible. Note that putting JWT's priorities initially on the XPDL grammar and business-level activity representation would make JWT a natural complement to the existing BPMN and BPEL projects, while not precluding any further collaboration.

• Validation frameworks (like the EMF Validation Framework or Recipe from GTM/OAW)

• Callisto

Additionally JWT will have impact on project which are not hosted by Eclipse, e.g.

• The Petals Objectweb ESB solution, which is the outcome of the JoNES project

• The recently approved SCorWare proposal, which gathers several Objectweb members (including INRIA, Amadeus, Open Wide) aims to build an SOA development and deployment platform on top of other ObjectWeb projects.

Organization

The life cycle of this project may be similar to the Equinox project. That is, once this work matures, it may be incorporated into the Eclipse Platform to provide a common open source substrate that industrial/commercial users could use to build solutions. Alternatively, it may continue as a Technology subproject.

Sponsoring Organizations

• ObjectWeb is an international consortium fostering the development of open-source middleware for entreprise applications: ESB, EAI, e-business, clustering, grid computing, managed services and more.

• SCOrWare is a recently approved project funded by european research public funds that aims to develop an SOA development and deployment platform. Its members include INRIA, Amadeus, Open Wide, Obeo, INT Evry. The SCOrWare-produced BPM tooling (comprising business process orchestration, semantic process matching, business use cases and an MDA / DSL approach) will be contributed and integrated in JWT.

• Open Wide is a French company created in 2001 providing services around open source components and a national leader in the entreprise portal integration field. Open Wide's developers are contributing to if not leading some open source projects such as RTAI or GForge. Open Wide has developed one of the first integration platform entirely based on open source components and called NoSICA. It is also part of the ObjectWeb's ESB initiative, of ObjectWeb's distributed, JBI based, ESB framework called Petals / JOnES and of Objectweb's forthcoming SCOrWare SCA platform.

• The Programming distributed Systems lab of the University of Augsburg is researching in the focus on Software Engineering in general and more detailed in the Model-Driven Software Development related to distributed systems. Their core competences are on software engineering, interoperability and software automation in the field of business process modeling, autonomic computing and semantics.

Proposed project lead and board

• Marc Dutoo (Project Lead) – Open Wide

• Florian Lautenbacher (Project Lead) - University of Augsburg, Germany

• Fabrice Dewasmes (Vision Advisor) - Pragma Consult

• Alain Boulze (Market Advisor) - INRIA / Objectweb BEING VALIDATED?

• Miguel Valdez (Technology Advisor) - Bull

• Günther Palfinger (Technical Advisor) - eMundo GmbH, Germany

Interested parties

At this time, the following people and companies have expressed their interest in actively participating to this project:

• Pardeep Sood - Independent Consultant

• Roman Zulauf – Object Engineering GmbH

• Guennadi V. Vanine – Independent Consultant

• Surrendra Reddy – Optena Corp.

• Object Engineering GmbH

• School of Software – Shanghai JiaoTong University

• Yang Guang – Allen Young (Shanghai JiaoTong University)

• Liu Yu – Tony Liu (Shanghai JiaoTong University)

• Sun Zhongyi – Sliver Sun (Shanghai JiaoTong University)

• Xiong Xiao Peng – BeiJing ChiPu network technic limited company.

Initial code contributions

JWT will use as a starting point the "AgilPro" contribution made by the University of Augsburg (through its partnering with eMundo GmbH) which is available here : https://sourceforge.net/projects/agilpro/.

In addition, several other code contributions have been submitted by various companies and individuals :

• Object Engineering GmbH : https://forge.openwide.fr/frs/download.php/83/ObjectEngineering_JWT_Contribution.zip

• School of Software – Shanghai JiaoTong University : https://forge.openwide.fr/frs/download.php/86/Elune_Workflow_Designer.zip

• Open Wide : https://forge.openwide.fr/frs/download.php/88/OpenWide-JaWESwing-contribution.zip

Initial Roadmap

• Prerequisite : decision process on the model

• Decision process on languages (includes studies and proof of concept) and engines

• WE : Making the model flexible. This comprises singleing out extension points in it for grammars, representation views and their business-specific extensions.

• WE : Doing or integrating an actual implementation over a chosen grammar language

• WE : Doing or integrating an actual implementation for a chosen representation language

• WE 1.0 release packaging - aiming at March 2007

• WAM : further decision process in order to chose a prefered engine (includes proof of concept)

• WAM : Process management API design and implementation for the chosen engine

• WAM : Dummy versions of other APIs needed for a basic version.

• WAM 1.0 packaging - aiming at June 2007

• other tracks : other WE extension implementations, SCOrWare contributions, AgilPro contributions...