Issues for QoS for CCM Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11697: IDL inconsistency in section 8.3.4
Issue 11698: Bad section numbers
Issue 11699: Section 8.5
Issue 11700: Section 8.5.5
Issue 11701: section 8.6
Issue 11702: Configuration of the underlying middleware
Issue 11703: Interceptor specific registration
Issue 12429: Service configuration
Issue 12430: Dynamic configuration of components

Issue 11697: IDL inconsistency in section 8.3.4 (qos4ccm-rtf)

IDL inconsistency for ContainerInterceptor interface:
In section 8.3.4, the IDL for CustomSlotItem (identifier is a string) is not
consistent with the one of the AnnexeA.2 section (identifier is an
OctetSeq).

Bad section number:
The 8.6.4.6 section shall be 8.6.5 section and 8.6.4.7 to 8.6.4.11 shall be
8.6.5.1 to 8.6.5.5
The 8.7.2.3 section shall be 8.7.3 section and 8.7.2.4 to 8.7.2.5 shall be
8.7.3.1 and 8.7.3.2

Section 8.5 "A basic Container Interceptor is designed to ..." shall be
replaced by "An extended Container Interceptor..."

Section 8.5.5 : write "To write an extended client-side..." shall be
replaced by "To write an extended server-side..."

section 8.6 "ContainerServantStubRequestInfo" shall be
"ContainerServantRequestInfo

Configuration of the underlying middleware:     
The « three different realization mecanisms » mentionned in section 1.1 are
not all managed in the specification. Especially the second topic « The
configuration of the underlying middleware, for instance the use of certain
policies of the portable object adapter, or object references, typically in
order for QoS properties to be propagated in a suitable way ».
Interceptor mechanism allows injection of non-functional properties at
interception points, but it is not sufficient to correlate non-functional
properties with component feature out of the calling process. The necessity
to configure the underlying middleware, for instance the use of certain
policies of the portable object adapter, or object references, may be
designed with new interfaces as well as interceptors. 
We propose to introduce a means to configure on activation interception
points to configure POA or RT-POA policies on the activation of a facet.
This shall also allow to have "on connection interception" to set easily the
transport protocol policies (SHMIOP, UIOP,...)

Interceptor specific registration: 
The section 8.7 mentions in a note that « Possible specific registration
operation (e.g., register only for a specific facet) shall be investigated
in FTF. In constraint environments, the need can be to register interceptors
at operation level.
In section 8.3.4 there is no means for interceptor registration on specific
operation of facet. We propose to introduce the ability to specify a port
name and an operation name in order to access easily to these data at
implementation level. No registration interface modifications are needed
here.
As said in section 8.3.4.1 name attribute can be also used to order
interceptors stored into a list. We suggest adding a priority attribute that
should supply such need.

Service configuration :
The QoS4CCM standard doesn't speak about access of QoS Enabler at container
level. The 'install_service_reference' operation definition allos to
register service reference at container level but doesn't allow the
configuration of the services in a standard way. This would be useful to
have a configuration interface and to invoke it at service installation.


We propose to define a standard QoS Usage's interface to make service
configuration and to improve 'install_service_reference' operation
definition.

Dynamic configuration of components :
In the Scope section of QoS4CCM specification, the following is mentionned: 
"Dynamic configuration and re-configuration is also an essential point of
distributed systems, because in order to adapt an application to a specific
execution environment, one has to be aware that the QoS of the execution
environment evolves during execution. There is a strong need to be able to
make on-the-fly adaptation. That is why it is very important to provide an
architecture, mechanisms, and monitoring concepts that allow dynamic
adaptation of a running application, explicitly by an administrator, but
also automatically. The specification addresses this problem domain in the
context of the CORBA Component Model (CCM) [CCM]."


For example reading/writing component's attributes or installing or
uninstalling non-functional properties is necessary. This issue propose to
address this topic which is not concretly resolved in the current
specification. 


To achieve this goal, a small evolution is needed.  The existing CCM
specification allows some application specific means like home user defined
operations or 'configurator' setting but such mechanisms don't work without
respectively using home finder or dynamic invocations. The necessity to
develop applications that can dynamically reconfigure components and get
knowledge of component configuration in a generic way, bring us to consider
a new configuration mechanism at runtime to facilitate dynamic adaptation of
running application.
We propose to add configuration ability with access of special
'configurator' implementation using component's home interface. We also
propose to improve StandardConfigurator to get component configuration.This
will allow to configure easily non-functional properties at run-time.