Oracle Web Listener

The Web Listener is the second component of the Oracle web architecture. It is an HTTP engine, similar in role to an Oracle background process, located on the Oracle host that manages incoming requests for services. Each host may run multiple listener processes depending on the processing needs of the web server deployment.

The Web Listener acts as the entry point for all web traffic destined for the Oracle database. It receives HTTP/HTTPS requests from browsers and client applications and routes them to the appropriate processing layer — historically the Web Request Broker (WRB) or CGI, and in Oracle 23ai, Oracle REST Data Services (ORDS). Oracle now recommends ORDS as the sole web listener for all new Oracle APEX deployments; the legacy Oracle Web Listener based on Apache HTTP Server is deprecated.

As the diagram shows, the modern Oracle web listener (ORDS) handles the complete request lifecycle across five phases:

1. ORDS receives the web request: a web user or browser sends an HTTPS request to ORDS. ORDS runs in one of three servlet containers — Standalone ORDS/Jetty, Apache Tomcat, or Oracle WebLogic — depending on the deployment configuration.
2. ORDS routes the request for processing: the ORDS request routing engine examines the URL pattern and routes the request to the appropriate handler — an APEX Application, a REST API Module, or the PL/SQL Gateway.
3. Oracle 23ai processes the request and builds the response: the ORDS application layer sends a database call to Oracle Database 23ai. Oracle executes the SQL, PL/SQL, APEX Engine processing, or JSON/Duality View operation and returns the raw result set — rows, JSON, or data — to ORDS.
4. ORDS prepares the completed web response: the application layer performs data handling, business logic, response formatting, and caching. The result is prepared as HTML, JSON, an APEX page, or a REST API response.
5. The completed response returns to the user: ORDS delivers the HTTPS response back to the requesting browser or client application.

Oracle Application Express supports three web listener choices. All three serve as the HTTP communications broker between the web browser and the Oracle APEX engine in the Oracle database, mapping browser requests into database stored procedure calls or REST operations. The three options differ significantly in status and suitability for new deployments.

Status: The only recommended listener for Oracle 23ai.

ORDS is the undisputed modern standard and the only supported web listener for Oracle APEX environments on Oracle 23ai. It is highly scalable, supports modern REST/JSON standards, and is actively developed by Oracle. Key capabilities in Oracle 23ai:

• Accepts HTTP/HTTPS requests and routes them to APEX, REST API modules, or the PL/SQL Gateway via a configurable request routing engine.
• Manages a pool of JDBC connections to Oracle Database 23ai, handling the impedance mismatch between stateless HTTP and stateful Oracle database sessions.
• Supports OAuth2 authentication and OpenID Connect for secure API access.
• Auto-REST enables tables and views for immediate REST access without writing PL/SQL or Java code.
• Deploys in Standalone/Jetty, Apache Tomcat, or Oracle WebLogic servlet containers.
• Supports sessionless transactions in Oracle 23ai for improved stateless web workload scalability — database sessions are not held open between HTTP requests.

If deploying APEX on Oracle 23ai, ORDS is essentially mandatory as the web listener.

Status: Repurposed — reverse proxy only, not a primary listener.

Oracle HTTP Server historically used the mod_plsql plugin to translate HTTP requests directly into PL/SQL procedure calls against the database. That architecture is obsolete and deprecated. In modern deployments, OHS appears only as a reverse proxy or load balancer sitting in front of ORDS — OHS no longer translates database calls itself. No new deployments should use OHS as the primary web listener for Oracle APEX or database-driven web applications.

Status: Deprecated — do not use for new deployments.

The EPG relied on the Oracle XML DB HTTP Server running directly inside the Oracle database. It was convenient for quick local development in older Oracle versions because no separate web server installation was required. However, it lacked the performance, security features, connection pooling, and REST capabilities required for enterprise applications. Oracle has phased the EPG out for modern APEX deployments and it is not supported for Oracle 23ai production use.

Web Listener Evolution

Oracle 11g: the Web Listener was primarily Oracle HTTP Server, based on Apache HTTP Server with the mod_plsql plugin for PL/SQL procedure access. OHS served Oracle Fusion Middleware components and database-driven web applications. Oracle XML DB HTTP Server provided a lightweight built-in HTTP server for basic HTTP services and XML DB resource access.

Oracle 19c: focus shifted to ORDS as the central component for web-based database interaction. OHS remained but realigned with Oracle Fusion Middleware rather than direct database access. XML DB HTTP Server was further integrated and optimized within the database for streamlined secure HTTP-based access.

Oracle 23ai: ORDS is the sole recommended web listener. OHS is a reverse proxy option only. EPG is deprecated. Sessionless transaction support in ORDS for Oracle 23ai delivers a fundamental improvement in stateless web workload scalability.

ORDS Evolution

Oracle 11g era: ORDS — then called APEX Listener — was used primarily to support Oracle APEX applications. It provided a RESTful interface to the database but was still early-stage and not feature-rich. Manual creation of web services via PL/SQL or Java stored procedures was the common approach for non-APEX web services.

Oracle 19c: ORDS became the central component for RESTful services on Oracle Database. Declarative RESTful web service creation, auto-REST enabling of tables and views, OAuth2 authentication support, and deeper Oracle Cloud integration were introduced. The development burden compared to the 11g era was dramatically reduced.

Oracle 23ai: ORDS supports sessionless transactions, JSON Relational Duality Views exposed via REST, APEX 23.x runtime, and Oracle Cloud Infrastructure (OCI) native deployment. The gap between ORDS and the deprecated alternatives is now too large to justify any use of OHS or EPG for new Oracle APEX deployments.

Key Improvements from Oracle 11g to Oracle 23ai

• Performance and scalability: JDBC connection pooling and sessionless transactions support high-volume web workloads that would have required dedicated application servers and custom connection management code in the Oracle 11g era.
• Security: OAuth2 and OpenID Connect replace the basic HTTP authentication of the OHS/EPG era. Fine-grained privilege control is declarative rather than hand-coded.
• Simplified development: auto-REST, declarative module definitions, and APEX low-code tools reduce the PL/SQL coding burden significantly compared to manual web service construction in Oracle 11g.

For Oracle 23ai deployments the choice is straightforward: use Oracle REST Data Services. For legacy environments that have not yet migrated, the three options are:

1. Oracle REST Data Services — the only recommended option for Oracle 23ai.
2. Oracle HTTP Server — reverse proxy role only in modern architectures.
3. Embedded PL/SQL Gateway — deprecated, not suitable for production use.

Oracle Application Express uses a simple runtime architecture where pages are dynamically generated from metadata stored within the Oracle Database. There is no code generation or file-based compilation. The APEX Engine — running inside Oracle Database 23ai — interprets page metadata at request time and generates the HTML response on the fly. Once APEX is installed, a URL is defined for both developers and end users. Users require only a web browser and the URL — no additional client software is required.

ORDS serves as the communications broker between the browser and the APEX Engine, routing each HTTP request through a pooled JDBC connection to the APEX Engine inside Oracle Database 23ai. The APEX Engine reads the page metadata, executes any PL/SQL associated with the page, and generates the HTML response that ORDS delivers back to the browser. The entire page lifecycle — from HTTPS request to rendered HTML — occurs without any file system reads or compiled code execution outside the database.

The next lesson examines WRB Cartridges — the specialized request handlers that the Web Request Broker used to process different content types, and their modern equivalents in ORDS request routing.