Issues for Mailing list of the QoS for CCM Finalization Task Force

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

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

Issue 9735: Section: 8.6 Derivation of RequestInfo
Issue 9736: Derivation of Registration Interfaces
Issue 9737: Mandatory in Binding class
Issue 9738: Disign Principles
Issue 9739: Is Principle 3 talking about ORB-level location forwarding
Issue 9740: set_slot_id
Issue 9741: Basic Container Interceptors
Issue 9742: Stub Intercept Points
Issue 9743: Stub_receive_other Paragraph 2
Issue 9744: target_id and origin_id
Issue 9745: Registering Container Interceptors
Issue 9746: Negotiation
Issue 9747: require_qos from server side
Issue 9748: Examples
Issue 9749: Section: 8.5.1
Issue 10564: Section: 8.7.2
Issue 10565: Section: 8.7.2 StubContainerInterceptionRegistration has several errors
Issue 10566: Section: 8.7.3
Issue 11319: QoS for CCM ComponentInstallation
Issue 11322: operations in the interface StubContainerInterceptor
Issue 16253: ExtensionComponent and ccm_remove

Issue 9735: Section: 8.6 Derivation of RequestInfo (qos4ccm-ftf)

Derivation of RequestInfo Why isn't ContainerClientRequestInfo simply derived (with no extension) from PortableInterceptor::ClientRequestInfo? This would save a step (calling request_info()) in user code. Why isn't ContainerServerRequestInfo simply derived (with no extension) from PortableInterceptor::ServerRequestInfo? This would save a step (calling request_info()) in user code.

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

A container vendor may decide to either provide basic or to provide only
extended interceptors or to provide both in a container implementation with a
specific product configuration. For allowing a vendor to be flexible with respect to
this, the registration interfaces should be independent of each other. An
inheritance relationship would introduce the concepts of basic interceptors also to
extended interceptors.
Disposition: Closed, no change

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

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? 

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.

This principle refers directly to the principle 3 of the Portable Interceptor
specification, where permanent location forwarding is not defined. Permanent
location forwarding is only defined by CORBA for
PortableServer::ForwardRequest when using POA. Permanent location
forwarding is not defined for PortableInterceptor::ForwardRequest. The
specification of PortableInterceptor::ForwardRequest explicitly states that "a
retry" should be done by the ORB. So PI is doing location forwarding only once
and so should do COPI.
Disposition: Closed, no change

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?

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

The description of the Portable Interceptors in the CORBA specification and the
description of COPI differ in some but important sections and words. To
reference the PI description and to explain the difference only would make this
specification rather unreadable. For this reason it is better to keep the text in the
specification.
Disposition: Closed, no change

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

Permanent location forwarding is only defined by CORBA for
PortableServer::ForwardRequest when using POA. Permanent location
forwarding is not defined for PortableInterceptor::ForwardRequest. The
specification of PortableInterceptor::ForwardRequest explicitly states that "a
retry" should be done by the ORB. So PI is doing location forwarding only once
and so should do COPI. So no further specification is needed.
Disposition: Closed, no change

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.

Using the same thread is assumed, since container has still the control on this
call, it will ensure that the same thread is used for the retry. If not using the same
thread an alternative implementation strategy is that the container makes sure
that the new PortableInterceptor::Current contains the same content as the one
of the preceding call.
Disposition: Closed, no change

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.

Why use separate registration interfaces for each interceptor type?

A separate registration interface for basic and extended interceptors is needed to
ensure independence of these two levels of interceptors. A container vendor
could offer either basic or extended or both interceptors levels. A separation of
client and server part is done due to the fact that most likely only a server or a
client side interceptor is registered for a specific purpose at a given time. For this
reason only a narrow interface needs to be used and activated for registering an
interceptor.
Disposition: Closed, no change

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?

The basic intention of integrating negotiation into the connection set up is to
make this transparent for the business logic. So business logic, which is
component executor, is not involved or at least should not be involved in
negotiation. Furthermore, the exact implementation strategy is left open to not
restrict the implementation of the specification. Most likely negotiation is
implemented by the container. The connect call which is used to connect two
component instance is intercepted by the container. This interceptor calls the
provide_facet with the identifier (_ccm_qos_negotiation) to get the reference of
the negotiation interface. The negotiation interface is also implemented by the
container. If QoSEnablers are used for generic management of QoS aspects
they will use extended COPI to influence the outcome of the negotiation by
examining the client requirements and allocating resources or by raising
exception, which leads to unsuccessful completion of require_qos call. Again, the
external interfaces and the external negotiation flow are defined by the
specification the exact mechanisms to implement negotiation are not prescribed
by this specification since, for example, negotiation and QoS management could
also be done without QoSEnablers but with an otherwise extended container.
Disposition: Closed, no change

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

It is not possible. Only client side is allowed to state QoS requirements. This is an
architectural choice to simplify the implementation of the QoS framework and the
negotiation mechanism in particular.
Disposition: Closed, no change

More complete examples that show the actual QoSConstraint structures, the deployment of QoSEnablers, the negotiation, and the use of the COPIs would be really helpful in understanding the spec.

Although a prototype implementation of the specification exists. It is not 100%
complete and in particular does not directly reflect the changes resulting from this
FTF report. A completely conformant implementation and description of the listed
examples is currently not available. An updated implementation of the
specification can be expected to be available after publication of the FTF report.
For this reason a complete example can be described afterwards. Furthermore,
the examples are part of the non-normative annex. For these reasons this Issue
is deferred to RTF.

Figure seems not to correspond to the description of extended Interceptors 

Argument of register_server_interceptor must be a ServerContainerInterceptor

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

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

In section 8.11.4 (deployment), the ComponentInstallation interface is
referenced. It no more part of the current CCM specification and shall be
replaced by elements of D&C spec. NodeManager for the physical
transportation and NodeApplicationManager for the loading of libraries

The operations in the interface StubContainerInterceptor have an out boolean parameter called "con". It corresponds (I think) to the parameter "proceed_call" described in the text and should therefore be renamed accordingly

Can anyone explain why the ExtensionComponent only delivers the
ccm_remove method and not all the other methods which the
SessionComponent has?