Introduction

Migrating an application from the classic OpenEdge AppServer or the WebSpeed Transaction Server to the Progress Application Server for OpenEdge (PAS for OpenEdge) should involve minimal changes to ABL application code. However, an OpenEdge application may encompass many distributed components including AppServers, Adapters, various types of OpenEdge and non-OpenEdge clients, NameServers, and so forth. In fact, an application may actually be composed of multiple ABL applications, where an ABL application is identified by a unique ABL code base, AppServer, and database.

Therefore, the process of migrating an application to use PAS for OpenEdge instead of the classic OpenEdge AppServer or WebSpeed Transaction Server can be more involved than just moving the ABL code base and database configurations. PAS for OpenEdge is based on a server platform that is entirely different from the classic OpenEdge AppServer. PAS for OpenEdge is, however, designed for use with both current and future applications, with backwards compatibility to ease the burden of migrating current applications.

OpenEdge AppServer

When migrating an ABL application from the OpenEdge AppServer to PAS for OpenEdge, changes to the application should be minimal. However, it is helpful to be aware of the following considerations:

PAS for OpenEdge installation compared to the AppServer — Unlike the classic AppServer, OpenEdge business applications do not run in the PAS for OpenEdge that you install as part of the OpenEdge installation. Instead, applications run in one or more PAS for OpenEdge instances that you create from your OpenEdge PAS for OpenEdge installation as a template. Among other benefits, this means that when you upgrade OpenEdge, you do not lose your previous PAS for OpenEdge instances, as you do any local AppServer instances that you must restore from backup after upgrading.

Migrating to PAS for OpenEdge development and production servers — OpenEdge supports two different types of PAS for OpenEdge installation, a development server where you develop ABL business applications, and a production server where you can deploy business applications that are ready for release. You can develop ABL business applications in a PAS for OpenEdge project that you create in Progress Developer Studio for OpenEdge much as you do in an AppServer project for the classic AppServer. However, unlike the classic AppServer, you cannot deploy non-compiled ABL source code to a PAS for OpenEdge production instance, because, as a security feature, the PAS for OpenEdge production server has no ABL compiler. Therefore, to a PAS for OpenEdge production server you can only deploy compiled r-code.

Client connections compared to the AppServer — There is no direct or "native mode" connection to PAS for OpenEdge from an ABL client (and a Java or .NET Open Client) as there is to the classic AppServer. Because PAS for OpenEdge is a Web server, all clients of PAS for OpenEdge are Web clients and must connect using an HTTP or HTTPS URL to a PAS for OpenEdge Web application (an OE ABL Web application). This connected OE ABL Web application then manages the execution of all server ABL code on behalf of all supported OpenEdge clients.

Supported client types and transports in PAS for OpenEdge — For PAS for OpenEdge, there are no separate adapters (like the WSA or the AIA for the classic AppServer) to allow different types of OpenEdge clients to access an OE ABL Web application over the Internet. Instead, every OE ABL Web application supports up to three separate transports that provide access for the following types of PAS for OpenEdge clients:

When a given client type connects to a PAS for OpenEdge instance, the URL must contain the transport required for that type of client to connect to PAS for OpenEdge. Note that 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. You can also enable or disable each transport that a given OE ABL Web application supports, and thus configure the types of clients that the OE ABL Web application supports.

