As you design your application, you may want to consider how your application will be deployed in a distributed PAS for OpenEdge environment. The following is the hierarchy of components in a PAS for OpenEdge environment:
  • You can create and run more than one instance of PAS for OpenEdge, and you can configure the instances separately. Each instance shares the executables and libraries of a common Apache Tomcat server, but each instance is a separate process that runs in a separate JVM, with its own configuration (ports, security framework, web applications).
  • Each PAS for OpenEdge instance can contain multiple ABL applications. An ABL application is a grouping of ABL web applications and business logic that operates within a unique PROPATH and uses the same database connections and the same application and security configuration. A single ABL application can be used to replace both classic AppServer Agents and WebSpeed Messengers.
  • Each ABL application can contain multiple ABL web applications. A web application is the next level of isolation within an ABL application. It is identified by a unique URL path and security configuration. All HTTP/S requests to that URL are used to access either an ABL Service or some static content.
  • Each web application can contain multiple ABL services. ABL services define published APIs which map to specific ABL classes or procedures and create an abstraction over implementation details such as method and parameter names. Each ABL service is bound to a PAS for OpenEdge transport (WEB, REST, SOAP, or APSV).
  • Each ABL application has its own Multi-session Agent and Session Manager. A Multi-session Agent is a specialized AVM that can run multiple ABL sessions concurrently, allowing one agent to handle requests from multiple PAS for OpenEdge clients. A Multi-session Agent maps one-to-one with an operating system process. The Session Manager is responsible for processing all incoming requests and routing them to the ABL sessions within a Multi-session Agent. Since you can run multiple ABL sessions within a single process, this highly scalable architecture uses fewer system resources than the classic AppServer.

Incorporate continuous availability in your deployment design

Perhaps the most important goal of deployment design is to enable continuous availability and scalability. Continuous availability is the ability to deliver your application to end users without interruption. To achieve continuous availability, your deployment design should have:

  • No single point of failure
  • Use of at least two availability zones in a cloud environment
  • Stateless applications
  • Infrastructure as code

Deployment architecture for continuous availability

A continuously available deployment architecture is composed of several key structures:

  • Load balancer—A full-featured load balancer is a required part of the OpenEdge continuous operations solution. The load balancer is crucial to continuous operations because it redirects traffic from any PAS for OpenEdge instance that is at risk of becoming over loaded to an instance with less traffic. OpenEdge does not have a built-in load balancer. You must choose the correct load balancer with the features that you need.
  • Progress Application Server (PAS) for OpenEdge—PAS for OpenEdge has been designed for scalability and can work seamlessly with load balancers for continuous operation.
  • ABL and SQL applications—Continuous operations can be achieved with applications written in ABL or SQL programming languages because they were designed to push updates and schema changes while the application is online. This eliminates the need to take your application offline for updates or maintenance.
  • OpenEdge database—OpenEdge 12 databases are designed with continuous operation in mind, and they provide a means to update parameters, schemas, and more while they are online.
  • Data replication—Data replication helps you avoid single points of failure by enabling a disaster recovery or a failover site. Replication ensures the availability of an application and distributes copies of data to one or more sites for horizontal scaling. Using OpenEdge database replication is the best way to make your application highly available and fault tolerant. If your production database, database machine, or network becomes unavailable, then you can quickly transition to the replicated database.
  • Monitor the system—To have a continuously operating application, you must constantly monitor your application ecosystem, and have a system that will alert you about potential problems. In OpenEdge 12, this can be accomplished with the OpenEdge HealthScanner, deferred logging, and the OpenEdge Command Center—a cloud-ready management console capable of managing multiple OpenEdge resources and installations across various machines. In addition, if your OpenEdge application, database, and servers are in the cloud, you might use third-party cloud monitoring tools to get a unified view of your environment.