by May 1, 1999 0 comments

Zin.jpg (19632 bytes)Distributed computing is exciting.
Different components and objects comprising an application located on different computers
across a network, sometimes far apart, working together as one.

But implementing this remains a fine art, used only in
complex, often mission-critical situations. This is partly because the coding is complex,
and is often done in multiple-languages and operating systems. The programmers also have
to take into account problems such as network failures, communication issues, and the need
to react on the fly to altered or unknown networks.

Let’s look at the hardware side. Today’s networks
no longer use one type of hardware and OS. An ever-growing number of devices plug into
them, from cellphones to TV set-top devices, and of course, PCs. How do you ensure that
they work together on a network? For that matter, how do you make them even recognize each

The traditional method of making devices available on a
network has been to use device drivers. That’s device-specific, and OS-specific.

And what happens when a new device plugs into a network?
Each client must have the correct driver installed, to take advantage of the new device!
So if you connect your cellphone to this network, and want to use a printer, then you have
to install drivers for that printer on your cellphone. But chances are that the
right driver won’t be around…or that you won’t have the time or patience to
install and configure them.

     So what do you do?

     Send for Jini. Or Inferno.


Jini runs over Java and allows devices to connect and share facilities over a network, independent of OS or language. (Source is Sun’s
solution to the problem. It’s a service that resides on Java as a small bit of code,
and simplifies the connection and sharing of devices on a network. These devices cover a
wide range, from printers to digital cameras and cellphones, and have to be
“Jini-enabled”. When Jini is enabled on a network, the device will announce
itself to the network, provide its details, and immediately become accessible to devices
on the network, without the devices needing to boot up and load any drivers–and
without extra cables or connectors.

Jini’s 48 kB of code can be embedded on a processor
and inserted into any device, from PCs to consumer appliances. The software works by
exchanging snippets of code — applets — among devices. Jini can run on
any Java platform (PC, printer, server, et al). So any device that has the ability
to run Java will be able to access the code and data that passes among devices.

Devices and apps use a process called “discovery”
to register to the network. Once registered, the device or app places itself in the
“lookup service” (a sort of bulletin board for all services on the network). The
service stores not only pointers to the services on the network, but also the code to use
these services.

The software agent in Jini communicates through a protocol,
to look up services available on the network. When a Jini-enabled device leaves a Jini
system (by being removed or by becoming unreliable), its services are deleted from the
lookup service.

For example, when a printer registers with the lookup
service, it loads its drivers in there. When another device wants to use the printer, the
drivers get downloaded from the lookup service to that device. This code mobility means
that client devices can take advantage of services from the network without your having to
load the drivers or other software. And as Jini resides over Java, you’re OS

Jini uses “leasing”. When a device joins the
network, it registers for a certain leased time. When this time expires, the device can
re-negotiate the lease. If the device is removed from the network before the lease
expires, the device’s entry in the lookup is removed, and the lease dies anyway.

Coming back to our original analogy of distributed
computing, it’s easily possible to create distributed computing apps, and share
facilities among machines, on a common network with Jini. For Jini is aware of resources
on the network, and makes access to them easy. Jini would allow users to access the power
and features of any device or app on the network and would free the client from
unnecessarily blocking memory, storage space and processing power.

For example, if a disk drive on a network had Jini
capabilities, any computer on that network could use that drive. With Jini, you can easily
access your home appliances or connect to your office network while on the road. Users can
create their own “personal networks” no matter where they are located.

Jini uses the Java remote method invocation (RMI) to
communicate between the devices on the network. RMI allows not only data to be passed from
object to object around the network, but also the full objects themselves, including
programming code.

Sun plans to offer Jini in a community source code model in
August this year. This code would be free for software developers into research, or using
Jini for their own internal deployment. For more information, visit


Unlike Jini, which is a service on Java, Lucent’s
Inferno is a distributed OS that adapts to whatever you plug into the network — from
workstation to a palmtop. Built on “InfernoSpaces” technology, it lets two
network devices talk to each other regardless of the OS or language.

Inferno has a highly portable micro kernel, runs on minimal
hardware, and is supposed to have a simple, universal, and multi-threaded interface. The
biggest asset of this operating system is that it requires only 4 MB of RAM and 4 MB of
ROM. This is due to its distributed nature and allows an application to be split between a
client and a server. Thus, the software can run on the client with only 25 percent of
memory it would require otherwise.

Inferno can run independently, and also on Windows and
Solaris, on x86 or Sparc hardware platforms. It supports apps written in C, C++ and Java.

Inferno is designed to be a part of the network
infrastructure. In it, every resource, whether a database or a remote computer, is
accessed as if it were a file in a traditional hierarchical file system (such as
Unix’s). Thus, one filesystem accesses everything from data to network resources.

All Inferno services are joined in a single private
hierarchical name space and the Styx communication protocol is used to access all local
and external resources. Styx can run on top of TCP/IP, PPP, and ATM. So it can be deployed
across networks, easily.

Limbo is the portable programming language of this OS.
Limbo connects all the resources to the "garbage collector" (a sort of memory
flush). If an application dies, the OS doesn’t have to bother to reclaim the memory
reserved for it: this happens automatically. And this cuts down the amount of memory
required on the system.

Inferno has drivers for audio and speech applications.
It’s also compatible with software modem technology, so you wouldn’t need modem

The OS has been designed to run on multiple platforms
– from TV set-top boxes to routers. It can support communication over telephone
links, the Internet, enterprise- and satellite broadcast networks.

The software is expected to be available in the third
quarter of the year, free. A beta is available at

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.