[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Réf. : AW: [jwt-dev] [architecture] JWT and the Process VirtualMachine

> - A common meta-model which is as generic as possible to support multiple
> process languages (this would be the PVM applied to the graphical layer and
> based on EMF technologies).


as a basis for this, the (EMF) model should have a dynamic key-value based property set. so that each process language can just use it's own properties.

the other and less trivial challenge will be to express constraints for process constructs and convenience functions for language-specific features.

regards, tom.


miguel.valdes-faura@xxxxxxxx wrote:
Hi Marc, Florian, and others !

I'm just getting back from some days of vactions and I realised now
(checking my mailbox) that everybody is talking about the Process Virtual
Machine now :-)

I'm convinced that the PVM concepts we are pushing with Tom can be
extrapolated to the graphical layer as well. This is in fact what I
expected from the JWT project.

However i'm not sure (specially after reading the last messages echanged on
the list) that we are all sharing the same ideas on what JWT must be.
Hereafter the main points I see for the modeling part of JWT:

- A common meta-model which is as generic as possible to support multiple
process languages (this would be the PVM applied to the graphical layer and
based on EMF technologies). This model should, at least, allow the
generation of targeted process languages (let's say XPDL, BPEL, JPDL,... ?)
in fact the ones supported by the JWT partners.

After the first evaluation made by Steve Egbert on the AgilPro model i'm
not sure that we could easily extend it to support XPDL, BPEL or JPDL
generation so I think this is probably one of the main issues to address by
the JWT partners ???

- A generic plugin based on a graphical notation (let's say BPMN) with
basic fonctionalities to design process and which could be extensible. For
sure this plugin relies on the EMF model defined.

- Graphical plugins extentions to the previous one fitting with the process
languages to be supported (XPDL, BPEL, JPDL ...).

As Tom pointed out, I see the user selecting up front the language for
which he wants to start a process definition. I really think that we must
avoid things like users switching between views and generations in which
different standards are involved (i.e from an XPDL view to a BPEL one).

I really don't like the approach for BPM tooling in which from a graphical
notation and a particular process definition, the tool propose the
generation of multiple languages definitions. This end up with a tedious
work checking whether or not a particular process construct can be
expressed by two different process languages as well as bidirectional
mappings.

- From the previous assumption I even see interesting (as explained by
Florian) the possibility to refine a process definition including more
technical details (two different views of the same process definition). I
see that usefull ONLY in a particular use case: if the selected process
language and graphical notation for both views are the same i.e: the user
selects the XPDL definition (using the BPMN-XPDL view) and starts the
process definition by only defining basic content. At some point, another
user takes this same process definition but using the advanced view
(BPMN-XPDL advanced view) in which he has access to the list of
services/actions available.

In fact, in this example, the second view is an extention of the first one
with additional fonctionalities.

best regards,
Miguel Valdes

BPM Manager

Bull, Architect of an Open World TM
1, rue de Provence
38130 Echirolles (France)

(  Direct Line: +33-4-76-29-72-28
(  Fax: +33-4-76-29-75-18
(  Sec: +33-4-76-29-76-42
+   Email: miguel.valdes-faura@xxxxxxxx

This e-mail contains material that is confidential for the sole use of the
intended recipient. Any review, reliance or distribution by others or
forwarding without express permission is strictly prohibited. If you are
not the intended recipient, please contact the sender and delete all
copies.


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

-- regards, tom.