The focus of the talks that I attended today at EclipseCon, was about modeling and execution. The first talk (after the really great keynote that others on PlanetEclipse already posted about) was about a model-driven build management suite called Storm that is currently developed by Brane. If you ever had the problem, that you want to build your Eclipse distribution customized yourself, then this software might be interesting for you.
The second talk, "Executing BPMN" described the differences between graphical process modeling languages like BPMN and executing languages such as jPDL. Koen Aers, the presenter of this talk, also explained why an overall coverage of BPMN will not be possible in their tool (and is not even necessary as research found out). But he gave a quick preview on the coming modeler that will be distributed in the jBPM release in July and it already looked really nice (alas it is not yet build upon JWT!).
The next track was a set of SOA talks from the STP project: how the policy editor is evolving, what is currently happening around the Enterprise Integration Designer, how one can model SCA composites and how the STP-IM all connects these components has been summarized in short time quite well. Probably the tuturial on Monday has given much more insight, but having four hours is of course much more than only one.
Another track of this day was about an EMF repository, workflow and model execution. Actually, it have been three different talks: the first one was about EMFStore, a project some colleagues from the TU Munich presented and which was integrated in their tool suite Unicase. Alas, I didn't find the time to talk to them, but they said that they will have a poster at the poster session tomorrow, so I'm already looking forward to that. The second presenter was Bryan Hunt who gave a quick introduction into the MWE project and how the classes he has designed work together. The third one in this track was from the HU Berlin (so a lot of German Ph.D. students here!) and presented a framework for the execution of models. He demonstrated it on a C# interpreter where the dynamic behavior was actually modeled with his toolset(building on OCL and UML State diagrams). It reminded me a little bit at Executable UML (xUML), but I didn't have the time to look further into the differences between both.
In the end I got a good impression how the next major release, Galileo, is currently build using model-driven development tools: model-to-model transformations (QVTO) and model-to-text-transformations (XPand) are used in order to assemble and build all the milestone builds for Galileo. So, it seems to me that more and more areas are open to modeling and I'm already looking forward to the talks on this topic tomorrow.
Dienstag, 24. März 2009
Latest findings of the CAOS Report 2008
No, this is not a new version of the CHAOS Report of the Standish Group which reports about how many IT projects failed in the last year again. This is about a report concerning the Commercial Adoption of Open Source (CAOS) which the 451 group created last year and which Matt Aslett introduced us yesterday at the Eclipse Annual Member Meeting.
Hmm, if one only looked at the number of attendees, it seems that the Eclipse community is getting smaller, as only about 40 people attended the member meeting. But this is probably due to several really interesting tutorials that were part of EclipseCon and that happened at the same time. All in all there are about 1,000 people here at EclipseCon, so the community is much bigger!
So what did the CAOS report contain? The title of the presentation was "Open Source is not a business model". And as Matt finished, "Open Source is a business tactics, not a business model".
They had a look at 114 companies and investigated their business strategies. These were categorized in 4 categories:
- license choice
- development model
- vendor licensing strategy
- reveneue trigger.
Already the first category, the license choice, offered some quite interesting insights: most of these companies (51,8%!) use the GPLv2. All in all the usage of GPL and LGPL covered 72,8 % of all companies. The Eclipse Public License (EPL) for example is only used by 6,1 %! With probably hundreds of different open source licenses around, only 10 are mainly used!
Interesting was also the revenue triggers: many companies probably started their open source strategy with offering service and support for money. In the meanwhile this is only 7,9 % of how revenue is achieved. Mostly these companies make money by subscriptions(34,2%) and commercial licenses (24,6%).
There were a lot of more interesting things that were mentioned, but I guess this short summary shows already that this report might be interesting for you!
Oh yes, as we already have a look at different numbers, I might add some more statistics that different people from the Eclipse Foundation explained at the Annual Member Meeting: the Eclipse Foundation currently has 172 members and 901 different committers from at least 75 organizations! Wow, that's not bad!
There are approximatelly 1 million downloads each month of the different Eclipse releases whereas 26% of all downloads come from China! A huge number! Of all downloads 34% were the IDE for JEE and 22% the IDE for Java. So, Eclipse is still mostly important for developing Java.
But this will change in the future as the planning for Eclipse version 4.0 (Codename: e4) is already in an advanced state.
Oh, yes, some last numbers: when looking at the European region of Eclipse Germany is with 44% still in front, after that comes France with 16% and Sweden with 8%. As the committers of our JWT project mostly come from Germany and France, this meets perfectly our profile *g*.
Hmm, if one only looked at the number of attendees, it seems that the Eclipse community is getting smaller, as only about 40 people attended the member meeting. But this is probably due to several really interesting tutorials that were part of EclipseCon and that happened at the same time. All in all there are about 1,000 people here at EclipseCon, so the community is much bigger!
So what did the CAOS report contain? The title of the presentation was "Open Source is not a business model". And as Matt finished, "Open Source is a business tactics, not a business model".
They had a look at 114 companies and investigated their business strategies. These were categorized in 4 categories:
- license choice
- development model
- vendor licensing strategy
- reveneue trigger.
Already the first category, the license choice, offered some quite interesting insights: most of these companies (51,8%!) use the GPLv2. All in all the usage of GPL and LGPL covered 72,8 % of all companies. The Eclipse Public License (EPL) for example is only used by 6,1 %! With probably hundreds of different open source licenses around, only 10 are mainly used!
Interesting was also the revenue triggers: many companies probably started their open source strategy with offering service and support for money. In the meanwhile this is only 7,9 % of how revenue is achieved. Mostly these companies make money by subscriptions(34,2%) and commercial licenses (24,6%).
There were a lot of more interesting things that were mentioned, but I guess this short summary shows already that this report might be interesting for you!
Oh yes, as we already have a look at different numbers, I might add some more statistics that different people from the Eclipse Foundation explained at the Annual Member Meeting: the Eclipse Foundation currently has 172 members and 901 different committers from at least 75 organizations! Wow, that's not bad!
There are approximatelly 1 million downloads each month of the different Eclipse releases whereas 26% of all downloads come from China! A huge number! Of all downloads 34% were the IDE for JEE and 22% the IDE for Java. So, Eclipse is still mostly important for developing Java.
But this will change in the future as the planning for Eclipse version 4.0 (Codename: e4) is already in an advanced state.
Oh, yes, some last numbers: when looking at the European region of Eclipse Germany is with 44% still in front, after that comes France with 16% and Sweden with 8%. As the committers of our JWT project mostly come from Germany and France, this meets perfectly our profile *g*.
Freitag, 20. März 2009
Looking forward to EclipseCon - to meet you!
Next week EclipseCon 2009 will already start in Santa Clara, California. I guess most of you will look forward to have the best conference ever. Not only because the huge amount of interesting talks, but also because this is probably the best possibility to meet the persons you always wanted to talk to in person!
It already starts on Monday with quite interesting tutorials such as how to use Mylin, work with Eclipse RCP, apply the latest research results in model transformation, have a dive in the platform resource model or develop your SOA with Eclipse. There are so many tutorials (besides the Eclipse annual member meeting that happens on Monday afternoon, too), that I don't know yet which one to choose.
And it's getting much more difficult once the conference starts on Tuesday! Not only the BOFs will be fun, but of course also the plenty presentations. Since we'll have a talk on Thursday about how to execute a process (by the way, the presentation is nearly finished!), I'm of course interested in what other companies do in this context and am already looking forward to Koen having his talk Executing BPMN.
But besides that a lots of other talks (that are not related with BPM, SOA, Workflows, etc.) seem to be interesting: how to evolve a user community, what will happen in Eclipse e4, the newest development concerning Galileo, newest tools for web development, building and translation as well as others.
I'm sure everybody will find a topic that he's interested in!! And if not, you can still sing Karaoke, watch some posters or talk to exhibitors. And with the long list of presenters, you'll definitely find somebody to talk to!
I'm looking forward to meet you all in the next few days!
It already starts on Monday with quite interesting tutorials such as how to use Mylin, work with Eclipse RCP, apply the latest research results in model transformation, have a dive in the platform resource model or develop your SOA with Eclipse. There are so many tutorials (besides the Eclipse annual member meeting that happens on Monday afternoon, too), that I don't know yet which one to choose.
And it's getting much more difficult once the conference starts on Tuesday! Not only the BOFs will be fun, but of course also the plenty presentations. Since we'll have a talk on Thursday about how to execute a process (by the way, the presentation is nearly finished!), I'm of course interested in what other companies do in this context and am already looking forward to Koen having his talk Executing BPMN.
But besides that a lots of other talks (that are not related with BPM, SOA, Workflows, etc.) seem to be interesting: how to evolve a user community, what will happen in Eclipse e4, the newest development concerning Galileo, newest tools for web development, building and translation as well as others.
I'm sure everybody will find a topic that he's interested in!! And if not, you can still sing Karaoke, watch some posters or talk to exhibitors. And with the long list of presenters, you'll definitely find somebody to talk to!
I'm looking forward to meet you all in the next few days!
Freitag, 30. Januar 2009
Aspects for type-safe extensions of process models
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!
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!
Dienstag, 20. Januar 2009
Talk at Eclipse Forum Europe 09
In April, just right after EclipseCon, the Eclipse Forum Europe (EFE) is happening in Mainz, Germany. EFE is organized together with JAX and SOACON, so it offers insight into many interesting themes: Java and other languages on the JVM, SOA, Model-driven Engineering, Business Process Management, OSGi and Equinox as well as other tools.
There, I'll have a talk about Execute your processes with Eclipse JWT (Abstract), where I will have 60 minutes (luckily some more than at EclipseCon) to describe many details of JWT: the view mechanisms, aspect-oriented extensions of the metamodel, model transformations and code generation, monitoring, etc. This will be my first JAX, but I'm already looking forward to it!
There, I'll have a talk about Execute your processes with Eclipse JWT (Abstract), where I will have 60 minutes (luckily some more than at EclipseCon) to describe many details of JWT: the view mechanisms, aspect-oriented extensions of the metamodel, model transformations and code generation, monitoring, etc. This will be my first JAX, but I'm already looking forward to it!
Mittwoch, 17. Dezember 2008
Talk at EclipseCon 2009
Our talk with the title "Make Your Processes Executable!" for EclipseCon 2009 has been accepted. Alas, it has been shortened from half an hour to ten minutes only.
For a university in Germany having a business trip to California for only 10 minutes of presentation is a very high financial burden. Especially in todays monetary crisis!
Thanks to our boss, we are allowed nevertheless to make the trip in order to bring the project some steps further, to discuss with project partners and other project leads or committers. Probably we will try to have an additional poster in the poster session in order to have some more discussion about our project.
But for the next time, we will surely make it like other committers, too: we simply make several submissions. It is kind of strange now to read on e.g. PlanetEclipse that some people get a short talk, a long talk and a tutorial accepted, whereas other people are not even allowed to speak more than 10 minutes. But for next years Eclipse Summit Europe and the following EclipseCons we will probably consider that, too!
For a university in Germany having a business trip to California for only 10 minutes of presentation is a very high financial burden. Especially in todays monetary crisis!
Thanks to our boss, we are allowed nevertheless to make the trip in order to bring the project some steps further, to discuss with project partners and other project leads or committers. Probably we will try to have an additional poster in the poster session in order to have some more discussion about our project.
But for the next time, we will surely make it like other committers, too: we simply make several submissions. It is kind of strange now to read on e.g. PlanetEclipse that some people get a short talk, a long talk and a tutorial accepted, whereas other people are not even allowed to speak more than 10 minutes. But for next years Eclipse Summit Europe and the following EclipseCons we will probably consider that, too!
Dienstag, 16. Dezember 2008
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.
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.
Abonnieren
Posts (Atom)
