Overview of Oracle Web Applications

When using the web as a front-end to an Oracle database, all displays are delivered as Hypertext Markup Language (HTML) pages, JSON API responses, or Oracle APEX pages. In the legacy era, Active Server Pages (ASP) and CGI scripts were the primary delivery mechanisms. Oracle 23ai delivers web content through Oracle REST Data Services (ORDS), APEX, and custom web applications built on REST principles.

When a request is made to display data from an Oracle 23ai database, the following 8-step flow occurs.

Each numbered step in the diagram corresponds to a distinct phase in the Oracle web request lifecycle:

1. User request: the end user's browser sends an HTTPS request to display data from an Oracle 23ai-backed application.
2. Web listener receives the request: the HTTPS Listener and web tier receive the request and forward it to the application or REST layer — ORDS, APEX, Database Actions, or a custom web application.
3. Request is interpreted: the application layer (ORDS, APEX, or custom web app) interprets the request and translates it into the database operation that must be performed — a SQL query, REST call, or database service request.
4. Routed through Oracle Net: the request is routed through Oracle Net services to the Oracle database listener.
5. SQL reaches Oracle Database 23ai: the Oracle Listener establishes the database session and Oracle Database 23ai executes the SQL or service request.
6. Raw data is returned: Oracle Database 23ai processes the request and returns the raw result set — rows, JSON, or data — to the middle tier.
7. Response is formatted: the application layer formats the result as an HTML page, JSON API response, dashboard view, or APEX page for client consumption.
8. Response returns to the user: the completed HTTPS response is delivered back to the requesting web user's browser.

Modern Oracle web access commonly uses Oracle REST Data Services (ORDS), Oracle APEX, Database Actions, custom web applications, and Oracle Net connectivity to Oracle Database 23ai.

The following browser-based tools and web applications connect to OCI and Oracle 23ai, each addressing a different layer of the web-to-database stack:

• Database Actions (formerly SQL Developer Web): a comprehensive browser-based interface built into ORDS for SQL execution, database object management, and data modeling. The web alternative to the desktop SQL Developer client — no installation required.
• Oracle APEX (Application Express): a low-code web application development platform running directly inside Oracle Database 23ai. Builds scalable, secure web and mobile applications with minimal coding, using SQL, PL/SQL, and declarative components.
• Oracle REST Data Services (ORDS): the mid-tier Java application providing the REST API gateway for web applications, mobile apps, and microservices to interact with Oracle 23ai using standard HTTP methods. Serves as the APEX runtime.
• Data Studio: accessible via Database Actions in OCI for Autonomous Database. Provides data loading from CSV, Excel, and cloud storage sources, analysis tools, and insight generation — all via browser.
• Oracle Machine Learning (OML) Notebooks: a browser-based notebook interface accessed via Database Actions for data discovery, analytics, and building machine learning models directly against live database data.
• Oracle Cloud Infrastructure (OCI) Console: the primary web portal for provisioning, monitoring, and managing Oracle databases in OCI, including Base Database Service, Exadata, and Autonomous Databases.
• Oracle Enterprise Manager (Cloud Control): an enterprise-grade web console for monitoring health, performance, and security of Oracle databases from 11g R2 through 23ai, on-premises and in the cloud.

Using the web as a front-end to Oracle follows the same architectural principles as traditional client-server front-ends. Oracle SQL*Forms, Microsoft Visual Basic, and Sybase PowerBuilder all applied the same request/response pattern — a client submits a request, middleware routes it to the database, the database executes it, and results are returned to the client for display. The web simply replaces the proprietary client with a browser and the proprietary network protocol with HTTP.

In Oracle 23ai, ORDS and APEX replace the legacy CGI and Web Request Broker (WRB) layers. The advantages over the legacy architecture are significant: connection pooling is handled natively by ORDS rather than per-request CGI process spawning, REST-native interfaces eliminate the need for custom broker software, and cloud-native deployment in containers or OCI provides horizontal scalability that the legacy WRB architecture could not match.

Multiple factors affect the performance of a web database application. The DBA's tuning window is defined as the interval from the moment a URL request is intercepted by the web tier until the Oracle transaction is completed and the result is returned to the client. The focus is on the processes occurring between two points:

• The point a query enters the application layer (ORDS or APEX)
• The point the result row data is shipped back to the web tier

This is the same Oracle database used in all other deployment environments — the web-based front-end changes the delivery mechanism but not the database engine. SQL tuning, index optimization, execution plan analysis, and AWR-based diagnostics that apply to SQL*Forms, JDBC, and ODBC applications apply equally to web-facing Oracle workloads. The web tier introduces additional tuning dimensions: connection pool sizing in ORDS, APEX session management, HTTP keep-alive settings, and Oracle Net configuration for latency-sensitive web transactions.

The next lesson examines the Web Request Broker — its components and how it routes requests between the web listener and the Oracle database.