Java Workflow Tooling (JWT)
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
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 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 said genericity.
WE (Workflow Editor) 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
Desktop tools are useful to preview your processes without using any process
engine or to simulate a number of processes.
WAM (Workflow engine Administration and Monitoring tool) 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.
Further information about JWT
Currently there is no further description about this project. For the moment please refer to the