The aim of the report is to provide sufficient information about Jini and JavaSpaces to understand how they could be used to address emerging problems faced by ICT provision in Higher and Further Education over the next few years. Being available free for research and development, and for internal use, makes it easy to evaluate and use in HE/FE.

Jini: a platform for building adaptive integrated learning environments

This webpage has been archived. Its content will not be updated. View web retention policy

The aim of the report is to provide sufficient information about Jini and JavaSpaces to understand how they could be used to address emerging problems faced by ICT provision in Higher and Further Education over the next few years. Being available free for research and development, and for internal use, makes it easy to evaluate and use in HE/FE.

Summary

The report examines Jini, Sun’s new networking technology, together with JavaSpaces, a related service that runs over Jini, in the context of some of the changes and problems that are likely to face the provision of IT in campus-based learning institutions. It provides a high level view of how these technologies work, then reviews how they would be applied to address these problems, with an attempt to evaluate them and compare them with other emerging technologies that address some of the same issues.

The essence of the argument is that the provision of ICT in learning institutions is going through major changes. In five years time the landscape will look very different. There will be a great increase in the number and variety of both networked devices and mobile systems with radio networked links. The latter will become the new ‘scholar’s slate’ and will, as suggested in the Dearing Report, be an essential pre-requisite for the learning process to become effectively supported by integrated learning environments. Learning Environments, in turn, will make major new demands on the ICT providers within HEIs and FE colleges, particularly in the area of systems integration.

These changes bring new problems. In this emerging environment of numerous networked devices and ubiquitous mobile systems, the traditional approach of installing and maintaining device drivers on each user system for every device that a user may wish to use, breaks down. The approach of mandating, across the campus, a single operating system, down to the version, for all user systems, and a single make and model for each type of device, becomes increasingly untenable. It creates very inflexible systems, with high costs involved in upgrading all users when new devices are installed, and even higher costs when the operating system is upgraded or changed. It will probably also be highly unpopular with students, who will be paying for their own systems and be aware of the variety of options available in a rapidly evolving sector with an increasingly wide range of O/Ss available, as Palm, Psion and EPOC are already proving.

With increasing numbers both of networked devices and of mobile users needing to use them, the burden of distributing and maintaining device drivers threatens to become overwhelming. Discovery and Connection services, such as Jini provides, offer a way forward. Jini allows mobile devices to ‘discover’ what systems and services are available in the locality they have moved into. Once discovered, it allows a connection to be made with a networked device or service, with the Jini equivalent of a device driver being dynamically downloaded to client machines on demand. Thus Jini offers ‘plug-and-work’ operation. Jini is not the only approach to providing discovery and dynamic connection to network enabled devices. IETF’s Service Location Protocol (SLP), Bluetooth and HAVi, provide Discovery services, while both Microsoft’s Universal Plug’n’Play and Salutation offer Connection as well Discovery services. These are looked at and compared to Jini, which has some unique advantages, as well as some overheads, due to its being built on top of Java.

Jini is also designed to facilitate the integration of disparate system level components, such as is needed to build a cohesive learning environment. While the issue of agreeing standards for data exchange formats for the learning technology domain is being addressed, notably at present by the IMS Consortium, there is no agreement on application level communication protocols and, it seems, no immediate prospect of this happening. Even if there were protocol agreements, the problem remains of integrating new learning management system components with existing course catalogue, student enrolment, and student record systems which already use a variety of protocols, some proprietary. The learning systems integrator is therefore likely to be confronted with the unpleasant choice of either constraining the choice of systems they are prepared to work with, based on the protocol a system happens to use rather than on the features it offers, or they face the complex task of bridging a variety of different protocols.
In this context, Jini enables a service’s protocol to be hidden by using a ‘service proxy’ which is delivered directly to a client. The client talks to the proxy locally through an agreed Java interface. The proxy then communicates over the network to the service, using whatever protocol its service uses, thus ‘hiding’ it from the client. This also enables a client to use any service of the same type, regardless of the protocol it uses. To work, this requires an interface for each type of service, for example a student record system, to be widely agreed. Each system offering this type of service has to provide a proxy which implements the agreed interface. When started up, services ‘discover’ and register with a Jini Lookup Service, sending it their proxy. Clients are implemented that are able to make calls on proxies with this interface. When a client wants to use a service, it also ‘discovers’ the Lookup Service and requests data on all registered services of the type they are interested in. On selection of a particular service, they download its proxy which then handles the connection to the service. Jini thus enables clients to dynamically discover and connect to services. Once the connection is made between a client and service, the Jini Lookup Service steps back, and plays no further part.

