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.
Difference between revisions of "JWT Monitoring"
(→Monitoring workflow engine in JWT) |
|||
| Line 13: | Line 13: | ||
* 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. | ||
| − | == | + | == 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) | |
| − | + | # 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 == | ||
| Line 43: | Line 43: | ||
* 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) | ||
| + | |||
| + | |||
| + | == 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. | ||
Revision as of 11:55, 21 April 2008
Contents
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.
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)
- 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
These are a screenshot of what we currently have. Obviously, it can be improved...
Implementation
General schema:
- 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)
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.