Reviewing the JWT metamodel

In JWT we are working on all kinds of tools for workflows. One of these tools is the workflow editor (WE) which allows to model all kinds of workflows in order to deploy them to a workflow engine or process engine afterwards. Since we now developed an aspect-oriented mechanism with profiles and configurations to extend the metamodel by external plugins (I will post on this in another blog message), it is now time to review how the core metamodel currently looks like, what has been used till now, how these elements were designed and whether we might utilize them in the future.

The JWT metamodel currently consists of several packages. The main package (JWT Model) contains several other packages: Core, Processes (including ControlNodes), Events, References, View, Organisations, Application, Data and Functions. I will describe them shortly here, a more detailed (but somehow outdated) reference can also be found here.

Core package:

The Core package contains all necessary elements to display a model in the workflow editor (without the graphical layout stuff). The basis for all other elements is ModelElement. Every element that wants to be usable in the workflow editor must be a subclass of ModelElement. Each ModelElement might have some Comment attached. This cannot be displayed graphically at the moment, but one of my students is currently working on this (besides the integration in the tree-like outline view). A Comment itself is a GraphicalElement. Lateron we will see that all elements that are visible in the graphical editor (not only in the palette or outline view) need to inherit from GraphicalElement.

The mostly used subclass of ModelElement is NamedElement. Each NamedElement has a name and an icon with which it can be shown in the packages, palette or somewhere else. The icon describes the URI/URL to an image (in PNG or GIF) that might be used for showing this NamedElement (depending on the figure of the element).

In order to have not a flat hierarchy but some more intelligent structuring for future model elements, these can be differentiated in Packages. Packages can be nested and contain PackageableElements (which are themselves NamedElements again). One example for a PackageableElement is a ReferenceableElement which can be defined once, but referenced several times.
One specific Package is the Model: this is the root of all workflow models and contains the name of the workflow file, the author, the version of the modeled processes, the fileversion of JWT (only internally represented) as well as a human-understandable description.

Please note that in this image as well as in all coming pictures, I am using String, Boolean, Integer, etc. but actually mean the EMF-equivalents EString, EBoolean, EInteger, etc. My modeling tool only supported these standard datatypes natively, so please don't be confused.

REVIEW: When reviewing what has been used in the last years of this part of the metamodel, then we will find that except the Comment all elements have been used frequently. All of those are abstract, so the user didn't actually see that (s)he uses them.
It is understandable that the Comment was not used much, because there was no possibility to show this one graphically. But as already mentioned this will be changed in the near future, so the hope is that the Comment will be used much more frequent in the future, too.

Process package:


The next (and most important) package is Processes. In there, the basic elements of all workflows / processes are described. Most models contain nodes and edges connecting these nodes. You can also find this in the centre of this metamodel package: ActivityNode and ActivityEdge.
But of course these elements need to be defined in a specific Scope. This can be a single process model (called Activity here in analogy to UML2 Activity diagrams) or as part of an activity (called StructuredActivityNode). Activities can be integrated in packages again (as PackageableElements). ActivityNodes are GraphicalElements as well as NamedElements which means that they have a name and can be displayed in the graphical editor.
Each ActivityNode can have several incoming and/or outgoing ActivityEdges and each ActivityEdge has exactly one ActivityNode as source and one as target.

ActivityEdges can be constrained: you can specify whether you would like to have a Guard on the edge which restrictes the number of "tokens" (similar to Petri-nets) that are allowed on this ActivityEdge. Each Guard has a shortDescription and a textualDescription; each one is used in a different view on the process model. Guards can be specified (detailedSpecification) with a GuardSpecification which then uses well-known constructs like Equals, Lower, GreaterEquals, etc. (see OperationType) and BooleanConnectors between them (such as XOR or AND). The parameters that are used here can be existing Data elements or operations from an Application (see both later on) or self-defined constructs.

