DSM in IoC frameworks

[this is largely an article I posted on theservierside.com: here]

XML application descriptors (configurations) in core schemas of various IoC frameworks are more or less plain Java or C++ (or other languages) method invocations expressed in XML. Such a low level schema has the advantages of being compact, straightforward, and applicable to general applications. However, it has weaknesses of being poorly expressive and involving low level programming signatures (APIs). Therefore, IoC core schemas are verbose, error-prone, and not desirable for domain users.

One of the approaches to address these issues is to raise the abstracion level of XML configurations by supporting user-defined domain specific modeling/language (DSM/DSL) schemas in IoC frameworks. Spring 2.0 introduced the so-called extensible XML authoring (Spring 2.0 appendix B) allowing users to extend the core schema by user-implemented plug-in handlers. These manually crafted handlers process XML DOM elements that are defined by users to extend the core schema. This scenario has the disadvantages of involving low level XML DOM programming and tying to proprietary (Spring 2.0) callback interface API. Therefore, it is not suitable for domain users, not able to be automated/tooled, and not likely to be followed by other IoC containers.

The article Domain Specific Modeling in IoC frameworks presents another straightforward alternative based on the concept of model transformation. The idea here is simply leverage the IoC framework itself and the ubiquitous W3C XSLT technique without involving any proprietary plug-in API or low level XML DOM. To define a DSM, one only needs to define its XML schema and then design a XSLT stylesheet that maps a configuration in this DSM schema to a configuration in a target schema (such as the core schema). To use this new DSM schema, a XML configuration (in this DSM schema) only needs to have the stylesheet file name (or URL) specified in its process instruction (PI) section. With a XSLT transformer integrated IoC container, this XML configuration will be recursively transformed until a final target configuration that does not have such a transformation process-instruction (presumbly, it ends up with the core schema).

This model-transformation based DSM scenario has already been supported in the PocoCapsule/C++ IoC and DSM Framework and is straightforward to be applied to most other IoC containers. The PocoCapsule also supports the so-called higher order transformations (HOTs). Namely, this model transformation scenario of user-defined high level DSM is applicable not only to application configurations but also to the transformation stylesheets themselves. Therefore, one can design his/her own domain specific transformation (DST) languages and use them, instead of the XSLT, to design application DSM transformations.

With this model transformation DSM scenario, an IoC framework can be used as a framework to build other user-defined or committee-design component frameworks. Several such frameworks are presented out-of-the-box in PocoCapsule and with numerous examples. For instance, a SCA assembly model can be built as a DSM in merely 500 lines of code (XSL and C++) instead of several thousands lines of code and months of effort.

As argued in my article, with this DSM scenario in IoC frameworks, disadvantages of XML configurations of core IoC schemas can largely be avoided, while advantages of their declarativeness, self-documenting, schema validations, and easy manipulation start to become significant.