sca-c-cpp-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ISSUES 78-81: J. Durand PR Comments
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: sca-c-cpp-comment@lists.oasis-open.org
- Date: Mon, 13 Jul 2009 08:30:23 -0400
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 uptodate: 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]