Version 24
Created by heiko.braun on Oct 29, 2008 5:30 PM. Last modified by heiko.braun on Jan 20, 2011 10:45 AM.

    Project information

     

     

    Related topics

     

     

    Overview

     

    console_sample.png

    The client side uses GWT and additionally relies on GWT-Mosaic. 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-console-arch.jpg

    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.

     

     

    NOTE: The server module needs to be deployed on a running jboss instance, along with jbpm.
    The easiest way is using the installer as described here: http://www.jboss.org/community/docs/DOC-12863

     

    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 (or any other process engine)

     

     

    3. Launch/debug the GWT app itself

    cd gui/war

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

# hook up a debugger
mvn gwt-maven:debug

    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