Jini provides an open solution for network interoperability issues in a distributed computing environment.This means that Jini does the following:

• Finds and connects services on a network
• Creates reliable sets of services out of unreliable parts, including the network itself
• Deals with networks that are very large or last a very long time
• Enables components of a service to change at any time without interrupting the service.

Jini network technology is built on the Java platform and provides an infrastructure to deliver services to devices within a network, regardless of connectivity, wire protocol, and transport protocol.

The nuts and bolts of Jini

As mentioned above, Jini is designed to provide spontaneous networking, allowing users to plug almost any Java-enabled device (that is, any device whose operating system supports Java applications) directly into a network with all components of the network instantly aware of the new device and its capabilities. If the new device is a printer, for instance, other computers in the Jini network will immediately be able to find and use that printer.

By using objects that move around the network, Jini architecture means the network as a whole, along with each of its individual services, will be adaptable to change. Jini architecture specifies a way for clients and services to find each other on the network and to work together to accomplish a task. Service providers supply clients with portable Java technology-based objects that give the client access to the service. This network interaction can use any type of networking technology, such as RMI, CORBA, or SOAP, because the client sees only the Java-based object, with all subsequent network communication confined to that Java object and the service from which it came.

When a service joins a network of Jini-enabled services and/or devices, it advertises itself by publishing a Java object that implements the service API. This object's implementation can work in any way the service chooses. The client finds services by looking for an object that supports the API. When it gets the service's published object, it will download any code it needs in order to talk to the service, thereby learning how to talk to the particular service implementation via the API. The programmer who implements the service chooses how to translate an API request into bits on the wire using RMI, CORBA, XML or a private protocol.

Back to top

Challenges of Jini in PvC

Let's now look at the problems posed by using Jini in wireless devices, especially those caused by embedding Jini technology in mobile devices. First, Jini technology requires a full Java 2 Standard Edition (J2SE) virtual machine (VM) to be present on the device -- a difficulty which is compounded by the lack of a standard wireless networking technology for these devices.

To help overcome these problems, a surrogate Jini architecture has been created. Under the surrogate Jini model, a mobile device delivers code to the surrogate host, which then performs the regular Jini connection activities such as registering and using services on behalf of the device. A printer, for instance, could locate a surrogate host and deliver code in order to register a printing service on behalf of the printer. Likewise, a digital wireless camera could use the same surrogate host as a means of locating the printer and printing out a picture.

Back to top

The Jini surrogate solution

The Jini surrogate project defines an architecture that allows devices that otherwise wouldn't be able to participate in a Jini network to do so. Most mobile and wireless devices fall into this category, specifically those used for PvC. It involves bridging the device and its environment with one object capable of interacting with the Jini network. To do this, an object (or surrogate) is created to act on behalf of the device. The device finds a surrogate host in its "native" network environment and registers with it, providing the surrogate host with either a JAR file or the location of a JAR file. The surrogate host instantiates a surrogate object, which is obtained from the JAR file. The surrogate object then becomes the device's representative on the Jini network.

Wireless connections are not noted for their stability. With surrogate architecture, if connections come and go, the surrogate object can remain active, maintaining information regarding the current session and playing an active role on behalf of the device in the Jini network. As different CDC devices become available, a surrogate specific to them can also be programmed.

The following are the advantages of using a surrogate Jini architecture:

