Project information

• Source repository: https://svn.jboss.org/repos/jbpm/projects/gwt-console/trunk
  Anonymous access: http://anonsvn.jboss.org/repos/jbpm/projects/gwt-console/trunk/
• Forum: jBPM Developer Forum , JBoss GWT Developer
• Issue tracking: https://jira.jboss.org/jira/browse/JBPM
• Blog: http://relative-order.blogspot.com/
• IRC: irc.codehaus.org#jbpm
• ohlog.net: https://www.ohloh.net/projects/jbpm-gwt

Related projects

• Report server (BIRT integration)

Overview

The client side uses GWT and additionally relies on GWT-Ext. There is an intermediary facade build on RESTeasy (JSR311) which uses Json encoding. The console server itself is decoupled from concrete jBPM implementations through an integration layer,

which needs to be implemented by managed runtimes. The following picture shows a high level overview:

GWT Application

The client side use GWT 1.5 and currently relies on the GWT-Ext extensions. Recent discussions show that it's quiet likely that we are going to move away from GWT-Ext due to a change in their license model, but for now it enables us to get things done quickly. The client application shares a domain model (DTO) with the REST facade and json encoded data for the backend integration.

Console Server

The server is build on RESTeasy, a JSR 311 implementation. It allows for rapid publishing of REST resources and has out of the box support for "application/json" and "text/xml" marshalling. Support for specific content types can easily be extended, which can become important when extending the BI/BAM capabilities (think PDF or Image generation). REST was chosen over GTW RPC for several reasons:

• Decoupling of client and server (See "Testing the GWT console")
  
• Extendable content types
• Support for non  GWT clients, i.e. the eclipse tooling
• Simplified development model (i.e curl)

Integration Layer

The integration layer decouples the console server from the managed BPM runtime. Both the GWT application and the intermediary layer share a domain model which needs to be adopted by concrete BPM implementations. Differences between jBPM3 and jBPM4 will be tackled at this level.

Project structure

If you take a look at the maven build structure, you'll find  the modules: RPC,Server and WAR.

• RPC: Shared domain model between the GWT app and the console server
  
• Server: The REST facade plus integration layer
• WAR: The GWT application itself and test suite

The server and war modules create distinct web applications which can be deployed separately. This allows you to deploy the REST facade on  a running JBoss AS instance, while still developing in GWT hosted mode. The test suite  does rely on this mechanism as well. It's necessary, because the DAOFactory implementation usually require server resources like EJB's, Datasources, etc.

Build and test the console

The console is build within the WAR module. It relies on the maven-gwt plugin, which automatically downloads and install a GWT bundle specific to your OS. Detailed information goals, setup and examples can be found here .

Follow these 3 steps to get started:

1. Build the whole package:

cd gwt-console/trunk
mvn install

2. Make sure the gwt-console-server.war is installed along with jBPM

• Building jBPM4 from source

3. Launch/debug the GWT app itself

cd war

# compile and launch in hosted mode, requires the REST facade to be deployed
mvn gwt:gwt

# hook up a debugger
mvn gwt:debug

# execute both junit tests and specific GWT tests 
mvn test

Roadmap and Releases

The gwt console ships as optional installation component with the jBPM installer (beginning 3.3.0.GA). Since it has a dependency on the jBPM runtime it will follow the same release cycle, which every 8 weeks. Details on the jBPM roadmap can be found here .

Problems?

Ask for help at irc.codehaus.org#jbpm