Jini's architecture is based on the following environmental assumptions (see Figure 23):
The existence of a network with reasonable network latency This is to ensure that network latency does not affect the performance of a Jini system because Jini relies heavily on Java's mobile-code feature.
Each Jini-enabled device has some memory and processing power. For devices without processing power or memory, a proxy exists that contains both processing power and memory. This is a strong assumption because all network citizens are expected to have minimum computing capability, memory, and ability to communicate.
Each device should be equipped with a Java Virtual Machine (JVM). The availability of different JVM footprints makes it easier to Java-enable any device.
Service components are implemented using Java. This is an assumption for software components that would be joining a Jini community. All the service components should live as Java objects to facilitate the service requester to download and run code dynamically. The point to note here is that Jini does not expect a Java service implementation but a Java wrapper.
Figure 2-3 Jini's assumptions. Are the system assumptions hard to meet?
The only assumption, which is very strong, is the expectation of Jini-enabled devices. These are devices with minimum computing capabilities, communicating capabilities, and memory that should host a Java Virtual Machine (JVM). This is fine for many devices, but it can cause problems for the numerous devices that are currently processor-less and driver-controlled. But the provision of a proxy (any device that has a processor, memory, and network capability willing to represent a processor-less device) makes this assumption easier to meet. By this approach, you can use a desktop computer to represent all your processor-less devices, such as printers, scanners, electric switches, washing machines, and microwave ovens, and also to control them.