Download the JDK
Search the Tutorials
Hide the TOC
Trail: Deployment
Lesson: Applets
Section: Practical Considerations When Writing Applets
Subsection: Working with a Server-Side Application
Applets
Getting Started with Applets
Importing Classes and Packages for Applets
Defining an Applet Subclass
The Life Cycle of an Applet
Methods for Milestones
Methods for Drawing and Event Handling
Methods for Adding UI Components
What Applets Can and Can't Do
Taking Advantage of the Applet API
Finding and Loading Data Files
Displaying Short Status Strings
Displaying Documents in the Browser
Sending Messages to Other Applets
Playing Sounds
Defining and Using Applet Parameters
Deciding Which Parameters to Support
Writing the Code to Support Parameters
Giving Information about Parameters
Using the APPLET Tag
Practical Considerations When Writing Applets
Security Restrictions
Creating a User Interface
Creating a GUI
Displaying Diagnostics to the Standard Output and Error Streams
Getting System Properties
Threads in Applets
Threads in Applets: Examples
Working with a Server-Side Application
A Simple Network Client Applet
Using a Server to Work Around Security Restrictions
Finishing an Applet
Before You Ship that Applet
The Perfectly Finished Applet
Deploying Applets
General Deployment Considerations
Using the applet Tag
Using the object Tag
Using the embed Tag
Deploying Applets in a Mixed-Browser Environment
Solving Common Applet Problems
Questions and Exercises
Home Page > Deployment > Applets
« Previous • Trail • Next »
Using a Server to Work Around Security Restrictions

> As the What Applets Can and Can't Do section explains, applets are subject to many security restrictions. For example, they can't perform file I/O, they can't make network connections except to their original host, and they can't start programs.

> One way of working around these restrictions is to use a server application that executes on the applet's host. The server won't be able to get around every applet restriction, but it can make more things possible. For example, a server probably can't save files on the host the applet's running on, but it'll be able to save files on the host the applet originated from.

> This page features an example of a server that allows two applets to communicate with each other. The applets don't have to be running on the same page, in the same browser, or on the same computer. As long as the applets originate from the same computer, they can communicate through the server that's running on that originating computer. The example uses sockets, which are documented in All About Sockets.

> Here are the source files:

> `TalkClientApplet.java`
>   The source file for the client applet. After you compile it, you can run it by including it in an HTML page with this tag:

>   >     <APPLET CODE=TalkClientApplet.class WIDTH=550 HEIGHT=200>
>   >     </applet>

>   Here's a link to a `page` that includes the above HTML code. After saving this page to a file on your local HTTP server, you can use it to communicate with the talk server

> `TalkServer.java` and `TalkServerThread.java`
>   The source files for the server applet. After compiling both files, you can run the server on the applets' originating host by invoking the interpreter on the `TalkServer` class.

> The instructions for running the server are just like those for the previous example. Run the server on the applets' originating host, recording the port number the applets should rendezvous on. Then initialize both applets (which can be running on different machines) to talk to the server port number. After this initialization is complete, type a string into each applet's text field. Then press the Return key to send the message to the other applet.

> Here's the server in action:

> > `www% java TalkServer
> > TalkServer listening on rendezvous port: 36567`

> Here are pictures of the applets in action:

« Previous • Trail • Next »
Previous page: A Simple Network Client Applet
Next page: Finishing an Applet