net.jini.core.constraint

Interface RemoteMethodControl

All Known Implementing Classes:

ConstrainableEventLease, ConstrainableLandlordLease, ConstrainableLookupLocator

public interface RemoteMethodControl

Defines an interface to proxies for setting constraints to control remote method calls. If a proxy implements this interface, then the semantics of this interface apply to all calls through all remote methods defined by the proxy; there is no mechanism to exempt remote methods or remote interfaces from these semantics.

Constraints for a remote call come from two sources:

• Constraints imposed by the server (including any minimum constraints imposed by the communication mechanism used between the proxy and server)
• Constraints placed on a proxy by the client

The server constraints are controlled by the proxy implementation; they are not exposed to the client, and might vary in ways unknown to the client (for example, vary by method or over time). The client should set the constraints it wants rather than assuming that the server imposes particular constraints. Client constraints placed on a proxy apply to all remote calls made through that particular proxy by any thread, and the client can specify different constraints for each remote method.

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.

Since:

2.0

Author:

Sun Microsystems, Inc.

Method Summary

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.

Method Detail

setConstraints

RemoteMethodControl setConstraints(MethodConstraints constraints)

Returns a new copy of this proxy with the client constraints set to the specified constraints. These constraints completely replace (in the copy) any client constraints previously placed on this proxy; calling the 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.

Parameters:

constraints - client constraints, or null

Returns:

a new copy of this proxy with the client constraints set to the specified constraints

See Also:

getConstraints()

getConstraints

MethodConstraints getConstraints()

Returns the client constraints placed on this proxy. The return value can be null, which is interpreted as mapping all methods to empty constraints (one that has no requirements and no preferences).

Returns:

the client constraints, or null

See Also:

setConstraints(net.jini.core.constraint.MethodConstraints)