by Mark Wutka
Because this book assumes that you already know how to program in Java, you already have a good idea of what features are in the Java language. This book will notteach you how to program in Java; it takes the next step byshowing you what you can do with Java and how to do it.
Much of the initial appeal of Java comes from the fact that it can be embedded in Web pages. It allows you to go beyond the static nature of Web pages by making your pages come alive.Using Java's Abstract Windowing Toolkit (AWT), you can create interactive forms that go beyond the simple act of filling in abunch of fields and clicking the Submit button. You can perform error checking on forms, provide context-sensitive help, even give the user suggestions or examples. Some of these things you can do without Java, but not as quickly.
Java allows you to improve the interaction between the client and the server. The HTTP protocol, the native language of the World Wide Web, is very specific and somewhat restrictive as far as the interaction between the client and server. Whenever a client needs to send data to the server, it must open up a network connection, send a set of headers and the request data, and then sit and wait for a response. The server has very few options for sending data to a client. It must wait for the client to send it information, and the only option it has for sending back multiple responses is the "multi-part" message, in which the server sends part of a response, and then later sends more of the response. Given the static nature of Web pages, this has always been considered acceptable. Also, because the network connection is closed after a server has sent a response back to the client, there is no notion of a session within HTTP. Clients and servers have had to come up with their own interesting ways of maintaining session information between requests. The Netscape Cookie protocol is one such method.
The server puts Netscape cookies in a Web page when it sends information back to the browser. The pieces of information are tagged as being cookies, which the browser watches for and saves for later use. The next time the browser accesses that server, it sends the cookies back to the server. This allows the server to save information at the client-side and then receive the information at a later time. Cookies are discussed more fully in Chapter 6 "Communicating with a Web Server."
When you are writing serious applications, however, you need the interaction between client and server to be much more flexible. A client should be able to send information to a server at any time, and the server should be able to send data back to the client at any time. Java's networking support allows you to do this by creating a socket connection between the client and the server.
Look at an example of a real-world application and see how Java can improve yourapplications drastically.
Suppose you work for an airline and you are creating a program to display the current position of any of the company's aircraft. You would like this program to run on any Web browser within the company. Your server will be gathering aircraft position data and sending the information out to the browsers. You obviously want this to be a graphical program-you don't just want to list coordinates. You want the president of the company to be able to see immediately that flight 1313 is halfway between Cleveland and Detroit, without having to estimate its distance based on the latitude and longitude shown on some chart.
If you were to do this application using the traditional Web server and HTML forms, your server would have to generate entire images and send them to the client. Anytime a plane's position changed, you'd have to generate new images for each client that was watching that plane. Even if a plane's position changes once a minute, if you watch ten planes, you'll be receiving an average of one image every six seconds. That's an incredible burden to place on your server.
Now, suppose you were to create the same application in Java. The Java applet would download a blank map from the server and then open up a socket connection to the server. Anytime the Java applet wanted to watch a new plane, or stop watching a plane, it would send a message to the server. The server would track what clients were watching what planes. One of the keys here is that the connection between the client and the server stays up. This allows the server to keep track of clients based on their sockets. Now, suppose the server receives a position update for a plane. It looks through its tables and finds every client that was watching that plane and sends the new position down to that client. It does not have to perform any image generation. The amount of data sent to the client is probably 100-1,000 times smaller than the image that would be sent under the previous architecture.
The Java applet is responsible for creating the new image of the aircraft. Although this may take a little longer to generate on the client than on the server, the server is able to handle many times more clients than it otherwise would, because it doesn't have to do as much work for each client.
If you step back and take a look at this application, you'll see that the applet is really just implementing the user interface for the flight tracking system. The bulk of the work in gathering the flight data and analyzing it is done by the server. The interaction between the server and client is a clearly defined set of actions. The client starts watching a plane, the client stops watching a plane, the server sends a flight position to the client. That'sa pretty simply protocol! The client does what it does best-it interacts with the user. The server does what it does best-it gathers and analyzes information.
Keep this in mind as you design and develop new applications. Don't heap all the work on the applet, just let it do what it does best-interact with the user.
Realizing that applets are going to need a reasonable way to communicate with the actual applications, Sun added two important subsystems to Java. Remote Method Invocation (RMI) allows a Java object to invoke methods in another Java applet somewhere else on the network. You don't have to come up with your own way of transmitting data between the applet and the application on the server. The applet can simply invoke methods on the server using RMI.
RMI is a nice feature, and is very easy to use since it blends into your applet and application almost seamlessly. There is another way to invoke methods remotely, however.It's called the Common Object Request Broker Architecture, or CORBA. There are many differences between RMI and CORBA. One of the biggest is that CORBA is a multi-language protocol. You can use CORBA in an applet to invoke methods in a C++ application running on your server.
You will be able to choose between RMI and CORBA for your applets. They will both be supported as part of the core of Java. You can expect both mechanisms to be present in a Java-compliant Web browser, or any Java-compliant environment.
It's unfortunate that Java has gotten the reputation of being solely a Web programming language. It is a full-fledged application programming language. It contains all the features you need to write some pretty hefty programs-and they will all run on any system that runs Java!
Java is young and is still experiencing growing pains. One of
these pains is the fact that although Java runs on multiple platforms,
it doesn't quite run exactly
the same on every platform. Most of the time, these differences
are in the implementation of the AWT, causing the problems to
appear more often in applets than applications (unless you're
creating a graphical application, of course). Because most people
see only the graphical programs, the platform-to-platform variations
in Java look worse than they actually are. The Jigsaw WWW server,
discussed in Chapter 25, "Writing Web Services for Jigsaw,"
is written entirely in Java-over 30,000 lines! It runs very well
across all Java-enabled platforms.
The big difference between a Java application and a Java applet
is the lack of security restrictions. Java applications are given
free reign over the system (although they can't get around the
operating system's security). A Java application is free to open
a socket connection to any host it wants, open any file, and create
its own custom class loaders. If you have been banging your head
against a wall because you couldn't do these things in an applet,
you might be tempted to turn your applets into applications (in
other words, make them stand-alone) so you can have all these
features. That is, of course, your choice. But you should seriously
consider keeping the user interface and the application separate.
For some quick hack program that isn't very significant, it probably
won't matter. However, if you're writing a big commercial application,
it does matter. There are many advantages to being able to run
applets in a browser; one of the biggest advantages is that the
browser performs automatic software distribution for you. You
don't have to install the applet on a system ahead of time in
order for someone to use it. If you start writing everything as
a stand-alone application, you fall back into the old trap of
trying to maintain a program on a large number of machines.
Java's database API, called JDBC, is a boon for application programming.
You now have a standard interface for accessing a relational database.
JDBC frees you from being tied to a specific database API, meaning
you not only can create cross-platform applications, you can also
create cross-database applications.
Java is a great language for handling little ten-minute hack programs,
as well. You have immediate access to an excellent set of libraries
that handle many tedious functions that you won't find in the
standard library set of C or C++. You can buy these libraries
for other languages, of course, but why bother if you get them
free with Java? You may soon find that you are writing Java programs
when you previously wrote C programs or Perl scripts.
While the Java language itself will remain fairly static for now,
with only a few additions, the available APIs for the language
will be growing at a rapid pace. The original APIs that came with
Java were enough to generate great interest in Java. Now, as more
and more companies use Java for serious work, they are discovering
areas that Java hasn't addressed up to now.
Multimedia has become a hot topic on the World Wide Web. You can
now use your Web browser to view animated news clips, listen to
samples of new record albums, and even make video telephone calls
halfway around the world. Java's support of multimedia has been
minimal, so far, but that is being addressed. You will soon see
a flurry of new multimedia APIs for Java. These APIs will provide
improved audio service, full-motion video, 2-D and 3-D graphics,
and even telephony. The APIs will really help level the playing
field when it comes to selecting a platform for running your programs.
You will be able to count on having these services available on
whatever platform you choose, whether it be Windows, UNIX, or
Mac.
In the area of audio, you will be able to synchronize your audio
a little better, allowing you to create animation that is in sync
with the audio. You should also be able to support varying sample
rates. Most important of all, you will be able to find out when
an audio clip finishes playing. This is one of the most glaring
omissions in the current API. You can't even create a simple music
jukebox under the current API, because you never know when to
start the next piece of music.
The video API will allow you to display video clips in different
formats, and even synchronize them with the audio. Rather than
sticking to a single video format, the video API allows you to
plug in different kinds of video handlers. You could support MPEG
and QuickTime, for instance.
The 2-D API provides a rich set of drawing routines that is badly
needed. The Graphics class
in the AWT provides only the most basic drawing features. You
will be able to perform complex pattern fills with the new API,
for example. There will also be an API for doing sprite animation.
Sprites are essentially graphical objects that move around the
screen. You can do something similar right now, but you have to
write all the animation and redrawing code yourself. The sprite
API will take care of that for you, and will do it in a much more
efficient manner. This should result in a lot of neat new games
for Java, many approaching the capabilities of some home gaming
systems.
You will be able to create interesting new effects with the 3-D
API. There will be support for simple 3-D objects, as well as
animated 3-D objects, and even some of the features you now find
in VRML systems. Again, since these are part of the native Java
environment, they should be very efficient.
The telephony API addresses the growing integration between the
telephone and the computer. Essentially, the telephony API is
a mechanism for placing and receiving phone calls. You may need
special hardware to interface with the actual phone equipment,
but eventually you'll be able to redirect phone calls over your
home network to whatever device you happen to be near, whether
it is your WebTV, your PDA, or your old desktop computer.
Network management is another important topic, especially at large
companies. Right now, many operating systems and most network
devices support the SNMP network management protocol. There are
a number of tools available for configuring and monitoring SNMP-enabled
devices. The JavaManagement API will allow you to create new programs
for monitoring network devices. You will be able to monitor SNMP
devices, or plug in your own protocols to manage devices using
other network management protocols. The advantage here is that
you will be able to take advantage of Java's ease of use, and
create network management applications that will run on any Java-enabled
platform.
One of the most exciting new Java APIs to come along is the Beans
API. Beans is an API for creating and using software components.
One of the dreams in software development has always been that
software components could be used like electronic components.
When you buy electronic components, they have a standard interface.
Many times, the same kind of component is offered by a number
of vendors, giving you freedom of choice. You can create an electronic
board by looking at the specifications for the components and
designing the board. Once you finally assemble the components,
you have an excellent chance of things working as you had planned.
In the software arena, this is rarely the case. Beans doesn't
necessarily solve this problem, but it brings you one step closer.
The philosophy behind the Beans API is that you have a nice development
tool for creating new applications. In a way, it's like your workbench.
You buy software components from different companies, and each
component is a bean. You add the beans to your development tool,
and the tool uses the Beans API to find out what interfaces each
new bean supports. In addition, the Beans API defines mechanisms
for customizing a bean.
For example, you might buy a nifty new pushbutton bean and add
it to your graphical development environment. Your graphical environment
presents you with a visual toolkit of all the beans you have.
You could select the pushbutton and drag it onto your new application.
Next, you could pop up a configuration menu that allowed you to
customize the pushbutton. The Beans API uses a new Java feature
called reflection to discover the parts of the bean that can be
customized. As an alternative, you could supply your own customizer
for a bean.
If you think you can do a lot with Java now, imagine what you'll
be able to do when these new features become available.
The ability to run programs inside small devices like cellular
phones and PDAs (Personal Digital Assistants) is one of Java's
best kept secrets. Sun, and other hardware manufacturers, realized
that Java's virtual machine could easily be implemented in silicon
and placed in a wide variety of devices. Already, companies have
created cellular phones and PDAs that run Java. In fact, Java
itself came from a project that created a small handheld device.
One day, you may have a refrigerator that runs Java. What would
that mean to you? Probably nothing, unless it makes you play Tetris
in order to use the ice maker. The toaster has always been the
appliance that everyone wants to connect to the Internet. Yes,
someone has demonstrated a Java-enabled toaster. In fact, Sun
has considered changing its trademark phrase "The Network
Is The Computer" over to "The Toaster Is The Computer."
Okay, not really. Still, if things continue in the direction they
are going, you will have more and more pieces of equipment in
your house that run Java. This can be upsetting to an application
designer who is accustomed to thinking of the desktop as the sole
realm of applications.
This is where the notion of separating the user interface from
the application really becomes important. You can't cram some
behemoth of an application into a cell phone. You shouldn't even
try. Take the flight tracking system as an example.
Suppose the airline president handed you his Java-enabled organizer
and said, "I want to see flights on this thing." Fortunately
for you, you separated the application from the user interface,
so all you have to do is create a special user interface for the
organizer.If you had written the flight tracking system as a big
stand-alone application, you would have already torn your hair
out in big clumps trying to figure out how you were going to fit
all that code into an itty-bitty living space.
You may, in the future, have a completely different computing
model at home than you do now. Right now, you probably have a
single computer, a printer, a monitor, and a modem. Some of you
even have your own ethernet networks now. In the future, you may
have an application server on which all your favorite programs
reside-your e-mail system, your word processor, and yes, your
favorite games. This server may not even have a keyboard or a
monitor, just a connection to your home network. On your desktop,
you might have a Java-enabled monitor and keyboard that are also
hooked to the network. In the living room, your Java-enabled television
is also on the network. With the coming of digital TV and high-speed
networking to the home, there may no longer be a difference between
a computer monitor and a television. When you want to read your
e-mail, you can access it from the computer monitor, your TV,
or even your wireless digital assistant, all using your home network
to access the e-mail application running on your home server.
You may not even have a server at home-you might subscribe to
an e-mail service over the network and access a server somewhere
in Tuscaloosa. The point is that there are more and more ways
for you to interact with computer systems, and in the future,
one single way will no longer be sufficient.
As you design your applications, keep the image of a cell phone
or a personal digital assistant hovering like a dark cloud over
you, whispering menacingly, "Will your application run on
me?"
New Features on the Horizon
Java as an Embedded Systems Language