To use an ActivityNode one needs much more information than only "this is a node". Therefore, the subclass ExecutableNode says that this ActivityNode can be executed itself (dividing it from so-called ControlNodes that are only relevant for the control flow of the process).

An Action is one example for an executable node and means one specific task/action/activity (each standard speakes with different terms here) that can either be executed automatically or performed manually. One might want to specify a targetExecutionTime for an Action and compute afterwards whether the totalExecutionTime (as parameter of Activity) is fulfilled for a given model or not.
The last element in this package is the ActivityLinkNode. This specifies a sub process call from the internal of a given process. Therefore the ActivityLinkNode can be modeled similar to an Action in one Activity but actually linkto another Activity which shall then be executed when the ActivityLinkNode is reached. This allows a nesting of Activities.

REVIEW: The parameters of Action and Activity (target- and totalExecutionTime) have not been used at all as far as I know, since there is no algorithm currently that calculates whether the process can be executed in time or not. This might be removed from the metamodel and outsourced into its own aspect extension which then includes such an algorithm.
The Guards including their GuardSpecification are useful for code generation or simulation of the workflow. But different engines will probably need different constructs. Therefore, it might be possible that the current GuardSpecification will be removed to an extending plugin and only the Guard as a wrapper class will stay in the metamodel.
Since the ParameterMapping of the ActivityLinkNode is connected to the Data and Application package, it's future depends on how these packages will evolve.

Process package (Control node part):


The next screenshot is another part of the Process package and contains all kinds of ControlNodes. As already mentioned these are responsible for starting a process, specifying alternative pathes, parallel pathes or stopping them. The InitialNode and FinalNode are part of every process model and specify when the process shall start its execution and when it stops.
There are different possibilites how the flow can evolve: either we have a simple sequence (Action connected with another Action using an ActivityEdge) or we have alternative (XorControlNode) or parallel (AndControlNode) threads. To specify whether the alternative starts we distinguish between DecisionNode (the point where a decision needs to be made) and MergeNode (two already existing different pathes are merged together again). For parallel pathes the ForkNode (start) and JoinNode (stop) describe the same. Please note, that a JoinNode waits for a token on every incoming edge whereas a MergeNode only on one of the incoming edges.

REVIEW: We just added the AndControlNode and XorControlNode to the metamodel. Now it might be unclear whether to use the more abstract version like AndControlNode or the more concrete version like ForkNode or JoinNode in a model. This is probably specific for each view (e.g. BPMN might use an AndControlNode whereas UML activity diagrams will need the ForkNode and JoinNode), but occasionally inconsistencies between several models might occur. Therefore, this part is still under discussion and might change in the near future again.

Events package:

Another kind of ExecutableNode can be an Event. An Event happens at some point (a message comes in, a sensor recognizes something, a timelimit has been reached, etc.) and then triggers the following activity. In order to cope with these events, an EventHandler has been integrated in the metamodel as part of each Activity. An EventHandler can handle several Events in a predefined way.

REVIEW: Currently Events can be added to the model but one cannot specify any details for this event. Additionally, the EventHandler can't be specified graphically as well and therefore, both are not used very much right now. However, with the integration of the BPMN view in the WE we will need all kinds of Events (MessageEvent, TimerEvent, etc.) and therefore the Events will surely stay in the metamodel. But the future of the EventHandler is unsure at the moment. This might be helpful for BPEL-generation, but whether other languages or process engines actually need this construct is something that will only come up in the future.

References package:
A Reference is a construct to define something that will be available not only in one scope, but in several. Therefore, we will later show different kinds of ReferenceableElements. The Reference will be the element that stands for this ReferenceableElement and is connected with a ReferenceEdge to an Action. A Reference is only available in one specific Scope whereas the ReferenceableElement in more than one.

REVIEW: This technique is very helpful in practice and is quite often used for modeling data, applications or roles. It's usage will probably increase in the future.

