Server objects are governed by a "best effort" distributed garbage collector. When no outstanding references
to a remote object exist, that object can be collected. This is similar in principle to garbage collection for local
objects, but the failures of distributed computing make surety impossible. If a client hasn't been in contact for
a long time, it is presumed to have gone away without notifying the server (possibly the system crashed). If a
long-lived network failure is actually at fault, the client may find that the server has been garbage-collected
when the network reconnects. Every reasonable effort is made to preclude this possibility. A server can ensure
that it will never be garbage-collected by simply holding on to a remote reference to itself, thus ensuring that
at least one remote reference will keep it alive. This reference can be dropped when the server decides that it
no longer must be forced to be alive.
RMI is explicitly designed to take advantage of having both client and server in the Java programming
language. This gives it a form that is simple and direct for people who know the language. You can, of course,
implement any server methods you like as native methods. Native methods can help you use RMI as a
bridge to existing native code, such as in two- and three-tier systems.
The subpackage java.rmi.activation provides for activatable servers, which will be started when they
receive messages if they are not already running. Multiple servers can be put in the same activation group, and
will then be run in the same virtual machine.
25.7. java.security and Related Packages Security Tools
The security architecture that was introduced in Chapter 23 is quite extensive and incorporates a range of
mechanisms for encryption, authorization, authentication, and so forth. These mechanisms are spread across a
number of packages.
The package java.security contains several useful tools for security-related functions: digital signatures,
message digests, key management, and cryptographic keys. Subpackages define abstractions for certificates
(java.security.cert), RSA and DSA keys (java.security.interfaces), and key and
algorithm parameter specifications (java.security.spec).
The javax.security subpackages complement these tools with a full authentication and authorization
framework (javax.security.auth and its subpackages), including support for the Simple
Authentication and Security Layer (SASL) as defined by RFC 2222 (the javax.security.sasl
package). The authorization component allows specification of access controls based on code location, code
signers, and code executors (subjects), using common protocols such as Kerberos and X500.
The javax.crypto package and subpackages (interfaces and spec) provide rich mechanisms for
cryptography, including encryption with various kinds of ciphers, MAC generation, and key creation and
agreement.
The org.ietf.jgss package provides a framework that helps you use security services such as
authentication, data integrity, and data confidentiality from a variety of underlying security mechanisms. The
security mechanisms an application can choose are identified with unique object identifiers. For example, the
Kerberos v5 GSS-API mechanism has the object identifier 1.2.840.113554.1.2.2. This mechanism is available
through the default instance of the GSSManager class.
Because there are many ways to approach things like cryptography and authentication, and there will be many
more in the future, the security architecture provides abstractions of security interactions. Implementations of
the abstractions are supplied by providers. Each platform has one or more providers. The
java.security.Security utility class provides methods to find out which providers are available.
Providers can interoperate through the provided abstractions.