The application model you choose determines how you want PAS for OpenEdge to service clients, and that choice depends on the type of application you want to support.

Session-managed model

The session-managed model, especially with clients bound to ABL sessions, is specifically designed for business applications or SOAP Web services that support a single transaction across multiple requests from the same client, returning intermediate results with each request until the transaction is completed. Thus, the PAS for OpenEdge instance maintains context between requests for each client that it services, and each such client participates in a persistent connection to the application server. Any bound ABL session is dedicated to serving that one client until the binding between them is unbound.

In this application model, all client requests are single-threaded, meaning that the application server does not handle another request from the same client until it has completed and responded to any pending request from that client.

Session-free model

The session-free model is specifically designed for business applications or SOAP Web services that return a complete result, starting and ending any transactions, in a single request. Thus, the server maintains no context for any client that it services. Requests from a session-free client are handled by any available ABL session in any available multi-session agent that supports the required business application. The session-free client (or the session-free SOAP Web service on behalf of a SOAP Web service client) has each of its server requests executed by an available ABL session chosen by the PAS for OpenEdge session manager from its pool of ABL sessions.. Thus, PAS for OE executes requests from all session-free clients as it receives them, and completes each request independently of any prior request.

In this application model, all requests from a single client are multi-threaded, meaning that multiple requests from a single client can be executed in parallel, as PAS for OE resources permit. The more ABL sessions that are available to handle requests for a given business application (or SOAP Web service), the more requests that the application or SOAP Web service can handle simultaneously from a single client. Each PAS for OE instance executes requests as fast as communications and server agent resources permit. Thus, the same client can have multiple requests executed by an application server at one time, and each application server can execute requests from any number of clients at one time, both limited by the number of ABL sessions and multi-session agents configured for each application server.

Mixed application model

A mixed application model supports a business application that manages data transactions that span multiple requests (session-managed), while at the same time supporting an atomic request model for client operations that stand alone, such as independent queries on the data (session-free).

If your application requires a mixed application model, you have to identify the application model and client binding of each client request before servicing it, because any PAS for OpenEdge session can handle requests for clients running in any application model when the session is not bound to a single session-managed client. This makes the business application code more complex, especially for event procedures you have configured to manage client and session context across client connections and requests.

Making the final choice

As an aid to choosing an application 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
Business application programming model Every business application or SOAP Web service request is independent of every other request. No client or session context is maintained between the client and the servers 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). REST Web services implicitly instantiate procedure objects using the SINGLE-RUN or SINGLETON option, as part of defining them.

The use of connection-based interfaces (SubAppObjects and ProcObjects) is not recommended.

Any Connect or Disconnect event procedures in the PAS for OpenEdge configuration do not execute when the client connects or disconnects (respectively) from the PAS for OpenEdge instance.		 Every business application or SOAP Web service request is associated with a single connected client and PAS for OpenEdge server. Client and session context can be maintained across client requests. Note that for a SOAP Web service, both the Web service client and the Web service must maintain awareness of the connection using SOAP headers. The client developer must program the handling of these headers in the client application.

Any Connect or Disconnect event procedures in the PAS for OE configuration execute as the client connects and disconnects (respectively) from the PAS for OpenEdge instance.
Client Compatibility Compatible with all ABL, REST, and SOAP Web service clients. Compatible with all ABL and SOAP Web service clients.
Communications between client and server Clients of the PAS for OpenEdge instance exchange messages transparently with multiple ABL sessions that the session manager provides from its session pool.

These multiple ABL sessions handle all client requests in parallel, depending on the server resources available.

 Each client creates a separate and exclusive connection over which all messages are exchanged with one or more ABL sessions that the session manager provides from its session pool until the connection is terminated. This connection 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 application server to manage context for its clients, choose the session-managed application model. Also, if you are exposing an existing business application that relies on a specific application model as a SOAP Web service,, you must continue to use that application model for the Web service unless you make the necessary changes in the application to use the other application model.

Note: If you expose the application as a REST Web service, you must ensure that the application uses the session-free model.

If your application requires no context management on the application server, you can choose the session-free application model. For an existing session-managed business application that meets these requirements (maintains no context), you can immediately change the application model to session-free with no code changes, thus converting the entire application with potentially greater performance benefits.

If you can use the session-free application model, it has the following advantages over the session-managed model:

  • Both the business application and SOAP Web services scale much more readily compared to session-managed.
  • The programming model for session-free applications—for both the business application and for the client application can be simpler than for session-managed applications, especially if the relative order of responses to requests does not matter and context management is minimal or non-existent.

For more information on programming:

Whatever application model your business application supports, you must also perform these tasks for a SOAP Web service:

  • Specify the same application model for any SOAP service definition based on the same business application. For more information on specifying the application model for a SOAP Web service definition using ProxyGen, see Learn about Open Clients.
  • Manage the SOAP Web service through the OpenEdge Explorer or OpenEdge Management, or using the command-line tools, according to the same model. For more information on managing SOAP Web services for a given application model, see the sections on Web service management and deployment.