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!
Mittwoch, 17. Dezember 2008
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.
Mittwoch, 26. November 2008
JWT welcomes its new mentor!
The whole team of the Eclipse technology project Java Workflow Tooling (JWT) welcomes it's mentor John Graham. After we struggled for the last two years with the formerly unknown Eclipse processes (but nevertheless managed already two releases), we are glad to have some support for all questions now. John is currently in the PMC of the DTP project and has been working as a committer (and PMC Chair) for quite a while now and is therefore more than knowledgable about everything that we need to know about releasing, packaging, building, IP due dilligence and all the other things that are quite difficult to understand at the beginning.
With him we are looking forward to be integrated into Galileo. Our PMC already gave us the approval to get on the release train, so we are currently preparing everything that is necessary in order to be included in Eclipse Galileo in 2009.
Now you might ask: what is JWT about? With the included Workflow Editor (WE) one can model the business processes and workflows which are initial process engine-independent, but soon with the support of several vendors there will be first implementations and adaptations for important process engines that exist in the market. Using the already existing transformations the modeled workflows can easily be transformed into other models (such as into BPMN or STP-IM) or also to generate code e.g. in XPDL. If somebody prefers the SOA world and web services, then it's also possible to generate BPEL code using the friend Workflow Codegeneration framework. Additionally, there are also already first standalone RCP-applications available that build on JWT such as AgilPro.
With him we are looking forward to be integrated into Galileo. Our PMC already gave us the approval to get on the release train, so we are currently preparing everything that is necessary in order to be included in Eclipse Galileo in 2009.
Now you might ask: what is JWT about? With the included Workflow Editor (WE) one can model the business processes and workflows which are initial process engine-independent, but soon with the support of several vendors there will be first implementations and adaptations for important process engines that exist in the market. Using the already existing transformations the modeled workflows can easily be transformed into other models (such as into BPMN or STP-IM) or also to generate code e.g. in XPDL. If somebody prefers the SOA world and web services, then it's also possible to generate BPEL code using the friend Workflow Codegeneration framework. Additionally, there are also already first standalone RCP-applications available that build on JWT such as AgilPro.
Donnerstag, 20. November 2008
Eclipse Summit Europe 2008
Right now Eclipse Summit Europe just happens in Ludwigsburg and many many people from all different kinds of projects are here to explain what they are doing, how their tools can be used or simply to chat with other experts about their experiences.
As part of this conference there has been an STP face to face meeting. Since we are closely collaborating with these guys in several other projects, the JWT guys had been there too. And actually it was the first opportunity for the project leads of JWT to meet each other in person. After we now discussed all kind of matters via mailing list or on the telephone for the last two years, it was a pleasure to meet the other one in person for the first time. This was the picture that Anne Jacko (Eclipse EMO) has taken from us when we met for the first time.
´
During this meeting we also learned to know other people that are part of STP or met people again that we already knew since EclipseCon 2008 or Eclipse Summit Europe 2007.
It was quite interesting for us that also top-level projects that already exist a lot longer than we do, still cope with problems such as "How to organize the website", "How to make builds", etc.
Specific topics of this meeting were about existing components (SCA modeler, the Policy editor, etc.), but also about the collaboration between STP and JWT. There are a lot of touchpoints between the two projects and we hope that in the future we can work much more closely together than we already did in the last month.
But not only this discussion was quite interesting. Much more the different talks were fabulous. Thanks to Oisin (STP PMC Lead) we got a few minutes in the SOA Tools - New and Noteworthy talk which Marc used to explain the basics about JWT. Unfortunately, the keynote in the morning took much longer, so Oisin was supposed to start later which had a direct effect on the time that Marc had open to introduce JWT. During his talk many people left the audience to go to other talks that had just started, but also others came in who were not interested in STP or workflow details at all probably. Nevertheless it gave us a good opportunity to tell people what we are currently working on.
Another thing that was quite interesting was the Google Summer of Code which Eclipse joins every year now. Each student can apply with a specific topic to that program and from the 30 proposal 20-something have been accepted last year. Each student does get a fund of $4,500 from Google for his/her work, and the mentor needs probably something between 1 and 5 hours a week to work with the student together. Thereby it doesn't matter if the student already worked before on the project or is somehow related to the mentor. Therefore, this would be a good opportunity for our students at the University of Augsburg to get some funding for their work. We will consider that and ask our current students to apply in March.
We also learned to know some other projects such as Eclipse Babel or Buckminster that could be very helpful for us. Actually, the usage of Babel will also be mandatory for all Eclipse projects that would like to join the next Eclipse release (3.5, codename Galileo), so we will definitely have a closer look and integrate it with JWT. Buckminster on the other side allows projects to build an RCP-product or Eclipse application using code from different repositories. Thereby it doesn't matter whether these repositories are SVN, CVS, Maven or something else. So especially for the build of AgilPro or other projects that rely on JWT this will be very interesting to use.
There had also been many improvements on the Eclipse plattform or Plugin Development Environment (PDE) which will make work in the future much more easier. These improvements had either already been included in Ganymede (Eclipse 3.4) or are part of the milestones of Galileo.
What was also quite interesting to hear was that after Galileo, there will be two releases in 2010. One for Eclipse 3.6 (codename not known right now) and another one for Eclipse 4.0 (currently work starts in the e4 project). The workbench of Eclipse will be mostly re-written. Therefore, I heard a talk from somebody who said that it should be based on EMF. This is surely a good idea, but the strange thing was that the person who submitted the first version of this EMF-model did not use EMF for more than one year. So at the first moment, I thought, this is probably not good to build a new workbench on the proposal of somebody who didn't completely knew the technology. But afterwards he said that he works closely together with Ed Merks and other EMF committers and project leads, so I guess the EMF model has been reworked quite well.
As you can see on the following picture, the conference was quite crowded. But nevertheless, it's fun, too :-)
After lunch we attended the talk by Janet Campbell about IP for Eclipse Committers. Since we struggled several times with how this process works for our last release, it was great to hear the process explained in more detail and to get all our questions answered. So, hopefully, the work for the next release will be a lot easier.
Alas, after this talk and after lunch we needed to leave the conference already, since we had some other appointments the same day back at the office. So we missed interesting talks such as Modeling Amalgam as a DSL Toolkit or Eclipse Swordfish (and many others of course). Maybe somebody else listened to them and will write a short summary about them, too. If interested, you can find some more pictures from the conference here.
As part of this conference there has been an STP face to face meeting. Since we are closely collaborating with these guys in several other projects, the JWT guys had been there too. And actually it was the first opportunity for the project leads of JWT to meet each other in person. After we now discussed all kind of matters via mailing list or on the telephone for the last two years, it was a pleasure to meet the other one in person for the first time. This was the picture that Anne Jacko (Eclipse EMO) has taken from us when we met for the first time.
´
During this meeting we also learned to know other people that are part of STP or met people again that we already knew since EclipseCon 2008 or Eclipse Summit Europe 2007.
It was quite interesting for us that also top-level projects that already exist a lot longer than we do, still cope with problems such as "How to organize the website", "How to make builds", etc.
Specific topics of this meeting were about existing components (SCA modeler, the Policy editor, etc.), but also about the collaboration between STP and JWT. There are a lot of touchpoints between the two projects and we hope that in the future we can work much more closely together than we already did in the last month.
But not only this discussion was quite interesting. Much more the different talks were fabulous. Thanks to Oisin (STP PMC Lead) we got a few minutes in the SOA Tools - New and Noteworthy talk which Marc used to explain the basics about JWT. Unfortunately, the keynote in the morning took much longer, so Oisin was supposed to start later which had a direct effect on the time that Marc had open to introduce JWT. During his talk many people left the audience to go to other talks that had just started, but also others came in who were not interested in STP or workflow details at all probably. Nevertheless it gave us a good opportunity to tell people what we are currently working on.
Another thing that was quite interesting was the Google Summer of Code which Eclipse joins every year now. Each student can apply with a specific topic to that program and from the 30 proposal 20-something have been accepted last year. Each student does get a fund of $4,500 from Google for his/her work, and the mentor needs probably something between 1 and 5 hours a week to work with the student together. Thereby it doesn't matter if the student already worked before on the project or is somehow related to the mentor. Therefore, this would be a good opportunity for our students at the University of Augsburg to get some funding for their work. We will consider that and ask our current students to apply in March.
We also learned to know some other projects such as Eclipse Babel or Buckminster that could be very helpful for us. Actually, the usage of Babel will also be mandatory for all Eclipse projects that would like to join the next Eclipse release (3.5, codename Galileo), so we will definitely have a closer look and integrate it with JWT. Buckminster on the other side allows projects to build an RCP-product or Eclipse application using code from different repositories. Thereby it doesn't matter whether these repositories are SVN, CVS, Maven or something else. So especially for the build of AgilPro or other projects that rely on JWT this will be very interesting to use.
There had also been many improvements on the Eclipse plattform or Plugin Development Environment (PDE) which will make work in the future much more easier. These improvements had either already been included in Ganymede (Eclipse 3.4) or are part of the milestones of Galileo.
What was also quite interesting to hear was that after Galileo, there will be two releases in 2010. One for Eclipse 3.6 (codename not known right now) and another one for Eclipse 4.0 (currently work starts in the e4 project). The workbench of Eclipse will be mostly re-written. Therefore, I heard a talk from somebody who said that it should be based on EMF. This is surely a good idea, but the strange thing was that the person who submitted the first version of this EMF-model did not use EMF for more than one year. So at the first moment, I thought, this is probably not good to build a new workbench on the proposal of somebody who didn't completely knew the technology. But afterwards he said that he works closely together with Ed Merks and other EMF committers and project leads, so I guess the EMF model has been reworked quite well.
As you can see on the following picture, the conference was quite crowded. But nevertheless, it's fun, too :-)
After lunch we attended the talk by Janet Campbell about IP for Eclipse Committers. Since we struggled several times with how this process works for our last release, it was great to hear the process explained in more detail and to get all our questions answered. So, hopefully, the work for the next release will be a lot easier.Alas, after this talk and after lunch we needed to leave the conference already, since we had some other appointments the same day back at the office. So we missed interesting talks such as Modeling Amalgam as a DSL Toolkit or Eclipse Swordfish (and many others of course). Maybe somebody else listened to them and will write a short summary about them, too. If interested, you can find some more pictures from the conference here.
Dienstag, 11. November 2008
How to semantically annotate a process model?
During my research I got confronted with a lot of different approaches how Semantic Business Process Management (SBPM) can be done. This means in the first step, that the process models need a semantic annotation. But what does that mean?
If you model something (and here it doesn't matter whether this is a business process via BPMN, a UML class diagram or a flow chart) you make use of a standard that defines what kind of model elements exist: in BPMN you have Activities, Events, Gateways, etc. In UML class diagrams you have classes, attributes, methods and assoziations.
So these define what the metamodel element is about. There is often no clear defined semantics in a machine-readable way how a Gateway in BPMN or a method in UML shall be used. The semantics of these elements is mostly captured in a textual way.
So for every human who has a little bit of knowledge about BPMN or UML it is mostly clear what these diagrams mean. But what does a computer do with that? Can it "understand" what we model? Sure, you could say, I tell him that each Activity in BPMN shall be executed. Okay, that's fair. But what does it need to execute? What does the label in these Activities mean? And are there e.g. any relations between an Activity in BPMN and e.g. an Action in UML activity diagrams? The PC simply can't say.
That's where the semantic annotation comes into play. Annotation is contemporary English and has two meanings:
(1) a note added by way of comment or explanation
(2) the act of annotating.
As outlined in this session the annotation can be about a whole document (document-level annotation) or refer to just a specifi part of a text (character-level annotations). Additionally, it can be about the constructs defined in a metamodel (metamodel-level annotations) and on elements in the model itself (model-level annotations).
So, with semantic annotation we aim to capture the semantics of the metamodel elements when different representations are used as well as the terms that describe the model elements.
Now you may ask: what for?
Business process models and workflow models have despite their growing usage still some obstacles to cope with:
- they are used for documentation purposes only
- they are often not up-to-date
- they are not executable
- not all processes /workflows in a company are modeled
- there are different (somehow incompatible) representations used in different companies or departments
- several constructs for one real-world entity exist
- and (the other way round) one construct can be used for different purposes
Now I'd like to come to the initial question: how to semantically annotate a process model?
There are several research projects in the world and many of those need a semantic annotation of the process model (for the rest of this blog post I'll only speak about process models and workflows, however, semantic annotation is definitely something used also for other modeling areas such as software or systems engineering).
Yun Lin describes in her dissertation "Semantic Annotation for Process Models" an approach where an additional tool is used that can read an existing process model and one or more ontologies and can then annotate the model elements with concepts of the ontology and store that in an additional file. This approach (also called "Use metadata to bridge models and ontologies" makes it easy to leave the proprietary process model independent so it can be changed in the modeling tool, but once changes are performed the semantic annotation might not be actual any more.
Michael Fellmann and Oliver Thomas describe in their paper "Semantic Business Process Management: Ontology based Process Modeling Using Event-Driven Process Chains" and in a newer version in German I just got to read how semantic process modeling (a synonym for the semantic annotation of process models) can be done. In their approach they also use metadata to describe what each process action in a business process model means. This metadata connects the process model to an ontology that builds on the Suggested Upper Merged Ontology (SUMO) and where not only domain knowledge but also knowledge about the process language is stored (e.g. they have Activities as well as Offer). But in my opinion this approach makes it quite difficult to use existing ontologies: a domain ontology probably won't have concepts such as Process, but will only talk about the domain at hand.
Additionally, it remains somehow unclear how the semantic annotation is done in practice. They say that they use Protégé for ontology creation and in another paper they speak about semantic wikis for storing the relationsships in a process model. But neither of those two makes a semantic annotation possible. That there is a relationship can be seen on the website of one of the authors, where Semantic Business is linked with a semantic wiki.
The problem with both approaches (by Y. Lin and M. Fellmann) seems to me that they always need another tool. How can business managers be persuaded to first model their processes (which they don't seem to like that much) and afterwards also annotate these models in another tool? I guess this could be quite hard.
Therefore, our approach builds on the extension of a single tool. This can bring the problem that one is bound to a single modeling language for which this extension in the tool is created and that is of course not something we should aim for. Therefore, we'll leverage an existing well-known plattform that by now supports several modeling languages and a lot of more things and which usage is still growing more and more: the Eclipse plattform.
Therefore, we'll use the extension points that are one critical element in Eclipse and extend any existing EMF model with a semantic annotation. By this, we are not only bound to a specific modeling language (such as BPMN), but can support the semantic annotation for several existing modeling languages that already exist in Eclipse or will be integrated in Eclipse at a later time.
Our prototypical implementation will be based on the Eclipse project Java Workflow Tooling (JWT) that is a plattform for modeling, execution, simulating, deploying and monitoring any business process or workflow. More details on the project JWT as well as on our mechanism how this semantic annotation is made independent on the underlying metamodel will be described in the next blog post.
If you model something (and here it doesn't matter whether this is a business process via BPMN, a UML class diagram or a flow chart) you make use of a standard that defines what kind of model elements exist: in BPMN you have Activities, Events, Gateways, etc. In UML class diagrams you have classes, attributes, methods and assoziations.
So these define what the metamodel element is about. There is often no clear defined semantics in a machine-readable way how a Gateway in BPMN or a method in UML shall be used. The semantics of these elements is mostly captured in a textual way.
So for every human who has a little bit of knowledge about BPMN or UML it is mostly clear what these diagrams mean. But what does a computer do with that? Can it "understand" what we model? Sure, you could say, I tell him that each Activity in BPMN shall be executed. Okay, that's fair. But what does it need to execute? What does the label in these Activities mean? And are there e.g. any relations between an Activity in BPMN and e.g. an Action in UML activity diagrams? The PC simply can't say.
That's where the semantic annotation comes into play. Annotation is contemporary English and has two meanings:
(1) a note added by way of comment or explanation
(2) the act of annotating.
As outlined in this session the annotation can be about a whole document (document-level annotation) or refer to just a specifi part of a text (character-level annotations). Additionally, it can be about the constructs defined in a metamodel (metamodel-level annotations) and on elements in the model itself (model-level annotations).
So, with semantic annotation we aim to capture the semantics of the metamodel elements when different representations are used as well as the terms that describe the model elements.
Now you may ask: what for?
Business process models and workflow models have despite their growing usage still some obstacles to cope with:
- they are used for documentation purposes only
- they are often not up-to-date
- they are not executable
- not all processes /workflows in a company are modeled
- there are different (somehow incompatible) representations used in different companies or departments
- several constructs for one real-world entity exist
- and (the other way round) one construct can be used for different purposes
Now I'd like to come to the initial question: how to semantically annotate a process model?
There are several research projects in the world and many of those need a semantic annotation of the process model (for the rest of this blog post I'll only speak about process models and workflows, however, semantic annotation is definitely something used also for other modeling areas such as software or systems engineering).
Yun Lin describes in her dissertation "Semantic Annotation for Process Models" an approach where an additional tool is used that can read an existing process model and one or more ontologies and can then annotate the model elements with concepts of the ontology and store that in an additional file. This approach (also called "Use metadata to bridge models and ontologies" makes it easy to leave the proprietary process model independent so it can be changed in the modeling tool, but once changes are performed the semantic annotation might not be actual any more.
Michael Fellmann and Oliver Thomas describe in their paper "Semantic Business Process Management: Ontology based Process Modeling Using Event-Driven Process Chains" and in a newer version in German I just got to read how semantic process modeling (a synonym for the semantic annotation of process models) can be done. In their approach they also use metadata to describe what each process action in a business process model means. This metadata connects the process model to an ontology that builds on the Suggested Upper Merged Ontology (SUMO) and where not only domain knowledge but also knowledge about the process language is stored (e.g. they have Activities as well as Offer). But in my opinion this approach makes it quite difficult to use existing ontologies: a domain ontology probably won't have concepts such as Process, but will only talk about the domain at hand.
Additionally, it remains somehow unclear how the semantic annotation is done in practice. They say that they use Protégé for ontology creation and in another paper they speak about semantic wikis for storing the relationsships in a process model. But neither of those two makes a semantic annotation possible. That there is a relationship can be seen on the website of one of the authors, where Semantic Business is linked with a semantic wiki.
The problem with both approaches (by Y. Lin and M. Fellmann) seems to me that they always need another tool. How can business managers be persuaded to first model their processes (which they don't seem to like that much) and afterwards also annotate these models in another tool? I guess this could be quite hard.
Therefore, our approach builds on the extension of a single tool. This can bring the problem that one is bound to a single modeling language for which this extension in the tool is created and that is of course not something we should aim for. Therefore, we'll leverage an existing well-known plattform that by now supports several modeling languages and a lot of more things and which usage is still growing more and more: the Eclipse plattform.
Therefore, we'll use the extension points that are one critical element in Eclipse and extend any existing EMF model with a semantic annotation. By this, we are not only bound to a specific modeling language (such as BPMN), but can support the semantic annotation for several existing modeling languages that already exist in Eclipse or will be integrated in Eclipse at a later time.
Our prototypical implementation will be based on the Eclipse project Java Workflow Tooling (JWT) that is a plattform for modeling, execution, simulating, deploying and monitoring any business process or workflow. More details on the project JWT as well as on our mechanism how this semantic annotation is made independent on the underlying metamodel will be described in the next blog post.
Donnerstag, 6. November 2008
Just started...
So, this is the first article in this new blog. This blog will be concerned about personal experiences, many things about programming in general and especially about Eclipse. I'm a project co-lead of the Java Workflow Tooling (JWT) project and will write time and again about things that we experience there.
I'm working as a researcher on my Ph.D. at the Programming distributed Systems lab. My thesis is concerned about how business process and workflow models can be extended by semantic information and how this additional information can be used for other purposes. A list of my current publications can be found here.
I'm working as a researcher on my Ph.D. at the Programming distributed Systems lab. My thesis is concerned about how business process and workflow models can be extended by semantic information and how this additional information can be used for other purposes. A list of my current publications can be found here.
Abonnieren
Posts (Atom)
