${taskforce.name} Avatar
  1. OMG Task Force

Qos for CCM FTF2 — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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

Issues Descriptions

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