Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Re: MWE vs JWT

Hi Bryan

I second everything Michael has said.

Implementing a transformation for your model would allow you to use the full JWT editor feature set (including export to other BPM formats).

We'd be willing to help you do this. There are already good samples : look in the eclipse technology.jwt CVS, the "transformations" subtree contains a sample stub transformation you may start with, as well as several working transformations that will show you how to use ATL or XSL as transformation technologies (if you'd rather use JET or Acceleo, we got tutorials - well, any technology is ok !).

In addition, I note an interesting point about your sample : it showcases how your model may be extended concretized, meaning that in addition to the core workflow model, domain specific workflow model (especially domain specific actions and task implementations) inheriting from it can be defined.

This can be done in JWT, but for now such extended actions would not show differently in the UI, so their specific properties could not be set and therefore they would not be any more useful than normal actions.

However, we're currently working on how to allow to extend the JWT metamodel, which will imply being able to display such extended properties in the UI, which would fill you needs. So we're both rather in the same mindset ;)

Your sample / idea about this advocates a typed action extension mechanism. Another one would be mere key-value pairs on actions, which is simpler. I rather like the idea of typing actions since the PVM runtime (common future Bonita and jBPM BPM engine) does the same, and it would allow to control consistency of action types within a business process, as well as which ones are for example BPEL-compatible versus XPDL-compatible.

However if typing is too harsh it might be cumbersome to do extensions. Typically, having to write another EMF model whenever a custom property needs to be added and generate its companion Java code is a development task but (I think) should not be one, since mere users might want such custom properties.

I'm putting the dev mailing list (jwt-dev@xxxxxxxxxxx , you're welcome to subscribe) on cc so we can go further on this :)

Marc Dutoo
JWT Team co-lead
Open Wide

Mickael Istria wrote:
Bryan Hunt a écrit :

I just ran across the Eclipse JWT project and it seems that it either overlaps or compliments MWE - I'm not quite sure which. Have the two groups had any discussions on collaboration?

I am, hopefully, cross-posting to both groups and including a link to my starter EMF based workflow engine for discussion.



I took a look at MWE, and here are a few thought that could maybe show you some differences between MWE and JWT. (However, I am not a wise old man in JWT -and Eclipse more generally-, so that I apologize in advance if I make mistakes).

MWE is a modeler for workflow based on EMF. According to what I quickly saw when I tried it, it defines a metamodel for workflows, and allows users to write and run a workflow defined in this metamodel.

JWT is aimed to be a complete and generic tool for workflow designers. It includes a graphical editor that allows to "draw" a workflow. It uses an internal metamodel for workflows which is compatible with AgilPro Workflow Engine. In the future, JWT should include some runtime tools that would allow user to monitor his workflow from JWT with a large and open set of workflow engines (we are currently focusing on Bonita).

We recently integrated into JWT a transformation framework to give it more compatibility with other standards such as XPDL, BPMN... (the list is short for the time, but it may be extended). XPDL will give to JWT the ability to design workflows that will be compatible with Bonita, and BPMN will make JWT compatible with other graphical workflow editors.

As you can see, we are trying to make JWT as complete and general as possible.

The thought that came to my mind when I discovered MWE workflow engine was: "JWT could handle it". Including a new workflow engine into JWT can be done in a few steps (that may not be so easy to implement than to desctibe them): - Extend editor and JWT metamodel to make them support additional informations necessary to your metamodel (that is the most difficult point since changing metamodel must be done cleverly) - Add a transformation from JWT internal metamodel to your workflow engine metamodel, so that JWT can produce MWE files - and, if you want a full integration, add a launcher for your workflow engine, and everything to call it from the UI.

I hope that all this monologue answered your questions, and that it gave you some ideas for a possible future compatibility between JWT and MWE.


Back to the top