Ever tried a simple Java workflow engine ? This is the time to do it! Last week, we released jPDL 3.2.1. jPDL is the process language for writing statemachines in Java. jPDL is build in such a way that it supports Business Process Management (BPM), workflow and orchestration in standard as well as enterprise Java environments.
Download it from sourceforge and and check it out.
If you download and unzip the suite package, you get the full documentation, a graphical designer plugin for eclipse, the runtime engine preconfigured in a JBoss app server (jPDL also runs without an app server or on any other app server), and a web console. All preconfigured so that you don't have a hassle to get started and evaluate the process language.
Thursday, 28 June 2007
Wednesday, 20 June 2007
Is BPMN The Solution For All Process Languages ?
I would like to start this freely available answer with "It depends...", the typical answer of expensive consultants :)
BPMN is clearly a great language for non tech analysts. But the approach that BPMN has to map BPMN to all the executable process languages is sometimes misinterpreted. The Process Virtual Machine describes how multiple process languages can be supported by one single runtime engine.
The text below started off as an explanation of how we can replicate that approach in a graphical process designer. But it also contains a no-so-traditional-but-nonetheless-realistic view on how business analysts and developers can jointly work together on the automation of business processes.
A component model for nodes
On the tooling end, the base framework should be able to display nodes and transitions. Like e.g. in BPMN, but ignore the decorations and the properties for a minute.
Then a process construct should be a plugin. The plugin contributes the following to the base plugin:
- shape: the tool could predefine the 4 BPMN shapes, but a node-plugin should be able to self-define it's shape with its own figure.
- configuration: the plugin should contribute a properties form to enter the configuration information for that node type. to enable this, the internal model of the process graph must have a dynamic set of properties.
- constraints: the plugin should be able to specify constraints like: this type of node can only have 1 outgoing transition. or: outgoing transitions from this node type can only be connected with node type z.
- decorations: which decorations are supported. maybe this could be done with icons so that apart from the BPMN decorations, node implementors can supply a graphical colourful icon.
The whole idea is that you should separate all the node type specifics from the basic process designer container.
Guidance for process languages
BPMN recognizes multiple process languages. But it has suggested a problematic approach to handle that.
BPMN defines a mechanism of bidirectional mappings from BPMN to executable process languages. This suggests that you could model in BPMN and then translate to any executable language. IMO, that is a unidirectional translation.
When an (non-tech) analyst starts to model a process, this has to be done in free modelling language like BPMN, visio or IDS Scheer's ARIS notation. Of course, those models only contain graphical information intended for human-to-human communication and they are not executable.
Executable processes exists of graphical structure
and technical details to make a process executable. The graphical picture is the common language between analysts and developers. An executable process is human to system communication in the sense that it specifies to the computer system what it has to do.
The translation from a modelling process (graph only) to an executable process (graph and tech details) is a big one. First of all, the analyst may have modelled steps in the model that are not to be automated by the computer system. Second, the developer makes a selection as to which process language best fits his technical environment. It will most likely not be possible to keep the original process model as-is for the executable process because of the executable language specific constraints.
After the translation to an executable process, analyst and developers have a common language in the graphical part of the executable process. But now, the analyst lost his freedom to change anything he wants since that implies software changes.
This is why I come to the following conclusion: A process designer tool should support each process language individually. BPMN is one of those languages/notation. This is the free modelling tool. Then BPMN diagram can be converted (1 time translation) to executable process languages like BPEL, XPDL and jPDL. This translation should generate a new file.
For modelling an XPDL process for instance, the designer tool should present itself as a straight XPDL editor. All the parts that XPDL specifies should be exposed by the tool with their proper names (properties and node types). But where XPDL is undefined (like in the graphical notation), that is where BPMN can be used to complement. Same story for other executable process languages.
BPMN is clearly a great language for non tech analysts. But the approach that BPMN has to map BPMN to all the executable process languages is sometimes misinterpreted. The Process Virtual Machine describes how multiple process languages can be supported by one single runtime engine.
The text below started off as an explanation of how we can replicate that approach in a graphical process designer. But it also contains a no-so-traditional-but-nonetheless-realistic view on how business analysts and developers can jointly work together on the automation of business processes.
A component model for nodes
On the tooling end, the base framework should be able to display nodes and transitions. Like e.g. in BPMN, but ignore the decorations and the properties for a minute.
Then a process construct should be a plugin. The plugin contributes the following to the base plugin:
- shape: the tool could predefine the 4 BPMN shapes, but a node-plugin should be able to self-define it's shape with its own figure.
- configuration: the plugin should contribute a properties form to enter the configuration information for that node type. to enable this, the internal model of the process graph must have a dynamic set of properties.
- constraints: the plugin should be able to specify constraints like: this type of node can only have 1 outgoing transition. or: outgoing transitions from this node type can only be connected with node type z.
- decorations: which decorations are supported. maybe this could be done with icons so that apart from the BPMN decorations, node implementors can supply a graphical colourful icon.
The whole idea is that you should separate all the node type specifics from the basic process designer container.
Guidance for process languages
BPMN recognizes multiple process languages. But it has suggested a problematic approach to handle that.
BPMN defines a mechanism of bidirectional mappings from BPMN to executable process languages. This suggests that you could model in BPMN and then translate to any executable language. IMO, that is a unidirectional translation.
When an (non-tech) analyst starts to model a process, this has to be done in free modelling language like BPMN, visio or IDS Scheer's ARIS notation. Of course, those models only contain graphical information intended for human-to-human communication and they are not executable.
Executable processes exists of graphical structure
and technical details to make a process executable. The graphical picture is the common language between analysts and developers. An executable process is human to system communication in the sense that it specifies to the computer system what it has to do.The translation from a modelling process (graph only) to an executable process (graph and tech details) is a big one. First of all, the analyst may have modelled steps in the model that are not to be automated by the computer system. Second, the developer makes a selection as to which process language best fits his technical environment. It will most likely not be possible to keep the original process model as-is for the executable process because of the executable language specific constraints.
After the translation to an executable process, analyst and developers have a common language in the graphical part of the executable process. But now, the analyst lost his freedom to change anything he wants since that implies software changes.
This is why I come to the following conclusion: A process designer tool should support each process language individually. BPMN is one of those languages/notation. This is the free modelling tool. Then BPMN diagram can be converted (1 time translation) to executable process languages like BPEL, XPDL and jPDL. This translation should generate a new file.
For modelling an XPDL process for instance, the designer tool should present itself as a straight XPDL editor. All the parts that XPDL specifies should be exposed by the tool with their proper names (properties and node types). But where XPDL is undefined (like in the graphical notation), that is where BPMN can be used to complement. Same story for other executable process languages.
Wednesday, 6 June 2007
There is a big change going on lately
"There is a big change going on lately. A year ago, all BPM and workflow was centered around BPEL and around web service orchestration. And that was the way to go, that was the single process language that's going to make it. At that time we were already long time working on our multi-language approach."After noisy attempts at the moscone, inbetween ringing phones of the labs crew, an eager housecleaning lady and an apologising hotel manager we managed to shoot an interview in San Fransisco at JavaOne this year.
Monday, 4 June 2007
New JBoss User Group Starts in Rotterdam
A brandnew JBUG Benelux is launched by Lunatech in Rotterdam, The Netherlands next Friday, June 8th. I'll be speaking about jPDL, but more importantly, there will be pizza's ! It will also be a great way to meet new collegue nerd developers or see how others use JBoss. Check out all the details on Peter Hilton's blog and drop him an email if you intent to come. I hope to meet you there.
Subscribe to:
Posts (Atom)