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

Florian Lautenbacher wrote:

Hi Tom,

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. What use cases do you see for working in multiple views
iteratively ?

I agree with you that business analysts probably don't work with the view
for IT specialists and the other way round. But if these views are based on
the same metamodel and there is no model-transformation between them, then
both have the same property names they can talk about 

so far i agree.


and it is not the case
that the IT people simply change the process because it doesn't fit to their
execution logic and the business process stays put. We want to have a
process that contains the same flow logic in the business view as well as in
the technical view. And if a business analyst changes the process, then the
IT specialist should receive a message that he should have a look at this
process again and refine it.
with jPDL, i think we have created the process language that allows for the best possible matching between the analysis model and the execution model.
one of the important concepts to allow for this is actions. in jPDL, you can add hidden actions. a kind of callbacks that developers can add to associate programming logic without touching the graph.
also, we allow for custom node implementations. that way, a developer can just implement all the behaviour that an analyst describes in a node, even when there is no out-of-the-box process construct that matches these requirements.
but still, there are many non-trivial limitations that only come up in rare situations. like e.g. during execution, transitions cannot be waitstates. where as an analyst might specify a transition between the actual state and the desired state with a transition. a transition that takes some time.
in our experience, keeping the analyst process model *exactly* the same as the implementation process model is possible but it comes at (an often) big cost of associating a lot of custom code to the process.
so in practice, it is much easier to just apply some change to the analyst diagram to get an implementation diagram.
it is IMO just like with class diagrams. An analyst can draw UML class diagrams to analyse a domain model. but rarely these models end up as-is in the code base. some time ago, this was very clear when EJB's and DTO's forced us to have a different implementation model from the analysis model.
once you have an ejb implementation model working after a long struggle, i would guess that you don't want your analyst to check in some model updates right before a release.
another aspect is that envisioning all the tech details in configuration properties is problematic. when you're implementing node types, you define a set of configurations for that node. then you use those properties while coding the node implementations with an API (e.g. a task component API or a JavaMail API). but you can never capture the full power of an API in a few configuration properties. so if the configuration options don't give enough flexibility, you have to revert to custom coding. 

regards, tom.



Best regards,

Florian


-----Ursprüngliche Nachricht-----
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:
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






--
regards, tom.

Back to the top