[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jwt-dev] Beginning of a monitoring plug-in
|
Hi Mickaël
This is great !
However I think the WorkflowService API should not be buried in the
Monitoring plugin. Runtime Process APIs are in fact a primary goal of
JWT, as you can see in the original proposal. In this light the
Monitoring plugin is more of a sample showcasing how to use such API.
So could you please put WorkflowService in its own plugin / subproject ?
Which could later also be the place for WorkflowEventListenerService etc.
Concerning adding Apache jars to Eclipse, see my note in the private
wiki : licenses are compatible, that's a first ; now please take a look
at whether it is a pre-req or a works-with kind of dependancy, and at
how Orbit works - but at the end of the day I guess we'll have to ask
Emo anyway...
Regards,
Marc
Mickael Istria a écrit :
Hi all!
I committed the code of the monitoring plug-in (with a poll mechanism,
no event). You can find it in the "wam" module.
I'd like to be able to commit an implementation for the
WorkflowService (the interface with the workflow engine), and an
implementation for the WorkflowServiceProvider (the binding to the
WorkflowService), however I'm not sure whether it is allowed to add
Apache jars in Eclipse...
I'll verify what I can check in.
Feel free to ask any question or make any suggestion!
Regards,
Mickael
Marc Dutoo a écrit :
About the event mechanism :
This is also done in the context of integration between business
applications and workflow engine(s) at runtime.
The idea revolves around defining (Java, WSDL, SCA) a generic
WorkflowEventListenerService
* that a runtime process engine should call on state change
* basically task lifecycle changes : ready, before / after
start, before / after stop . These could be the operations of said
service, taking as parameter the part of the workflow state
(typically a Process's Activity, as defined in the existing
WorkflowService) that has changed
* NB. I think property changes would be too heavy
* and that might be implemented by business applications so they
can be notified
So, an eclipse-based UI could use this event mechanism to help the
developer monitor runtime processes in a "push" manner (rather than
polling), thanks to notifications of the changes to the workflow state.
Open questions are
* where should be the listeners configured ? these possibilities
are not mutually exclusive :
* the application may use a WorkflowEventSubscribeService
implemented engine-side. Should it be fine-grained (ex. listen to a
given state of a given activity) or not ?
* engine side, configured in the process model
* also configured on application side : we could provide a
sample Java implementation of the service that merely dispatches to
other configured services
* should we allow open events, i.e. an additional
onCustomEvent(name) method ?
* what about using JWT -> executable process format transformations
in order to add dispatchingListeners everywhere, for instance to ease
activation of monitoring ?
Regards
Marc
Mickael Istria a écrit :
Hello,
I added on the wiki page the model that we use for a workflow state.
This model is part of the workflow service API that must use any
extension. Of course it can be corrected/improved according to other
specific features (it currently fits with Bonita, but we didn't try
with other workflow engines).
I also added the code of WorkflowService interface, that we use to
get the state of the workflow.
It might be interesting for you.
In the Bonita remote implementation of this interface, we only use
the "listUserActivities(true, true, login)" method to get all
informations about the state of the workflow. Indeed, calling this
method with this attributes gives us the whole workflow state, since
this workflow state is fully serializable.
Thus, you're right, it is a poll mechanism, with all the limits that
it involves. (especially the need to refresh to check for
modifications)
We are still thinking about an event mechanism, but I'll let Marc
tell you more about this, since he has more knowledge on this subject.
Regards,
Mickael
Bryan Hunt a écrit :
This is interesting. I've been doing some more work on my EMF
workflow model/engine and I'm about to look at modeling state
information and the ability to monitor that state. It sounds like
this is using a polling mechanism to monitor the state. Is that
correct? I'm considering using an event model for state
transitions. I would be concerned about using a polling mechanism
especially when running the workflow remotely - performance is
critical in my intended application.
Bryan
On Apr 21, 2008, at 10:56 AM, Mickael Istria wrote:
Hello,
I've written a little plug-in framework that can be used to
monitor a workflow state from a workflow engine. This is not at
all a mature plug-in for the moment, but I hope it is an
interesting base for the future.
Monitoring a workflow engine can be done in a few steps:
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 acces
the service (so called a service provider) from inside Eclipse.
We are currently able to monitor Bonita via a CXF/Aegis WebService
(see the wiki for screenshots).
You can find more detailed information and basis for discussion on
the JWT wiki at http://wiki.eclipse.org/JWT_Monitoring
Hope you will find it interesting!
Regards,
Mickael
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev