ClientProtocolPolicy can be set on either client or server. Section 4.8.5 in CORBA 2.4 cautions against defining policies that can be set in both places:
If the Policy can be used with POA creation to tune IOR contents and can also be specified (overridden) in the client, specify how to reconcile the policy's presence from both the client and server. It is strongly recommended to avoid this case! As an exercise in completeness, most POA policies can probably be extended to have some meaning in the client and vice versa, but this does not help make usable systems, it just makes them more complicated without adding really useful features. There are very few cases where a policy is really appropriate to specify in both places, and for these policies the interaction between the two must be described.
While the specification does describe what happens if ClientProtocolPolicy
is set on both client and server, it is not clear that being able to set the
policy on the server-side adds any useful functionality. With ServerProtocolPolicy,
the server already has the ability to specify which protocols and in what
order can be used by clients for invocations. So, ClientProtocolPolicy
should be made a pure client policy, to reduce the complexity of the
system. A related issue, which becomes moot if the policy is made pure
client, is whether nil ProtocolProperties are allowed in ClientProtocolPolicy,
and, if so, how are they encoded into a TaggedComponent if the policy is
set on the server-side.
The specification does not define APIs for setting and getting Priority Mappings and Priority Transforms, leaving it up to ORB implementations. These APIs should be standardized in order for application code to be portable.
The specification defines a number of policies involving priorities, and describes some of their interaction. However, it does not completely specify the validity and semantics of all possible combinations of those policies. For example, does the combination of Server Declared Priority Model with server-set Priority Banded Connections make sense? For all values? If the purpose of Priority Banded Connections is to avoid priority inversions, then why would we ever want to use PriorityModelPolicy without PriorityBandedConnectionPolicy? And, if we would always want to use Priority Banded Connections, why does there need to be a policy, why can't banded connections be a mechanism the ORB uses internally as needed, transparent to the user?
What is clear from the spec is the availability of certain policies, what is not clear is what exactly using each one of those policies achieves - in other words, when and why different combinations of them are appropriate.
Section 4.12.2 of the specification says the following about server ORB and priority band establishment: "if the priority band is inconsistent with the ORB's priority configuration then the ORB shall raise a INV_POLICY system exception". However, the specification never defines what is meant by the ORB's priority configuration, leaving it up to implementations. One implementation, for example, might use Threadpool threads for servicing banded connections, and consistency with the ORB's configuration would mean availability of a threadpool lane with priority matching band's priority range. Another implementation might be spawning separate threads for servicing banded connections, and consistency with the ORB's configuration would be automatic. With these two implementations, a band that will cause exception in the first implementation will work just fine in the second. The specification does not provide a model of ORB thread resources: it provides APIs for creating Threadpools, but does not describe how the threadpool threads are used. I/O threads are never even mentioned. On one hand, this lack of a resource model is beneficial: it allows greater freedom and variety of implementations. But, on the other hand, it hurts portability, since a configuration might work with one real-time ORB implementation but not another. Also, bounding priority inversions is a quality of implementation: there is no explicit requirement for I/O threads to run at the same priority as request processing threads.
In summary, we believe that Real-Time CORBA 1.0 specification is a good start, but needs some work, especially in regards to resolving ambiguities. Currently, applications must depend on many implementation details. For example, a policy combination providing certain semantics in one ORB can provide different semantics or be invalid when used in another ORB, with both ORBs being compliant with the specification.