A modern OpenEdge application is designed on OpenEdge Application Architecture (OEAA) principles, which prescribe isolating UI code, business logic code, and data access code into separate layers. You start the design process by identifying the APIs that will be used by client applications and then determining the underlying software components.

OpenEdge Application Architecture

OpenEdge Application Architecture (OEAA) is the recommended way to design an OpenEdge application.

OEAA consists of the following layers:

  • A Data Access layer that manages the retrieval of data from sources such as an OpenEdge database.
  • A Business Components layer that contains the core business logic.
  • A Service Interfaces layer that translates requests into a format that the Business Components layer can process.
  • An Enterprise Services layer that exposes the business logic to applications and services that exist beyond the bounds of the OpenEdge application.
  • A Presentation layer that contains the user interface.
  • A Common Infrastructure layer that contains framework code to support the application business logic. The recommended way to develop components in this layer is to use a framework based on the Common Component Specification.

Common Component Specification

The Common Component Specification (CCS) is a specification which was driven by the OpenEdge community to define a prescriptive architecture to use when building enterprise business applications with OpenEdge. The CCS uses a service-oriented architecture (SOA) design in which application components provide services to other components through a communications protocol. The CCS resulted in a suite of object-oriented ABL classes which exist as part of the OpenEdge.Core.pl/apl procedure libraries. To learn more about these classes, see the OpenEdge ABL API Reference or the ABL Class, Interface, and Enumeration Reference.

API-first design

An API provides a set of functions or procedures that a client application can call on a server application. Modern applications are built API first, which means prioritizing the concerns of the client application developer. You begin by visualizing your application as a set of services that can be easily consumed by client applications. Complexities in your business logic layer are managed in the service interface and hidden from the client application. An API-first design leads to a better developer experience and enables you to add new functionality later, with minimal disruption to existing integrations.

OpenEdge enables you to expose APIs to client applications through ABL services. You can think of an ABL service as having two layers—an API and a service interface. The API is the URI that a client application sends requests to. The service interface is the code that handles those requests and transforms them, if needed, so that the underlying business logic layer can process them.

To learn more about developing APIs in OpenEdge, see API-first development in Develop ABL Services.