Distributing client requests on PAS for OpenEdge — Each deployed OE 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 (PAS for OpenEdge, or server 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 server sessions at once, allowing a single PAS for OpenEdge instance to handle multiple requests from one or more clients in parallel. Thus, compared to the classic AppServer, where every server session runs in its own agent (OS process), a PAS for OpenEdge instance can process the same client load using fewer OS resources.

Executing client requests on PAS for OpenEdge — To execute client requests, each multi-session agent actually maintains two pools within its single process space: a pool of server sessions (ABL execution contexts) and a pool of AVMs (ABL Virtual Machines) that execute the ABL code. When a multi-session agent receives a client request, it associates an available server session (ABL execution context) with an available AVM, and the AVM executes the ABL code to handle the request in the associated session context. When the AVM completes execution for the client request, both the AVM and its associated server session are returned to the agent's respective pools. The newly available session retains all context (global data) established for the most recent client request unless it is explicitly cleared by the application during handling of the request.

PAS for OpenEdge application models and AppServer operating modes — Unlike the classic AppServer, which supports four different operating modes, PAS for OpenEdge supports only two operating modes, referred to as application models, which include session-managed and session-free. The PAS for OpenEdge application model is thus closely equivalent to the AppServer session model, where the PAS for OpenEdge session-managed model runs most like the AppServer stateless operating mode and the session-free model runs almost exactly like the AppServer state-free operating mode.

Although the PAS for OpenEdge session-managed application model runs like the AppServer stateless operating mode, you can emulate either the AppServer state-reset or state-aware operating mode on a PAS for OpenEdge instance by running session-managed requests with minor code changes to the original AppServer Connect and Disconnect configuration procedures (referred to as event procedures on PAS for OpenEdge).

Note also, that you do not configure a PAS for OpenEdge instance to support a single application model as you do an AppServer instance to support a single operating mode. Instead, every PAS for OpenEdge instance supports both application models simultaneously, and each client connection identifies the application model that the connected OE ABL Web application uses to service all requests from that connected client. The client identifies the application model for PAS for OpenEdge to run in exactly the same way as it identifies the session-model when connecting to the classic AppServer. Thus, any available PAS for OpenEdge session can handle requests from a given client according to the application model that it requires.

This means that as long as you migrate ABL code to a PAS for OpenEdge instance from one, and only one, 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 AppServer applications running in different operating modes to a single PAS for OpenEdge instance, you will probably have to make many more code changes, especially to PAS for OpenEdge event procedures, in order to handle the context management for any changes in application model and binding state for each client connection.

Self-service and network database connections on PAS for OpenEdge — On the classic AppServer, every agent session establishes its own self-service connection to a local database. This means that on the AppServer there are as many self-service connections to the database as there are started sessions that have made them. In PAS for OpenEdge, any self-service connection to a local database must first be established by a multi-session agent; then all server sessions managed by that agent make their own user connections to the same database that share the agent's self-service connection. This means that on PAS for OpenEdge, there are only as many separate self-service connections to the database as there are multi-session agents, each of which is shared by all of the server sessions that the agent manages. However, server sessions continue to make their own network database connections on PAS for OpenEdge just as they do on the AppServer.

Fault tolerance and load balancing with PAS for OpenEdge — PAS for OpenEdge instances do not support application services that can be accessed through a NameServer. There is no NameServer or Unified Broker architecture in PAS for OpenEdge, because PAS for OpenEdge is essentially a Web server. However, you can achieve fault tolerance and load balancing across multiple PAS for OpenEdge instances that support a single session-free business application by registering the instances with a Domain Name System (DNS) load balancing service, like Apache Camel. In this case, your PAS for OpenEdge clients connect to the DNS load balancer using a URL that identifies the same OE ABL Web application and the appropriate connection transport supported by all the registered PAS for OpenEdge instances. Depending on the load balancing service, it can then delegate client requests to the available PAS for OpenEdge instances using several different load balancing policies.

WebSpeed Transaction Server

WebSpeed on PASOE employs a more integrated architecture compared to classic WebSpeed because both the Web server and the WebSpeed Transaction sever are combined in a single instance.

WebSpeed on PASOE is more efficient than classic WebSpeed regarding the management and the availability of the agents that handle client requests.

Classic WebSpeed only supports the GET and POST HTTP verbs. WebSpeed on PASOE supports all standard HTTP verbs.

WebSpeed on PASOE supports event procedures that were not supported on classic WebSpeed.

PAS for OpenEdge includes support for multiple servers in a single instance; you do not need to configure and run separate Web server, WebSpeed Transaction server, and AppServer instances.

PAS for OpenEdge shares a single security context among the WEB transport that supports WebSpeed and the other transports (REST, SOAP, and APSV).

Introduction

OpenEdge AppServer

WebSpeed Transaction Server

See also