Skip to main content

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

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 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.

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