Mbirn: Workflow Update 2-2-2006

BIRN Workflow Executor

Introduction

Build a architecture that will execute and monitor various different workflows applications. Users will be presented with a list of predefined workflows, once selected they will be required to enter the information needed and will be able to monitor the results

Process

The business logic involved in the workflow executor is broken down into the following steps. First, the user is authenticated against the BIRN portal, which is running gridsphere. Once they are authenticated, they are able to upload data to the SRB (Storage Resource Broker), which could be used with the workflows. One of the portal portlets is the workflow manager. In this portlet, the user is able to list currently running and previously run workflows, terminate a running workflow, or start a new workflow. If they select to execute a new workflow, they will be presented with a list of available workflows. Once they select one of these workflows, the required parameters will need to be entered in order for the workflow to run successfully. Once the workflow has started, status information will be emailed to the user, if it has terminated or finished successfully. Interprocess status will be provided, under the condition that the remote workflow engine provides it.

Architecture

The architecture that will execute and monitor various different workflows engines will be jBpm, written by the Jboss Group. Once the user had authenticated against the gridsphere framework, their credentials will be provided to jBpm thru the org.gridlab.gridsphere.services.core.security.auth and org.gridlab.gridpshere.portlet method calls. Using these credentials jBpm will be able to lookup any workflows that are owned by this user. This will be achieved by using jsp pages that will call the org.jbpm.webapp.bean and org.jbpm.taskmgmt,.exe methods. JBoss has provided a jbpm.war file which contains sample code to achieve the executing and list. Once a workflow has been selected, a corresponding jsp file will be displayed that will contain a form with the required parameters needed for the workflow. Future version of this application may make it possible to parse a XML file to dynamically generate the html form. The form can contain radio buttons, input fields or select boxes. If select boxes or radio buttons are used, the value will need to be acceptable values for the workflow. The name field in all three will correspond to the variable name in the workflow. Once the user has entered the data, 2 options are possible. In the case of kepler, using the ptolmey.vergil.VergilApplication method, the name of the MoML workflow and the variables will be passed in. GEON (http://portal.geongrid.org:8443) has an example of a user entering data and running a kepler workflow through a web interface based on input information as described below. In the case that passing in workflow parameters is not possible, the xml based workflow will be run thru a xslt transformation process to hardcode the variables into a new MoMl workflow, which will be used as the executed workflow. This might be the case needed for other workflow engines. The current version of this application, will use the standard jBpm schema of its database, but instead of using the default hypersonic database a Postgres or Oracle database will be used instead. I don’t foresee any changes to the schema in the current version.

Development/Production Environment

The required software is GridSphere 2.1.2, Apache Tomcat 5.5.12, Kepler 1.0 Alpha 8, Loni 3.0 and jBpm 3.0.2. The deployment will consists of two web applications, the gridsphere (gridsphere) and the BIRN workflow (birnworkflow). Within the BIRN workflow,, the skeleton will be based on (ant new-project) from within the gridsphere environment. This will create everything needed to start make a portlet based on the JSR Portlet specification. Running the jBpm workflow, we have two options, one is to run it within the tomcat environment in the BIRN workflow web application and the other is to have it run in standalone mode, as a separate application. I am going to implement the standalone application, so that the web application and worflow application can run on separate machines if needed. Within the BIRN workflow web application, the following jars will be in the WEB-INF/lib directory: jbpm-3.0.2.jar (349K). This will be needed in order for the web application to communicate with the jBpm process. The jBpm process will contain the kepler and loni workflow engines. For the kepler workflow engine, the following two jars are needed kepler.jar (16M) and kepler-config.jar (899K).

Screenshots

Screen which will allow users to run a new workflow, by selecting the workflow by name

A sample workflow, which requires user input before continuing.

List of workflows that are currently running or finished and the status of them