Applet <==> Servlet Communication

[Mustafa Aydin]

Hello,

I'd like to offer an applet/servlet combination on my HP
that is able to calculate the movement of the sun for
any locations and a whole year, or, as animation,
visualize it (length of shadow, ...)for one day.
I know, such stuff very often yet exists but I
like to )
and besides it will help me to get practice with
the servlet/jsp/applet APIs.

Because the geographical database is too big
to download for the user, the applet has to
communicate with a servlet or just a package
on the server somwhow.

The most elegant method to make a connection over
a defined port and let the applet/servlet use it
does work locally but on my provider it doesn't

I am able to have a static method run on the server
that listens to a port, but the call to the accept method
never returns. My local client program only shows
me "Connection refused" on every port (besides
the predefined 21 (FTP), ...)

My question:

What is the "correct" way to let an applet communicate
with its server?

I could imagine that the applet sends "its" parameters via
"GET /GetValues?country=abc&city=xyz&year=2042 HTTP/1.0"
to the server in order to invoke a JSP page (from which I
have access to my packages) that delivers the data line by line
and the applet in return will "extract" the data out of this
HTML page.

Otherwise I think that there exists no way that
is more stupid and complicated :-((

I'd be appreciated for any scheme that does this
task without any "tricks".

Thanks in advance
Mustafa

 

[Michael Borgwardt]

What is the "correct" way to let an applet communicate
with its server?

I could imagine that the applet sends "its" parameters via
"GET /GetValues?country=abc&city=xyz&year=2042 HTTP/1.0"
to the server in order to invoke a JSP page (from which I
have access to my packages) that delivers the data line by line
and the applet in return will "extract" the data out of this
HTML page.

Why not a Servlet that returns (in serialized form) exactly the
data objects that the Applet needs?

 

[Mustafa Aydin]

Why not a Servlet that returns (in serialized form) exactly the
data objects that the Applet needs?

So you mean to share two classes among the
applet and the servlet, one with instances
that represents requests and the other class
instances containing the responses.

It would'nt be nice OOD than using interfaces,
because the "client applets" always have to
have the identical class definitions in order
to work together.

But it sounds interesting and easy to realize.

Thanks so far )

Mustafa

 

[Michael Borgwardt]

So you mean to share two classes among the
applet and the servlet, one with instances
that represents requests and the other class
instances containing the responses.

Actually, I still would put the request data as parameters in the URL.

It would'nt be nice OOD than using interfaces,
because the "client applets" always have to
have the identical class definitions in order
to work together.

I don't see much of a problem. Of course you can't change the data class
much and still expect older applet versions to work, but it should not
contain much functionality anyway and basically just represent a data
exchange format, an interface if you will. If you used text, you'd also
have to stick with a format.
If you define serialVersionUID right at the start, minor changes in the
class (such as changing method bodies) will not lead to incompatibility.

 

[Sudsy]

So you mean to share two classes among the
applet and the servlet, one with instances
that represents requests and the other class
instances containing the responses.

I did this "way back when", exchanging objects via HTTP. The sample
code included here utilizes two classes: toServer and toClient. The
names indicate their respective roles.
ps. No flames on coding style, please.

In the applet:

toServer request = null;
toClient response = null;

try {
url = new URL( "path_to_servlet" );
connection = url.openConnection();
connection.setDoOutput( true );
connection.setRequestProperty( "Content-Type",
"application/octet-stream" );

/*
* build the request
*/

request = ...

/*
* send the request
*/

oos = new ObjectOutputStream(
connection.getOutputStream() );
oos.writeObject( request );
oos.flush();
oos.close();

/*
* receive the response
*/

ois = new ObjectInputStream(
connection.getInputStream() );
response = (toClient) ois.readObject();
ois.close();
}
catch( Exception e ) {
...
}

In the servlet:

public void doPost( HttpServletRequest req,
HttpServletResponse resp ) {
ObjectInputStream ois = null;
ObjectOutputStream oos = null;
toServer request = null;
toClient response = null;

try {

/*
* get the input stream and prepare the
* output stream header
*/

ois = new ObjectInputStream(
req.getInputStream() );
resp.setContentType(
"application/octet-stream" );
resp.setHeader( "pragma", "no-cache" );
resp.setHeader( "expires", "-1" );

/*
* receive the request
*/

request = (toServer) ois.readObject();

/*
* get the output stream
*/

oos = new ObjectOutputStream(
resp.getOutputStream() );

/*
* build the response
*/

response = ...

/*
* send the response
*/

oos.writeObject( response );
oos.flush();
oos.close();
}
catch( Exception e ) {
...
}
}

 

[Jez Naisbitt]

Hi,

I may bit a bit off beam with your thread, so apologies in advance.

I also did this long ago in a similar way, and found that class
serialisation was very specific and required careful tracking of when you
built the servelet and client applet. Not too much of a problem if you are
delivering the applet as an embedded object in your asp page (using the
<APPLET> tag) from the SAME server as the servelet is running , as you can
then ensure your distribution of the applet and servelet match. From your
asp you can also pass in parameters to the applet, one of which is your URL
to the servelet, and the other your valid port number, so these can be
configured on your server and you know they are right.

In the end I transmitted the information as XML, as this took away all my
worries about matching the class serialisation. It's relatively easy to
implement the subset required to transmit data this way, and reasonably easy
to map object members onto the tag=value format of XML.

e.g.:

<MyClass m_Version="1" m_Member1="abcd" m_Member2="0.13" />

I used the m_Version value to ensure I could sensibly use the data or return
default values, etc.

HTH.

Rgds,

Jez.

 

[Mustafa Aydin]

Thanks for all your help

Mustafa

 

[Nigel Wade]

So you mean to share two classes among the
applet and the servlet, one with instances
that represents requests and the other class
instances containing the responses.

It would'nt be nice OOD than using interfaces,
because the "client applets" always have to
have the identical class definitions in order
to work together.

But it sounds interesting and easy to realize.

Thanks so far )

Mustafa

This is exactly what I am doing at the moment. It's really not that difficult.

The servlet container (in my case Tomcat) responds to a URL request on port
8080 and returns an applet to the client. The jars for the applet are those
used by Tomcat for the servlet, so all classes are the same on client and
server.

The applet communicates with the servlet using a URLConnection, sending
objects via ObjectOutputStream.writeObject and receives replies from the
servlet via ObjectInputStream.readObject. The URLConnection invokes the
servlets service() method and the objects sent by the applet can be read
from its request parameter's inputStream, and objects returned by writing
them to its response parameter's outputStream.

So far it works very well (apart from GregorianCalendar, which won't
de-serialize in the applet, but that's another story which I'm currently
investigating).