Differences between PAS for OpenEdge and Progress AppServer

The following list presents the key points that will influence your migration plans.

• PAS for OpenEdge is a web server platform. PAS for OpenEdge is a unified web server platform built on Apache Tomcat web server technology and enhanced by OpenEdge development to manage the specific needs of OpenEdge clients. Because the underlying technology is different, there are differences in how you install, configure, connect, and run applications using PAS for OpenEdge
• Licensing is different. PAS for OpenEdge is available as two separate product licenses:
  • The Progress Development Application Server for OpenEdge is a web server for developing and testing OpenEdge applications.
  • The Progress Production Application Server for OpenEdge is a secure web server for OpenEdge production application deployment.
• Applications run in an instance. Unlike the classic AppServer, applications do not run in the PAS for OpenEdge installation directory. Instead, applications run in one or more instances that you create based on the installation template. This makes future upgrades easier because changes made in an instance can be kept when you upgrade to a new release. Additional backup and restore steps are not required for upgrading classic AppServer applications.
• Special adapters are no longer required. With PAS for OpenEdge, there are no special adapters (WSA or AIA) to support different OpenEdge client types. Instead, instances support four transport types to connect all existing and future client types.
  • APSV transport is for ABL clients, Java clients, or .NET OpenClients.
  • REST transport is for existing REST, mobile, and web clients.
  • SOAP transport is for SOAP web service clients.
  • WEB transport is for WebSpeed and new web service clients.
  When a given client type connects to an instance, the URL must contain the transport required for that type of client. These transports are important when you configure security. You can enable and disable a transport for a given ABL web application to secure specific applications.

  Note: For OpenEdge REST web services implemented on the AppServer, you can migrate the AppServer business application to a PAS for OpenEdge instance so that existing clients of OpenEdge REST and Data Object Services can connect and send requests using the same resource URIs. New REST applications should be implemented with the WEB transport to access more REST methods.
• Clients connect differently. Client connections are standardized on HTTP or HTTPS URL connections to a web application (an OpenEdge ABL web application derived from oeabl.war). The OpenEdge ABL web application, also known as an ABL web application, then manages the execution of all server ABL code on behalf of all supported OpenEdge client types. Your applications no longer use direct or native mode connections to an instance from an ABL, Java, or .NET Open client as they did with the classic AppServer.
• Client requests are distributed differently. Each deployed ABL web application includes a session manager that handles all client connections to the web application, and distributes client requests to the server's available multi-session agents, which in turn pass each request to an available ABL session. Each configured multi-session agent is a separate operating system process that maintains a pool of ABL sessions that are used to execute all client requests sent to that agent. Depending on the application, each multi-session agent process can run requests in multiple ABL Sessions at one time, allowing a single agent process to handle multiple requests from one or more clients in parallel. Therefore, compared to the classic AppServer, where every ABL Session runs in its own agent (OS process), the multi-session agent process can handle the same client load using fewer OS resources.
• Two application models replace four operating modes. Unlike the classic AppServer, which supports four different operating modes, PAS for OpenEdge instances support two operating modes, referred to as application models. The supported models are:
  • Session-free model which runs almost exactly like the classic AppServer's state-free operating mode
  • Session-managed model runs similarly to the classic AppServer's stateless operating mode.
  Note: You can emulate state-reset or state-aware operating modes with code changes to the connect and disconnect configuration procedures, referred to as event procedures for an instance. For more information, see Migrate classic AppServer operating modes.
• Client connections set the application model, not the server. You do not configure an instance to support a single application model as you do with the classic AppServer. Each client connection identifies the application model that the connected ABL web application uses to service requests from that connected client. This is the same way that a client identifies the session mode when it connects to the classic AppServer. The benefit of this type of connection is that any available session can handle requests from any given client according to the application model that it requires. When you migrate ABL code to an instance from a classic AppServer application, the code should run on that instance with very few (if any) changes, as described in ABL Application Code Migration. If you try to migrate multiple classic AppServer applications running in different operating modes to a single instance, you must make more code changes, especially to an instance's event procedures, in order to handle the context management for any changes in the application model and binding state for each client connection.
• Client requests are processed simultaneously within the same agent OS process. To execute client requests, each multi-session agent maintains two pools within its single process space: a pool of ABL Session contexts and a pool of ABL Virtual Machines (AVMs, which are threads in the agent process) that execute the ABL code. When a multi-session agent receives a client request, it associates an available ABL Session context with an available AVM, and the AVM executes the ABL code to handle the request in the associated session context. When the AVM finishes executing the client request, both the AVM and its associated ABL Session context are returned to the agent's respective pools. The newly available ABL Session retains all context (global data) established for the most recent client request unless it is explicitly cleared by the application during the handling of the request.
• Client connections are unbound by default. Client connections are unbound to a session connection to allow efficient reuse of server resources. If your application requires a client connection to be bound to a session connection, then see Manage context for bound and unbound session-managed connections.
• Load balancing is no longer handled by the NameServer. There is no NameServer or Unified Broker architecture in PAS for OpenEdge because each instance is a web server. However, you can achieve fault tolerance and load balancing across multiple instances that support a single session-free business application by registering the instances with an industry-standard HTTP load balancer. Your clients connect to the load balancer using a URL that identifies the same ABL web application and the appropriate connection transport supported by all the registered instances. Depending on the load balancing service, it can then delegate client requests to the available instances using different load balancing policies.
• AppServer KeepAlive (ASK) protocol is no longer supported in PAS for OpenEdge. The ASK protocol feature ensures that an idle AppServer session remains active and prevents it from timing out due to inactivity. This feature was useful in scenarios where a client intermittently communicates with the AppServer, avoiding unnecessary reconnections and overhead.

  This feature is specific to Classic AppServer and it is not supported with PAS for OpenEdge, neither as ClientASK nor ServerASK. Hence, the related connection parameters like AppServer Keepalive and clientASKResponseTimeout are also not supported in PAS for OpedEdge.

Differences between PAS for OpenEdge and the WebSpeed Transaction Server

A detailed introduction to PAS for OpenEdge can be found in Learn about Progress Application Server for OpenEdgeLearn about Progress Application Server for OpenEdge.