Tom Jenkins wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hello all,
> while this is not specifically a quixote question, this involves a
> quixote app and i'm gonna take advantage of the knowledge base here
> .
>
> we have an application where users enter information that will feed into
> a long running process.  what they would like is to enter the
> information, submit it and receive a response with the url that they
> should go to in an hour to get their results.
>
> what is the best way to handle this type of situation?  should the
> quixote class handling the request take the information, setup the long
> process and fork a child to run the long running process, while the
> parent returns the reponse?  or should we pass the information to some
> "thing" (be it database/config file/whatever) and have a separate
> process that polls for entries to that thing that then handles running
> the long running process?


Personally, I would go for the separate-process model, for a couple of
reasons:

    * it's cross-platform: for example, Win32 can't fork. This may not
      be a requirement for your app, of course.
    * it's distributable. Once you're message-passing between
      independent processes, it's a small jump to passing those messages
      across a network. Imagine a Beowulf cluster of those... ;-)
    * improves availablity and reuse: it's easy to add other types of
      clients which can request the same type of task. You're building
      components and wiring them together, instead of building
      monolithic apps.
    * it really forces a clean separation between the client and the
      business process. Maybe it's just me, but I like to have buffers
      like that, to prevent me from creating dependencies where they
      don't belong.

You've got lots of choices for interprocess communication; I'd go for
something that, at its basic level, is inet-socket based and
language-neutral, again for cross-platform and distributability: xmlrpc,
maybe, or tuple spaces if you go in for that kind of thing. (I run a
little Quixote-based tuple-space server that works well enough, and is
very easy to use from a developer standpoint.) Or just drop job-files in
an "in" directory and look for results in an "out" directory...

A drawback is that you have an extra dependency for your app: you have
to keep the back-end application running independently of your
Quixote/Apache processes. You may also need a means of ensuring that the
back-end app is running, and a way to kickstart it if it's not. They are
surmountable issues, but it's a step away from the "works out of the
box" simplicity of a monolithic app.

Are you "gonna need it?" Maybe this is a whole lot of overkill for a
simple application. Personally, I've not been disappointed by
service-oriented design -- there are some real benefits to be reaped --
but it has to feel right to you, and seem logical for your application.

Just my two cents,

-- Graham