• Use of gateways to interconnect various devices (therefore suitable for PvC computing)
• Jini surrogate host for legacy devices;
• Local caching;
• Single entry point to Internet (broadband WAN, lower bandwidth to local devices);
• Firewall for local devices (high security); and
• Wide industry adoption (OSGi -- see http://www.osgi.org -- Espial, Echelon).

All these advantages make Jini surrogate architecture well-suited for PvC computing, where the common attribute of the hardware or software components targeted by this architecture is the inability to download code, due to either resource limits on the device or network connectivity limitations (as in wireless networks). Following are the fundamentals of the Jini surrogate architecture in wireless PvC.

Device type independence: The surrogate architecture must be able to support a wide range of hardware and software components with different capabilities. A device like a cell phone cannot directly use Jini because it does not have the resources to support a full J2SE virtual machine.

Network type independence: The surrogate architecture must be able to accommodate a diverse range of connectivity technologies. Network type independence includes support for different protocols simultaneously on the same physical transport.

Preserve plug-and-work: The surrogate architecture must preserve the plug-and-work model of Jini technology. Jini architecture includes the concepts of discovery, code downloading, and leasing of distributed resources. This principle assumes existence of a machine that is connected to both the lightweight device and the Jini network to overcome limitations such as not being able to download code.

Back to top

Additional PvC-suitable architectures derived from Jini

Here are some recent Jini projects undertaken to tailor Jini specifications to particular implementation needs.

Project Jump (addresses P2P networking)

Project Jump's goal was to create a new methodology of discovery and resolution for P2P, or point-to-point communication. This required a name server using a system of "natural language addressing" based on specifications, which has since been adopted by JXTA (see Resources) and an application gateway to provide a method of proxying private addresses. The project stalled without a solution, probably due to the JXTA project introduction. Details on using JXTA with J2ME can be found at their site.

Edge Networking (allows devices to communicate regardless of protocol)

Edge Networking allows all the devices located at the edge of networks, whether on LAN/WAN or through a dial/DSL connection, to be networked together. Edge Networking allows these devices to be easily discovered using natural language and allows inbound connections to these devices across traditional network boundaries. Edge Networking is transport protocol-independent, which allows application developers the flexibility to use JXTA, HTTP, SIP, or any other protocol to communicate.

Davis Project (addresses various aspects of security in JINI architecture)

The JINI Davis Project focused on support for several points to do with security architecture, including non-uniform network security (variations involving client, server, remote method, and parameters) and a variety of security implementations with differing protocols, algorithms, mechanisms, and policies.

Edge Zucotto Xpresso (commercially available JINI solution)

The commercial version of the JINI surrogate architecture is designed to enable even simple devices to make use of and provide Jini services, but the greatest benefit is obtained when using a device that is capable of running Java applications, such as a cell phone with an embedded Zucotto Xpresso Java-native processor.

Bluetooth (overcomes protocol differences and device awareness)

Bluetooth wireless technology provides a way for mobile devices to discover and communicate with other nearby devices. As new devices are brought into range and established devices are taken out of range, each device is kept aware of the other devices in its neighborhood. Such dynamic, impromptu networking is the perfect complement to Jini connection technology, which is designed to perform well in such situations meeting the requirements of the Jini surrogate architecture.

JINI with J2ME (overcomes limitations by treating devices as objects)

Currently, limitations exist for using Jini in CLDC wireless devices. With the implementation of the Jini surrogate project, Jini is being extended specifically for J2ME. Imagine using your J2ME device to participate in an online transaction, for example. As you move from location to location, you meet different people and find different items (clients). All this interaction occurs with your own transaction object, an object that is really your interface to this world -- an object you control from your J2ME device. When a transaction is undertaken, a billing service finds you, recognizes when you began playing, and starts to charge you accordingly.

The advantage of having devices as unique objects in the Jini network is to increase the set of interaction semantics. In a portal model, device login and registration might appear identical from the device's point of view, but other services see the portal, not the individual objects.

Back to top

JINI-RMI approach (another way to overcome device differences)

Client A sends a multicast request to Lookup Service; and in the same way, Service B sends a multicast request to Lookup Service. The Lookup Service responds with a marshaled Lookup Service proxy object to Client A and to Service B; Service B sends a ServiceRegistrar.register() request to Lookup Service. Lookup Service responds with registration. Client A makes a ServiceRegistrar.lookup() on Service B, Service Lookup responds with a Service B proxy object. Client A directly sends the method on to Service B, and Service B thereby responds to Client A.

When Jini is used on small devices, the Service B residing on a small device faces a problem, since it cannot unmarshal the Lookup Service proxy object. That leads to a "pretend" Lookup service interaction with Client A. Client A calls ServiceRegistrar.register() which then returns a Service B proxy object. That means the device does its own Lookup Service and all the Jini discovery protocols; a Device Service Lookup Service proxy object runs entirely on a local client.

Back to top

JINI and the future

As you can see, all of the particular implementations of Jini networking attempt to provide services that address specific solution needs, especially those concerned with the limitations of devices participating in a Jini network interaction.

Certainly, device limitation is a particular concern for the mobile world. The current standard cannot implement full-scale Jini and, therefore, in various projects a workaround has been established. The many variations on Jini architecture, from the Jini-RMI implementation, to Bluetooth's meeting requirements for surrogate Jini architecture, to the Davis project's security enhancements, to Jini architecture, tell us that Jini is not only here to stay awhile, but may prove to be the wireless key PvC has been needing. With Jini at hand we'll be able to meet the goal of enabling various devices on networks to create a true community of users..

Resources

• You can find more information on JINI networking technology here.
  
  
• Visit the resource page for everything about Jini.
  
  
• See Roman and Vivek's recent article on PvC architecture.
  
  
• Get full information on the project for Surrogate Architecture.
  
  
• Likewise, get all the information on Project Jump.
  
  
• Get full specs on Reverse Port Address Translation, or RPAT.
  
  
• Project JXTA members continue to enhance this cutting-edge platform.
  
  
• See the full specs on the Davis project for JINI security.
  
  
• Have a look at another chart that lays out the Jini / J2ME / Java2 technologies.
  
  
• Find the specs on the Jini PretendServiceRegistrar here.
  
  
• Go on to find the guide to Refactoring the Jini Lookup Service.
  
  
• Read over the specs on the Jini WirelessDevice Project.
  
  
• See also Jini Network Technology available on an aJile platform.
  
  
• The Artima.com site offers useful resources on Jini technology.
  
  
• Have a look at the Project JXTA site to get info on joining the project, aquiring downloads, and getting other useful material.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• The nuts and bolts of Jini
• Challenges of Jini in PvC
• The Jini surrogate solution
• Additional PvC-suitable architectures derived from Jini
• JINI-RMI approach (another way to overcome device differences)
• JINI and the future
• Resources
• About the authors
• Comments