Von: Tom Baeyens [mailto:tbaeyens@xxxxxxxxxx]
Gesendet: Mittwoch, 20. Juni 2007 17:05
An: Florian Lautenbacher
Cc: tom.baeyens@xxxxxxxxx; 'Java Workflow Toolbox'; 'Philipp Kretschmer'
Betreff: Re: AW: [jwt-dev] [architecture] JWT and the Process VirtualMachine
> So the idea of JWT is to have a process model that is visible in
different > views (one BPMN view where probably some details are missing
and a more > technical view with the additional information) which can also
be displayed > as an XPDL process (this is conform also to your image about
the technical > details of the PVM).
I think this is very close to what I said with the last sentence in:
> 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.
In practice, my guess would be that teams will not work with different
views. E.g. the analyst looking at the BPMN view and the developer looking
at the XPDL view.
If this implies different property names, then you're bound for
misunderstandings when they communicate about a diagram.
What use cases do you see for working in multiple views iteratively ?
The one time translation was not inspired by technical reasons, but more by
the "process development process"
Florian Lautenbacher wrote:
thanks a lot for your extensive description of your view on the things. In
most of the points I agree with you:
business managers are used to model their processes using nodes and
transitions. So this is the very basic part of each process model and
of course to be extended with additional information such as who is
responsible, what kind of service is to be invoked, what data and
are passed between these actions (activities, tasks, process steps -
whatever each standard names them).
And this (nodes and edges) is also the basic concept of BPMN, EPCs, UML
Activity Diagrams and other proprietary notations for modelling a business
process. Yes, most of these descriptions are only intended for
between humans and are therefore not executable.
But, in our eyes, these business models can be enhanced with technical
informations, so that they are executable. Therefore, it is not
a unidirectional translation between BPMN and an execution language. Of
course, if you are using ONLY the BPMN constructs then you can't
execute it (and that would make it unidirectional), but with an extension
the meta-model you can execute it.
So the idea of JWT is to have a process model that is visible in different
views (one BPMN view where probably some details are missing and a more
technical view with the additional information) which can also be
as an XPDL process (this is conform also to your image about the technical
details of the PVM). Personally I don't think that this would be also
possible with BPEL, since BPEL is a block-based language and therefore you
need a unidirectional transformation between the process model and
But with XPDL (and maybe also with jPDL) this should be possible.
In the project AgilPro (which is one of the contributions for JWT) we made
such a distinction between a business manager process model and a more
technical model which can then be executed. Therefore, we currently use an
adapter-framework with adapters for several existing applications (Office,
PDF, Browser, Mail, Google Maps, ERP-specific-things, etc.) and are also
working on the execution of these process models on jBPM using the
I understand your concerns about the translation between the graph and the
tech model: Yes, not all steps in a process can be performed by computers.
In fact, most of the current tasks in companies are done by humans. This
no problem when using our adapter framework, but leads to difficulties
translating the process into languages such as BPEL or XPDL which doesn't
support human interaction (at least without extensions such as the
I'm not sure whether the developer should be allowed to change the
process in order to fit only to the constraints by the executable
However, he should be allowed to refine the process. So, if a business
manager modeled one action the developer should be able to describe that
this action can be performed by several other actions. This way the
analyst still sees the original process and not something that he
but that is not executable in real life. If the developer recognizes that
this process can't be executed the way it was designed by the business
manager/analyst he needs to contact him(her) and discuss these issues.
Otherwise the process models won't be of much use for the future, too!
Considering the graphical notation: we currently have a notation that is
proprietary, but we want to have different views. So, a student of mine
be working on a comparison between BPMN and AgilPro and we will try to
different graphical representations for the different needs of users
(somewhere in the future ;-)
Oops, this was also lengthy :-) Sorry for that!
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Tom Baeyens
Gesendet: Mittwoch, 20. Juni 2007 09:35
Betreff: Re: [Fwd: [jwt-dev] [architecture] JWT and the Process
I see two main principles for the tooling counterpart of the PVM:
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
configuration information for that node type. to enable this, the
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
- 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
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
When an (non-tech) analyst starts to model a process, this has to be done
free modelling language like BPMN, visio or IDS Scheer's ARIS notation.
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
make a process executable (see
http://docs.jboss.com/jbpm/pvm/technical.details.png). 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
process because of the executable language specific constraints.
After the translation to an executable process, analyst and developers
a common language in the graphical part of the executable process. But
the analyst lost his freedom to change anything he wants since that
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
Then BPMN diagram can be converted (1 time
translation) to executable process languages like BPEL, XPDL and jPDL.
translation should generate a new file.
For modelling an XPDL process for instance, the designer tool should
itself as a straight XPDL editor. All the parts that XPDL specifies
be exposed by the tool with their proper names (properties and node
But where XPDL is undefined (like in the graphical notation), that is
BPMN can be used to complement.
Same story for other executable process languages.
sorry for the length :)
Koen Aers wrote:
Van: Marc Dutoo <marc.dutoo@xxxxxxxxxxx>
Antwoordadres: Java Workflow Toolbox <jwt-dev@xxxxxxxxxxx>
Aan: Java Workflow Toolbox <jwt-dev@xxxxxxxxxxx>
Onderwerp: [jwt-dev] [architecture] JWT and the Process Virtual
Datum: Tue, 19 Jun 2007 21:03:22 +0200
Following my last email, I'll try here to give more details on the
concept of the "Process Virtual Machine" and why it's very interesting
for the whole BPM field and especially for JWT.
The core idea is to solve the problem of "too many different BPM
standards and languages", which hinders and complexifies integration
between components using different standards. You'll note that it is
the same problem JWT attempts to solve though on the tooling side, by
having a unified tooling solution. The proposed solution is to "use
the right language for the right job" without integration and
compatibility worries by making all of them run on the same Process
Virtual Machine (metaphorically similar to Java or rather the .NET
I personally think this "gordian knot"-like approach is clever and
quite right, since the advocated "use the right language for the right
says that having multiple standards should not bring problems but
flexibility, being a range of diverse solutions for diverse needs
available to the architect. It would even allow users to write their
own business-oriented BPM language and let it run on top of it, as
well as being an open door for any proprietary language.
Moreover, being championed (and implemented in their next generation
solutions) by JBoss jBPM, which is almost a defacto standard in the
Open Source world, and Bull Bonita / Orchestra, which is (the just
released Shark 2.0 aside) by far the other more complete, visible and
entreprise ready BPM solution, it is promised, at the very least to
have quite an imrpressive audience.
So where does JWT fit in ? The bottom line is : JWT solves the tooling
side of the problem, so in a global point of view the picture remains
the same : offering genericity across BPM languages and representation.
Now how could JWT actually benefit from this paradigm and runtime ?
Please send you feedback !
jwt-dev mailing list
jwt-dev mailing list