Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [jwt-dev] Transformation architecture (and more)

Hi Mickael, hi Marc,
thanks a lot for your quite impressive email and content. The design of the transformation extension point seems quite good. It is simple to comprehend, gives a good basis model that can easily be extended by others, but includes all the power we need.
However, I got a few comments concerning the implementation:
- Please, if you include comments in the source code, write it in English.
- There is no header on the mail: who has written the code, when has it been implemented and a part that states that this will be EPL (if it will be contributed to JWT).
- The plugin does not use the WEExternalAction-mechanism which is responsible for displaying the item in the tool bar as well as in the menu bar. Since we would maybe want to include that part in a later version of AgilPro LiMo (currently the only existing RCP program of JWT) this would be very helpful for us.
- The plugin can be found on my PC in a runtime workbench: the window is then displayed somewhere on the bottom (probably because you are using a functionality to get the middle of the display, but I'm using two displays in parallel).
- The UI does not look very similar to Eclipse. Please have a look at the UI guidelines (but this is really a minor issue at the moment)
- The bigger problem is that I don't receive any XPDL code at the end: I see that a file is created but this has zero bytes (indifferent whether I specify a source file or want to use the open file in the background) Does it maybe have problems finding the jwt2xpdl.xsl?
Concerning the given names: I agree that jwt-xxx would be a good structure for specifying lateron which kind of transformation it is and I also agree with the plan of the CVS/SVN layout. Renaming jwt-compatibility to jwt-transformation shouldn't be an issue.
Do you already have some samples you used to test your transformation? The folder you've sent was empty...
Thanks for the moment. I will take a closer look at the code in the following days.
Best regards,

Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Mickael Istria
Gesendet: 25 February 2008 17:39
An: Java Workflow Toolbox; stephane.drapeau@xxxxxxx
Betreff: [jwt-dev] Transformation architecture (and more)


Here is a a mail to introduce you the architecture for transformations integration.
1. Description of the architecture
   a. when activating the plugin
   b. when running a transformation
2. How to add a transformation?
3. Repository layout
4. Related elements in other JWT parts
5. Feedback, improvements, remaining issues...


0. Goal
Allow developer's to add their own transformations to and from other standards into JWT project. (JWT -> BPEL...)

1. Description of the Transformations architecture
I attached a file that describes the architecture as a class diagram. It may be a little messy to read since I put a lot of details in it whereas it is not necessary for general comprehension. (This diagram was made with netbeans6, if you want the original file, don't hesitate to ask).
As you can see, this architecture uses Eclipse extension points to facilitate the add of a transformation. Extension points are also useful because the are extensible, so that it will be easy to add other metadata if necessary (file type, version...).
(It is the time to take a glance at the diagram before we continue...)
...Ok? Thus, let's continue...
As you can see, this architecture is composed of a main generic plug-in which defines everything necessary to add a specific transformation that would be automatically included by the generic plug-in.
The following is a description of what happens
   a. When the plug-in is activated
Activator is called on the generic plug-in. This activation calls the ProcessServiceMember.process method, which will get all informations to get informations from the extension point and add it to a registry that will be use later. (This mechanism is done as explained at
This part of the code is used only once, at activation.
   b. When calling a transformation from the generic plug-in
The method that handle the call just has to call TransformationsRegister.getInstance.getTransformation(transformationName_defined_in_extension).transform
It is aimed to have one or several generic handlers that would be defined in generic plug-in, to unify transformations that have the same goal (export to model, export to execution platform compliant type...)
Currently, there is only one export handler that is used to manage all the transformations, but an import handler will be soon written.

2. How do I add my custom transformation?
Nothing is easier!
Of course, it requires org.eclipse.jwt.compatibility.generic plug-in.
You just have to implement a class that extends TransformationService, with its method transform (that will be called to apply the transformation). Then, you create an extension for the extension point org.eclipse.jwt.compatibility.transformations that defines a name for your transformation and the class that implements the transformation (extending TransformationService), and more other optional fields.
I attached a tarball with the code. Take a look at the extension of StubTransformation to give you a concrete example.

3. Repository layout

This is the description of the SVN Layout:
 * jwt-transformation/jwt-transformation-base -> contains the generic plug-in with handlers & co
 * jwt-transformation/jwt-xpdl -> contains JWT to XPDL transformation
 * jwt-transformation/jwt-stubTransformation -> A stub
 * jwt-transformation/[other transformation] -> ...
 * jwt-transformation/jwt-samples -> contains sample files that can be used for demonstrations, functional and technical (e.g. unit) testing.
Each transformation will have to be ok with the samples of jwt-transformation/jwt-samples, they must become a reference set of scenarii.

Notes about the layout
   * <Marc speaking> jwt-transformation was previously named jwt-compatibility because I felt it was about more things than transformations (like validation, integrating other DSLs...). However, besides transformations there are not a lot of ways to achieve compatibility with other kind of processes, and none of them apply here :
      * either (on the UI side) develop a new, dedicated view / editor (not the solution we've chosen till now),
      * or interface with APIs provided by existing tools (ex. with STP BPMN ed, UDDI service registry...) or execution engines (ex. jwt-runtime-bonita-sca, going in the wam).</Marc speaking>
   * in the project name "jwt-xpdl", "jwt-" is the prefix (enforcing jwt's status of pivotal metamodel) and "xpdl" the name of the transformation
   * example : the jwt-xxx transformation project may contain material related to the jwt to xxx and / or xxx to jwt transformations

4. Related elements in other JWT parts
How JWT transformations relate to other JWT parts : transformations must translate well
   * application (especially service and sca) mappings : related to runtime workflow & process API
   * & user mappings (roles)

5. Improvements, remaining issues...
Here are some clues to give your feedback about this architecture and detect things to improve and problems to solve.
   * Should we add informations to distinguish several kinds of transformations? What are the they? With Marc, we thought that there were mainly 3 kinds of transformations:
      * those that make graphical format from JWT (JWT->BPMN),
      * those that are a bijection between JWT and an intermediary equivalent type,
      * and those that generate a execution platform compliant type (such as XPDL for Bonita) that could be integrated later in a "deployment" tool on a workflow engine.
   * Should we clearly distinguish import and export transformations? IMHO: yes (ExportTransformationHandler is different from ImportTransformationHandler), and next work will help us to verify it or not.
   * Is there a better layout for SVN repository?
   * <Marc speaking>(using XPDL as an example) How to keep the notion of "generic" XPDL versus execution platform specific XPDL, and avoid having a lot of copy-pasted transformations with only slight differences : What about the concept of pluggable Application "sub-"transformation ? Ex. Application with class SCAServiceApplication -> XPDL for Bonita __with__ SCA specific Bonita Hook... This would target the "Application Mapping" problematic (that is of concern in the WAM - anyway, we're going to explore it next)</Marc speaking>
   * To be continued...

To Be Done
next step : commit, try to integrate Obeo's BPMN2JWT over ATL using ant (Open Wide),
later on : deploy (related to WAM's runtime workflow API)


Mickael and Marc

Back to the top