Jump to: navigation, search

Difference between revisions of "JWT Monitoring"

(Implementation)
(Monitoring workflow engine in JWT)
Line 1: Line 1:
= Monitoring workflow engine in JWT =
 
 
 
== Introduction ==
 
== Introduction ==
 
We want to give to JWT the ability to monitor workflow engines (ie AgilPro, Bonita...) at thein runtime; to give the user the ability to check the state of a workflow from Eclipse.
 
We want to give to JWT the ability to monitor workflow engines (ie AgilPro, Bonita...) at thein runtime; to give the user the ability to check the state of a workflow from Eclipse.
Line 18: Line 16:
  
 
* SCA is aimed to make binding between several components (eg a Workflow Engine that promotes a service to monitor it, and a client to this service that monitor it in another application...) become more abstract. When possible, we could use SCA to manage theses bindings in JWT.
 
* SCA is aimed to make binding between several components (eg a Workflow Engine that promotes a service to monitor it, and a client to this service that monitor it in another application...) become more abstract. When possible, we could use SCA to manage theses bindings in JWT.
 +
* We could provide a composite generator binary (for SCA) in the base plugin. This is possible by adding a binary without problem of license (see java2wsdl binary in STP), so that it could be part of an official release.
  
 
== Screenshot ==
 
== Screenshot ==
  
 
These are a screenshot of what we currently have. Obviously, it can be improved...
 
These are a screenshot of what we currently have. Obviously, it can be improved...
[[Image:jwt_monitor1.jpg]]
+
 
[[Image:jwt_monitor2.jpg]]
+
[[Image:jwt_monitor1.jpg|500px]]
[[Image:jwt_monitor3.jpg]]
+
 
[[Image:jwt_monitor4.jpg]]
+
[[Image:jwt_monitor2.jpg|500px]]
[[Image:jwt_monitor5.jpg]]
+
 
 +
[[Image:jwt_monitor3.jpg|500px]]
 +
 
 +
[[Image:jwt_monitor4.jpg|500px]]
 +
 
 +
[[Image:jwt_monitor5.jpg|500px]]
  
 
== Implementation ==
 
== Implementation ==

Revision as of 10:49, 21 April 2008

Introduction

We want to give to JWT the ability to monitor workflow engines (ie AgilPro, Bonita...) at thein runtime; to give the user the ability to check the state of a workflow from Eclipse.

Ideas

  • We think that "monitoring a workflow" is a synonymous for "getting full workflow state"
  • To define a workflow state, we need a generic API to define a workflow. This API must fit with most of workflow engines.
  • The monitoring tool must be able to support several workflow engines, and several ways to access them (WebService, RMI, ...)

Concretely

  • As this work has been done in the context of SCorWare SCA project, first implementation is done with the aim of monitoring a Workflow Engine (Bonita) through WebServices. SCorWare uses CXF webservice engine, with Aegis databinding. That is the only technologies that are currently supported.
  • However, we made some efforts to make the architecture extensible enough to handle other bindings; so that it might be easy to add a support for RMI, or an Eclipse internal Workflow Engine (eg MWE) or anything else. This is made by using extension points.

With SCA

  • SCA is aimed to make binding between several components (eg a Workflow Engine that promotes a service to monitor it, and a client to this service that monitor it in another application...) become more abstract. When possible, we could use SCA to manage theses bindings in JWT.
  • We could provide a composite generator binary (for SCA) in the base plugin. This is possible by adding a binary without problem of license (see java2wsdl binary in STP), so that it could be part of an official release.

Screenshot

These are a screenshot of what we currently have. Obviously, it can be improved...

Jwt monitor1.jpg

Jwt monitor2.jpg

Jwt monitor3.jpg

Jwt monitor4.jpg

Jwt monitor5.jpg

Implementation

General schema:

Jwt monitoring.jpg

  • The UI is implemented as an Eclipse View
  • The view uses the interface WorkflowService, and creates the tree wih the beans that WorkflowService methods provide. Those beans are then embedded in a composite pattern, to fit with TreeViewer requirements.
  • The interface WorkflowService is an adapter. Each workflow engine that is to be supported in JWT must implement this interface according to its own specifications.
  • When accessing a Workflow Service, the plug-in calls a method from a plug-in linked to the base plug-in through extension point. This extension provides an implementation for the interface WorkflowServiceProvider, and more specifically for its "processServiceAdd" method.
  • This way, we can consider that we have one plug-in per binding. (That's why SCA could be useful => One plug-in for several bindings)