In March ’99 the IMS Consortium approved the scope for a Messaging specification, but, as of December 2000, it is still not on the IMS road map. The Scope proposed defining an abstract messaging system supporting Request/Response and Publish/Subscribe modes, with both capable of synchronous and asynchronous operation. Although simple and basic, not all systems, particularly legacy systems, support this.

Where Jini provides a connection and steps out, JavaSpaces is used to decouple and mediate the communication between distributed systems. JavaSpaces is provided as a service which systems can discover and connect to via Jini. JavaSpaces is very flexible and can be adapted to provide the proposed IMS Messaging services. It greatly eases the task of developing distributed systems by providing a very simple programming interface to clients and handling much of the complexity of distributed communications itself. As a Jini-enabled service, the two combine to provide a unique systems integration toolset.

Additionally, Appendix A looks at the potential of JavaSpaces to effectively harness the spare processor cycles commonly available on a Campus network in to a usable compute server. Although earlier attempts have shown this to be hard to achieve, JavaSpaces may offer a combination of features that make this possible. Should this prove to be the case, there would be some important consequences. As students and staff increasingly come to use their own portable systems, IT provision may be expected to gradually move towards providing usable and sharable capacity that can enhance these systems, rather than providing rooms with PCs and workstations.

Under the JavaSpaces compute server model, capacity can be added incrementally to meet loading demand. As all that is needed to provide this capacity is a processor and memory, it will also be relatively cheap to provide, with cost perhaps shifting to the provision of very high speed networking. The key issue for compute nodes will be the price/performance ratio. The highest ratio may well be produced by harnessing large numbers of lower capacity processors: their price can be expected to drop dramatically as they become commodity ‘jelly-bean’ components.

Another advantage of using Java in this context is that software does not have to be rewritten, or at least recompiled, as new types of processor become available and introduced to the network, so long as they are capable of running Java. This greatly simplifies the management of such systems, extends the life of software developed in this way and creates much better opportunities for taking advantage of processor advances as they become available, rather than being constrained to adopt a single processor family or operating system.

Conclusion

Jini, at least in its current form and using IPv4, is seen primarily as an intranet technology. JavaSpaces, to the extent that it is able to operate independently of Jini, can be used over the Internet, particularly for distributed computing applications. Together, they offer solutions to several difficult problems confronting the provision of IT on campuses over the next few years. Jini’s applicability to distance learning is indirect and lies more in the creation of robust campus-based integrated systems and learning environments that support remote learners. JavaSpaces, on the other hand, could be used to develop collaborative systems with which remote learners interact directly. Overall, it is also a good technology for the evolution of flexible systems that support hybrid combinations of traditional teaching approaches, coupled with on and off campus learning and teaching support.
Jini and JavaSpaces are both made freely available by Sun to Education for internal use and the sources for both are also freely available for research and development. In both cases the Sun Community Source License (SCSL) needs to be signed. This gives automatic membership of the Jini Community which Sun has set up to define interfaces for types of Jini devices and services and to determine the future development Jini and JavaSpaces.

It is too early to be clear whether Jini will emerge as the dominant standard in the 'discovery & connect' self-configuring network world, but its chances appear reasonably good. In the near term, several standards are likely to co-exist and bridges will be built between them, a task which Jini is also well suited to fulfilling. Other standards do not offer the same range of application as Jini, and none offer the capabilities of Jini and JavaSpaces when taken together. As a technology with the potential to both significantly reduce costs as well as solve several of the problems outlined, it should be piloted and its progress in the market closely monitored. A number of projects are recommended to test the technology and, where it proves positive, make it available widely to HE and FE. The Sun Community Source License makes this straightforward and inexpensive.

In the near term, its main benefit is likely to lie in the area of systems integration, enabling robust distributed learning environments to be created and managed, which can be changed and adapted to take advantage new developments in the rapidly evolving area of learning technology.

Read the final report below

Documents & Multimedia

  • Jini
    Portable Document Format (pdf) File [ 591 Kb ]
Bookmark and Share
Summary
Author
Bill Olivier
Publication Date
1 December 2000
Publication Type
Topic