Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [jwt-dev] [architecture] JWT and the Process VirtualMachine

Hi Tom, 

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 needs
of course to be extended with additional information such as who is
responsible, what kind of service is to be invoked, what data and artifacts
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 communication
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 necessarily
a unidirectional translation between BPMN and an execution language. Of
course, if you are using ONLY the BPMN constructs then you can't completely
execute it (and that would make it unidirectional), but with an extension of
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 displayed
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 WS-BPEL.
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
BPEL-extension. 

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 is
no problem when using our adapter framework, but leads to difficulties when
translating the process into languages such as BPEL or XPDL which doesn't
support human interaction (at least without extensions such as the upcoming
BPEL4People).
I'm not sure whether the developer should be allowed to change the original
process in order to fit only to the constraints by the executable language.
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 business
analyst still sees the original process and not something that he designed,
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 will
be working on a comparison between BPMN and AgilPro and we will try to offer
different graphical representations for the different needs of users
(somewhere in the future ;-)

Oops, this was also lengthy :-) Sorry for that!

Best regards,

Florian



-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Tom Baeyens
Gesendet: Mittwoch, 20. Juni 2007 09:35
An: jwt-dev@xxxxxxxxxxx
Betreff: Re: [Fwd: [jwt-dev] [architecture] JWT and the Process
VirtualMachine]

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.

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev




Back to the top