|Subject:||RE: [sca-c-cpp-comment] comments from Jacques D.|
|From:||Bryan Aupperle (aupp...@us.ibm.com)|
|Date:||Jul 16, 2009 9:44:57 am|
The SCA C-C++ TC thanks you for review and comments on the SCA Client and Implementation Model for C++ Specification.
Our responses to your comments are below.
- In the PDF, title of section 6.4 seems to not be right (formatting issue?)
- It looks like (in PDF) the table of contents is not up-to-date: section 6.5 is announced as SCAExceptions, but it is actually 6.6.
Response: Thank your pointing out the PDF formatting problems. They will be addressed in future drafts.
- The "promotion" mechanism described in Assembly specification, does not seem to be addressed here. I guess I am a little confused about how the distinction between Composite and Component plays in the C++ implementation model: Do you consider "composite" as just an implementation concept only? (i.e. no dedicated class). I see composite mentioned as a Component implementation "scope", so it seems it does not have a construct or class on its own. If that is the case that should be more clearly stated, as in the Assembly mark-up it appears that a component is always used inside a Composite - and not by itself. So that would also address my question about the "promotion" concept in Assembly that relates the Services of a composite to the Service of a component inside.
Response: The C++ client and implementation specification describes how SCA components can be implemented in C++. This includes definitions of <implementation.cpp/> and <interface.cpp/> as well as the classes available to C++ component implementations. As described in the Assembly specification, components can only be included in an SCA domain when included in a composite. The SCA runtime is aware of the composite instance that a component implementation instance is contained by. However, there is no direct implementation of a composite. A composite instance is a collection of its component implementation instances and as such has no direct representation in C++ (i.e. there is no class corresponding to a composite) and Assembly concepts like promotion and property value assignment are handled by the SCA runtime.
Because the SCA runtime is aware of the composite instance that a component implementation instance is contained by, it is possible to have composite-scoped component instances. Unlike stateless-scoped instances, which exist only as long as a specific operation is being processed, once a composite-scoped instance is created, it exists until the composite instance itself goes out of scope. One way to consider this from a C++ view is to think about when the library containing the class is loaded into memory. For a stateless-scoped instance, the runtime can load a library instance for each operation request. But for a composite-scoped instance, the library instance should be loaded when the composite instance is created, a class may have static data members (consider an in-memory database). The component implementation itself determines if it is stateless or not and thus the appropriate scope, but it has no awareness of any composite(s) that may used it as a component implementation.
We would be happy to answer any further questions.
- It is unclear what the notion of "SCA runtime" corresponds to in C++. Is there a particular framework or container (in C++) to manage components? For example, what entity is raising SCA Exceptions ? (as opposed to business exceptions).
Response: The Assembly specification repeatedly discusses SCA runtime behavior and has conformance clauses for it. An SCA runtime is responsible for loading appropriate artifacts, including component implementation instances. This means that C++ component implementation instances are loaded by and run in the context of the SCA runtime. An SCA runtime that supports C++ component implementations provides the classes defined in the C++ client and implementation specification. These classes could be contained in one or more libraries provided by the runtime implementation, but the runtime must also be able to load component implementation instances when external requests are made of remotable services via identified bindings and invoke the appropriate member functions.
The C++ client and implementation specification does not in and of itself define how the SCA runtime is implemented. The implementation could clearly be in C or C++ but there is no reason that a Java SCA implementation could not be created that provides the required support for C++ component implementations via appropriate JNI logic.
- The ServiceProxy base class is empty... is it really needed?
Response: The ServiceProxy class serves as the return type for several API member functions. It is necessary to have this defined as a user defined class to allow it to be dynamic_cast to specific proxy classes for interfaces. The TC also envisions that this class may be extended in the future in support of functionality like WiredByImpl.
Bryan Aupperle, Ph.D. STSM, WebSphere Enterprise Platform Software Solution Architect OASIS SCA C-C++ TC Chair
Research Triangle Park, NC +1 919-254-7508 (T/L 444-7508) Internet Address: aupp...@us.ibm.com