Re: [jwt-dev] Beginning of a monitoring plug-in

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

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