| [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 |
Attachment:
jwt-transformations.tgz
Description: application/compressed-tar