Issues for QoS for CCM Revision Task Force
To comment on any of these issues, send email to qos4ccm-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
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 14920: Casing issue, CORBA::OCtetSeq
Issue 15670: QoSPropertyRegistration used but not defined
Issue 17442: simplified api (un)intall_service_reference
Issue 11697: IDL inconsistency in section 8.3.4 (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
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).
Resolution: Regarding the resolution of issue No 9740, update the IDL of 'struct CustomSlotItem' in section Annex A.2 with the one in section 8.3.4.
A new repository Id shall be added for CustomSlotItem, CustomSlotItemSeq and COPIServiceContext
Revised Text: · The definition of custom slot item is changed (and includes new repository IDs) in section Annex A.2 as follow:
struct CustomSlotItem
{
string identifier;
any content;
};
typeid CustomSlotItem
"IDL:omg.org/Components/ContainerPortableInterceptor/CustomSlotItem:1.1";
typedef sequence<CustomSlotItem> CustomSlotItemSeq;
typeid CustomSlotItemSeq
"IDL:omg.org/Components/ContainerPortableInterceptor/CustomSlotItemSeq:1.1";
struct COPIServiceContext
{
CORBA::OctetSeq origin_id;
CORBA::OCtetSeq target_id;
CustomSlotItemSeq slot_info;
};
typeid COPIServiceContext
"IDL:omg.org/Components/ContainerPortableInterceptor/COPIServiceContext:1.1";
typedef sequence<CustomSlotItem> CustomSlotItemSeq;
· The service ID for COPI is modified
module IOP {
const ServiceId COPI = 23;
};
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11698: Bad section numbers (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: Replace the section numbers with the good numbers
Revised Text: Replace following section numbers 8.6.4.6, 8.6.4.7, 8.6.4.8, 8.6.4.9, 8.6.4.10, 8.6.4.11, 8.7.2.3, 8.7.2.4, 8.7.2.5 respectively by 8.6.5, 8.6.5.1, 8.6.5.2, 8.6.5.3, 8.6.5.4, 8.6.5.5, 8.7.3, 8.7.3.1, 8.7.3.2
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11699: Section 8.5 (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.5 "A basic Container Interceptor is designed to ..." shall be
replaced by "An extended Container Interceptor..."
Resolution: Replace the old text with the new one.
Revised Text: The following paragraph:
"A basic Container Interceptor is designed to intercept the flow of a request/reply sequence through the Container at specific points so that container services and other container extensions such as QoS Enablers can query the request information and manipulate the invocation parameters."
Is replaced by this one:
"An extended Container Interceptor is designed to intercept the flow of a request/reply sequence through the Container at specific points so that container services and other container extensions such as QoS Enablers can query the request information and manipulate the invocation parameters."
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11700: Section 8.5.5 (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.5.5 : write "To write an extended client-side..." shall be
replaced by "To write an extended server-side..."
Resolution: Replace the old text with the new one
Revised Text: The following paragraph:
"To write an extended client-side Container Portable Interceptor this interface needs to be implemented."
Is replaced by this one:
"To write an extended server-side Container Portable Interceptor this interface needs to be implemented."
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11701: section 8.6 (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: section 8.6 "ContainerServantStubRequestInfo" shall be
"ContainerServantRequestInfo
Resolution: Replace the old text with the new one
Revised Text: The following paragraph:
"Each interception point is given an object through which the Interceptor can access request information. Client-side and Server-side interception points as well as basic interception points and extended interception points are concerned with different information. ContainerClientRequestInfo is passed to basic client-side interception points and ContainerServerRequestInfo is passed to basic server-side interception points. ContainerStubRequestIfno is passed to extended client-side interception points and ContainerServantStubRequestInfo is passed to extended server-side interception points. There is information that is common to all information objects, so they all inherit from a common interface: ContainerRequestInfo."
Is replaced by this one:
"Each interception point is given an object through which the Interceptor can access request information. Client-side and Server-side interception points as well as basic interception points and extended interception points are concerned with different information. ContainerClientRequestInfo is passed to basic client-side interception points and ContainerServerRequestInfo is passed to basic server-side interception points. ContainerStubRequestIfno is passed to extended client-side interception points and ContainerServantRequestInfo is passed to extended server-side interception points. There is information that is common to all information objects, so they all inherit from a common interface: ContainerRequestInfo."
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11702: Configuration of the underlying middleware (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: 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,...)
Resolution: 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,...).
We propose to add a means to configure the underlying middleware corresponding to the second mechanisms mentioned in section 1.1. This one is not managed by the specification.
Below a section to be added after Negotiation is presented. The mechanism is designed with new interfaces as well as interceptor mechanism.
Revised Text: · The following sections are added in section 8:
8.13 Binding QoSConstraint with component feature
Even if the interceptor mechanism allows for an injection of non-functional properties at interception points, the level of control by manipulating the calling thread is limited. It is for instance possible to block this thread, but not to ensure that a pool of threads with a certain priority should handle a request - as it is possible in RT-CORBA. 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. This section introduces two interfaces based on interception principle:
1 - The QoSPropertyInstance is designed to provide a means for non-functional properties definition. A QoSPropertyInstance has to be referenced inside the run-time environment in association with a component feature (ComponentFeature). The container manages the activation and deactivation of the QoSPropertyInstance. This interface can be necessary to configure particular QoS constraints not related to interception mechanisms.
The considered QoS properties and the way they are managed in a CCM framework is vendor specific.
Examples of integration points:
· at connection time the connect operation of the container can use this interface to configure communication protocol,
· Another key concern is the creation of a component instance, and the way its facets take shape. The CORBA and real-time CORBA Portable object adapter propose different strategies to activate an object. This can be considered at container level to configure POA policies at this stage,
· …
2 - The QoSPropertyInstanceRegistration, as well as container interceptor registration, shall be used to register and unregister QoSPropertyInstance.
8.13.1 QoSPropertyInstance
This interface allows to associate a QoS constraints (via QoSInstances) to component features (ComponentFeatures, meaning facets, receptacles, …)
The following IDL fragment defines the QoSPropertyInstance interface.
module QoS {
local interface QoSPropertyInstance {
attribute readonly string functionality;
attribute QoSInstances qos_instances;
void activate( in string operation, in ParameterList parameters)
raises (CCMException );
void deactivate( in string action,
in ParameterList parameters);
};
};
8.13.1.1 functionality
This attribute provides the name of the functionality that the QoS property corresponds to. It corresponds to the component feature name (ex: facet or receptacle name).
8.13.1.2 qos_instances
This attribute is a sequence of QoSInstance (QoSInstances). This set of tag/value pairs describes the property. QoS instances can be priority with RTCORBA::Priority value or transport protocol policy with standard or vendor specific protocol policy value.
8.13.1.3 activate
This operation is called by the container (ex: at connection or facet activation stage) to activate a property on a correlated component feature (see section 7.2.2 - Binding).
The action parameter allows to identify the kind of activation to process (on activation, on connection, …)
The parameters parameter allows to process the activate operation on object references (ex: CORBA::Object representing a connection). This is a ParameterList because, depending on the kind of configuration, these objects can be IN, INOUT or OUT.
If activation can't be realized the operation shall return a CCMException with the reason QOS_ERROR.
8.13.1.4 deactivate
This operation is called by container to disable a property associated to a component feature.
8.13.2 QoSPropertyInstanceRegistration
The following IDL fragment defines the QoSPropertyInstanceRegistration interface.
module QoS {
local interface QoSPropertyInstanceRegistration {
Cookie register_qos_property( in QoSPropertyInstance instance );
void unregister_qos_property( in Cookie ck )
raises(InvalidRegistration );
};
};
8.13.2.1 register_qos_property
This operation may be called by a service to register a QoSPropertyInstance interface to the run-time environment and to bind the property to a functionality of the component. If the operation is successful, it returns a Cookie to identify the biding. This Cookie value can be used to identify the registration and needs to be used for subsequent operation to unregister the property.
8.13.2.2 unregister_qos_property
This operation unregisters a previously registered property. This operation expects a Cookie value to identify the QoS property that was previously registered. If the provided Cookie value does not correspond to a previously registered property, the InvalidRegistration exception is raised
· The following section have to be modified:
8.9.2 ExtensionContext
// ---
local interface ExtensionContext : CCMContext {
…
QoSPropertyRegistration get_qos_property_registration() raises (CCMException);
…
} ;
8.9.2.7 get_qos_property_registration
This operation returns a QoSPropertyRegistration interface, which can be used subsequently to register a QoSPropertyInstance. If a registration interface is not available, an exception of type CCMException with a reason REGISTRATION_ERROR shall be raised.
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 11703: Interceptor specific registration (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: 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. An addition of a priority attribute that should supply such need.
Improvement of existing ContainerInterceptor interface in order to allow interceptor registration at facet and operation level.
Revised Text: · The note below shall be removed in section 8.7:
8.7 Registering Container Interceptors
Note - Current definition of registration interfaces allow only for unspecific registration. Possible specific registration operations
(e.g., register only for a specific facet) shall be investigated in FTF.
· The name definition should be updated in section 8.3.4.1. The name attribute is no more used to order list of interceptor, because it is done by the priority attribute.
8.3.4.1 name
Each container interceptor may have a name that may be used for administrative purposes; in particular, to order the list of registered interceptors. It is possibly to use anonymous interceptors. In this case the name is an empty string. There can be more than one anonymous interceptor.
· In section 8.3.4, modification of existing ContainerInterceptor interface in order to allow interceptor registration at facet and operation level. Add of a priority attribute to order the list of interceptors.
8.3.4 Container Interceptor Interface
module Components {
module ContainerPortableInterceptor {
struct CustomSlotItem
{
string identifier;
any content;
};
typedef sequence<CustomSlotItem> CustomSlotItemSeq;
struct IntegrationPoint
{
string port;
string operation;
};
local interface ContainerInterceptor
{
readonly attribute string name;
attribute unsigned short priority;
attribute IntegrationPoint registration_info;
void destroy ();
void set_slot_id(in PortableInterceptor::SlotId slot_id);
};
};
};
8.3.4.2 priority
Each container interceptor may have a priority that may be used to order the list of registered interceptors. Priority value may help implementor to control execution order of interceptors and some existing dependencies between interceptors. The determination and management of priority values is free.
8.3.4.3 registration_info
This attribute is a structure containing a port and an operation string that informs about the specific intercepted call. If null strings are set, interceptor is registered for all interception points.
Actions taken:
November 30, 2007: received issue
October 27, 2008: closed issue
Issue 12429: Service configuration (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: We propose to define a standard QoS Usage's interface to make service configuration and to improve 'install_service_reference' operation definition. A new interface QoSUsage to the following interface to make service configuration in standard way. The definition is inserted at end of section 8.11.2
Revised Text: · The section 8.11.2 is updated by the addition of the QoSUsage interface
8.11.2 QoS Usage Interface
...
In some very constrained environments, it can be more efficient to design services as interfaces, not necessarily part of a component. Since the service is co-localized with components, it can be designed as an interface accessible at container level. The following interface is a standard base interface for services and is designed to allow service configuration when installing reference using the install_service_reference operation.
A service is identified with the characteristic it manages which is part of the QoSConstraint definition. A QoSConstraint shall also contain a sequence of QoSInstances. These QoSInstances are the concrete resource requirements.
module Components
{
module QoS
{
local interface QoSUsage : public ExtensionComponent
{
attribute readonly string characteristic;
Cookie install_qos_property( in QoSInstances instances )
raises(CCMException);
void uninstall_qos_property( in Cookie ck ) ;
} ;
} ;
} ;
8.11.2.1 characteristic :
This attribute identifies a QoSCharacteristic corresponding to the service_id parameter of the install_service_reference operation.
8.11.2.2 install_qos_property :
This operation is called by the container, to set the service configuration defined in QoSInstances that are description of the constraints. The QoSInstances can be expressed in a QoSPropertyInstance and bind to a component feature if needed. Whenever the service is not able to process a QoSValue it shall return a CCMException with the reason QOS_ERROR. This means that the QoS property can't be installed or managed by service.
8.11.2.3 uninstall_qos_property :
This operation is called by the container to unset some QoS properties managed by the service and uninstall related QoSPropertyInstance if exist.
Actions taken:
May 7, 2008: received issue
October 27, 2008: closed issue
Discussion:
Issue 12430: Dynamic configuration of components (qos4ccm-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: If the component is created dynamically, or configured at runtime, the QoS value needs to be configured either via application specific means or by using configurator. Sections are added to support dynamic adaptation of a running application. This implies the modification of the CCM interface StandardConfigurator to be able to retrieve configuration values. HomeConfiguration interface is also modified to be able to retrieve a configurator.
Revised Text: · The section 6.1 is modified to support dynamic configuration elements:
6.1 Changes to Adopted OMG Specifications
...
· Extension of the context interface to retrieve reference to container services.
· Extension of the StandardConfigurator interface to get component configuration.
· Extension of the HomeConfiguration interface to retrieve reference to Configurator.
...
· The section 7.1 is modified to support dynamic configuration elements:
7.1 Scope of QoS Properties
...
If a QoS property is bound to a component or connection instance, its actual scope depends on their lifetime. If a component instance is already declared during the assembly and never deleted until application shutdown, its lifetime - and that of the QoS property as well - is identical with that of the application. In this case, the value of the QoS property may be configured during the deployment and configuration phase. However, if the component is created dynamically or configured at runtime, the QoS value needs to be configured either via application specific means or by using configurator. The latter mechanism is modified by this specification, see section 8.11, "Dynamic adaptation of a running application" for details.
...
· The following sections are added to the specification:
8.12 Dynamic adaptation of a running application
In a most general way, the QoSEnabler life cycle may need to be managed over the component life cycle. This means that creation, deletion and configuration of QoSEnabler have to be done independently of corresponding component means. Container vendor are free to exploit CCM capacities to add specific operations for QoSEnabler configuration, however configuration at run-time may become constraining :
· client may have to manage QoSEnabler owned by components with heterogeneous configuration interface.
· client implementation may be generic code and not be aware about specific component definition.
· client in an embedded environment may not be allowed to use CORBA dynamic capacities.
To help container vendors to implement standard and homogeneous dynamic configuration mechanisms the StandardConfigurator and the HomeConfiguration definition has been extended.
8.12.1 Modification of StandardConfigurator interface
module Components {
interface StandardConfigurator : Configurator
{
void set_configuration (in ConfigValues descr);
/* QoS4CCM */
ConfigValues get_configuration( in CCMObject comp )
raises (WrongComponentType);
};
};
8.12.1.1 get_configuration
This operation returns a sequence of ConfigValue instances containing the configuration of the target component. If the target component is not of the type expected by the configurator, the get_configuration operation shall raise the WrongComponentType exception.
8.12.2 Modification of HomeConfiguration interface
module Components {
interface HomeConfiguration : CCMHome {
void set_configurator ( in Configurator cfg);
/* QoS4CCM */
Configurator get_configurator();
void set_configuration_values ( in ConfigValues config);
void complete_component_configuration (in boolean b);
void disable_home_configuration();
};
};
8.12.2.1 get_configurator
This operation returns a Configurator reference to the standard configurator that manages this home. This one may be able to process particular configuration values and to call specific user interface of component and component's home.
Actions taken:
May 7, 2008: received issue
October 27, 2008: closed issue
Issue 14920: Casing issue, CORBA::OCtetSeq (qos4ccm-rtf)
Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary: In the document there are several casing problems, search for CORBA::OCtetSeq, it should be CORBA::OctetSeq
Resolution:
Revised Text:
Actions taken:
January 4, 2010: received issue
Issue 15670: QoSPropertyRegistration used but not defined (qos4ccm-rtf)
Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Significant
Summary: The specification adds QoSPropertyRegistration as part of the context definition but this interface isn't defined at all in the specification
Resolution:
Revised Text:
Actions taken:
October 1, 2010: received issue
Issue 17442: simplified api (un)intall_service_reference (qos4ccm-rtf)
Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary: The spec defines the following methods
Cookie
install_service_reference(
in string service_id, in Object objref)
raises (CCMException);
Object
uninstall_service_reference(in Cookie ck)
raises (CCMException);
it is described that the service reference id is unique, so why do we need a cookie at all. It will simplify things for users if we do:
void
install_service_reference(
in string service_id, in Object objref)
raises (CCMException);
Object
uninstall_service_reference(in string service_id)
raises (CCMException);
Resolution:
Revised Text:
Actions taken:
June 18, 2012: received issue