Java Network Programming By Elliotte Rusty Harold 1st Edition February 1997 1-56592-227-1, Order Number: 2271 442 pages, $34.95

Java Network Programming

Chapter One: Why Networked Java?

Java is the first programming language designed from the ground up with networking in mind. As the global Internet continues to grow, Java is uniquely suited to build the next generation of network applications. Java provides solutions to a number of problems--platform independence, security, and international character sets being the most important--that are crucial to Internet applications, yet difficult to address in other languages. Together, these and other Java features let web surfers quickly download and execute untrusted programs from a web site without worrying that the program may spread a virus, steal their data, or crash their systems. Indeed, the level of safety you have with a Java applet is far greater than you get with shrink-wrapped software.

One of the biggest secrets about Java is that it makes writing network programs easy. In fact, it is far easier to write network programs in Java than in almost any other language. This book shows you dozens of complete programs that take advantage of the Internet. Some are simple textbook examples, while others are completely functional applications. One thing you'll note in the fully functional applications is just how little code is devoted to networking. Even in network-intensive programs like web servers and clients, almost all the code handles data manipulation or the user interface. The part of the program that deals with the network is almost always the shortest and simplest.

In short, it is easy for Java applications to send and receive data across the Internet. It is also possible for applets to communicate across the Internet, though they are limited by security restrictions. In this chapter you'll learn about a few of the network-centric applets and applications that can be written in Java. In later chapters you'll develop the tools you need to write these programs.

What Can a Network Program Do?

Networking adds a lot of power to simple programs. With networks, one program can retrieve information stored in millions of computers located anywhere in the world. You can communicate with tens of millions of people. You can harness the powers of many computers to work on one problem.

But that sounds like a Microsoft advertisement, not the start of a technical book. Let's talk more precisely about what network programs do. Network applications generally take one of several forms. The distinction you hear about most is between clients and servers. In the simplest case, clients retrieve and display data. More complex clients repeatedly retrieve changing data, send data to other people and computers, and interact with peers in real time for chat, multiplayer games, or collaboration. Servers respond to requests for data. Simple servers merely look up some file and return it to the client, but more complex servers often do a lot of processing on the data before answering an involved question. Beyond clients and servers, the next generation of Internet applications will almost certainly include intelligent agents that move from server to server, searching the web for some information and dragging their findings home. And that's only the beginning. Let's look a little more closely at the possibilities you open up when you add networking to your programs.

Retrieve and Display Data

At the most basic level, a network client retrieves data from a server and shows it to a user. Of course, many programs did just this long before Java came along; after all, that's exactly what a web browser does. However, web browsers are limited. They can only talk to certain kinds of servers (generally web, FTP, Gopher, and perhaps mail and news servers). They can only understand and display certain kinds of data (generally text, HTML, and a couple of standard image formats). If you want to go further, you're in trouble; for example, a web browser cannot send SQL commands to a database server to perform interactive queries. Java programs can do this and a lot more. Even better, a Java program embedded in an HTML page (an applet) can give a Java-enabled web browser capabilities the browser didn't have to begin with.

Java programs are flexible because Java is a general programming language, unlike HTML. Java programs see network connections as streams of data which can be interpreted and responded to in any way that's necessary. Web browsers see only certain kinds of data streams and can interpret them only in certain ways. If a browser sees a data stream that it's not familiar with (for example, a binary response to an SQL query), its behavior is unpredictable.

Thus, a Java program can connect to a network time server to synchronize itself with an atomic clock. A web browser cannot. A Java program can display the local time using the local machine's clock. A web browser cannot. A Java program can connect to an Oracle database to ask for the salespeople in the midwest region whose sales exceeded their quotas by more than 50%. A web browser cannot. Finally, a Java program can use the full power of a modern graphical user interface to show this data to the user. Although web browsers can create very fancy displays, they can only work with HTML.

Connecting to servers is easy. Java includes built-in classes that connect to other Internet hosts, using the TCP and UDP protocols of the TCP/IP family. You just tell Java what IP address and port you want, and Java handles the low-level details. Java does not currently understand Netware, AppleTalk, or other non-IP-based network protocols; but this will cease to be an issue as TCP/IP becomes the lingua franca of networked applications. Furthermore, release 1.1 of Sun's JDK (Java Development Kit) allows you to extend Java's network classes to support other protocol families. Doing so is beyond the bounds of this book, but I'll at least show you where Java is headed.

