Thinking about AppServer - Forum - OpenEdge General - Progress Community

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?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • A good question,
    I use OE and I am currently evaluating the use of AppServer for a future release of our home grown ERP system. (But we do have Sonic ESB , Jboss/Tomcat J2EE and BEA for other applications).
    The AppServer solved as usual the 90% of all "bread and butter" requirements which we need in a typical ERP environment.
    The AppServer Agent is the service and comparable to a service instance (a running process or thread) in J2EE. The execution of a code is equivalent (it do’s not matter if you call an ABL Object or JAVA Object).
    In an ERP environment it is most unlikely that every call to such a service will benefit from caching and complicated services which do cache and hold context, as everything comes and ends up finally in the database. 

    The overhead of setting up a new procedure context in a running service is very low compared to the necessary Authentication and Database access (not to speak from invoice creation).

    A client can use state-less for most calls without a big penalty for overhead in performance compared to dedicated services.  If a client does need it, it can bind an AppSever Agent and gets a dedicated service. In this case you have a session managed context and you can do all tricks with caching etc. to create either complex business processes or to reach low answer times. Other agents can be used to defer work to the background to reach a good UI answer time for users.
    Clearly the other 10% of requirements are more easily to reach with a full-fledged system programming language as JAVA (on Sonic or and other professional J2EE Server):

    ·         Persistent services  with lowest possible answer time for dedicated services

    ·         Network wide event subscription

    ·         Load balancing and hot failover

    ·         Queuing, parallelizing of service requests for optimizing throughput


    But this comes with a price tag for Complexity. If I compare the complexity and cost of a non-trivial J2EE application running on BEA or JBOSS with something comparable the OpenEdge AppServer, Open Edge wins.

    So you cannot forget the AppServer, if you need to think about the TCO of your solution.
    As usual some solutions of OE in the AppServer are strokes of geniuses. (Like the remote persistent procedures with automatic bind of Agent). They can be used to drive into the 10% area, but for a complexity price tag.