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
|