Inexpensive computer processing and networks have created a growing ocean of connected devices. Seamlessly tying together this mass of resources is ambitious — and problematic. It will happen, and Sun’s Jini is one such attempt to do so. This Tech Focus covers concepts that make Jini and distributed objects possible. Used correctly distributed objects can make it easier to develop more coordinated, balanced, and fault-tolerant systems.
Jini is made possible by several Java mechanisms.
Making two programs on two different processors communicate generally means lots of code. A protocol, such as HTTP, can allow the programs to talk. However, what does the source code look like? Protocols require parsing, and can be difficult to debug at runtime. When you use distributed objects, instantiating objects, passing objects as parameters, and calling methods is the protocol for communication. You work with objects like you normally would, but get powerful distributed behavior when it all compiles. Distributed objects make the compiler do more work for you.
The Jini way
Jini is made possible by several Java mechanisms. The Java virtual machine provides a consistent processor, so the same binaries can run on various architectures. Java has explicit syntax to support interfaces. When dealing with distributed objects you almost always deal with an interface to an object, not the object itself. Object serialization allows an object’s state to be sent through streams, which means they can be sent through the network. Remote Method Invocation provides the fundamentals for running objects from different virtual machines. And finally, Java provides fine-grain security to grant specific objects specific access.
One of the first problems a distributed system faces is how programs find each other. This can be solved with the client-dispatcher-server pattern. There is a dispatcher, or middleman, that both programs know about. Thus, the programs do not have to know about each other, just the dispatcher. The dispatcher is the key piece that bootstraps the rest of the object interaction. In Jini, the dispatcher is called the Lookup service, also in CORBA (Common Object Request Broker Architecture) this is the Object Request Broker (ORB). There are two ways to find the Lookup service in Jini. One is to hardcode the address. Second is to use IP multicast to essentially shout for any listening Lookup services in the vicinity of your IP network. Multicast IP’s reach depends on the router configuration on your network.
Now that the two programs know about the Lookup service, they still need to find each other. A program that provides objects to another program is called a service. When a service first starts, it contacts the Lookup service. The service has various properties, which it sends to Lookup. Another program can then query Lookup for any services matching certain properties. For example a digital camera wants to print a picture, so it contacts the lookup service for a printer interface that has the properties color, photo quality, etc. After the Lookup service connects the two programs, Lookup is no longer involved in the communication.
When two programs start communicating over a network there is the potential for problems. Jini does not hide the fact you are using distributed objects. All distributed objects at least throw the Remote exception. This means you have to explicitly handle failure conditions when trying to create and access remote objects. Also, all services are leased. Leasing means services are requested for a certain period of time. If a program needs more time, it can request to renew its lease. Leasing allows object to handle failures of remote objects more gracefully. For example a service provider can clean up after a lease expires. Also leases keep the Lookup service from getting stale. All entries in the Lookup service are leased, so as devices are unplugged from the network they eventually disappear from the Lookup service.
Writing distributed systems is much easier with support from frameworks such as Jini.
Dispatching and leasing start the communication, but there are other mechanisms to help objects work together. A particularly useful communication device is asynchronous events. For example, user interfaces typically use events to connect user interface objects. Jini provides all the pieces for remote objects to send and receive events. For example a user could be notified when a printer is low on paper. Another issue is coordinating groups of objects to perform an atomic operation, commonly called a transaction. Because various objects may be on different systems, a central service needs to control the transaction. Thus, Jini provides a separate service called the Transaction Manager to help transaction participant objects commit, or rollback, a transaction.
Bumps in the road
Writing distributed systems is much easier with support from frameworks such as Jini. You can focus on behavior, instead of the low-level object communication details. However there are some issues. Jini requires static and well-defined interfaces for objects to use. This puts much more focus on writing good object interfaces, because it may be difficult to update them as the interface is replicated to a bunch of devices. Jini has several services to run and configure. Also, the Lookup service (dispatcher) can be a performance bottleneck in intensive systems.
In general, however, the real problem is widespread acceptance of a particular standard. If everything communicates, then everything must share the same communication method. Many people agree that everything from toasters to dog collars will get an IP address. However, what will be sent to and from those addresses? That is the core of the problem. Jini might not be the final effort to coordinate the expanding universe of network of devices. However many of the concepts and ideas, such as distributed objects, dispatching, leases, events, and transactions, carry over to other efforts. Looking at more details of using Jini will be the subject of a future Tech Workshop.
About the author
Eric Grab is a lead analyst/programmer at San Diego State University. He speaks on object-oriented technology and design patterns.