public interface RemoteMethodControl
Constraints for a remote call come from two sources:
A remote call will be performed only if the combined requirements (from
both sources) can be satisfied. If the combined requirements cannot be
ConnectIOException will be thrown by the
remote call, typically containing (but not required to contain) a nested
In addition to the requirements, both client and server preferences will
be satisfied, to the extent possible.
Note that constraints imposed by the communication mechanism must be
factored into the requirements. For example, if the only explicit
Delegation.YES, but the communication
mechanism always requires client authentication, then effectively a
ClientAuthentication.YES requirement exists, and so the
Delegation.YES requirement must also be satisfied.
The constraint mechanisms are designed such that client constraints do not weaken server constraints, and vice versa. However, it is certainly possible to specify conflicting constraints. Preferences that conflict with requirements are ignored, and if preferences conflict with each other it is arbitrary as to which (if any) are satisfied, but if there are conflicting requirements the remote call will not be made.
|Modifier and Type||Method and Description|
Returns the client constraints placed on this proxy.
Returns a new copy of this proxy with the client constraints set to the specified constraints.
RemoteMethodControl setConstraints(MethodConstraints constraints)
getConstraintsmethod of the copy returns the identical constraints instance. The original proxy is not modified. A
nullvalue is interpreted as mapping all methods to empty constraints (one that has no requirements and no preferences). For any given remote call, the specific client requirements and preferences to be satisfied are given by the return value of invoking the
getConstraintsmethod of the specified
MethodConstraintsinstance with a
Methodobject representing the remote method.
Client constraints placed on a proxy are included in the serialized
state of the proxy. This allows third-party services to be transparent
to the client's needs. For example, if remote object
obtains a proxy for remote object
s2, and passes that
proxy to remote object
invoke a remote method on
control that call by placing its constraints directly on the proxy
before passing it to
s3 does not
wish to be transparent in this way, then it should explicitly replace
the client constraints on received proxies with whatever constraints
are appropriate to implement its own policy.
constraints- client constraints, or
null, which is interpreted as mapping all methods to empty constraints (one that has no requirements and no preferences).
Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.