Did you ever face the problem that you have a process model and would like to generate code and execute it on a process engine?
There are different possibilities: either you model your process directly in a
BPEL-editor or you have a more abstract process model (and modeling editor), but then you don't know where to put the technical details.
The
typical approach is that you start with a high-level process model, e.g. in
BPMN, and then transform your process into another format where you then specify the technical details. But what do you do, if the technical engineer does not agree with the abstract model that the business analyst did design? Does he simply change the flow in the technical model or tell the business analyst where she needs to adapt her abstract model?
It's quite easy for such simple process models, but it becomes especially hard for bigger ones. Additionally, especially SMEs won't have the time and money to buy a lof of different tools and change their model transformations time and again. They are happy with one kind of tool where they can model their process, add some technical details and execute the processes.
If it would only be BPMN, then life would be easy. But there are a lot of languages out there and especially in order to collaborate with others a company needs adapters to these languages. As you can see in the following image, standardization organizations were quite active in the last few years and it is not foreseeable which new standards will emerge in the coming years.
But not only the graphical notations differ, also the different process engines each have their own requirements. This is why you specify some hooks in the generated
XPDL code or change the generated BPEL code again, so that it can be executed in your process engine.
That's probably okay if you have only one process engine or there is already a modeling tool that supports your process engine and generates exactly the right code. However, quite often there is a lack of compatible tools (either because the vendor doesn't support own modeling tools or because the process modeling tool of your choice doesn't support exactly the process engine that you would like to use). Then, you will have to change all the generated files manually so they can be executed.
But how can a modeling tool give you the possibility to add the kind of details that you need for the process engine of your choice? Surely, you can specify some annotations in BPMN which the process engine can evaluate. But there is no type safety, i.e. you can specify there anything you like (numbers, Strings, boolean values as Strings, etc.).
What would be preferable is a possibility where you have one single modeling tool you can build on and this tool allows you to specify the additional parameters that are needed for execution as well as their types and everytime after that you only have these parameters and types.
That was the reason why we developed in the Eclipse project
JWT an
aspect-oriented extension mechanism for vendors and other persons who want to extend the already existing metamodel.
The extension metamodel looks as follows:
For each process model you can specify a configuration model (actually, this has been implemented on top of
EMF, so you can extend any EMF metamodel!). This ConfModel contains a set of profiles with several aspects in them. For each profile you can specify the name, version, author, some description and an URL. The interesting things are the Aspects: they allow to point to some already existing metamodel elements (via targetModelElements) which shall be extended. Thereby you can specify whether this extension shall be the same for all elements of this kind or different (multiple). You can also say whether this extension shall be automatically added to the model element once it is created or only on request. You can set some default value for the extension and name an identifier. The aspect instances then specify what you exactly want to add: some new properties, completely new nodes, etc.
We already added e.g. new properties. These can then be seen in an additional properties tab which can be adapted to the needs of a vendor (see the new tab Advanced in the following screenshot).
If a vendor wants to have another view on the process (either with more or less details or with different figures, one for BPMN, one for UML activity diagrams, one for EPCs, etc.), then they can simply
add it to JWT, too.
Additionally, its quite easy to add an own editor sheet, if somebody prefers to have much more information in their editor: copyright information, nice images, more text, whatever!
With these extension points as a basis and some more that will come soon (e.g. enhancements on the current view mechanisms, additional transformations, etc.), the above described problems can hopefully be decreased!
We hope that more and more vendors will be interested in JWT in the future and we look forward to work with them together on their requirements!
