Jini clients select Jini services according to the Java interfaces that they implement. This means any Jini client you write will automatically recognize services that provide the functionality you need without you ever needing to know what those services are named, where they are located, who provided them, or anything else about them. Besides making it easier to code your client, you also gain tremendous flexibility in terms of service substitution. As new or changed service implementations become available anywhere on the network, you can automatically recognize and use them.
Using interfaces to identify service capabilities also eliminates "mistaken capability" problems that can arise when relying on potentially ambiguous names or other conventions to describe service capabilities indirectly. For example, if you mistakenly rename a service, systems that rely on that service's name to identify its capabilities may assume incorrectly that your service has new capabilities suggested by its new name. Jini systems do not depend upon service names in this way (Jini services don't even need to be named). Instead, Jini service capabilities are identified directly, according to the interfaces they implement.
|Figure 2: Dynamic Networking with Jini Technology 2|
As a useful aside, Jini services can register with additional attributes to help differentiate them from other services that provide the same capabilities. If the ability to refine your service selection is important to you (maybe you want to be sure you're using an implementation that meets certain requirements you may have for cost or performance), you can use attributes to help you do that too.
Since the Java type system is a true object-oriented type system and supports polymorphism and inheritance, any Java program readily understands the relationships between Jini service types. So the Java type system provides a built-in service ontology that Jini clients use. Among other benefits, this allows you to evolve your system by replacing older versions of Jini services with new ones without needing to simultaneously update older clients that may still be looking for the original service functionality. The same Jini services that you extend with additional functionality will still be automatically recognized as able to implement their original interfaces too.
|Figure 3: Java Type System as a Jini Service Ontology|