An Eclipse editor for basic Smooks configuration files appears for the first time in JBoss Tools 3.0. In this initial version, the editor aims to handle Java to Java and XML to Java transformations. Essentially, the editor is a graphical means for creating and modifying Smooks configuration files. This is welcome, as it helps developers avoid directly editing the configuration file XML (tedious and error prone process), and it helps developers to think more in terms of the problem they are trying to solve (defining the transformation), rather than exactly how Smooks needs to be configured to accomplish the task.

Often the ideal solution to a problem heavily depends on how the problem is framed. What, exactly, is the Smooks editor trying to solve? There are two broad possibilities:

1. Following the current work, making it easier for developers to create and edit Smooks configuration files.
   
2. Making it easy for developers to define data transformations.

The two are not the same, and many implications follow from each approach. In the first approach, the focus is on the transformation technology (Smooks) and support for (ultimately) the range of possible configuration details provided by that technology. So, while there is some abstraction from the underlying technology and its specific configuration format, the editor is there to serve the purposes of the implementation technology, and then secondarily the problem domain (data transformation).

A Data Mapper is a different type of tool. A Data Mapper concentrates on the task of defining data transformations and, to a large extent, hides the implementation technology used behind a Domain Specific Language (DSL) for data transformations. (This DSL is often realized in graphical form, but can also be textual if desired.) This difference can be pictured as in the following:

The Data Mapper uses a compiler to translate the transformation from the (graphical) DSL into the required implementation target language (here Smooks, but conceptually could be others, as the diagram shows). The graphical mapping language used in the Data Mapper is by nature abstracted from the implementation languages used, and often is a subset of any one specific implementation language. As the diagram shows, compilation from the graphical mapping language to the target implementation language is typically seen as being one-way, though a "decompiler" is also possible, typically with similar fidelity to those found for other languages such as Java. (Further, annotated target language can ease decompilation, as in the cases where debug support is necessary.)

Neither of these two approaches is correct or incorrect in isolation. Rather, the appropriateness of each depends heavily on how the problem is conceived. In our case, we need to consider this question:

Are we providing tools for users who want to accomplish data transformation in the context of SOA (or Enterprise) application development, or are we providing tools for users who want more easily to configure the underlying transformation technology (Smooks)?

Another way of framing the issue is to consider the target developer segment: technology expert (Smooks editor) or domain expert (which includes technology experts as well).

A possible middle ground could see the Smooks configuration editor and the Data Mapper in a similar relation as that of the JBoss ESB configuration file editor and the SOA Modeler. It remains to be seen whether this approach is the right emphasis for SOA-P tools.

<-- Back to SOA Tools