Quality of Service for CCM Avatar
  1. OMG Specification

Quality of Service for CCM — Closed Issues

  • Acronym: QOSCCM
  • Issues Count: 25
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
QOSCCM11-5 Dynamic configuration of components QOSCCM 1.0 QOSCCM 1.1 Resolved closed
QOSCCM11-4 Service configuration QOSCCM 1.0 QOSCCM 1.1 Resolved closed
QOSCCM_-19 Configuration of the underlying middleware QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-18 section 8.6 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-20 Interceptor specific registration QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-17 Section 8.5.5 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-16 Section 8.5 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-15 Bad section numbers QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-14 IDL inconsistency in section 8.3.4 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-10 Registering Container Interceptors QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-12 require_qos from server side QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-11 Negotiation QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-13 Section: 8.5.1 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-9 target_id and origin_id QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-7 Stub Intercept Points QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-6 Basic Container Interceptors QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-8 Stub_receive_other Paragraph 2 QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-3 Disign Principles QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-2 Mandatory in Binding class QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-5 set_slot_id QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-4 Is Principle 3 talking about ORB-level location forwarding QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM_-1 Derivation of Registration Interfaces QOSCCM 1.0b2 QOSCCM 1.0 Resolved closed
QOSCCM-7 Section: 8.7.2 StubContainerInterceptionRegistration has several errors QOSCCM 1.0b1 QOSCCM 1.0b2 Resolved closed
QOSCCM-6 Section: 8.7.2 QOSCCM 1.0b1 QOSCCM 1.0b2 Resolved closed
QOSCCM-8 Section: 8.7.3 QOSCCM 1.0b1 QOSCCM 1.0b2 Resolved closed

Issues Descriptions

Dynamic configuration of components

  • Key: QOSCCM11-5
  • Legacy Issue Number: 12430
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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.

  • Reported: QOSCCM 1.0 — Wed, 7 May 2008 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Service configuration

  • Key: QOSCCM11-4
  • Legacy Issue Number: 12429
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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.

  • Reported: QOSCCM 1.0 — Wed, 7 May 2008 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Configuration of the underlying middleware

  • Key: QOSCCM_-19
  • Legacy Issue Number: 11702
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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,...)

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

section 8.6

  • Key: QOSCCM_-18
  • Legacy Issue Number: 11701
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    section 8.6 "ContainerServantStubRequestInfo" shall be
    "ContainerServantRequestInfo

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Replace the old text with the new one

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Interceptor specific registration

  • Key: QOSCCM_-20
  • Legacy Issue Number: 11703
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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.

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section 8.5.5

  • Key: QOSCCM_-17
  • Legacy Issue Number: 11700
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Replace the old text with the new one

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section 8.5

  • Key: QOSCCM_-16
  • Legacy Issue Number: 11699
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Replace the old text with the new one.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Bad section numbers

  • Key: QOSCCM_-15
  • Legacy Issue Number: 11698
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Replace the section numbers with the good numbers

  • Updated: Fri, 6 Mar 2015 20:54 GMT

IDL inconsistency in section 8.3.4

  • Key: QOSCCM_-14
  • Legacy Issue Number: 11697
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • 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).

  • Reported: QOSCCM 1.0b2 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Registering Container Interceptors

  • Key: QOSCCM_-10
  • Legacy Issue Number: 9745
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Why use separate registration interfaces for each interceptor type?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

require_qos from server side

  • Key: QOSCCM_-12
  • Legacy Issue Number: 9747
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Is it possible for a server (i.e. facet) to require QoS? How?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Negotiation

  • Key: QOSCCM_-11
  • Legacy Issue Number: 9746
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    Its not really clear here what is done by the business-logic component executor, what is done by the container, and what is done by QoSEnabler components. Who implements the Negotiation facet? Who makes the require_qos calls?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section: 8.5.1

  • Key: QOSCCM_-13
  • Legacy Issue Number: 9749
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Figure seems not to correspond to the description of extended Interceptors

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Figure 8.3 has been updated depicting the extended interception points.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

