Java Expert Solutions

Peter Kitson

ISBN : 078970935x

Order a printed copy of this book from Amazon.

For your free electronic copy of this book please verify the numbers below. 

(We need to do this to make sure you're a person and not a malicious script)

Java as a Web Programming Language

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.

Java as an Applications Programming Language

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.