BPMN 2.0 ==> emf.cloud

[rsoika]

Hi,
I am a committer of the Eclipse BPMN2 project and I am currently considering migrating this project into EMF.coud and GLSP. But there are some aspects here where I'm not sure how they can be transferred to the concepts of EMF.coud and GLSP. I would therefore like to ask you for your opinion on this.

BPMN is a standard notation for business process management specified within the OMG group (https://www.omg.org/spec/BPMN/). The Eclipse BPMN2 project already defines a EMF meta model which is part of the Model Development Tools (MDT) project. The model was originally developed by contributing members of the OMG BPMN 2.0 working group and is fully compliant with the spec. Eclipse BPMN2 Plugin is so "just" an editor based on the model.

Extensibility

One of the concepts of BPMN 2.0 is its extensibility mechanism that allows extending standard BPMN elements with additional attributes. It can be used by modellers and modelling tools to add non-standard elements or Artefacts to satisfy a specific need, such as the unique requirements of a vertical domain, and still have valid BPMN Core.

The goal of the Eclipse BPMN2 Modeler was to not only provide a graphical modelling tool for BPMN, but also to allow plug-in developers to easily customize the behaviour and appearance of the editor for specific BPM workflow engines that use this BPMN 2.0 extensibility mechanism. For example Open Source Workflow Engines like jBPM and Imixs-Workflow integrate Eclipse BPMN2 into there tooling platforms and extend the core features of BPMN2 with platform specific functionality.

This is one of my questions: Do you think this concept can be adapted into the EMF.coud ? This would mean that at the end the EMF.cloud provides a BPMN modelling tool and also supporting the extensibility mechanism that allows other projects to adapt this modeller tool to individual needs.
In the Eclipse BPMN2 project we call this an ExtendingRuntime and we provide an tutorial how to create such a runtime based on the Eclipse Plugin concept.

The BPMN complexity

Another aspect that gives me a headache is the concept of the containers. In BPMN 2.0 you can define a so called 'pool' which can contain 'lanes' and in that lanes the modelling elements like tasks, events or gateways can be placed.
Even when I start with the Coffee Editor, I am shocked by the complexity of the BPMN model. I'm not at all clear how to start. I am ready to take over the implementation of the graphic elements and the different forms, but I think that I will need a lot of help.

So my question is what you think about migrating the Eclipse BPMN2 into EMF.cloud. Not simply building the modelling tool but also providing a concept for other projects to extend the tool based on the BPMN 2.0 extensibility mechanism.
Would this be interesting for you to host such a project within the EMF.Cloud and would you like to help me with the implementation?

===
Ralph

[planger]

Hi Ralph,

thanks for reaching out!

Of course it is hard to clearly evaluate the particular challenges on such a high level. But overall, I don't see any conceptual issues for GLSP and EMF.Cloud with supporting the extensibility mechanisms you are describing. Of course it'll be quite some development effort and requires dedicated extension mechanisms that are provided by the BPMN platform on top of the EMF.cloud/GLSP technology stack and generic frameworks those projects provide. But in general there doesn't seem to be a blocker on a first glance.

As far as I understand your use case, extensibility would need to take place on two levels: (1) The metamodel shall be extensible and (2) the notation in the diagram / UI shall be extensible.

1. EMF.Cloud can essentially work with any EMF model in the backend. So if a core metamodel is extended by someone and registered in the model server, it can process it. In addition, you can register custom composite operations in EMF to provide a higher-level command API to clients. With the extension mechanisms EMF already provides for that and maybe some additional dedicated extension mechanisms put on top of EMF.Cloud by your BPMN platform, it should be doable to provide a similar extension experience as you offer today.

2. The notation and rendering is done by a component that translates the original models (EMF in your case) into a so called GModel, which is a description of what shall be rendered (typed nodes and edges with attributes, layout hints, etc.). This GModel will then be sent to the client and translated into SVG based on view implementations. In order to take metamodel extensions into account for diagram notation, extenders may have to also extend this translation to the GModel and/or customize their own views. Then they'd have full control over how the diagram will look like. Both can be done via the basic extension mechanisms of the GLSP server (e.g. via OSGI or maven dependencies that extend default implementations) or on the GLSP client (via npm packages that register custom views and CSS). Of course, it may make sense to add a layer for BPMN extension use cases on top, if needed. Dedicated generic implementations could provide reasonable defaults. For reflecting metamodel extensions also in property views, one could use the metamodel information at runtime, similar to how EMF does that. We've used JSON forms for such use cases in other projects.

Swimlanes and other specific challenges around BPMN may have to be evaluated in detail. GLSP supports containments (e.g. for swimlanes), but the generic tool support (e.g. for moving elements between swimlanes, their resizing behavior during move, etc.) likely will have to be customized to exactly achieve the specific user experience BPMN users may want to have.

Regarding your other questions, I think it'd be best to have a chat about that to better understand your plans. If you'd like that please send us an email (see https://www.eclipse.org/glsp/contact) and we'd be happy to schedule a meeting.

Best wishes,

Philip

[rsoika]

Thanks for your feedback. I will first dive into the GLSP round trip (model-server-client) to get more familiar with the core concepts. Than I hope to be in a better position to discuss with you further the more complex aspects :-)

[rsoika]

Ok, now I make some progress and I understand more and more the concepts of GLSP.
I will now work on my GLSP BPMN Modeler within the imixs project domain. In its final version, I plan to replace it with the Eclipse BPMN2 Plugin which is part of the official release train. This is than a kind of technology switch form GEF/Graphiti => GLSP/Sprotty
I also slowly develop a vision how to realize the extension mechanism. But this will be in a later phase. And of course I guess I need your support in many details. So I will continue asking questions....