Once you've connected to a server, it is your responsibility to communicate properly with the remote server and interpret the data the server sends you. In almost all cases, packaging data to send to a server and unpacking the data you get back is harder than simply making the connection. Java includes classes that help you communicate with certain types of servers, notably web servers; it also includes classes to process some kinds of data, such as text, GIF images, and JPEG images. However, not all servers are HTTP servers, and not all data are GIFs. Therefore, Java lets you write protocol handlers that communicate with different kinds of servers and content handers that understand and display different kinds of data. By the time you read this, probably at least one web browser will be available that can automatically download and install the protocol and content handlers needed by a web site it visits. When the protocol or content handler is no longer needed, Java will automatically dispose of it so it doesn't waste memory or disk space. Protocol and content handlers perform a task similar to Netscape plug-ins, but they are much more convenient--they don't require user intervention to download and install the software, and they don't waste memory or disk space when not in use.

Repeatedly Retrieve Data

Web browsers retrieve data on demand; the user asks for a page at a URL and the web browser gets it. This model is fine as long as you only need the information once, and the information doesn't change often. However, continuous access to information that's changing constantly is a problem. There have been a few attempts to solve this problem with extensions to HTML and HTTP. For example, server push and client pull are fairly awkward ways of keeping a client up to date. There are even services that send email to alert you that a page you're interested in has changed.

See, for example the URL-minder at http://www.netmind.com/URL-minder/URL-minder.html.

A Java client, however, can repeatedly connect to a server to keep an updated picture of the data. If the data changes very frequently, like a stock price, a Java application can keep a connection to the server open at all times, and display a running graph of the stock price on the desktop. A Java program can even respond in real time to changes in the data. For example, a stock ticker applet might ring a bell if IBM's stock price goes over $100 so you know to call your broker and sell. A more complex program could even perform the sale without human intervention. It is easy to imagine considerably more complicated combinations of data that a client can monitor--data you'd be unlikely to find on any single web site. For example, you could get the stock price of a company from one server, the poll standings of candidates they've contributed to from another, and correlate that data to decide whether to buy or sell the company's stock. A stock broker would certainly not implement this scheme for the average small investor.

As long as the data is available through the Internet, a Java program can track it. Data available on the Internet ranges from weather conditions in Tulsa to the temperature of soft drink machines in Pittsburgh to the stock price of Sun Microsystems. Any or all of these can be integrated into your programs in real time.

Send Data

Web browsers are optimized for retrieving data. They send only limited amounts of data back to the server, mostly through forms. Java programs have no such limitations. Once a connection between two machines is established, Java programs can send data across that connection just as easily as they can receive from it. This opens up many possibilities:

File storage

Applet authors often want to store data between runs of the applet. For example, you might want to store the level a player has reached in a game. Applets aren't allowed to write files on local disks, but they can store data on a cooperating server. The applet just opens a network connection to its host and sends the data to it. The host may accept the data through CGI (the Common Gateway Interface), through FTP, or through a custom server (or servlet).

Massively parallel computing

Since Java applets are secure, you can safely offer the use of your CPU cycles to scientific projects that require massively parallel machines. When your part of the calculation is complete, the program makes a network connection to the originating host, and adds your results to the collected data. This wouldn't work without secure execution of code, two-way network communication, and platform independence.

Smart forms

Java's AWT (Abstract Window Toolkit) has all the user interface components available in HTML forms, including textboxes, checkboxes, radio buttons, pop-up lists, buttons, and a few more besides. Thus, with Java, you can create forms with all the power of a regular HTML form. These forms can even use network connections to send the data back to the server exactly as a web browser does.

However, because Java applets are real programs instead of mere displayed data, these forms can be truly interactive and respond immediately to user input. For instance, an order form can keep a running total including sales tax and shipping charges. Every time the user checks off another item to buy, the applet can update the total price. A regular HTML form would need to send the data back to the server, which would calculate the total price and send an updated version of the form--a process that's both slower and more work for the server.

