US.1. Summary

When developing clients and services that will participate in the application environment for Jini technology, there are a number of behaviors that the developer may find desirable to incorporate in the client or service. Some of these behaviors may satisfy requirements described in the specifications of various Jini technology components; some behaviors may simply represent design practices that are desirable and should be encouraged. Examples of the sort of behavior that is required or desirable include the following:

• It is a requirement of the Jini discovery protocols that a service must continue to listen for and act on announcements from lookup services in which the service has registered interest.

• It is a requirement of the Jini discovery protocols that, until successful, a service must continue to attempt to join the specific lookup services with which it has been configured to join.

• Under many conditions, a Jini technology-enabled client (Jini client) or service will wish to regularly renew leases that it holds. For example, when a Jini technology-enabled service (Jini service) registers with a Jini lookup service, the service is requesting residency in the lookup service. Residency in a lookup service is a leased resource. Thus, when the requested residency is granted, the lookup service also imposes a lease on that residency. Typically, such a registered service will wish to extend the lease on its residency beyond the original expiration time, resulting in a need to renew the lease on a regular basis.

• Many Jini services will need to maintain a dormant (inactive) state, becoming active only when needed.

• Many Jini clients and services will need to have a mechanism for finding and managing Jini services.

• Many Jini clients and services will find it desirable to employ a separate service that will handle events, in some useful way, on behalf of the participant.

To help simplify the process of developing clients and services for the application environment for Jini technology (Jini application environment), several specifications in this document collection define reusable components that encapsulate behaviors such as those outlined above. Employing such utilities and services to build such desirable behavior into a Jini client or service can help to avoid poor design and implementation decisions, greatly simplifying the development process.

What is presented first is terminology that may be helpful when analyzing these specifications. Following the section on terminology, brief summaries of the content of each of the current helper utilities and services specifications are provided. Finally, the other specifications on which these specifications depend are listed for reference.