[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jwt-dev] JWT extension - EMFT MWE use case
|
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