applet as servlet BACK end

[Guest]

We have a servlet (managing a mysql database of astronomical data) which
is accessed by HTML forms as front end (actually after a login form, it
generates its own HTML pages which invoke other methods in the servlet).

At present the servlet has limited graphics capabilities, i.e. can
produce GIF, JPEG or Postscript plots sent back to the user via http.

I thought to improve this (or better a variant of it for a different
project) having an applet doing the plots, and having the servlet
sending the data to be plotted to the applet. One could also think to
implement some interactivity in the applet, like zoom and pan, or by
selecting data points with the mouse and getting additional information
about them.

I have spent the entire afternoon browsing the net for tutorials and
examples about servlet-to-applet communication, but I would like your
advice on the matter.

- is the usage of sockets the best (and also most efficient in terms
of network load) way to handle servlet-to-applet communication ?

or are there any better classes ?

- are there any likely security problem (permission denied) if the
servlet (running on port 8080 of 'host') will generate HTML pages
making reference to an applet residing somewhere on 'host' (via
default port 80) ?

- will one gain something using serialization on the stream between
applet and servlet, or is there any penalty w.r.t. to transmission
of raw binary data, eventually gzipped (or conversely should one
use serialization to prevent portability issues like endianness of
the data if applet and servlet run under different OS's) ?

- any other issue I should be aware of ?

 

[John C. Bollinger]

We have a servlet (managing a mysql database of astronomical data) which
is accessed by HTML forms as front end (actually after a login form, it
generates its own HTML pages which invoke other methods in the servlet).

At present the servlet has limited graphics capabilities, i.e. can
produce GIF, JPEG or Postscript plots sent back to the user via http.

I thought to improve this (or better a variant of it for a different
project) having an applet doing the plots, and having the servlet
sending the data to be plotted to the applet. One could also think to
implement some interactivity in the applet, like zoom and pan, or by
selecting data points with the mouse and getting additional information
about them.

I have spent the entire afternoon browsing the net for tutorials and
examples about servlet-to-applet communication, but I would like your
advice on the matter.

- is the usage of sockets the best (and also most efficient in terms
of network load) way to handle servlet-to-applet communication ?

or are there any better classes ?

Any such communication will ultimately rely on sockets. The question
really is whether you need to go down to that level to get satisfactory
results, and the answers is probably "no".

- are there any likely security problem (permission denied) if the
servlet (running on port 8080 of 'host') will generate HTML pages
making reference to an applet residing somewhere on 'host' (via
default port 80) ?

An unsigned applet applet will not be able to open a ServerSocket to
accept connections. In most cases even a signed applet could not open
one on port 80.

- will one gain something using serialization on the stream between
applet and servlet, or is there any penalty w.r.t. to transmission
of raw binary data, eventually gzipped (or conversely should one
use serialization to prevent portability issues like endianness of
the data if applet and servlet run under different OS's) ?

Serialization is only relevant if you need to transmit Java objects. In
that case, consider RMI. Otherwise, come up with a suitable
representation and transmit it as data.

- any other issue I should be aware of ?

You seem to want to push from the servlet to the applet. This model is
fundamentally flawed. However, you can probably achieve your goals by
writing an applet that knows how to pull the data it needs from the
server. The necessary instructions would be communicated via applet
parameters. I have a series of related applets that work along these
lines; try this for a demo:

http://www.reciprocalnet.org/recipnet/showsample.jsp?sampleId=27344711

You might also want to consider an application served up via Java
WebStart; its limitations would be fewer, although it probably still
couldn't accept connections on port 80.


John Bollinger
(e-mail address removed)

 

[Guest]

Any such communication will ultimately rely on sockets. The question
really is whether you need to go down to that level to get satisfactory
results, and the answers is probably "no".

alternatives ? to me it seemed rather simple to wrap a socket in some
input and output stream, unless there are other canned solutions.

An unsigned applet applet will not be able to open a ServerSocket to
accept connections. In most cases even a signed applet could not open
one on port 80.

If I use a socket I'll use some dedicated port (above 1024) for the
applet-server channel, not port 80.

What I was afraid of was the fact that the applet will load from a web
page running on machine:80, while the servlet runs on the SAME machine
on port 8080. Given the 'Mozilla security model' this gives some
troubles (I already encountered them for javascript talking with a java
servlet and have a workaround)

Serialization is only relevant if you need to transmit Java objects. In
that case, consider RMI. Otherwise, come up with a suitable
representation and transmit it as data.

I read the RMI documentation but seemed overshot for my purposes. I had
the impression that RMI is to load tasks defined by the client for
execution in the server, which is not what I want.

My concern was with the fact that, if my data are relatively bulky (say
a table of 1000 entries with a dozen columns), ASCII data transfer may
be inefficient. For this reason we already offer a way to store the
results of mysql queries (inerently ASCII) in the FITS binary format (a
standard widely used in astronomy). But that seemed also overshot for
"interprocess" communication. Sending straight binary data seems to me
the most efficient way, but of course there is the little-endian vs
big-endian issue. I thought an Object..Stream could take care of that.

You seem to want to push from the servlet to the applet. This model is

Do you mean "pushing" the computing load from the servlet to the applet,
or initiating the data transfer (push vs pull) ?

fundamentally flawed. However, you can probably achieve your goals by
writing an applet that knows how to pull the data it needs from the
server.

Our system already works with HTML forms generated by the servlet, which
essentially pull the data from the server (the servlet is a front end to
a mysql server).

What I wanted here was to add interactivity to the plotting of a
specific subset of results, no more queries. The applet should be a
"data viewer" (like e.g. xv is a viewer for a GIF or JPEG "static"
image).

http://www.reciprocalnet.org/recipnet/showsample.jsp?sampleId=27344711

I've seen your demo, that's the sort of thing I was considering about
interactivity (although I won't need any sophisticated 3-d stuff, just
dealing with plain 2-d plots) ... but since you do not publish any
code, I do not see where is the "communication" in your demo.

You might also want to consider an application served up via Java
WebStart; its limitations would be fewer, although it probably still

Sincerely I just wanted to add some capabilities to what we already
have, not revamp it from scratch !

 

[Nigel Wade]

We have a servlet (managing a mysql database of astronomical data) which
is accessed by HTML forms as front end (actually after a login form, it
generates its own HTML pages which invoke other methods in the servlet).

At present the servlet has limited graphics capabilities, i.e. can
produce GIF, JPEG or Postscript plots sent back to the user via http.

I thought to improve this (or better a variant of it for a different
project) having an applet doing the plots, and having the servlet
sending the data to be plotted to the applet. One could also think to
implement some interactivity in the applet, like zoom and pan, or by
selecting data points with the mouse and getting additional information
about them.

No problems at all. I am about to release a very similar system for our
radar data.

I have spent the entire afternoon browsing the net for tutorials and
examples about servlet-to-applet communication, but I would like your
advice on the matter.

- is the usage of sockets the best (and also most efficient in terms
of network load) way to handle servlet-to-applet communication ?

or are there any better classes ?

The applet/servlet comms is done over a stream. You open a URLConnection and
use getInputStream() and getOutputStream() to get the streams.

If all you want is to get the servlet to generate an image and the applet to
display it, use the doGet()/doPost() httpServlet methods.

If you want to get data back from the servlet then you would probably be
better off using genericServlet and defining your own comms protocol.

I use genericServlet, and in the applet I open a connection to the servlet
using URLConnection. Requests are sent as serialized objects down the stream
connecting the applet to the servlet. The request objects are received by
the service() method of the servlet, which process the request and generates
the response. Data is returned as serialized objects along the same stream,
and the applet uses the data to generate the plot.

- are there any likely security problem (permission denied) if the
servlet (running on port 8080 of 'host') will generate HTML pages
making reference to an applet residing somewhere on 'host' (via
default port 80) ?

I serve the applet from Tomcat, which is running the servlets. It avoids any
related security problems. The applet codebase is specified on port 8080
which is where Tomcat resides.

- will one gain something using serialization on the stream between
applet and servlet, or is there any penalty w.r.t. to transmission
of raw binary data, eventually gzipped (or conversely should one
use serialization to prevent portability issues like endianness of
the data if applet and servlet run under different OS's) ?

I use serialized objects for simplicity; the data object is the same in the
servlet and the applet, so it makes sense just to send the data object.
Unless bandwidth or CPU is a problem, simplicity always wins out over
efficiency (in my book, anyway) in terms of maintainability of the code.

You could certainly transmit binary data over the stream if you wanted to.

- any other issue I should be aware of ?

Can't think of any offhand.

 

[Sudsy]

Nigel Wade wrote:

I use genericServlet, and in the applet I open a connection to the
servlet using URLConnection. Requests are sent as serialized objects
down the stream connecting the applet to the servlet. The request
objects are received by the service() method of the servlet, which
process the request and generates the response. Data is returned as
serialized objects along the same stream, and the applet uses the data
to generate the plot.

Nigel,
This is the same approach I took so it must be a case of either
- great minds think alike, or
- fools seldom differ
I was watching this thread but hadn't gotten around to posting
before I saw your sage advice. It's simple, it doesn't incur a lot
of overhead if you use wrapper classes, and it works!
Bravo!

 

[Nigel Wade]

Nigel Wade wrote:



Nigel,
This is the same approach I took so it must be a case of either
- great minds think alike, or
- fools seldom differ
I was watching this thread but hadn't gotten around to posting
before I saw your sage advice. It's simple, it doesn't incur a lot
of overhead if you use wrapper classes, and it works!
Bravo!

Well, I can't claim credit for the principle. I had originally setup the
servlet to handle requests using RMI. Whilst this approach worked pretty
well, it had some drawbacks, the most notable being that I could never
shutdown Tomcat because I couldn't get the RMI registry thread to end.

So, I searched for a solution which would allow me to send objects to/from
the service() method and found a solution on the Web
(http://www.j-nine.com/pubs/applet2servlet/Applet2Servlet.html). I
incorporated that solution into the interface which I had been using for
RMI. The interface was virtually unchanged, it's just that I had to
implement it rather than rmic doing it for me - the applet was unaffected.
Each RMI method is translated into a command and parameters, all of which
are encapsulated in an enumeration. What is sent to the servlet is a
serialized instance of this enumeration.

Similarly in the servlet, most of the implementation of the interface was
the same, but called from the service() method rather than RMI. The servlet
receives an instance of the enumeration, looks at the contents and invokes
the relevent method to deal with it. The service method sends back the
resulting object to the applet.