Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "JWT Monitoring"

(Implementation)
(Workflow State Model)
 
(8 intermediate revisions by 2 users not shown)
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 7: Line 5:
  
 
* We think that "monitoring a workflow" is a synonymous for "getting full workflow state"
 
* 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.
+
* To define a workflow state, we need a generic API to define a workflow. This API must fit with most of workflow engines. This introspection and query API can be usefully complemented by a consistent workflow management API.
 
* The monitoring tool must be able to support several workflow engines, and several ways to access them (WebService, RMI, ...)
 
* The monitoring tool must be able to support several workflow engines, and several ways to access them (WebService, RMI, ...)
 +
 +
== Workflow State Model ==
 +
 +
* Workflow Engine
 +
** Process(*)
 +
*** name(1)  ''String''
 +
*** Project(1)
 +
**** name(1)  ''String''
 +
**** version(0..1)  ''String''
 +
**** properties(*)
 +
***** name(1)  ''String''
 +
***** value(1)  ''String''
 +
*** Activity(1)
 +
**** name(1)  ''String''
 +
**** state(1)  ''String''
 +
**** properties(*)
 +
***** name(1)  ''String''
 +
***** value(1)  ''String''
 +
* Query facilities ''ADDED 201009''
 +
** Processes
 +
*** start  ''int''
 +
*** end  ''int''
 +
*** size''int''
 +
** ProcessQuery
 +
*** returnProperties  ''boolean''
 +
*** start  ''int''
 +
*** end  ''int''
 +
*** filterProcesses(*)  ''Process''
  
 
== Concretely ==
 
== Concretely ==
Line 15: Line 41:
 
* 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.
 
* 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 ==
+
== How do I monitor another workflow engine over another binding with this plugin? ==
 
+
# Implement an interface (WorkflowService) with your favorite workflow engine. (We use the "Adapter" design-pattern)
* 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.
+
# Make this service accessible to the user who wants to monitor it in Eclipse (you can use webservices, rmi, or anything you are able to write a client programmaticaly)
 +
# Implement an extension plug-in which defines the way to access the service (so called a service provider) from inside Eclipse.
  
 
== 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 ==
  
 +
=== General Schema ===
 +
[[Image:jwt_monitoring.jpg]]
 +
 +
=== Comments ===
 
* The UI is implemented as an Eclipse View
 
* 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 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.
Line 35: Line 71:
 
* 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.
 
* 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)
 
* 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)
 +
 +
=== Code ===
 +
WorkflowService API combines both workflow Query and Management APIs :
 +
<source lang="java">
 +
package org.eclipse.jwt.runtime.workflow;
 +
import org.eclipse.jwt.runtime.workflow.bean.Activity;
 +
import org.eclipse.jwt.runtime.workflow.bean.Process;
 +
import org.eclipse.jwt.runtime.workflow.bean.Processes;
 +
import org.eclipse.jwt.runtime.workflow.bean.Project;
 +
import org.eclipse.jwt.runtime.workflow.bean.Projects;
 +
 +
 +
/**
 +
* @author gdecarnin
 +
*
 +
* NB. These methods do not "officially" throw BonitaServerException because
 +
* it will rather result in an UndeclaredThrowableException in a ws client.
 +
*/
 +
public interface WorkflowService {
 +
 +
    public Projects listProjects(boolean returnProperties, boolean startableOnly, String login);
 +
 +
    public Project getProjectProperties(Project project, String login);
 +
 +
    public Process instanciateProject(Process process, String login);
 +
 +
    public Processes listUserActivities(boolean returnProperties, boolean returnTerminated, String login);
 +
 +
    public Process startActivity(Process process, String login);
 +
 +
    public Activity getActivityProperties(Process process, String login);
 +
 +
    public Activity setActivityProperties(Process process, String login);
 +
 +
    public Process terminateActivity(Process process, String login);
 +
 +
    /**
 +
    * Allows pagination and server-side filtering. ADDED 201009
 +
    * @param processQuery
 +
    * @param login
 +
    * @return
 +
    */
 +
    public Processes listUserActivities(ProcessQuery processQuery, String login);
 +
}
 +
</source>
 +
 +
== 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.

Latest revision as of 21:10, 23 November 2010

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. This introspection and query API can be usefully complemented by a consistent workflow management API.
  • The monitoring tool must be able to support several workflow engines, and several ways to access them (WebService, RMI, ...)

Workflow State Model

  • Workflow Engine
    • Process(*)
      • name(1) String
      • Project(1)
        • name(1) String
        • version(0..1) String
        • properties(*)
          • name(1) String
          • value(1) String
      • Activity(1)
        • name(1) String
        • state(1) String
        • properties(*)
          • name(1) String
          • value(1) String
  • Query facilities ADDED 201009
    • Processes
      • start int
      • end int
      • sizeint
    • ProcessQuery
      • returnProperties boolean
      • start int
      • end int
      • filterProcesses(*) Process

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.

How do I monitor another workflow engine over another binding with this plugin?

  1. Implement an interface (WorkflowService) with your favorite workflow engine. (We use the "Adapter" design-pattern)
  2. Make this service accessible to the user who wants to monitor it in Eclipse (you can use webservices, rmi, or anything you are able to write a client programmaticaly)
  3. Implement an extension plug-in which defines the way to access the service (so called a service provider) from inside Eclipse.

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

Comments

  • 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)

Code

WorkflowService API combines both workflow Query and Management APIs :

package org.eclipse.jwt.runtime.workflow;
import org.eclipse.jwt.runtime.workflow.bean.Activity;
import org.eclipse.jwt.runtime.workflow.bean.Process;
import org.eclipse.jwt.runtime.workflow.bean.Processes;
import org.eclipse.jwt.runtime.workflow.bean.Project;
import org.eclipse.jwt.runtime.workflow.bean.Projects;
 
 
/**
 * @author gdecarnin
 * 
 * NB. These methods do not "officially" throw BonitaServerException because
 * it will rather result in an UndeclaredThrowableException in a ws client.
 */
public interface WorkflowService {
 
    public Projects listProjects(boolean returnProperties, boolean startableOnly, String login);
 
    public Project getProjectProperties(Project project, String login);
 
    public Process instanciateProject(Process process, String login);
 
    public Processes listUserActivities(boolean returnProperties, boolean returnTerminated, String login);
 
    public Process startActivity(Process process, String login);
 
    public Activity getActivityProperties(Process process, String login);
 
    public Activity setActivityProperties(Process process, String login);
 
    public Process terminateActivity(Process process, String login);
 
    /**
     * Allows pagination and server-side filtering. ADDED 201009
     * @param processQuery
     * @param login
     * @return
     */
    public Processes listUserActivities(ProcessQuery processQuery, String login);
}

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.

Back to the top