http://qs321.pair.com?node_id=665465

Tanktalus has asked for the wisdom of the Perl Monks concerning the following question:

How do you generally approach multi-client/multi-application application systems? This is a bit vague, so perhaps an example will help.

You have some data or actions (e.g., CSV/Oracle/DB2/MySQL/whatever or sending email/triggering a CGI script/uploading a file) that can happen a number of ways. For example, it could run at the commandline, as well as in its own CGI script. And maybe from a cron job, or maybe in a Postfix filter. Of course, the inputs to each of these are both similar and different - similar in that the same data can be present (maybe some of it is optional), but different in that the source needs to be massaged into the format used by the core engine.

For me, the first two paradigms that come to mind are:

  1. Put all the logic and functionality into modules, allow the front-end to massage the input into parameters (perhaps via other modules, doesn't matter), and run in the front-end's process space.

    This brings up concurrency issues, I think. Of course, if the data is going into an RDBMS, then that largely goes away. Other actions may render concurrency moot, too, but in the general case concurrency may need to be dealt with.

    Upgrading the modules may result in some funky behaviour - clients that start up each time may be using a mix of modules (e.g., if they load while the new modules are being updated), and clients that are daemons themselves (say mod_perl) may simply be using out-of-date modules until reload.

  2. Put all the logic and functionality into modules, put that into a daemon that listens on some socket and requires its input in that format. All the other clients need to reformat their input into the format required by this server, open the socket, send it, possibly wait for a return value, and close.

    Here, concurrency is controlled by the daemon which can fork if concurrency isn't an issue, or deal with one socket at a time if it is.

    Upgrades are tightly controlled - don't reload the daemon until the upgrade is done. And mod_perl won't be affected - no need to reload the apache server. (Ok, so reloading apache isn't that big of a deal - it even has a signal handler to do that gracefully, but it's just an example.)

So ... the question is: for an active production system, which paradigm do you go for? a? b? or some other one? I'm not particularly in love with either, but my limited comp-sci background means I may not have been exposed to other methodologies.