Issue 11702: Configuration of the underlying middleware (qos4ccm-rtf) Source: THALES (Mr. Olivier Hachet, olivier.hachet2@fr.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 Discussion: End of Annotations:===== m: olivier.hachet2@fr.thalesgroup.com To: qos4ccm-rtf@omg.org Cc: issues@omg.org Subject: QoS4CCM issue Date: Fri, 30 Nov 2007 09:26:20 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id lAU8SFQC017539 Here is a new issue for QoS for CCM specification: 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,...) ---------------------------------------------------------------------------- -- Olivier HACHET THALES Communications DLJ/FR/OPS-F/SAT/SC2 1-5, ave. Carnot / Bat.E - 91883 MASSY Cedex Tel : +33 1 69 75 32 39 Fax : +33 1 69 75 31 79