Thus, the programmers of the client need not have prior knowledge of a service when a UI and user are also present. Because the programmers of the UI had prior knowledge of the service object interface, the programmers of the client need only have prior knowledge of the standard way to find and select an appropriate UI associated with a service. In Figure 2, it is the UI code, not the client code, that talks to the service object interface directly. Universal Access Separating UI and functionality is a flexible way to architect Jini services, because the same service object can be used with more than one UI object. This enables the same service to be accessed from many different kinds of Jini-enabled computers and devices.
Different devices have different user interface capabilities.
For a given service, a service provider can create multiple UI objects, each of which is geared for a different set of capabilities, and associate them with the service. Third party developers can potentially create their own UI objects to supplement those provided by the service provider. Thus, a Jini service architecture in which functionality is separated from UI enables users to access a service via many different kinds of Jini-enabled devices. A separation of UI and functionality also makes it possible to make a Jini service accessible to devices that are not Jini enabled. As shown in Figure 3, a a non-Jini device talks to a protocol adapter via a network protocol.