[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Fwd: [jwt-dev] [architecture] JWT and the Process Virtual Machine]
|
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 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 (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
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.
sorry for the length :)
regards, tom.
Koen Aers wrote:
-------Doorgestuurd bericht-------
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 Machine
Datum: Tue, 19 Jun 2007 21:03:22 +0200
Hi all
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 approach).
I personally think this "gordian knot"-like approach is clever and quite
right, since the advocated "use the right language for the right job"
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 !
Regards
Marc Dutoo
Open Wide
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
--
regards, tom.