target_id and origin_id

  • Key: QOSCCM_-9
  • Legacy Issue Number: 9744
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    How does the client get the target_id? How does the server get the origin_id? It would seem that IOR components and service contexts would need to be standardized to portably exchange these.

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    Service Context ID and the content of the service context need to be
    standardized. For this reason a subsection has been added to section 8.3

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Stub Intercept Points

  • Key: QOSCCM_-7
  • Legacy Issue Number: 9742
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Need to specify whether raising ForwardRequest changes the target persistently, or just for the current invocation

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Basic Container Interceptors

  • Key: QOSCCM_-6
  • Legacy Issue Number: 9741
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Could duplication of Portable Interceptor text be avoided? Why not just reference the descriptions of the PI intercept points in CORBA?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Stub_receive_other Paragraph 2

  • Key: QOSCCM_-8
  • Legacy Issue Number: 9743
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Stub_receive_other Paragraph 2, which discusses retries, does not seem to be consistent with the approach of implementing these intercept points by wrapping the ORB-level stub. ORB-level retries would be transparent to the wrapper, and wrapper-level retries would appear to the ORB as independent requests. I don't see how the wrapper could ensure that the PortableInterceptor::Current remains the same, except that the same thread is presumably used.

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Disign Principles

  • Key: QOSCCM_-3
  • Legacy Issue Number: 9738
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    Disign Principles The concepts of Basic vs. Extended Container Interceptors need to be introduced before they are references in the various principals listed here. After reading all of this, I would infer that the Basic COPIs are intended to be called from an ORB-level Portable Interceptor that is part of the container implementation, and that the Extended COPIs are called directly by the container. Is this correct? Could it be stated more explicitly?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    To introduce the concept of Basic and Extended Concept beforehand a text
    section will be added at the end of section 8.3.1.
    In general the implementation of the Container and the used mechanism are
    completely transparent, which means a container vendor could implement the
    specification in various different ways. However, to implement the basic COPIs
    by wrapping the PI and to implement the extended COPIs by calling it directly
    from the container is one possible solution and also a most likely one. However,
    to state this directly in the spec would possibly constrain the implementation of
    the specification too much. For this reason the described solution will be
    mentioned as one possible implementation variant by adding text at the end of
    section 8.3.1.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Mandatory in Binding class

  • Key: QOSCCM_-2
  • Legacy Issue Number: 9737
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    Mandatory in Binding class Its not clear what mandatory means. What does it mean for a Binding to exist but not be bound?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    More detailed text has been added to explain that.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

set_slot_id

  • Key: QOSCCM_-5
  • Legacy Issue Number: 9740
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    This needs clarification. Does each COPI get its own slot_id assigned by the container? Does the COPI control what (if anything) goes in this slot?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    The usage of the slot id needs more detailed specification to be used in an
    interoperable way. The following text will be given in response to this issue:
    COPIs are not able to allocate a slot id since this is done in the ORBInitializer
    which is executed at component server creation, which is before any user code
    (i.e. COPI) is executed. Therefore, a slot id is allocated by the component server
    and is communicated to the COPI by using the set_slot_id method. By using this
    slot_id Container Portable Interceptors can have access to a PICurrent slot to
    exchange thread and call specific information. All COPIs get the same slot id
    since the number of registered COPIs is not known beforehand. A definition of
    the content of the slot where COPIS can read and add information is also added

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Is Principle 3 talking about ORB-level location forwarding

  • Key: QOSCCM_-4
  • Legacy Issue Number: 9739
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Disign Principles Is Principle 3 talking about ORB-level location forwarding? If so, it should be clarified that this redirects not only the current request but also subsequent requests to the new location.

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Derivation of Registration Interfaces

  • Key: QOSCCM_-1
  • Legacy Issue Number: 9736
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    Derivation of Registration Interfaces Why isn't StubContainerInterceptorRegistration derived from ClientContainerInterceprotRegistration? Why isn't ServantContainerInterceptorRegistration derived from ServerContainerInterceprotRegistration?

  • Reported: QOSCCM 1.0b2 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — QOSCCM 1.0
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section: 8.7.2 StubContainerInterceptionRegistration has several errors

  • Key: QOSCCM-7
  • Legacy Issue Number: 10565
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    StubContainerInterceptionRegistration has several errors. In IDL the local interface name is wrong, the register and unregister method names are wrong and have wrong types. In 8.7.2.4 and .5 headers are wrong

  • Reported: QOSCCM 1.0b1 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0b2
  • Disposition Summary:

    IDL problems have been fixed. Wrong names and headers have been fixed.
    Some other minor typos have been fixed.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section: 8.7.2

  • Key: QOSCCM-6
  • Legacy Issue Number: 10564
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Argument of register_server_interceptor must be a ServerContainerInterceptor

  • Reported: QOSCCM 1.0b1 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0b2
  • Disposition Summary:

    IDL Problems has been fixed.

  • Updated: Fri, 6 Mar 2015 20:54 GMT

Section: 8.7.3

  • Key: QOSCCM-8
  • Legacy Issue Number: 10566
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    8.7.3 has several errors, in description, headers, idl, wrong types, interfaces, etc

  • Reported: QOSCCM 1.0b1 — Fri, 5 Jan 2007 05:00 GMT
  • Disposition: Resolved — QOSCCM 1.0b2
  • Disposition Summary:

    Wrong IDL and headers have been fixed.

  • Updated: Fri, 6 Mar 2015 20:54 GMT