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 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 9736: Derivation of Registration Interfaces (qos4ccm-ftf)
Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Tom Ritter, ritter@fokus.fraunhofer.de tom@users.berlios.de)
Nature: Revision
Severity: Minor
Summary:
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
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