Furthermore, a Java applet can verify input. For example, an applet can warn the user that he can't order 1.5 cases of jelly beans, that only whole cases are sent. When the user has filled out the form, the applet sends the data to the server over a new network connection. This applet can talk to the same CGI program that would process input from an HTML form, or it can talk to a more efficient custom server.

Peer-to-Peer Interaction

The above examples all follow a client-server model. However, Java applications can also talk to each other across the Internet, opening up many new possibilities for group applications. There is no fundamental reason why Java applets can't talk directly to each other as well, but this is not always allowed by the AppletSecurityManager and is not possible at all in Netscape. (You can get around this limitation by writing a custom server that forwards information from one applet to others; again, Java makes the job relatively easy.)

Games

Combine the easy ability to include networking in your programs with Java's powerful graphics and you have the recipe for truly awesome multiplayer games. Some that have already been written include poker, backgammon, Battleship, Othello, Go, mah jongg, Pong, charades, and bridge.

Chat

Java lets you set up private or public chat rooms. Text that is typed in one applet can be echoed to other applets around the world. More interestingly, if you add a Canvas with basic drawing ability to the applet, you can share a whiteboard between multiple locations. And as soon as a sound input facility is added to Java (probably in the first half of 1997), writing a network phone application or adding one to an existing applet will become trivial. Other applications of this type include custom clients for MUDs (multiuser dungeons), which could easily use Java's graphic capabilities to incorporate the pictures people have been imagining for years.

Collaboration

Peer-to-peer networked Java programs can allow many people to collaborate on a document at one time. Imagine a Java word processor that two people, perhaps in different countries, can both pull up and edit simultaneously. Imagine the interaction that's possible when you attach an Internet phone. For example, two astronomers could work on a paper while one is in New Mexico and the other is in Moscow. The Russian could say, "I think you dropped the superscript in equation 3.9," and then type the corrected equation so that it appears on both people's displays simultaneously. Then the astronomer in New Mexico might say, "I see, but doesn't that mean we have to revise Figure 3.2 like this?" and then use a drawing tool to make the change immediately. This sort of interaction isn't particularly hard to implement in Java (a word processor with a decent user interface for equations is probably the hardest part of the problem), but it does need to be built into the word processor from the start. It cannot be retrofitted onto a word processor that did not have networking in mind when it was designed.

Servers

Java applications can listen for network connections and respond to them. This makes it possible to implement servers in Java. A number of people have already written simple web servers in Java. Both Sun Microsystems and the World Wide Web Consortium have written web servers in Java designed to be as fully functional and fast as the common ones like Apache, Netscape, and Microsoft's Internet Information server. There is nothing to stop you from writing servers for other protocols as well, like FTP or POP (Post Office Protocol).

More interestingly, you can write custom servers that fill your specific needs. For example, you might write a server that stored state for your game applet and had exactly the functionality needed to let the players save and restore their games, and no more. Or, since applets can normally only communicate with the host from which they were downloaded, a custom server could mediate between two or more applets that need to communicate for a networked game. Such a server could be very simple, perhaps just echoing what one applet sent to all other connected applets.

