You've got the right suspicions. Applets run on the client machine. A web server (as you'll often hear me repeat, if you hang around here) is not a file server, so the only way you could access files on the web server would be if that machine also was running a file server program.
Even then, since applets are denied the right to read and write files by the Java sandbox, to do traditional file I/O, you'd have to create a signed applet. Even then, if you're doing this over the Internet, you might end up being blocked by firewalls. Especially since the MSBlaster worm used Windows File Sharing TCP/IP ports as a point of infection, so over the last 2 weeks, a lot of new filewalls have been raised.
There is a way to get an applet to retrieve information from a server and to store information from a server without
too much trouble. Use the java.net.HttpURLConnection class. You set up an HTTP Get or Post request to tell the server what data you want and fire off the request. The response comes back to you as a sequential data stream which you can use standard Java I/O stream services to read.
Updating data on the server works in the same way. Set up an HTTP GET or POST that tells the the server that you want to store data and where to put it. You'll probably want to do a POST. Then open the HttpURLRequest output data stream and write your data to it. The webserver will process the data using a
servlet,
JSP, ASP or CGI you've provided for that purpose. Becuase this is HTTP, you'll then get back a response code and maybe some more data such as an error message from the servlet or whatever.
As a side benefit, the HttpURLConnection manages all the headers and cookies (which typically contain session information) for you. And you don't need to sign the applet as long as you're talking to the same server that the applet came from.
This technique is known as HTTP Tunneling.
One other thing. I recommend you DON'T send/receive data as binary, and especially as serialized Java classes. Plain text or XML is far better. First of all, that way you can submit your request directly in your browser to
test it and see the results, so you can test the server-side code without having to worry about bugs in the applet. Secondly, on the Internet, binary data often has incompatibilities between clients and servers, so you'll be avoing those problems. And if you were looking to reduce data transmission, be aware that many modern-day systems will use data compression automatically if they can, so there's no real benefit to doing your own compression unless you can't have it done for you.
