[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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 :)
Regards
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.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=225892
Bryan
Hello,
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.
Mickael
