[jwt-dev] JWT extension - EMFT MWE use case

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hi all

Here's an analysis I've written of Bryan's EMFT MWT use case (see 
bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=225892 ).


Hi Bryan

I've taken a look at your updates, here is my feedback.

"The idea is that a editor could treat the composite as a black
box and show only the inputs and outputs of the composite." -> I like 
the "black box" point of view, it is very much in sync with allowing any 
kind of JWT Action / WorkflowComponent extensions, and with my latest 
tries in enabling extensibility of the JWT model (more soon on mailing 
list).

From what I've understood (please correct me if I'm wrong), you want to 
make primarily a runtime workflow model, i.e. a workflow model that not 
only can be executed but has even runtime state information in it.

So it is not surprising that your model has quite a few things in it 
that are only runtime (and not devtime) : WorkflowState, 
WorkflowEngine... This "runtime" flavour has the advantage of making it 
a model that can directly be run (if only at development time by the 
developer). However I'd still advise to carefully make the separation 
between devtime information and runtime information.

For example, maybe XxxWorkflowOrchestrator should be renamed to 
something like XxxWorkflowOrchestrationStrategy, therefore making it 
more like information and less like actual runtime implementation ?

Maybe Florian and other Augsburg U. contributors have some input from 
their JWT Simulator experience on how to tread the line between devtime 
and runtime when "executing" an EMF workflow model.

Simplifying parameters is good.

A simple way to map a JWT model to your model would be : 
CompositeWorkflowComponents correspond with JWT StructuredActivityNode, 
and custom WorkflowComponent extension implementations will be the 
forecoming JWT Action extension (your endeavours are my inspiration on 
this side ;). I think this should be straightforward and powerful enough 
for you to use. Another, more powerful but more complex, would be to use 
pattern detection strategy like in BPEL generation (see below).

Since your model is EMF, you could use ATL to implement the 
transformation we've talked about in your jwt2mwe transformation plugin. 
Mickael has just written a doc about ATL here : 
http://wiki.eclipse.org/JWT_Transformations#About_ATL .


Finally, some "philosophying" about your workflow semantics (I mean how 
the engine decides which next WorkflowComponent is must run) and how it 
matches with JWT.

From what I've read, your workflows are mainly recursive compositions 
of CompositeWorkflowComponent and custom WorkflowComponent extension 
implementations, and execution of a given Composite is governed by its 
strategy parameter (XxxWorkflowOrchestrator). This gives it a definitive 
bloc-oriented, bpel-like, recursive orchestration feel.

It is quite different from the JWT metamodel, which is rather an 
oriented graph (node and transition -oriented). Anyway Augsburg U. has 
already generated BPEL from JWT (and there will be other JWT to BPEL 
mappings in the future as well) so the semantics and execution paradigms 
should map well with yours as well. The bottom line is we're very 
committed to also support tooling for orchestration and BPEL-like 
processes (we'd even be open to add another, orchestration-minded native 
format to the JWT suite, with optimal transformation support).

For now there are no conditional transition in your model. I guess it 
will appear in a ConditionalWorkflowOrchestrator, as well as other types 
of transitions.

Finally, note that the JWT native metamodel has a better support of 
usual workflow patterns (as defined at workflowpatterns.org ), while 
yours has a better support of orchestration concepts and strategies, 
such as loops.

Regards,
Marc