Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] About workflow integration with JWT
Hi,

Not too much useful at the moment :)

Shark as other workflows (like OSWorkflow from OpenSymphony) can run embedded into Eclipse. YAPROC uses Shark in this manner. Thus, the communication layer has not too much interest to such sort of workflows. Direct access trough extension points would be preferable rather than a web services or other overhead communication.

I think that if users draw theirs processes on the JWT Editor then they would like seeing the progress on the graphs which they have drawn. And maybe they would be happy interacting with the graph at runtime (to examine it, change manually the flow, seeing the running activities highlighted in some way, accepting task, navigate to/from main processes and  subflows, and so on). Many of this things are done by YAPROC.I send you a link to show how it does:

       http://www.upversion.com/multimedia/flow.htm

This is a good example because it's an integration exercise between a graph editor (JaWE) and a plug-in YAPROC (translate it to JWT and 3r party tool). The context menus which you can see in the flash demo are not part of JaWE. All them belongs to the YAPROC plugin. In other words: they are SWT items rather SWING items. To achieve this I re-wrote a very small part of the JaWE code to introduce a callback functionality. Thus YAPROC  decides what to do based on the received event.

This is a functionality which, IMO, JWT should give through extension points. This would be a nice feauture very appreciate by workflow vendors who want to use JWT as editor/monitor.

The most similar thing (idea)  to this which I've found in your "org.eclipse.jwt.we_0.5.0.jar" plugin is this declared extension point:

  <extension-point id="propertyDescriptor" name="Custom property descriptor for property sheets" schema="schema/PropertyDescriptor.exsd"/>
.
Best regards,
Pablo.

2008/12/29 Mickael Istria <mickael.istria@xxxxxxxxxxx>

Hello Pablo, hello all,

First of all, I prefer telling you now that the monitoring part of JWT os still a DRAFT, so that it is not intended to be used as it is now. It is currently a simple TreeTableViewer that displays the value of the workflow variables (ie the process state). There is some work that will be done on it within next monthes (with the end of SCorWare, the beginning of Scarbo@OW2 and Bull's contribution)

 For more detais, please take a look at the wiki page http://wiki.eclipse.org/JWT_Monitoring. It contains some information, but some part of the architecture has been changed since the last update of this page (for example jwt-runtime-api has been put out of jwt-monitoring). jwt-monitoring  is build on jwt-runtime-api, that actually contains beans that can be interpreted as a "metamodel of process state" and the interface WorkflowService that contains the list of basic operations necessary to use the monitoring plugin.

Thus, to be able to use this plugin with Shark, here is what you might do:
1. Implement the WorkflowService (locally inside Eclipse or remotely beside of Shark) so that it will give you the ability to get processes states.
2. Implement in an Eclipse plugin (that depends on jwt-runtime-api and jwt-monitoring) the WorkflowServiceProvider. If you have implemented WorkflowService inside of your plugin, simplycreate an instance in your provider. If you implemented the WorkflowService as a remote stateless service (such as a WebService), your WorkflowServiceProvider may create a proxy to this service... (that's where we've been using SCorWare or CXF, but this is just an implementation choice, jwt-monitoring is not at all linked directly to them)
3. Add your WorkflowServiceProvider to the extension point defined in jwt-monitoring

>From here, it should be OK, but the basic UI that is currently used may not fit your needs.

 

You'll understand that most of the work is still to be done (improve the WorkflowService, improve view, improve dialogs...). As I said an effort will be done on it for the next few months. If you are interested in contributing and helping JWT to fullfil its objective "to provide a complete, flexible, interoperable Business Process Management platform", your knowledge of Shark and YAPRO would be very welcome!

 

Since I'm currently on holiday, I won't be able to help you more than that until the 5th of January. I hope it is enough for you to go ahead!

 

Regards

Mickael

On Mon, 29 Dec 2008 12:12:18 +0100, "Pablo Beltran" wrote:
Hi,

OK. I'll wait for the Mickael's answer. But I'm quite confused about why the monitor process is not build on the jwt-runtime-api (I've read some papers -parts- from SCOrWARE and it seems like communication layer).

Regarding your comment in the 5th point and my previous email  I would like  integrate Shark workflow with the JWT Workflow Editor. IMO I'm very close to achieve it because I've all the parts to do it comming from the YAPROC project (www.upversion.com). Internally, YAPROC uses JaWE to paint the processes through a well defined API, so I only need replace JaWE by your JWE editor (I hope).

Might you give some indications about how to start with this task?

Thaks in adavanced,
Pablo


2008/12/29 Florian Lautenbacher <florian.lautenbacher@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Hi Pablo,
 
JWT is ought to work not only with one specific engine (like Bonita, allthough many examples are currently connected to that one), but with all kinds of process engines or workflow engines. Therefore, we are currently developing extension mechanisms: if some engine does need additional information that cannot be covered with the current metamodel (which is in the process of change anyway, see [1]), then it can be extended with new properties, new node types, etc.
 
The process after that would be similar to what you already described:
 
1) Draw the process model in the JWT Workflow Editor (WE)
2) Add some engine-specific details
3) Export the workflow in a suitable format (this might be XPDL, BPEL or any other language such as the JBoss-specific jPDL)
4) Deploy the workflow on the process engine (we would like to have a mechanism directly in Eclipse for that, but currently didn't have the time for that)
5) Monitor the process on the workflow engine. The jwt-monitoring is a first draft to show that this is possible in Eclipse, but still dependant on Bonita, other implementations will come and are welcome from contributors, of course, too.
6) Concerning the jwt-runtime-api: this has been created as part of a French research project called SCOrWare. Since I have not been involved here, others are problably better to comment on that (Marc, Mickael?).
 
Best regards and a happy new year,
 
Florian
 

Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Pablo Beltran
Gesendet: 28 December 2008 06:58
An: jwt-dev@xxxxxxxxxxx
Betreff: [jwt-dev] About workflow integration with JWT

Hi,

I would like to integrate other workflow with JWT rather than Bonita and doing only at the graphical level.

Which are the steps to achieve it?

1. Draw the process into the JWT Workflow Editor
2. Export the workflow to the XPDL format
3. Load the XPDL into the external workflow
4. Mapping real users with participants (external workflow)
5. Reflect what is happening via the jwt-monitoring(-test) into Eclipse (like highlight activities, participants, application/tools,...).
6. Not sure about whether using the jwt-runtime-api would be necessary...

Might someone clarify this?

Best regards,
Pablo.






_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev


Back to the top