[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.
Tuesday, November 13, 2007
SCA considered harmful!
[Additional discussions: here and here]
[Full scale examples (bigbank, calculator etc.): here]
Advocates of the service-component-architecture (SCA) always like to emphasize its strength of multi language support whenever being compared to other competing java-centric alternatives (such as JBI). Therefore, serious issues of SCA C++ mapping naturally raise the concerns on the soundness of the entire SCA, unless one was willing to admit that SCA was also a Java-only marketecture that came with some poorly designed non-java language mappings pretty much as bells and whistles.
As I summarized in this and other articles, there are numerous fatel problems in the SCA C++ mapping designed by the committee. For instance:
1. The SCA C++ mapping is dangerously type unsafe: The SCA assembly model heavily relies on the getService() method of component contexts. However, this method returns service objects as opaque pointers (void*). Business logic implementations suppose to typecast these opaque pointers back to their interface class types declared in .componentType side files. This kludge is equivalent to a C-style cast or a C++ reinterpret_cast without using any type validation system. Generally speaking, this is considered to be a dangerous code smell by C/C++ professionals. Firstly, such a type cast will not work correctly in case of multiple inheritance. Secondly, it is very error-prone in case of component class type changes. The mismatch between the casted types in application code and the actual types declared in the .componentType side files is neither reportable at compile time nor detectable at runtime.
2. Tight coupling to container programming model: The dependency lookup design of SCA tightly couples implementations to the underlying container. It largely prevents SCA components to be used in foreign or legacy runtime environments and vice versa.
3. Tight coupling to container thread model: on calling ComponentContext::getCurrent() within a component implementation, SCA assumes the context of the calling component is on the thread local storage. This assumption tightly ties the component wiring mechanism with the thread model of the underlying request-dispatch engine, significantly increases the cost of SCA container implementations on existing WebServices containers (or SOAP stacks), prohibits many useful application designes, and makes testing and debuging of SCA components more difficult.
With these flaws and many others listed in the table here, SCA (especially its C++ model) would only make simple things hard, and make complex things impossible.
I am not suggesting we should throw the baby out with the bath water. In a violent agreement, some alternative solutions are suggested in my article . These solutions are based on the inversion-of-control (IoC) and domain-specific-modeling (DSM). One of the solutions (here) even supports the exact SCA assembly model (SCDL). However, it replaces the SCA proprietary programming model with the so-called Plain-Old C++ Objects (POCOs). This design largely avoids those contrived vendor-lock-in kludges designed by the SCA committee and significantly simplifies both the container implementation and applications built on top of it. See a list of examples (including a full scale bigbank example, see the following diagram) for WebServices and SCA based on this design.
[Full scale examples (bigbank, calculator etc.): here]
Advocates of the service-component-architecture (SCA) always like to emphasize its strength of multi language support whenever being compared to other competing java-centric alternatives (such as JBI). Therefore, serious issues of SCA C++ mapping naturally raise the concerns on the soundness of the entire SCA, unless one was willing to admit that SCA was also a Java-only marketecture that came with some poorly designed non-java language mappings pretty much as bells and whistles.
As I summarized in this and other articles, there are numerous fatel problems in the SCA C++ mapping designed by the committee. For instance:
1. The SCA C++ mapping is dangerously type unsafe: The SCA assembly model heavily relies on the getService() method of component contexts. However, this method returns service objects as opaque pointers (void*). Business logic implementations suppose to typecast these opaque pointers back to their interface class types declared in .componentType side files. This kludge is equivalent to a C-style cast or a C++ reinterpret_cast without using any type validation system. Generally speaking, this is considered to be a dangerous code smell by C/C++ professionals. Firstly, such a type cast will not work correctly in case of multiple inheritance. Secondly, it is very error-prone in case of component class type changes. The mismatch between the casted types in application code and the actual types declared in the .componentType side files is neither reportable at compile time nor detectable at runtime.
2. Tight coupling to container programming model: The dependency lookup design of SCA tightly couples implementations to the underlying container. It largely prevents SCA components to be used in foreign or legacy runtime environments and vice versa.
3. Tight coupling to container thread model: on calling ComponentContext::getCurrent() within a component implementation, SCA assumes the context of the calling component is on the thread local storage. This assumption tightly ties the component wiring mechanism with the thread model of the underlying request-dispatch engine, significantly increases the cost of SCA container implementations on existing WebServices containers (or SOAP stacks), prohibits many useful application designes, and makes testing and debuging of SCA components more difficult.
With these flaws and many others listed in the table here, SCA (especially its C++ model) would only make simple things hard, and make complex things impossible.
I am not suggesting we should throw the baby out with the bath water. In a violent agreement, some alternative solutions are suggested in my article . These solutions are based on the inversion-of-control (IoC) and domain-specific-modeling (DSM). One of the solutions (here) even supports the exact SCA assembly model (SCDL). However, it replaces the SCA proprietary programming model with the so-called Plain-Old C++ Objects (POCOs). This design largely avoids those contrived vendor-lock-in kludges designed by the SCA committee and significantly simplifies both the container implementation and applications built on top of it. See a list of examples (including a full scale bigbank example, see the following diagram) for WebServices and SCA based on this design.
Subscribe to:
Posts (Atom)