As well as classical servers that listen for and accept socket connections, Java provides several higher level abstractions for client-server communication. Remote method invocation allows objects located on a server to have their methods called by clients. Servers that incorporate Java (like Sun's Java server, Jeeves) can load extensions called servlets that give them new capabilities. The easiest way to build your multiplayer game server might be to write a servlet, rather than writing an entire server. In the future, it may be possible for clients to upload servlets, subject to the constraints of a SecurityManager object; this is the reverse of applets being downloaded from a server to a client to be run on the client.

Applications of the Future

Java makes it possible to write many kinds of applications that have been imagined for years, but that would have required too much processing power because they were server-based. Java moves the processing to the client, where it belongs. Other application types (like intelligent agents) require extreme portability, and some guarantee that the application can't do anything hostile to its host. While Java's security model has been criticized (and yes, some bugs have been found), it's a quantum leap beyond anything that has been attempted in the past, and an absolute necessity for the software we will want to write in the future.

Shopping carts

Shopping carts (pages that keep track of where users have been and what they have chosen) are at the outer limits of what's possible with HTML and forms. Building a server-based shopping cart is difficult, requires lots of CGI and database work, and puts a huge CPU load on the server.

Java can move all this work to the client. Applets can store state as the user moves from page to page, making shopping carts much easier to build. In future browsers, applets will even be able to store the state of a shopping cart between visits to a web site, further expanding the convenience of online shopping.

Three-dimensional worlds

Virtual Reality Modeling Language (VRML) lets you create three-dimensional environments you can move through, but those environments have a limited range of behavior. For example, it's not really possible in VRML to set up a world in which pushing a button makes a jack-in-the-box pop up. You can create a button and you can create a jack-in-the-box, but you can't connect the two. Java provides the logical glue you need to add behavior and connections to the otherwise static worlds of VRML. In the future, Java will have a 3D API (Application Programming Interface, a fancy term for a class library) that will make visual environments even more interactive and exciting.

Spiders

World Wide Web search applications for java programs can wander through the web, looking for crucial information. These sorts of programs are called spiders. Spiders crawl the web by following the links they find on pages. Generally a spider does something with each page it sees, ranging from indexing it in a database to performing linguistic analysis to hunting for specific information. This is more or less what services like Altavista do to build their indices. Building your own spider to search the Internet is a bad idea because Altavista and similar services have already done the work, and a few million private spiders would soon bring the Net to its knees. However, this doesn't mean that you shouldn't write spiders to index your own local intranet. In a company that uses the Web to store and access internal information, building a local index service might be very useful. You can use Java to build a program that indexes all your local servers, and interacts with another server program (or acts as its own server) to let users query the index.

It is easy to write a spider in Java, but there are some caveats. As mentioned previously, uncontrolled proliferation of spiders could quickly make the Internet unusable. If you write a spider, keep a list of the URLs you've already visited so you don't visit a page twice just because it's linked from two other pages. When visiting a site, check for a robots.txt file, and respect any restrictions you find there. If you are writing a spider for a local network, make sure it doesn't "escape" by following links to the outside world. When you're testing a spider, put a restriction on the depth or breadth to which the spider will search. Finally, don't run your spider at the maximum speed it can handle. Slow it down. Restrict the number of requests the spider will make per minute.

Intelligent Agents

Intelligent agents are programs that can move from host to host on their own, performing some action (like researching a stock price, or soliciting quotations for a purchase), and eventually returning with data, possibly even a completed contract for some goods or service. People have been talking about intelligent agents for some time, but until now, practical agent technology has been rather boring. It hasn't come close to achieving the levels envisioned years ago in various science fiction novels, most notably John Brunner's Shockwave Rider and William Gibson's Neuromancer. The primary reason for this is that agents have been restricted to running on a single system--and that's neither useful nor exciting. It's like a personal shopper that can call up different stores on the telephone to find out who has what you need, but can't actually go to the different stores to buy it. In fact, until 1996, there's been only one widely successful (to use the term very loosely) true agent that ran on multiple systems, the Morris Internet worm of 1989.

The Internet worm demonstrates one reason why developers haven't been willing to let agents go beyond a single host. It was destructive; after breaking into a system through one of several known bugs, it proceeded to overload the system, rendering it useless. In order for an agent to do something useful, it must be powerful enough to do some damage--and that's a risk most network managers haven't been willing to take. Java mitigates the security problem by providing a controlled environment for the execution of agents. This environment has a SecurityManager that can ensure that, unlike the Morris worm, the agents won't do anything nasty. This allows different systems to open their doors to these agents.

The second problem with agents has been portability. Agents aren't very interesting if they can only run on one kind of computer. That's sort of like having a credit card for Niemann-Marcus; it's a little bit useful and exotic, but won't help as much as a Visa card if you want to buy something at Macy's. Java provides a platform independent environment in which agents can run; the agent doesn't care if it's visiting a Sun workstation, a Macintosh, or a Windows machine.

The spider application discussed above could be implemented in Java as an intelligent agent. Instead of downloading pages from servers to the client, and building the index there, the spider could travel to each server, build the index locally, and send much less data across the network. Another kind of agent could move through a local network to inventory hardware, check software versions, update software, perform backups, and take care of other necessary tasks. Commercially oriented agents might let you check different record stores to find the best price for a CD, see if opera tickets are available on a given evening, and more. The same security features that allow clients to run untrusted applications downloaded from a server lets servers run untrusted applications uploaded from a client.

Electronic commerce

Ever since the Internet's popularity exploded, people have been talking about electronic commerce. Unfortunately, this explosion happened so quickly that people haven't given much thought to the details. Although many sites accept credit cards through HTML forms, the mechanism is clunky. It is inconvenient to fill out a form with your name, address, billing address, credit card number, and expiration date every time you want to pay $0.50 to read today's Daily Planet. Furthermore, many sites trying to sell something don't address security.

Imagine how easy it would be to implement this kind of transaction in Java. The user clicks on a link to some information. The server downloads an applet that pops up a dialog box saying, "Access to the information at http://www.greedy.com/ costs $2.00. Do you wish to pay this?" The user can then click buttons that say "Yes" or "No." If the user clicks "No," then they don't get into the site. Now let's imagine what happens if the user clicks "Yes."

When the applet is downloaded from the server, it contains a small amount of information: the price, the URL, and the seller. If the client agrees to the transaction, the applet adds the buyer's information to the transaction, perhaps a name and an account number, and signs the information with the buyer's private key. Then the applet sends the data back to the applet host over the network. The applet host grants the user access to the requested information using the standard HTTP security model. Then it signs the transaction with its private key and forwards the data to a central clearinghouse. Sellers can offer money-back guarantees or delayed purchase plans (No money down! Pay nothing until July!) by agreeing not to forward the transaction to the clearinghouse until a certain amount of time has elapsed.

The clearinghouse verifies each transaction with the buyer's and seller's public keys, and enters the transaction in its database. The clearinghouse can use credit cards, checks, or electronic fund transfers to move money from the buyer to the seller. Most likely, the clearinghouse won't move the money until the accumulated total for a buyer or seller reaches a certain minimum threshold, keeping the transaction costs low.

Every part of this can be written in Java. An applet is used to request the user's permission. The java.security package authenticates and encrypts the transaction. The data can be sent from the client to the applet using sockets, URLs and CGI programs, servlets, or remote method invocation. These can also be used for the host to talk to the central clearinghouse. The web server itself can be written in Java, as can the database and billing systems at the central clearinghouse; or JDBC (Java Database API) can be used to talk to a traditional database like Informix or Oracle.

The hard part of this is setting up a clearinghouse, and getting users and sites to subscribe. First Virtual (http://www.fv.com/) and the major credit card companies have a head start, though none of them yet uses the scheme described here. In an ideal world, you'd like the buyer and the seller to be able to use different banks or clearinghouses. However, this is a human problem, not a technological one, and it is solvable. You can deposit a check from any American bank at any other American bank where you have an account. The two parties to a transaction do not need to bank in the same place.

At present, this is a little on the speculative side, so the details are likely to change. Nonetheless, all the technical pieces needed to make this happen should be in place by the time you read this. The Java Electronic Commerce Framework (JECF) should make it easier to tie the different pieces into an easily managed package.

But Wait. There's More!

Most of this book describes the fairly low-level APIs needed to write the kinds of programs discussed above. Some of these programs have already been written. Others are still only possibilities. Many of the low-level details will be encapsulated in high-level APIs in the future. This year promises to be a watershed, as Sun releases Java APIs for cryptography, advanced multimedia, commerce, telephony, and many other crucial areas. At present, you'll frequently hear the lament, "This would be possible if such-and-such a feature were available." Over the next year, this complaint should become much less frequent.

This chapter has just scratched the surface of what you can do when you make your Java programs network-aware. The real advantage of a Java-powered web site is that anything you can imagine is now possible. You're going to come up with ideas others would never think of. For the first time, you're not limited by the capabilities that other companies build into their browsers. You can give your users both the data you want them to see and the code they need to see that data at the same time. If you can imagine it, you can code it.

Back to: Java Network Programming