> Dave's probably right about a missing abstraction. Dave does tend to be right, but here's another idea entirely. Accept the deployment of the whole application and configure the application as a cluster, if possible. The cluster could even be on the same machine, so you don't necessarily need additional hardware, but it would permit bringing the application down for a deployment without resulting in downtime, which is the assumed aversion to the deployments, right? It adds complexity to the deployments (especially if DB changes) and you have to spend the time setting up the cluster, and testing failover without losing sessions (turn off new requests to a node and let the current requests complete before shutting down), but it would greatly ease application design, from what I can tell and that is where your big time sink *may* be over the life of the application (my lack of knowledge of your environment notwithstanding).
In my experience, it isn't atypical for the design that you come up with to be repeated if it seems to work. If you (eventually, this could be precedence setting) have lots of little apps communicating back to the main app, when the changes are more easily, and perhaps appropriately, completed in the main app, then you end up with a messy bunch of apps to manage and lots of plumbing code to maintain. Now you end up with configuration management (different revisions) both in the apps and the communication channel. - Eric
