Skip to main content

[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 ).

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 : .

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 ), while yours has a better support of orchestration concepts and strategies, such as loops.


Back to the top