Re: AW: AW: [jwt-dev] [architecture] JWT and the Process VirtualMachine

[Koen Aers <koen.aers@xxxxxxxxx>]

Hi All,

To add a bit to this discussion, I would like to bring on the example of
EMF. EMF provides a metamodel that serves as a hub between multiple ways
of expressiong a relationship between classes: 
- UML class diagrams expressed in XMI
- Java class hierarchies
- XSD documents expressing the serialized (XML-)form of objects
Now while EMF is successful in transforming itself to one of these other
representations, there are a lots of issues if you try to transform one
of these three representations into another one of these. EMF is capable
of doing some of these transformations, but if for instance you start
from an XSD that is not written up with this transformation in mind the
generated Java code will be brittle and crippled.
IMO similar issues will be faced if someone tries to transform a BPMN
diagram in a BPEL or XPDL diagram. If you don't write up the BPMN
diagram with the target runtime language in mind, there is a fair risk
that the resulting process in the target language is not optimal, to say
the least. 

Regards,
Koen

Op donderdag 21-06-2007 om 19:06 uur [tijdzone +0200], schreef Marc
Dutoo:
> Hi Tom, Florian,
> 
> I agree with Tom's argument that "the process development process" 
> starts from the business view and later goes to the technical view.
> 
> Being able to go back to the business view from the technical one has 
> advantages and is made possible by using the same metamodel. However 
> once the implementation step has been started in the technical view, 
> modifying the business view is dangerous because it may (will) probably 
> have yet unforeseen consequences on the way the present implementation 
> works (ex. in step 1, you do a login session action and a get info 1 
> action ; in step 2 you do a get info 2 action ; so if you switch them in 
> the business view, it will be broken).
> 
> Going back to the business view may happen :
>     * 1. because the implementor can't implement the business view, 
> because of some limitation of his BPM language of choice or of his 
> chosen engine. In the real world, I'd rather see the technical person 
> going to the functional person and finding a solution together, i.e. 
> adapting the functional BP representation so it still fits the 
> requirements and the technical person will be able to actually implement it.
>     * 2. or because functional requirements have changed. Now that means 
> that a previous version of this BP has already been released and 
> deployed in the information system : so this is actually a new, updated 
> version. Well, if requirements change, the business as well as technical 
> informations of the process will change too, and it fast becomes another 
> process.
> 
> So if we want to help developers in the real world, we also have to give 
> them tools for all these operations. Being able to seamlessy switch to 
> one view to another is great, but tools to help importing and exporting 
> business process definition are just as valuable to the developer in the 
> real world.
> 
> Now being able to help the business analyst and the technical developer 
> to work together thanks to collaboration features would be great, but 
> it's another matter.
> 
> I'll try to put down some requirements provided by the SCOrWare partner 
> project soon. They are interesting because since SCOrWare is an SOA 
> platform, it addresses well the technical problematics.
> 
> Regards
> Marc Dutoo
> Open Wide
> 
> Florian Lautenbacher a écrit :
> > 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
> >>
> >>
> > 
> 
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev