JINI^TM: Setting the Record Straight

Looking for help with JINI 2.0? - Check this out

Introduction

1. It's just for devices
2. It's Java only
3. It's not secure
4. It's nothing new
5. It's too complex
6. It's dependent on RMI
7. It can't run on devices
8. It's dependent on multicast
9. It won't work with J2EE
10. It won't work with WebServices

Whilst I do not consider myself to be a JINI zealot, I do feel that, for various reasons, JINI has been given a raw deal and merits a second look. In this article, I am going to attempt to redress the balance so, without further delay......

Update 8/4/04: Revised to include commentary on additional JINI fallacies such as it's dependency on RMI, JINI's inability to run on devices, JINI's dependency on multicast and various integration issues.

Now, ask yourself just how could we possibly make use of that many addresses? Even if every human on the planet had several network-aware devices and a couple of PC's, there are still a lot of spare addresses! The answer lies in the expected increase in the use of EmNets (large numbers of network-aware devices) for factory automation, farming, transport etc. For more detailed information, see Embedded, Everywhere.

1. How do these devices communicate with each other?
2. How are they deployed?
3. How do we manage them?
4. How is partial failure handled within a group of co-operating devices?

From a simplistic point of view, these devices, just like enterprise servers and, increasingly, home PC's all run services. In some cases, these services interact with humans, in a lot of cases, these services interact with each other. Enterprises have been struggling for years to handle the need for spontaneous deployment of new services or additional instances of existing ones to cope with spikes in load. This exact same scenario (deploying software services) will be played out with the deployment of additional devices in a factory or the adding of an entertainment device to a car.

Thus, we have a technological world which is moving towards a proliferation of software services running on a variety of hardware (enterprise servers, wrist watches, in car entertainment systems, engine management systems). New services will be deployed, old ones will be retired. Services will rely on each other and need to be able to cope with this constant changing of deployed services as well as classic distributed computing issues such as partial failure.

JINI was designed with this sort of world in mind. SUN, IMHO, were trying to convey this story but the world ended up concentrating too much on devices, rather than on the services these devices would provide and the external services these devices would be dependent upon. In addition, the assumed type of device was far too narrow and focused very much on the immediate rather than the future.

In conclusion, JINI was designed with spontaneous networking of services in mind rather than devices.

This conclusion is supported by a JavaOne 2001 presentation by Jim Waldo - JINI Networking Technology and Service-Based Architectures (TS-1137) which can be found at The JavaOne 2001 web-site.

JINI certainly requires some aspects of Java to work. In particular, it needs support for mobile code but not much else. This requirement results in a JINI proxy needing to be, at least in part, Java-based. But the back-end that the proxy is associated with need not be Java at all. In fact, the JINI community has long recognised that legacy integration issues are important resulting in the creation of project such as Surrogate.

• JINI Security
• Proxy Trust
• Object Integrity
• Security Constraints
• Dynamic Permission Grants
• JINI Extensible Remote Invocation

1. Wide-area distribution
2. Partial Failure

1. Get reference to lookup service.
2. Ask lookup service for reference to another service using, often, a particular name.
3. Invoke a series of transactional operations on the service.

Perspective 1: Wide-area distribution

Step (1) can be troublesome - how does one get a reference to a lookup service? Normally, one hardwires an address into the client. After a little consideration, one decides to hardwire a number of addresses to account for failure and load balancing. What happens when the load gets too high for even a few addresses? How do you ensure sufficient geographical distribution of the lookup services such that all clients around the world get dependable and scalable access?

Clearly, a static scheme such as hardwiring is inadequate. JINI has an in-built mechanism for coping with this issue called Discovery and Join which allows a JINI-based client to locate nearby lookup services without any prior knowledge of their existence.

Step (2) also presents challenges. One needs to ensure that each lookup service has a remote reference identified in whatever manner the client is expecting (e.g. a particular name). What if the remote service reference is invalid because of some form of network or server failure? What if the remote service reference relates to a system on the other side of the world from the client?

JINI services identify themselves not by name but by the type of service they offer - e.g. Printer, BookSeller or DryCleaner. Thus a client locates a suitable service by asking the lookup service for a particular type. The lookup service allows for each service to provide further information about itself which may be useful to the client in selecting which service it uses. For example, a DryCleaner service implementation might wish to advertise that it's available 24 hours. Further, should a new service be deployed, it will automatically register with nearby lookup services and be "visible" to clients of that lookup service. A client can register interest in a particular kind of service such that, should a new one appear it will automatically be informed giving it the option to switch services should it wish to do so.

[ Implementation note: SUN's JINI implementation, of course, uses multicast to implement it's dynamic lookup mechanism. Obviously, it's not desirable to use multicast across the entire Internet. This problem can be solved by federation of lookup services such that each lookup service knows about a number of others (these other lookup services could be a large number of network hops away). This allows a deployer to build a more hierarchical type lookup structure similar to DNS with the crucial difference being that a client can dynamically locate a nearby lookup service thus avoiding the hardwiring problems discussed earlier.]

Perspective 2: Partial Failure

Step (3) is most often considered from a client perspective - "what if the service fails?". The client is concerned with ensuring that it's work is atomic - it all gets done or none of it does.

This is certainly important, but what about the service's perspective - "what if the client crashes?"

The client may crash halfway through performing a transaction leaving the server, for example, holding locks on particular resources. How does the server know that the client has crashed? Maybe a temporary network problem is preventing the client closing the transaction? In the meantime, other clients may be impacted by these no longer valid locks still being held?

1. Regular pinging of the client - this can work but suffers from a problem when the server decides the client has crashed and frees associated resources after which the client returns and attempts to continue the operation. Whilst one can certainly write code to handle this problem it's not terribly elegant
2. Leases - the client "borrows" resources from the server for some period of time. It may extend that time if it wishes. If the client fails to "return" the resources within the alloted time, the server is permitted to release associated resources. Note that the client also knows how long a duration lease it has which means that should it be unable to contact the server within the alloted time, it knows that the server will have cancelled the operation and can immediately take steps to restart the operation.

JINI adopts the leasing approach and makes it available via suitable API's to all clients and services.

• Leasing has been used within the SUN RMI implementation for quite some time.
• JINI transactions are leased. When a client creates a transaction it receives both a transaction instance and a lease for that instance. The client maintains/renews the lease for as long as it is performing work with the transaction. Under normal circumstances, the client will then commit or abort the transaction which invalidates the lease. Should the client fail before either commiting or aborting, the transaction is automatically aborted when the lease expires which allows services involved in the transaction to release resources that otherwise may have been held indefinitely.

Nothing New?

Perhaps, but certainly JINI has enough differences (and for brevity, I've left some out) from other approaches to merit examining it without preconceptions.

Which brings us to........

[I recommend that you review "It's Nothing New" before reading this section]

I believe that the reason many find JINI "too complex" is because it's somewhat different from more "traditional" approaches to building distributed systems. Thus getting to grips with JINI requires the programmer to learn some new concepts and adopt a different perspective on distributed systems design. The programmer will make this more difficult for themselves if they lean upon the knowledge they have accrued from building distributed systems using other technologies. (Note: I am not saying that JINI is better or worse, I'm saying it's different and recognising that fact can speed up the learning process).

JINI tends to encourage a more granular approach to the construction of distributed systems (a service should do one small thing well) which gives the programmer great flexibility but can make deployment and testing more difficult. The JINI 2.0 starter kit has taken steps to reduce these difficulties and there are now a number of commercial and non-commercial container implementations available which support deployment of services in groups making deployment much easier.

Writing a JINI service for the first time is certainly daunting but tools are beginning to appear which make this much less arduous (see Inca X). In addition there is a very active community with a number of mailing lists you can mail to for advice. The Blitz Project also provides a number of useful resources.

There is no requirement for RMI in JINI. The specifications are such that certain classes such as Remote and RemoteException would need to be available but there is no requirement for RMI itself. It's a common mistake to assume that because an interface extends Remote or a method throws RemoteException there's a dependency on RMI. This is plain wrong - the presence of these exceptions or Remote constitutes a contract stating that the underlying implementation is possibly using remote resources. The nature of the underlying implementation could be socket based, RMI, CORBA, XML-RPC or any number of other transports. For more details on this, see The End of Protocols.

It's also important to realize that the specifications permit multiple implementations of JINI. SUN's version happens to make use of RMI but there's nothing preventing other companies from doing things differently.

This will always be true of some devices that are simply too low-powered to run JINI but they'll likely be extremely simple, low-cost devices doing trivial tasks. However, Moore's Law will ensure that a growing number of devices can run JINI. There are a number of projects examining wide-area sensor deployment scenarios which could easily end up using JINI for their infrastructure. Several examples were presented at the 7th JINI Community Meeting including work on RFID and a project at The Johns Hopkins University Applied Physics Lab concerning autonomous vehicles and swarm technology.

Firstly, JINI has a number of lookup facilities that do not require the use of multicast. Secondly, multicast is not the only means by which the dynamic networking property of JINI can be realized. The standard broadcast facilities could also be used (though they'd be less optimal) and limited solutions based on UDP could also be deployed. It might also be possible to build on top of the infrastructure provided by ZeroConf

© Copyright 2003 Dan Creswell

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U. S. and other countries