Tom--
If your users are running as applets, why not run your server as a servlet?
Does it need to hold state information across the entire userset, or is
each user interaction stateless?
What I'm suggesting is something like this: create a number of different
servlets to perform each task ("AddFooServlet", "RemoveFooServlet", etc.),
and have the applet simply open up URL connections (with appropriate
parameters sent as URL parameters) to the servlet of the appropriate type.
The servlet performs its thing, hands back any data, and quits. The data
(either direction) could even be URL-friendly string representations of
Serialized data, if necessary.
I can hear the OO purists preparing their flamethrowers now, so let me
issue the one argument that will make all this non-OO work worthwhile:
PERFORMANCE. Holding state is wasteful, so long as the various operations
can be held in a stateless manner (or state is held within the back-end
database, which is usually easier than you'd imagine), since state means
that object is now bound to a single client, and cannot service other
clients--this means you will need to hold 1 object on the server for every
client currently using the system, EVEN IF THE CLIENT ISN'T CALLING YOU AT
THE MOMENT.
With a stateless model, which works well with HTTP servers anyway (and
would allow for HTML-only thin client layers if the requirement came down
the pike, which it usually does, in my experience), a given servlet can be
unloaded when client "a" is still thinking, or service clients "b", "c" or
"d" as necessary. With a stateful model, 4 objects would need to be held
(one for a, b, c and d) until each client dropped out.
Whenever you start thinking about distributed objects, push for
statelessness as much as possible; if that's not feasible, push the state
someplace else, like the back-end database.
In your particular case, a servlet could take the SQL (or whatever you're
handing the back-end, you didn't specify) and pass it directly through to
the database. The servlets can open one (or more, if you want to support
some sort of pooling mechanism, or need to differentiate by
userid/passwords) connection to the database on startup, close it when the
servlet is unloaded, and use the same connection over and over to avoid
having to make that connect each time.
Opinions welcome, well-thought-out arguments welcome, flames > NUL. Hope
this helps.
At 10:15 PM 5/4/99 -0400, Tom Roche wrote:
>First: I hope this, being more of a Linux question rather than a Java
>question, isn't off-topic: if so, please excuse.
>
>Second: feel free to correct any and all errors in conception or
>usage you see--I know all too little about Linux, Unix, and system
>administration. (But I hope to devote more time to this over the
>summer.)
>
>I'm working on a Java-based website, running on Apache on a Linux
>box. It has a backend that connects users (applets) to the
>database. For testing, I've been logging in and running a script that
>runs my backend classes. Now I want the backend to run as a service,
>i.e. without a user logged in (like FTP, etc).
>
>Is "service" the proper term to use here? ("daemon"?)
>
>What is "the best way" to do this?
>
>I believe the best way to do this is via inetd: is this correct?
>
>If so, what would be the proper settings for inetd.conf?
>
>Your assistance is appreciated, [EMAIL PROTECTED]
>
>
>----------------------------------------------------------------------
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
