Building Distributed
Applications
Using the Progress AppServer
Choosing an AppServer Operating Mode
You can configure an AppServer to run in one of three operating modes:
In addition, stateless operating mode supports two connection states, bound and unbound, that are determined by your AppServer application at run time. For information on how each operating mode affects the operation of an AppServer installation, see Overview of the Progress AppServer."
Application Characteristics to Consider
To understand the trade-offs between these operating modes, you must first determine the goals of your application. In general, each operating mode offers different trade-offs among three general characteristics:
The best operating mode for your application depends on a number of factors, including the:
In some cases, it might be significantly more complex to program your AppServer application with one operating mode rather than another. In many cases there might be more than one operating mode and design strategy that is appropriate. The purpose of this section is to explain some of the trade-offs associated with each operating mode so you can determine the most appropriate operating mode and design strategy to use for your situation.
Table 6–1 lists each operating mode, describing it in terms of the three general characteristics with performance divided between throughput and response time.
Managing Larger Amounts of Context
If you application has a large amount of context to manage between each request, then state-reset or state-aware are appropriate choices. Stateless is not a good choice because of the complexity and performance impact of managing this connection context through the Activate and Deactivate procedures for each request.
If there is a large amount of context that you need to establish for each connection that is independent of the user who is running the client application (for example, loading a TEMP-TABLE with static data), and only a small portion of the context is user specific, then state-aware might be a better choice then state-reset. This is true because with state-aware, you only need to establish the connection-independent context once, in the Startup procedure. You generally establish the user-specific context within the Connect procedure, using the user ID and password information provided by the client application.
The Startup procedure is not available for state-reset. Thus, both the connection-independent context and the user-specific context have to be established within the Connect procedure. Under these conditions, the time it takes to connect to a state-aware AppServer can be significantly shorter than the time it takes to connect to a state-reset AppServer because all of the connection-independent context is established before the client actually attempts to connect to the AppServer.
Managing Smaller Amounts of Context
If there is a minimal amount of context that needs to be maintained between each request and you have limited computing resources that need to service a large client load, the stateless operating mode might be the appropriate choice for your application. This increases your ability to service a large number of clients, because no Application Server process is dedicated to any particular client. The minimal context that needs to be maintained between requests can be stored either in the SERVER-CONNECTION-CONTEXT attribute or within an application-specific context database. No matter where you store the context, you probably want to use the Activate and Deactivate procedures to manage that context for each request.
Limiting Bound Connections
However, you need to use bound connections on a stateless AppServer with care. If client connections to a stateless AppServer are bound the majority of the time, the stateless operating mode is not a good choice, especially under heavy client load. In this case, the stateless AppServer is effectively running much like a state-aware or state-reset AppServer where each Application Server process remains effectively dedicated to one client for the duration of the bound connection.
In some cases, if most of the context that you need to maintain between requests is minimal, but occasionally you need to maintain a large amount of context for a small portion of the application, then stateless might still be an appropriate choice. In that case, you can temporarily make the connection bound by having the client run a remote persistent procedure and delete shortly after, or by setting the SERVER-CONNECTION-BOUND request attribute to TRUE within the AppServer session and setting it to FALSE shortly after.
NOTE: You might want to run all of your requests on a bound connection, if you use a briefly-bound approach. In a briefly-bound approach, you reserve all context maintenance to a few requests on the bound connection during processing that is free of user interaction or other client-blocking activity. Then, you make the connection unbound before performing any blocking or other intensive activity (think time) on the client. With briefly-bound connections, the AppServer remains free to service other clients most of the time and with fewer Application Server process required.In addition, all requests for a stateless AppServer go through the Application Broker. Thus, two messages are sent for each request. One message travels between the client and the Application broker and the other message travels between the Application Broker and the Application Server process. However, because a state-aware or state-reset AppServer maintains a direct connection between the client and the Application Server process, only one message is sent per request. Under these conditions, your only choice, to both maintain AppServer context and increase the response of the AppServer to client connections, might be to use state-aware or state-reset and to add additional computing resources at the AppServer site to sustain the client connections.
Considering Ample Computer Resources
Note that for the most part, using stateless only makes sense when you must provide high throughput with minimal computing resources. Even if you only have minimal context that needs to be maintained between requests, if you have plenty of computing resources relative to your current and expected client load, then there is no inherent advantage to using stateless. Under these more favorable conditions, even if there is only minimal context to manage, using state-aware (or state-reset) might provide a somewhat simpler programming model.
Considering the Future
When considering whether to use stateless, be sure to consider your current and future performance goals. Redesigning a state-aware or state-reset application to be stateless can be very complicated. Even if your current goals do not require stateless, stateless might still be the right choice based on your future performance requirements.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |