CORBA35 — GIOP Conformance and Interceptors

GIOP Conformance and Interceptor don't play well together.

GIOP minor version conformance mandates two things.

1. That standard service contexts that are considered optional
can be ignored should the implementation not understand them.

2. That certain service contexts get processed according to the
specification of where they are defined.

This requirement works well for GIOP 1.2 where a lot of them are optional,
since (1) will apply. An implementation can claim 1.2 conformance and not
process any of them.

However, 1.3 and upcoming 1.4 will mandate the processing of them
according to their specification. In many cases, this means that some
default response may be required, which means that a GIOP 1.3, or later
engine must have a "default" response for these service contexts.

In an ORB that uses interceptors and has a generic GIOP messaging engine
there is no way for the engine to "know" when or not to process a
particular service context. It requires strict processing by the GIOP
engine, or it requires "default" interceptors to be installed to maintain
the level of conformance.

However, interceptors have no way of "declaring" which service contexts
they handle, and whether they they are overriding already installed
(default) interceptors for processing those particular service contexts.

For example, an non-transactional ORB that is GIOP 1.2 compliant must
process the Transaction Service Context by raising a
TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
by certain in implementations it ALWAYS is). A default interceptor is
needed in the ORB implementation to do this. However, for an ORB
configuration that wants to process this, there is no way for an
interceptor to "override" default processing.