ISSUES 78-81: J. Durand PR Comments

[Bryan Aupperle <aupperle@us.ibm.com>]

I propose we use the following text
as the response to J. Durand's Public Review comments:

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 concrete 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

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com