Dennis Govoni
Sun Microsystems Computer Company
dennis.govoni@Sun.com
I have a dream. This dream is that in the future, any device
that can be networked will be networked. I'm not talking about
the usual suspects such as desktops, servers, routers, switches,
and the like, I'm thinking about common everyday items we don't
think of as being network-aware. I have a dream that someday our
appliances, our houses, even our cars will participate in a
network. The manufacturer of your car will be able to monitor its
health and well-being, warn you if a problem is occurring, and
even schedule maintenance. Our whole approach to network
computing will change. The world will be more plug-and-play than
it is now. We will view the network much as we do the phone
system, with a "net tone" in place of a dial tone.
Network computing as
it is today is too complex. For almost fifty years, we have been
hamstrung by disk-oriented systems and software so complicated
that it is virtually impossible to debug, and the problem is
getting worse. Client-server computing, which promised to take
advantage of the power in the desktop, has suffered in many cases
from lack of understanding of the complexity of doing network
computing, lack of tools, long development cycles, and deployment
issues. Many companies have just not been prepared for dealing
with administration of their networks and network-based software.
But the current state
of computing mandates the use of networks. Businesses and
consumers are demanding more and more interaction with networks.
It is not just that our reliance on networks is becoming a
dependency, it is also that more and more devices are being
integrated into these networks. Pagers, digital cameras, and the
like already have network connectivity—and newer consumer
devices are being built with an eye toward network connectivity.
What I see is that more than half of future devices connected to
a network will not be PC-centric. The devices of the future will
require network connectivity, but they will also need to have a
simple way to be managed and to be able to enter and leave the
network in a seamless way. In essence, devices need to be simple
yet capable of playing in a complex networked environment.
Recently, Bud Tribble
of Sun Microsystems pointed out that as computer chips get
cheaper, it is possible to put them in all sorts of devices. He
further points out that the value of these devices increases as
they become networked. Your automobile will contain networked
components that will notify you of maintenance needs, even
recalls. Microsoft is also working on this "Auto PC"
approach (Haring, 1998).
Does this sound like
science fiction to you? You may be surprised, but this technology
is already here, albeit at an early stage. Four important drivers
are bringing this to fruition:
- The speed and number of different types of networks are
increasing.
- Systems are moving toward chip-level implementation,
making them more reliable and very cheap. Thus it is cost-effective
to put them literally everywhere.
- Object technology is now reliable and easy to implement
using Java.
- We are becoming increasingly dependent on network
connectivity.
The demon that
confronts this vision is that under the current technology,
massive resources are needed to add, delete, and maintain a
properly functioning network. As more and more services are
offered on these networks, it becomes an administrative nightmare
to manage and control them. The giant monolithic environments we
all "enjoy" are a terrible fit for the networks of the
future, which must be fluid and pliable to meet changing demands.
Often components that fail or are improperly configured have dire
effects on the running network. Complexity in these networks
gives administrators indigestion. Something needs to change to
simplify the building of these complex networks from relatively
simple components.
Just as the
Internet is constantly changing, so will user requirements. We
need a technology and methodology for allowing networks to be
constructed on the fly with new services that will need to be
reliable and constantly available. There will be a new generation
of devices and services that will look outward—that is, they
will be network-centric and capable of joining and leaving a
network in a straightforward, seamless way (Joy, 1998) without
disturbing the normal flow in the network.
The vision that
accompanies the preceding objective is that someday access to the
Net will be by anyone, anywhere, anytime, on anything. The goal
is to finally realize Marshall McLuhan's dream of "one huge
computer" (Kelly and Reiss, 1998). While we now know that
most computing devices such as PCs and workstations are the
primary approaches to accessing the Internet, we can expect their
usage rate will drop to around 50 percent as other devices become
network-aware. As previously mentioned, we are already seeing
phones, pagers, smartcards, kiosks, and even jewelry (Java™
Rings) being used as I/O devices to the Net. Much of this
activity has happened in the last five years as the result of two
inventions: Web-based technology and Java.
1993 was a turning
point in the history of the Internet, with the invention of what
is now known as the World Wide Web with the Mosaic browser, HTTP
protocol, and HTML. People who never knew what network computing
was all about were now enamored with "surfing the Net."
The whole character of the Net and its use changed overnight.
Once a research-only environment, the Internet is now a
commercially oriented venture. But the Web interaction then was
strictly of a static nature—that is, there was no way to
deliver executable content that interacted with the user, much
like a well-written program does. Therefore, it was necessary to
find some technology that would mimic a human being's natural
tendency to interact in a dynamic way. The first step in solving
this problem was the invention of an Internet-aware language now
known as Java.
In 1995, the Java
language was born. The basic concept behind this language was to
offer a platform-independent way to do computing on the Internet.
Java provided a way to move executable content from the Web to
the user, something the static nature of the World Wide Web did
not previously provide. For the first time, applications (called
applets) could be dynamically downloaded and executed in a user's
browser. The user did not have to explicitly request the code or
even reference a place to locate it. Network computing was now
becoming powerful. Developers could concentrate on building
network-aware applications without dealing with the complexity of
the underlying infrastructure or using low-level network
interfaces such as sockets and remote procedure calls (RPCs).
Java became the lingua franca of the Internet. And Java was an
object-oriented language, which meant that complex problems could
be viewed as a simple set of objects. From this simplicity,
complex solutions could be formed. All that was needed was a way
to make Java-enabled devices and software transparent to the
network.
So while users now had
a simple point-and-click approach to the Web via the browser, and
developers had an elegant language that was "net aware"
in Java, devices on the network that supported these technologies
still required a significant level of expertise to configure and
manage. Network computing was and is still too complicated.
Something needed to be done to make the network more user-friendly—so
services in the network could be viewed as simple objects that
could be plugged in and immediately available to the network and
its users, and so network services could be available on demand
and could seamlessly enter and leave a network without disturbing
it.
And so, in the summer
of 1998, Jini was born. In one sentence, Jini allows hardware and
software to be automatically identified to a network and allows
clients to easily locate and use these hardware and software
services. To do this, Jini is totally Java-centric—that is,
it relies on Java and the Java Virtual Machine.
Jini devices and
software will enter a network automatically and become an
integral part of a computing community using the underlying
networks as its nervous system. There is no single point of
failure in this community; as a device fails or leaves the
network, the community "self-heals." Jini should be
viewed as a system of services, not simply a bunch of devices and
software. There is no concept of a single computer, but rather
that of a set of services working in concert (Sun Microsystems,
Inc., 1998). The network does, indeed, become the computer. But
how does this actually work?
In today's world, a
similar function is fulfilled by providing access to devices that
are connected directly to a computer—disk drives, scanners,
multimedia devices, and the like. Jini allows these devices to be
disassociated from the shackles of a computer system and tosses
them out to the network. Physical location does not matter in a
Jini environment. It simply exists on the network.
The immediate
implications of this behavior are quite evident. First, it
drastically limits the amount of configuration and administration
needed. All the requisite code to interact with and properly
access the device (or software, if it is a program) is inherent
in the device or the software program.
Second, it means
devices only need two connections: one for power and one for the
network. Once the device is plugged into the network and powered
up, it begins a process of identifying itself and what services
it offers. With a software program, it would happen the same way.
That is, once the program is started, it begins to identify
itself and its services to the networking community. One
interesting implication of this approach is the blurring of the
distinction between hardware and software. From a user's
perspective it really doesn't matter; users are only interested
in using a service, not what the underlying implementation is.
They leave that to the developer.
The method by which
Jini devices and software join a network is quite straightforward.
Once a Jini device is activated, it requests attention from a
lookup service running on one or more servers. A lookup service
provides a central repository where services can be registered
and found. The beauty of this approach is that there can be many
replicates of the lookup service in the network, thus providing
redundancy and fault resilience. Once a Jini device has
registered, it will pass any Java code that will be required by a
client application of the lookup service to communicate with that
device or program. So when a client enters the network, the first
thing it will do is query the lookup service for a list of
services that are available. Once it finds the service it wants,
the code to interact with that device or program will
automatically be downloaded. There will never be a need to
preload device drivers or machine-specific code.
With code and data
describing a device's capabilities able to move freely about the
network as Java objects, all the basic ingredients for
spontaneous networking are now available. Devices can interact
with one another. For example, a camera may be ordered to take a
picture and then send it to a specific printer. The camera would
simply use the lookup service to find the printer and use the
Java code the printer identified to the lookup service. No
special driver code is needed by the camera to do this.
An analogous process
is building a table. To build a table you need certain tools.
When a hammer is needed, you simply retrieve one. When you are
done, you no longer need it. Users obtain "tools" (Java
code for devices) when they need them and not before. Every
device has its own set of tools that a user will retrieve when
the device is selected. The tools are provided in the device by
the manufacturers of that device, since they are the designers.
For example, printer manufacturers will provide Java objects for
interacting with their printers and disk manufacturers will
provide Java objects for their devices.
For network
administrators, this method of providing "tools" means
Jini devices can be easily added to and removed from the network
without complex procedures and without a negative impact on the
network. Management of devices becomes simpler because each
device contains enough information to be self-managing; hence we
have the notion of building a complexity of services via the
simplicity of Java-oriented devices.
While Jini seems like
an excellent answer for building complex networks from simple,
object-oriented components, Jini devices still require the
developer of that product to build the Java components that will
allow clients to use it. The burden falls on the developer, not
the users, but that is nothing new. Developers must provide the
interfaces to their devices via Java code. So a printer
manufacturer will need to provide Java methods for printing,
error notification, resolution, and whatever else is needed to
properly interact with their printer. With this approach, no one
need install a printer driver from a disk or CD-ROM ever again.
It can simply be obtained from the lookup service after the
device has registered itself.
While this technology
has the potential to be ubiquitous, what value does it have in
the field of education? First, we should recognize that the use
of networked-based computing is growing at all levels of
education. Universities in particular want to reach more and more
students in nontraditional ways. Use of the Internet and its
technologies play a large part in these plans. The idea of a
virtual university, venue independent, for students not able to
physically be on campus has emerged at the University of Colorado,
the Virtual Online University (aka Athena), and Washington State
University, to name just a few.
Imagine Jini devices
carried by students who will plug them into a network and
instantly become part of a virtual classroom. Visual aids used in
teaching can be easily added and removed by the instructor as
needed. Even coursework can be objectified such that it becomes
"Jini-aware" and part of a virtual classroom. One
example might be a music appreciation class. The music CDs would
be loaded into a Jini-enabled CD player, which would then
identify the selections to the network. Jini-enabled software
would monitor where each student is in the course and what
selections he or she has used. In this way, the content of the
course could be more tuned to each student's particular needs.
While this could also be done with other current technology, Jini
makes it easier to develop network-aware educational experiences,
which can be plugged into the network and become immediately
available. No special administration of a Web site is needed;
information just shows up in the lookup service.
As a result of Jini,
we can expect development of a more dynamic educational
experience for students and the means to allow students access to
that experience anytime, anywhere by plugging their client
devices into the network. What will these client devices be? Well,
they can be anything that will interact with the Jini device. In
our music example, they might be Jini-enabled headphones that
would identify each student with a simple input device for
accessing the selections on the CD player that he or she needs to
hear. For chemistry or biology students, they might be devices
for monitoring the status of experiments in a lab across campus
from the dormitories.
One very simple but
powerful way Jini could be used is in mobile computing, where
students could read their mail by simply plugging into the
network and being instantly identified. (This technology could
also be wireless.) The client device could be a Jini pager or
display phone or PDA. The concept behind all of this is "spontaneous
networking," gaining access anywhere, anytime, on anything.
Why should Jini matter
to you? Think of how much networking and administrative costs
have risen in recent years and how much duplication of effort
there is, particularly in client-side software. Jini may also
help reduce costs by avoiding the problem of obsolescence of
equipment. How? As an example, a 486 PC could be used to access
Jini services without that PC needing 40 million lines of code on
it to use the network and services. It would need only to have a
Java environment with a Jini client code that could use the power
of the Jini devices on the network. This approach should help to
greatly reduce the cost and complexity of maintaining a
distributed computing environment that is only getting more
complex.
We are, of course, at
the beginning of this journey; the landscape for Jini will emerge
over the next few years. Suffice it to say that some thirty large
corporations are already building Jini devices, which we will see
in the near future. Jini software requires only the imagination
of the developer to implement it. I expect to see many innovative
solutions not only in the corporate world, but also in the
educational arena, where many new ideas are spawned. Jini proves
not only that "the network is the computer," but that
the network is whatever is on it.
References
Haring, B. "Coming Soon: Cooperating Appliances." USA
Today Tech Extra, Oct. 7, 1998, p. 5D.
Joy, B. "Jini Keynote Address." Internet Week,
Fall 1998.
Kelly, K., and Reiss, S. "One Huge Computer." Wired,
Aug. 1998, p. 122.
Sun Microsystems, Inc. "Why Jini Technology Now?" Sun
White Paper, Revision 1.0. http://www.sun.com/jini/whitepapers/whyjininow.html.
Aug. 1998. |
