The Artima Developer Community
This article is sponsored by the Sun Microsystems, Inc..

Leading-Edge Java
Banking on Jini Services
Innovative Architectures
by Frank Sommers
December 7, 2005

<<  Page 3 of 3


WebStarting Jini services

Rubean's service installation is based on Java WebStart. A user with a banking device connected to his PC visits a Web page, and invokes on that page a WebStart application. The application commences an installation wizard that interrogates the local PCs serial and parallel ports and tries to determine the kind of device connected to those ports. If a device does not support automated querying, the user is given an opportunity to enter configuration data. Next, the installation program installs an operating system service suitable for running RMI-based remote object services. That RMI daemon - RMID -- is part of the J2SE distribution, and Rubean's installer sets RMID up as an OS service.

Next, the Rubean installer downloads the appropriate RMI service object for the device, and registers that remote object implementation with RMID. The result of these steps is that whenever the user's PC is booted, the remote object representing the device will instantiate and start listening for incoming method calls. As that object instantiates, it registers a proxy for itself in Jini lookup services, using the dynamic Jini service registration mechanism. Should the device's host power down, that service will cease to renew its lookup service leases, causing Jini lookup services to purge the stale service proxy.

For every supported device, Rubean provides such a Jini service. The remote object implementation contains the complicated code - a device delegate -- to communicate with each device type over the PC's serial or parallel communication ports. As clients discover such services on the network and make method calls on the service's Jini proxy, those method calls dispatch back to the service implementation, which then performs the device-specific logic.

Figure 4: A Rubean device bean

A Jini network typically runs several Jini lookup services, and Rubean's service installer installs a Jini lookup service on each service host. Therefore, even if all but two computers are powered on in a bank branch, a user on one PC can still discover and use devices connected to the other computer.

DAN, the JavaScript that discovers Jini services

Because the Jini approach abstracts out communication based on Java interfaces, the remote banking software's business logic needs to know only the available Java interfaces, not implementations of those interfaces. For instance, to dispense cash from an ATM, the remote banking software would invoke the ATM service's dispense() method.

As a result, Rubean's architecture does not require a remote application server to be aware of specific devices in each branch office. Instead, a crucial aspect of Rubean's architecture is that device control is a presentation-layer responsibility: a banking device, for instance "presents" some business operations or its view, much as a display presents the view of an application's user interface. Thus discovery and use of the actual device service—an implementation of the Jini service interface—occurs in the application's presentation logic, and is performed entirely on the client.

Rich Java UI clients, such as Swing or the Eclipse Rich Client Platform, can use the standard Jini discovery and lookup mechanisms to locate nearby devices dynamically. For HTML front-ends, however, Rubean developed a JavaScript bridge between their service beans and the Jini discovery and lookup mechanisms: the DRubeans Device Access Node, or DAN. DAN comes with a JSP tag library, making device access and dynamnic Jini discovery and lookup possible by placing DAN JSP tags on a Web page. DAN JSP tags can also be used in conjunction with additional client-side JavaScript, such as those used in AJAX applications.

Figure 5: Device access from the application server

Decentralize and save

Many traditional enterprise architectures center around the notion that centralizing resources reduces costs. For instance, having one user directory in an organization is more cost effective than managing numerous departmental directories. Or, having a large document repository in an enterprise data center is more economical than storing documents on a myriad of office servers. The logic behind this notion is that having one administrator for the centralized resource is not only cheaper than having to manage the multitude of resources, but also produces fewer errors, misunderstandings, and security risks.

But the assumption behind that logic is being questioned by novel and innovative architectures. The assumption is that the administrator is a human. Paying people costs a lot of money, but the situation might be different if administration of distributed resources is completely automated. Such high levels of administrative automation are behind architectures that have proven to scale to very large numbers of users with only marginal increase in costs. Google, for instance, is known to prefer many inexpensive servers to a few pricier and beefier ones, thanks to a server management system that allows for a ratio of one administrator for every few thousand servers.

Rubean's architecture has also proven that decentralizing device management can save money. Automated service installation and Jini discovery at the branch level allows for a completely decentralized device management environment. Rubean's customers no longer have to manage a large centralized database of devices and device settings. Instead, each device publishes its availability and settings though their Jini service proxies.

Since devices in a branch office are of use only inside that office, limiting their dynamic discovery and use to clients within the branch is preferred. This also enables the central application server to remain completely ignorant of the specific devices available in each bank branch. The J2EE application logic can, instead, focus on device types represented by Java interfaces and Rubean's device beans.

In addition, while traditional enterprise architectures consider centrally located resources -- such as an application server, a database server, or a file server -- as services, Rubean's architecture extends the service notion to devices on the network's edge. It enables an ATM machine, for instance, to offer services on the network, and even allows an application server to become a client of that service.


Rubean's distributed device management architecture has been in use in German and Swiss banks since 2002, with currently over 35,000 users. The decentralized Jini approach at first seemed counter to accepted wisdom, but at the end the system exceeded users' expectation in reliability and cost savings. In the words of Rubean's chief engineer, Anton Decker, Jini technology is not simply an architecture or an API, but forces a designer to adhere to realities of the network:

"You could build a conventional system that communicates with a socket or plain RMI... Jini is not so much an API ... but is really a philosophy that describes a model for distributed objects that you have to fulfill to achieve a robust and reliable system. There is no other approach that's really addresses issues such as partial failure, self healing and stuff like that."


We would like to thank Richard Rupprecht and Anton Decker at Rubean for providing a description of their DRubeans system architecture, and to Sun Microsystems, Inc., for supporting this research.

Talk back!

Have an opinion about Jini technology? Discuss this article in the Articles Forum topic, Banking on Jini Services.


Rubean AG

Jini Community Web site

<<  Page 3 of 3

Leading-Edge Java | Discuss | Print | Email | First Page | Previous | Next

This article is sponsored by the Sun Microsystems, Inc..

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use