View package:
The next package is the View package. This contains details that are necessary in order to display model elements similar all the time when closing and opening the file again. Therefore, the coordinates of each element are needed (Point) as well as the width, height or size (Dimension). Additionally, the direction an edge has needs to be defined (does it point on one side, the other or on both?).

REVIEW: Since the graphical representation of a model is not helpful when executing the workflow later on, we are currently sourcing this out into a separate file. This is also necessary, because different views probably need a different location and size for a model element which is currently not possible.

Organisation package:
As already mentioned there are several kinds of ReferenceableElements. One of these is the Role. A Role describes who is responsible for the execution of a specific Action. If the Role is left out, then this points to a fully automatic execution. Otherwise, people (at least one person) are involved in the execution. In order to structure the different Roles, they can be performed by OrganisationUnits which can be packaged and nested.

REVIEW: Roles are another important aspect of workflow modeling when human interaction is needed (see e.g. the discussions about BPEL4People). They are used quite often, whereas the OrganisationUnits are not used at all. We will see whether those will be removed in the future or whether we will develop an own graphical viewer for these OrganisationUnits in order to support their usage better.

Application package:

The next package (Application) describes how an Action be executed fully automatically. Therefore, one needs to specify several values such as which javaClass is needed, which method shall be invoked or whether the javaClass can be found in a specific jarArchive. The Application comes with an ApplicationType which describes what kind of Application we have: Is it ERP, CRM, PPS, etc.?
After this basic structure we recognized the need for web services and added the WebServiceApplication. This does not need a javaClass, but only an Interface and Operation (and probably some more).

REVIEW: This package needs a complete restructuring. With the subclass-relationship between Application and WebServiceApplication, a WebServiceApplication now contains both: a method and an operation. The ApplicationType is not used at all, so we are already discussing how this part of the metamodel will look in the future.

Data package:

The Data package provides the user with a possibility to specify which files or parameters are needed for a specific execution. Therefore, an Action might have 0..n input and output Data. These data can be structured in several Parameters, whereby Applications have Parameters, too. With the DataMapping the Parameters of an Application can be mapped to the Parameter of the Data and vice versa. Data can be specified in more detail in DataType and InformationType, the former showing the file format (e.g. Adobe Acrobat Reader file), the latter describing the topic of the file (e.g. Order, Invoice, etc.).

REVIEW: The only tool that currently utilizes the Data, is the AgilPro Simulator. But, it only uses the Data and it's value, not considering that there is something like Parameter or DataMapping at all. Additionally, DataType and InformationType are neglected, too. The compution which data is needed for a specific application is only via String-comparison (does the name of the data fit to the needed application-internal parameter? If yes, then it is loaded). Therefore, this whole package probably needs a restructuring as well. Nevertheless, the idea of the DataMapping and binding two parameters together, seems to be a good one, IMHO, and maybe other vendors might find that useful for their tooling. We will see in the future...

Function package:

The last package, a quite easy one, is the one for functions. Similar to EPCs where the function of a specific process can be specified, this function also provides the user with another easy possibility to say what kind of function an action is for. This can be specified on a very high-level business analyst perspective without even knowing what kind of applications and data might be needed for executing the action and can be the basis for a developer in the technical view to decide which application shall be invoked.

REVIEW: The functions are not visible graphically and (probably therefore) not used right now at all. They should be part of an aspect-based extension plugin, but probably removed from the main metamodel.


SUMMARY: We are currently finalizing the aspect-related mechanisms that will allow us to source specific parts of the metamodel out into other plugins. As we have seen, there are many areas where the metamodel should be refined. We will shortly make an own plugin for the metamodel only (currently it is included in the WE) and during this development step we will refine our metamodel. Any comments, ideas and requests are welcome on this blog, the JWT newsgroup or the JWT mailing list. If you already have an Eclipse Bugzilla account, then please feel free to add your comments to the following bug.