Standardizing Interfaces

Jini services are manifested as Java objects that expose interfaces conforming to the Jini specification. The type of the service determines the interfaces that comprise the service. Jini relies on the richness of Java type semantics. These type definitions and the ease with which they support subtyping (inheritance) resembles the way we build systems. Systems can evolve as the technology evolves. Many of the other approaches rely on XML definitions or APIs that might limit the systems' adaptability to change: For instance, versioning has always been problematic with XML.

Jini services advertise their operations by registering an object with a Jini-compliant lookup service. Service registration is at the core of building the Jini network community. Jini does define special roles for service discovery, but does not limit the number of lookup services that a network can support.

There are three infrastructure services that are required somewhere on your Jini network:

• An HTTP server that supports the dynamic downloading of code

• The Remote Method Invocation daemon (rmid) that provides the distributed remote object lookup and activation mechanism

• The Jini Lookup Service (LUS) that provides the service registry and the service lookup capabilities on the Jini network