Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
In last month's edition, we discussed the specifications of the Interchange client -- the applet parameters, the GUI, the
modes of operation, and the user's identity -- and worked through the ForumLauncher and Forum classes to implement them. ForumLauncher displays the icon that stores the client app, while Forum presents the GUI and contains the majority of the app's logic. If you haven't already done so, click on the icon at the top
of this article to see the discussion forum applet in motion.
I told you we were only going to do a brief review. If you're feeling a bit behind the eight ball on these topics, I recommend that you review last month's installment and brush up before running headlong in to this month's article.
Oh, and if it's Java code you want, you'll find the full source for the forum here.
As we saw last month, our system is going to follow a simple communications protocol to read and post topics. This simple
protocol moves thread listings from server to client and articles from client to server (and vice versa). The networking classes
(ForumComm, ForumConnectionHandler, and ForumServer), which we'll cover in detail shortly, will implement the following actions:
The client drives the server's actions with requests. The client will likely make very few requests over the course of its life; users typically spend the majority of session time reading articles and composing posts. For this reason, as well as the fact that requests are all discreet in nature (as opposed to transmission of real-time data, for example), each client request is serviced in a single connection, which is then closed down. The other alternative -- leaving a connection open between each client and the server for some specified period of time -- would waste precious server resources.
The communications code for the client is bundled up nicely in one class, ForumComm. This class, shown in Listing 1, is a communications library that implements client-side networking calls.
import java.net.*;
import java.util.*;
import java.io.*;
import ForumLauncher;
public class ForumComm {
// port for server to listen for Forum clients
static final int FORUM_PORT = 5000;
// possible client requests
static final int LOAD_ALL_THREADS = 1;
static final int LOAD_THREAD_ARTICLES = 2;
static final int POST_ARTICLE = 3;
ForumLauncher gp;
public ForumComm (ForumLauncher gparent) {
gp = gparent;
}
The top section of the code defines the TCP port used for the Interchange service, as well as the protocol requests that the
client can send to the server. These definitions have identical counterpart definitions in the server's ForumConnectionHandler class. The constructor does nothing except provide a pointer to the ForumLauncher applet to allow access to its getCodeBase() method.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq