[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.
9 comments:
Good observations....
I have been hearing a lot against SCA. I really think its a good start with fuzzy edges. i.e. an attempt to standardize without all the variables.
IoC is certainly an effective way to manage the component interconnect problem using protocol adapters etc....
Strangely enough about 10 years ago as part of a larger team we did an RPC implementation in JNI using shared memory between Java components and C/C++ components.
Basically integrating C Queues with Java Queues across Edge components.
A lot of what is being standardized looks like the culmination of many philosophies from proprietary standards.
Good observations....
I have been hearing a lot against SCA. I really think its a good start with fuzzy edges. i.e. an attempt to standardize without all the variables.
IoC is certainly an effective way to manage the component interconnect problem using protocol adapters etc....
Strangely enough about 10 years ago as part of a larger team we did an RPC implementation in JNI using shared memory between Java components and C/C++ components.
Basically integrating C Queues with Java Queues across Edge components.
A lot of what is being standardized looks like the culmination of many philosophies from proprietary standards.
thanks for your input.
"The SCA C++ mapping is dangerously type unsafe"
The contract mapping is an implicit enforcement of the type binding. so this is not a valid point.
Thanks for your input. Obviously, you don't do C++ programming and don't understand the point made in my article. Regardless what contract was made, the user business logic (component implementation) has to call getService() explicitly (as far as SCA 0.95) and cast the returned opaque pointer to assumed type. SCA provides no type checking in this cast. Also, regardless whether the type contract is explicit or implicit, it does help to remove the ugly container dependency (on API and thread model).
Anyway, SCA folks made a wrong decision not to use dependency injection but the context (directory) lookup ...
been a C++ developer for 13 years mate... don't make assumptions just like you have with your so called "flaws". by the way don't reference it in Wikipedia with your blog.
again your assumption that its unsafe is bull.
Then, elaborate your point please. Specifically, how an application could ensure the type safety on type casting a returned opaque pointer of getService(). Thanks!
By the way, I have been a C++'er for 17 years :)))
To the annonymous:
Other than the type unsafe issue (and you believed it was type safe), you are welcomed to elaborate why other listed flaws (such as that SCA business logic implementations have to be tightly coupled to container API model, container runtime, and container request dispatch thread model, etc.) are wrong assumptions (actually, they are not assumptions, but are facts elaborated sufficiently detailed in my article). Simply saying you had 13 years C++ experience does not prove anything.
Post a Comment