| Previous | Table of Contents | Next |
When new PolicyTypes are added to CORBA specifications, the following details must be defined. It must be clearly stated which
particular uses of a new policy are legal and which are not:
• Specify the assigned CORBA::PolicyType and the policy's interface definition.
•If the Policy can be created through CORBA::ORB::create_policy, specify the allowable values for the any argument 'val' and how they correspond to the initial state/behavior of that Policy (such as initial values of attributes). For example, if a Policy has multiple attributes and operations, it is most likely that create_policy will receive some complex data for the implementation to initialize the state of the specific policy:
//IDL
struct MyPolicyRange { long low; long high;
};
const CORBA::PolicyType MY_POLICY_TYPE = 666;
interface MyPolicy : Policy { readonly attribute long low; readonly attribute long high;
};
If this sample MyPolicy can be constructed via create_policy, the specification of MyPolicy will have a statement such as:
“When instances of MyPolicy are created, a value of type MyPolicyRange is passed to CORBA::ORB::create_policy and the resulting
MyPolicy’s attribute ‘low’ has the same value as the MyPolicyRange member ‘low’ and attribute ‘high’ has the same value as
the MyPolicyRange member ‘high.’
•If the Policy can be passed as an argument to POA::create_POA, specify the effects of the new policy on that POA. Specifically define incompatibilities (or interdependencies) with other POA policies, effects on the behavior of invocations on objects activated with the POA, and whether or not presence of the POA policy implies some IOR profile/component contents for object references created with that POA. If the POA policy implies some addition/modification to the object reference it is marked as “client-exposed? and the exact details are specified including which profiles are affected and how the effects are represented.
• If the component that is used to carry this information can be set within a client to tune the client’s behavior, specify the policy’s effects on the client specifically with respect to (a) establishment of connections and reconnections for an object reference; (b) effects on marshaling of requests; (c) effects on insertion of service contexts into requests; (d) effects upon receipt of service contexts in replies. In addition, incompatibilities (or inter-dependencies) with other client-side policies are stated. For policies that cause service contexts to be added to requests, the exact details of this addition are given.
•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.
• Pure client-side policies are assumed to be immutable. This allows efficient processing by the runtime that can avoid re-evaluating the policy upon every invocation and instead can perform updates only when new overrides are set (or policies change due to rebind). If the newly specified policy is mutable, it must be clearly stated what happens if non-readonly attributes are set or operations are invoked that have side-effects.
• For certain policy types, override operations may be disallowed. If this is the case, the policy specification must clearly state what happens if such overrides are attempted.