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?"
