Re: How do I design this application ? (remote server procedures, etc.)
Me wrote:
On Fri, 24 Apr 2009 10:36:03 -0700, Mark Space wrote:
[quoted text muted]
Yes. So is an application downloaded from a server. The really big
question is: do you save time and effort installing and learning Apache
+ JEE or do you just implement a simple service and duplicate the small
amount of functionality you need? It sounds to me like doing the whole
thing in Java and skipping both Apache and JEE is feasible for you, but
this could also be a huge judgment call.
I think you are right. I think I should build the logging backend in
python and have it listen on a port and respond to applet connections.
I'd go with a Java application instead of an applet except that people
will need to access the weather site from public PCs, where they might
not have permission to download an application. In that case, the applet
works better.
If you want your applet to be publicly available then you almost certainly do
not want to expose the interface to the weather station to the applet. That
would mean making that interface public also.
In a very similar situation the solution I chose was to have a servlet (within
Tomcat) provide the public interface to the data. This servlet operates as a
proxy for the Java client (which used to be an applet, but is now a WebStart
application).
I did originally try to use the long-running-thread-within-the-servlet model
rather than a separate daemon process, but this caused problems which I was
never able to resolve. The solution I now have is that the separate daemon
server which communicates directly with our real-time data feed is a java RMI
server. There is a continuous thread within this which reads and caches the
data internally. The RMI server thread serves requests for data from this cache
(this is accessible only from the local area network). The servlet waits on
requests from the Internet. On receipt of a valid request it makes an RMI call
to the data server then sends back the response to the client.
It sure would be nice to not have to install Apache though. Its pretty
simple to install it and serve the applet web page.
The simplest solution, if you don't need a website, is to install Tomcat and
have Tomcat handle the requests directly.
I would do the servlet thing, but I want the backend process to be
running all the time, logging data and such, even if the applet isn't
connected to it.
The model I have works very well. The background data server is not exposed to
the Internet. It runs all the time fetching data, caching it to disk, logging
information via a Logger. The servlet engine also runs all the time, but the
servlet itself is only run in response to a client request. Because the server
is an RMI server you can write simple Java applications which control the
server via RMI by adding more service routines, for example to
increase/decrease the verbosity of the logging information.
In my setup it's a one-way system. The server serves data, there is no control
of the server by the client. If you needed to do that you could easily add
additional service routines into the RMI server. You would then need to add
additional methods into your servlet to allow remote access from the client.
One of the advantages of the servlet-as-proxy model is that you can add all the
service routines you want to your RMI server, but only expose those which you
really need to to the remote client via the servlet. However, you would need to
be very careful what you exposed and to whom, especially if multiple clients
can potentially have access to the server simultaneously over the Internet.
--
Nigel Wade