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
satisfied, a ConnectIOException
will be thrown by the
remote call, typically containing (but not required to contain) a nested
UnsupportedConstraintException
.
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
requirement is 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 |
---|---|
MethodConstraints |
getConstraints()
Returns the client constraints placed on this proxy.
|
RemoteMethodControl |
setConstraints(MethodConstraints constraints)
Returns a new copy of this proxy with the client constraints set to the
specified constraints.
|
RemoteMethodControl setConstraints(MethodConstraints constraints)
getConstraints
method of the copy returns
the identical constraints instance. The original proxy is not modified.
A null
value 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 getConstraints
method of
the specified MethodConstraints
instance with a
Method
object 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 s2
, and passes that
proxy to remote object s3
, expecting s3
to
invoke a remote method on s2
, then s1
can
control that call by placing its constraints directly on the proxy
before passing it to s3
. If 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
getConstraints()
MethodConstraints getConstraints()
null
, which is interpreted as mapping all
methods to empty constraints (one that has no requirements and no
preferences).null
setConstraints(net.jini.core.constraint.MethodConstraints)
Copyright © 2016–2018 The Apache Software Foundation. All rights reserved.