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
Note that constraints imposed by the communication mechanism must be
factored into the requirements. For example, if the only explicit requirement is
Delegation.YES, but the communication mechanism always requires client
authentication, then effectively a
ClientAuthentication.YES requirement exists, and
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
s1 obtains a proxy for remote object
and passes that proxy to remote object
s3 to invoke a
remote method on
s1 can control that call by placing its
constraints directly on the proxy before passing it to
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
constraints- client constraints, or
null, which is interpreted as mapping all methods to empty constraints (one that has no requirements and no preferences).
Copyright © GigaSpaces.