Thinking about AppServer

I have been having some architectural discussions with someone who is not in the OpenEdge community and he is a little puzzled by the OE AppServer.  As I understand it ... which is certainly open to correction ... in the typical non-OE Appserver, one starts up various processes which provide some service.  These services are published so that they can be located by those that need them.  In some cases one can start more than one instance of a service and access these instances in a round robin or other load balanced approach, although this is less necessary when the services are multi-theaded since the main process can do little more than listen for work and spin off a thread to process each request and go back to listening until the process is complete and it is time for a response.

This contrasts with the aggressively statefree approach in OE Appservers where the typical agent has nothing prerun unless it is some generalized procedures and the request from clients is distributed across a relatively large pool of available agents.  I have heard of people experimenting with running multiple Appservers, each of which has some subject matter specific code running at start up, but even still the usage pattern is highly generic.

Now, particularly in the absence of multi-threading, it does seem that the OE approach would allow a smaller pool of agents to service a given level of work because every agent is generalized and can work on any task.  But, the price for this is having to reinitialize the agent after each use and having to run most functions as new programs to start, rather than having already running instances.  Moreover, while the non-OE approach would require more sessions, it is not at all clear that this would require more machine resources because it is the same amount of work ... it is just that some services would be heavily used and others lightly.  It is possible it would require more memory, but these days this would not be a big consideration.

The non-OE approach does provide some capabilities that are difficult to achieve in OE.  In particular, one can have a service which is the source for some particular data and when a client requests the data it also registers with the service for a change notice.  Then, if the data previously fetched is changed while the client is still using the data, it can be sent an alert so that it knows to refresh with the changed data.  This is conspicuously useful for something like validation tables which rarely change since the client can cache the data with confidence knowing that, should the data change, it will get a notice.  It might also improve optimistic locking issues since a client who is editing a record will receive a change notice while it is still editting rather than having its commit rejected.

Greg Higgins, in particular, has observed that one can create a context more like a non-OE Appserver by using Sonic since that involves continuously running published services.  Asynchronous use of an AppServer to perform the actual work could produce a simulcrum of multi-threading, albeit with more overhead.  But, use of Sonic per se implies a highish license cost and using non-Sonic alternatives means a less clean interface.

What do people think?  Is the OE approach a piece of OE genius which is actually ahead of the rest of the world?  Or, do we have it backwards?  Would multi-threading and the future context cache change this?  Or, should we just be forgetting about AppServer and focus on one or the other bus solutions?