Java Workflow Tooling (JWT)
State of the commercial BPM tooling marketCompanies 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 standardsThe 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 proposesThe 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 others.
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.