Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## net.jini.core.constraint
Interface RemoteMethodControl

All Known Implementing Classes:
  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

Method Summary
`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

    public 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

    public 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)`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2004 Sun Microsystems, Inc. All rights reserved