Try OpenEdge Now
skip to main content
Developing AppServer Applications
AppServer and Client Interaction : Session models and application services : Choosing a session model : Making the final choice
 
Making the final choice
As an aid to choosing a session model, the following table shows major points of comparison between the session-free and session-managed models.
Table 1. Session-free and session-managed models compared
Point comparison
Session-free
Session-managed
AppServer operating mode
Supported by the state-free operating mode.
Supported by the state-aware, state-reset, and stateless operating modes.
AppServer application programming model
Every application service or Web service request is independent of every other request. No session context is maintained between the client and the AppServers involved in the requests.
The use of RUN PERSISTENT to instantiate remote persistent procedures is not recommended. Instead, use the SINGLE-RUN or SINGLETON option (supported for ABL clients only).
The use of connection-based interfaces (SubAppObjects and ProcObjects) is not recommended.
The use of connect and disconnect procedures in the AppServer configuration is not allowed.
Every application service or Web service request is associated with a single connected client and AppServer. Session context for that client can be maintained by the AppServer across client requests.
Compatibility with different ABL clients
Compatible with all ABL clients, including Web service clients supported by the WSA (or OpenEdge Adapter for Sonic ESB) and Internet clients supported by the AppServer Internet Adapter (AIA).
Compatible with all ABL clients, including Web service clients supported by the WSA (or OpenEdge Adapter for Sonic ESB) and Internet clients supported by the AppServer Internet Adapter (AIA).
Client connection model
The client application does not physically connect to or disconnect from an AppServer.
The client logically connects to an application service or Web service and simply sends requests to any available AppServer and handles the responses from wherever they are sent.
Before sending any other Web service request, the client application must first establish a physical connection to a single AppServer instance through an application service or Web service it wants to access.Once a physical connection is established, the AppServer can maintain session context for the client and application service, but for a Web service, both the Web service client and the Web service must maintain awareness of the physical connection using SOAP headers. The client developer must program the handling of these headers in the client application.
Communications between client and AppServer
Clients of the AppServer exchange messages transparently with any available AppServer resource using a pool of physical AppServer connections (connection pool) maintained by the WSA and OpenEdge Adapter for Sonic ESB for Web services and maintained by the client session for all other clients.
Thus, AppServer resources handle all client requests in parallel, depending on the resources available.
Each client of the Web service creates a separate and exclusive connection over which all messages are exchanged with a particular AppServer resource until the connection is terminated.Thus, the AppServer resource handles each client request in sequence, executing each request only after the previous request from the client has completed.
Thus, if your application requires the AppServer to manage context for its clients, choose a session-managed operating mode (stateless, state-aware, or state-reset). Also, if you are Web-service–enabling an existing AppServer application that relies on a specific operating mode, you must continue to use that mode for the Web service unless you make the necessary changes in the application to use another operating mode.
If your application requires no context management on the AppServer and otherwise has no programming dependency on a session-managed operating mode, you can choose the session-free operating mode (state-free). For an existing session-managed AppServer application that meets these requirements (maintains no context), you can immediately change the AppServer operating mode to state-free with no code changes, thus converting the entire application to a session-free model with potentially greater performance benefits.
Note: If you do convert an existing AppServer application from the session-managed to the session-free model, be sure to set any AppServer instances that support the same application service to the state-free operating mode.
If you can use the session-free operating model, it has the following advantages over the session-managed model:
*Both application services and Web services scale much more readily compared to session-managed.
*The programming model for session-free applications—for the AppServer application and for the client application—is simpler than for session-managed applications.
For more information on programming:
*Session-free and session-managed AppServers, see Programming the AppServer.
*Session-free and session-managed ABL clients, see ProgrammingABL Client Applications.
*Session-free and session-managed Open Clients, see OpenEdge Development: Open Client Introduction and Programming.
*Session-free and session-managed Web service clients of OpenEdge Web services, see OpenEdge Development: Web Services.
Note: If your aim in choosing the session-free model is greater scalability and performance, and you also require secure connections, note that using either (or both) the AIA with HTTPS or an SSL-enabled AppServer tends to incur heavy performance penalties regardless of the session model that you choose. For more information, see the sections on security considerations in Design and Implementation Considerations.
Whatever session model your AppServer application supports, you must also perform these tasks for a Web service:
*Specify the same session model for any Web service definition based on the same application service. For more information on specifying the session model for a Web service definition using ProxyGen, see OpenEdge Developmentc_asaps_design-and-implementation-considerations_oe.xml: Open Client Introduction and Programming.
*Manage the Web service through the WSA (or OpenEdge Adapter for Sonic ESB) according to the same session model. For more information on managing Web services for a given session model, see the chapters on Web service management and deployment in OpenEdge Application Server: Administration.