|
•
|
Thread level policies are set through PolicyCurrent, which contains operations for viewing and setting Policy overrides at the thread level. Policies set at the thread level override system defaults and values set at the ORB level.
|
VisiBroker for .NET extends CORBA.Object to provide additional QoS support as defined in the OMG Messaging specification. This means that there are two exposed
Object interfaces.
The CORBA.Object interface contains the following methods used to get the effective policy and get or set the policy override.
Returns the effective overriding Policy for the object reference. The effective override is obtained by first checking for an override of the given PolicyType at the Object scope, then at the Current scope, and finally at the ORB scope. If no override is present for the requested
PolicyType, the system-dependent default value for that
PolicyType is used. Portable applications are expected to set the desired defaults at the ORB scope since default Policy values are not specified.
The effective override is then compared with the Policy as specified in the IOR. The effective Policy is the intersection of the values allowed by the effective override and the IOR-specified Policy. If the intersection is empty, the system exception INV_POLICY is raised. Otherwise, a Policy with a value legally within the intersection is returned as the effective Policy. The absence of a Policy value in the IOR implies that any legal value may be used. Invoking
NonExistent_ or
ValidateConnection_ on an object reference prior to
GetPolicy_ ensures the accuracy of the returned effective Policy.
If GetPolicy_ is invoked prior to the object reference being bound, the returned effective Policy is implementation dependent. In that situation, a compliant implementation may do any of the following: raise the exception
CORBA.BAD_INV_ORDER, return some value for that
PolicyType which may be subject to change once a binding is performed, or attempt a binding and then return the effective Policy.
Note that if the RebindPolicy has a value of
TRANSPARENT,
VB_TRANSPARENT, or
VB_NOTIFY_REBIND, the effective Policy may change from invocation to invocation due to transparent rebinding.
Returns the effective policy for an object reference—a Policy object of the type specified by the
policy_type parameter.
This method works in a way similar to the CORBA.PolicyManager method of the same name. However, it updates the current set of policies of an Object, thread, or ORB with the requested list of Policy overrides. In addition, this method returns a
CORBA.Object whereas other methods of the same name return
void.
|
|
|
|
|
an array of Policy objects containing the policies to be added or to be used as replacements
|
|
|
either SetOverrideType.SET_OVERRIDE, indicating that the given policies will replace any existing ones, or SetOverrideType.ADD_OVERRIDE, indicating that the given policies should be added to any existing ones
|
Returns a boolean value based on whether the current effective policies for the object will allow an invocation to be made. It returns the value TRUE if the current effective policies for the Object allow an invocation to be made. If the object reference is not yet bound, a binding occurs as part of this operation. If the object reference is already bound, but current policy overrides have changed or for any other reason the binding is no longer valid, a rebind is attempted regardless of the setting of any
RebindPolicy override.
The ValidateConnection_ operation is the only way to force such a rebind when implicit rebinds are disallowed by the current effective RebindPolicy. The attempt to bind or rebind may involve processing GIOP
LocateRequests by the ORB. Returns the value
FALSE if the current effective policies would cause an invocation to raise the system exception
INV_POLICY.
If the current effective policies are incompatible, the out parameter inconsistent_policies contains those policies causing the incompatibility. This returned list of policies is not guaranteed to be exhaustive. If the binding fails due to some reason unrelated to policy overrides, the appropriate system exception is raised.
The CORBA.PolicyManager interface provides methods for getting and setting
Policy overrides at the ORB level.
This method returns a PolicyList sequence of all the overridden policies for the requested
PolicyTypes. If the specified sequence is empty (that is, if the length of the list is zero), all
Policy overrides at the current context level will be returned. If none of the requested
PolicyTypes are overridden at the target
PolicyManager, an empty sequence is returned.
This method modifies the current set of policy overrides with the requested list of Policy overrides. Invoking
SetPolicyOverrides with an empty sequence of policies and a mode of
SET_OVERRIDE removes all overrides from a
PolicyManager.
The first input parameter, policies, is a sequence of references to
Policy objects. The second parameter,
set_add, of type
CORBA.SetOverrideType indicates whether these policies should be added onto any other overrides that already exist in the
PolicyManager using
ADD_OVERRIDE, or they should be added to a
PolicyManager that doesn't contain any overrides using
SET_OVERRIDES.
Only certain policies that pertain to the invocation of an operation at the client end can be overridden using this operation. Should you attempt to override policies that do not apply to your client, a CORBA.NO_PERMISSION exception will be raised. If the request would cause the specified
PolicyManager to be in an inconsistent state, no policies are changed or added, and an
InvalidPolicies exception is raised. There is no evaluation of compatibility with policies set within other
PolicyManagers.
|
|
|
|
|
|
|
|
A parameter of type CORBA.SetOverrideType that indicates whether these policies should be added ( ADD_OVERRIDE) to any other overrides that already exist in the PolicyManager, or added to a clean PolicyManager free of any other overrides ( SET_OVERRIDE). If the request would cause the specified PolicyManager to be in an inconsistent state, no policies are changed or added, and an InvalidPolicies exception is raised.
|
The CORBA.PolicyCurrent interface derives from
PolicyManager and
Current without adding new methods. Therefore all operations on the
PolicyManager interface are also available in
PolicyCurrent. See
“PolicyManager” for a description of these methods.
PolicyCurrent provides access to the policies overridden at the thread level. A reference to a thread's
PolicyCurrent is obtained by invoking
ResolveInitialReferences and specifying an identifier of
PolicyCurrent.
The QoSExt.DeferBindPolicy determines if the ORB will attempt to contact the remote object when it is first created, or to delay this contact until the first invocation is made. By default, the ORB connects to the (remote) object when on a
Bind or a
StringToObject call.
The valid values for DeferBindPolicy are
TRUE and
FALSE. If
DeferBindPolicy is set to
TRUE, all binds will be deferred until the first invocation of a binding instance. The default value is
FALSE.
If you create a client object, and DeferBindPolicy is set to
true, you may delay the server startup until the first invocation. This option existed before as an option to the
Bind method on the generated helper classes.
The QoSExt.ExclusiveConnectionPolicy is a VisiBroker for .NET-specific policy that gives you the ability to establish an exclusive (non-shared) connection to the specified server object. This policy can have a boolean value of
TRUE or
FALSE. If the policy is
TRUE, connections to the server object are exclusive. If the policy is
FALSE, existing connections are reused if possible, and a new connection is opened only if reuse is not possible. The default value is
FALSE.
The QoSExt.RelativeConnectionTimeoutPolicy indicates a timeout after which attempts to connect to an object using one of the available endpoints is aborted. The timeout situation is likely to happen with objects protected by firewalls, where HTTP tunneling is the only way to connect to the object.
The policy value of type unsigned long long specifies the timeout in 100s of nanoseconds. It is applied to every endpoint that the ORB tries to connect to. Therefore, if multiple connection attempts are made, the elapsed time will be a multiple of the configured timeout.
The accuracy is also limited by the Java virtual machine implementation.
The Messaging.RebindPolicy determines how the client-side ORB handles closed connections, GIOP location-forward messages and object failures. The ORB handles fail-overs, rebinds, and reconnections by looking at the effective policy at the
CORBA.Object instance.
The RebindPolicy is a client-side-only policy.
The RebindPolicy is enforced only after being successfully bound to an object. For GIOP-based protocols an object reference is considered bound once it is in a state where a
LocateRequest message would result in a
LocateReply message with status
OBJECT_HERE.
The RebindPolicy is set only on the client side. It can have one of six values that determines the behavior in the case of a disconnection, an object forwarding request, or an object failure. The
RebindPolicy accepts the following constants to define the behavior of the client when rebinding.
|
•
|
Messaging.TRANSPARENT—allows the ORB to silently handle object-forwarding and necessary reconnections during the course of making a remote request.
|
|
•
|
Messaging.NO_REBIND—allows the ORB to silently handle reopening of closed connections while making a remote request, but prevents any transparent object-forwarding that would cause a change in client-visible effective QoS policies. When RebindMode is set to NO_REBIND, only explicit rebind is allowed.
|
|
•
|
Messaging.NO_RECONNECT—prevents the ORB from silently handling object-forwards or the reopening of closed connections. You must explicitly rebind and reconnect when RebindMode is set to NO_RECONNECT.
|
|
•
|
QoSExt.VB_TRANSPARENT—is the default policy. It extends the functionality of TRANSPARENT by allowing transparent rebinding with both implicit and explicit binding.
|
|
•
|
QoSExt.VB_NOTIFY_REBIND—throws an exception if a rebind is necessary. The client catches this exception, and binds on the second invocation.
|
|
•
|
QoSExt.VB_NO_REBIND—does not enable failover. It only allows the client ORB to reopen a closed connection to the same server; it does not allow object forwarding of any kind.
|
Be aware that if the effective policy for your client is VB_TRANSPARENT and your client is working with servers that hold state data,
VB_TRANSPARENT could connect the client to a new server without the client being aware of the change of server, any state data held by the original server will be lost.
|
|
|
|
|
|
|
No, throws REBIND exception.
|
No, throws REBIND exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes. VB_NOTIFY_REBIND throws an exception after failure detection, and then tries a failover on subsequent requests.
|
|
|
|
|
|
The following example creates a RebindPolicy of type
TRANSPARENT and sets the policy on the ORB, thread, and object levels.
The QoSExt.RebindForwardPolicy determines whether the client ORB attempts to rebind in the case of a failure to connect during a
LOCATION_FORWARD. When the client is forwarded to a new object, an attempt is made to connect to a new destination object. If this attempt fails, the ORB transparently connects back to the original object (the source of the forward), under the following circumstances:
The vbroker.orb.rebindForward property sets the value for forward_count at the ORB level. You can override the value for forward_count at the ORB, thread or object level programmatically, as in any QoS policy. The default value of
0 (zero) for the property indicates that no limit has been specified.
Returns the current setting for forward_count of the
RebindForward policy.
The Messaging.RelativeRequestTimeoutPolicy indicates the relative amount of time which a Request or its responding Reply may be delivered. After this amount of time, the Request is canceled. This policy applies to both synchronous and asynchronous invocations. Assuming the request completes within the specified timeout, the Reply will never be discarded due to timeout. Timeout value is specified in 100s of nanoseconds.
The Messaging.RelativeRoundtripTimeoutPolicy specifies the relative amount of time for which a Request or its corresponding Reply may be delivered. If a response has not yet been delivered after this amount of time, the Request is canceled. Also, if a Request had already been delivered and a Reply is returned from the target, the Reply is discarded after this amount of time. This policy applies to both synchronous and asynchronous invocations. Assuming the request completes within the specified timeout, the Reply will never be discarded due to timeout. Timeout value is specified in 100s of nanoseconds.
The Messaging.SyncScopePolicy defines the level of synchronization for a request with respect to the target. This interface is a local object derived from
CORBA.Policy.
Values of type SyncScope are used in conjunction with a
SyncScopePolicy to control the behavior of one-way operations. It is applied to one-way operations to indicate the synchronization scope with respect to the target of that operation request. It is ignored when any non-one-way operation is invoked.
This policy is also applied when the DII is used with a flag of INV_NO_RESPONSE since the implementation of the DII is not required to consult an interface definition to determine if an operation is declared one way.
The default SyncScopePolicy is
SYNC_WITH_TRANSPORT.
Applications must explicitly set an ORB-level SyncScopePolicy to ensure portability across ORB implementations. When instances of
SyncScopePolicy are created, a value of type
Messaging.SyncScope is passed to
CORBA.ORB.CreatePolicy. This policy is only applicable as a client-side override.
|
•
|
CORBA.INV_POLICY is raised when there is an incompatibility between Policy overrides.
|
|
•
|
CORBA.REBIND is raised when the RebindPolicy has a value of NO_REBIND, NO_RECONNECT, or VB_NOTIFY_REBIND and an invocation on a bound object references results in an object-forward or location-forward message.
|
|
•
|
CORBA.InvalidPolicies can be raised when an operation is passed a PolicyList sequence. The exception body contains the policies from the sequence that are not valid, either because the policies are already overridden within the current scope, or are not valid in conjunction with other requested policies.
|