[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.
