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,
Florian
------------------------------------------------------------------------
*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)
Hello,
Here is a a mail to introduce you the architecture for transformations
integration.
Outline:
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
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html)
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
------------------------------------------------------------------------
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
