An RDBMS-Only
Architecture for
Web Applications
Alfonso Vicente, Lorena Etcheverry, Ariel Sabiguero
Facultad de Ingeniería – Universidad de la República
What is a web application ?
Let's see a dialogue between
the architect (A) and the questioner (Q)
What is a web application ?
A) Speaking minimally:
an application that is accessed by HTTP
Q) What about persistence ?
What is a web application ?
A) Ok: an application that is accessed by HTTP,
tipically uses an RDBMS for persistence,
and some kind of "program" between
the RDBMS and the web server
Q) Can we see the server side only ?
What is a web application ?
A) Here it is
Q) Where is the complexity located ?
A) In the “program”
Q) And what is the "program"?
A) Something outside the RDBMS
What is a web application ?
Q) Why not inside ?
A) For many reasons: Object Oriented Programming, SOA, microservices,
scalability, … and many more
Q) But theoretically, the complexity could be distributed in any way among tiers
A) … sure
The problem
How much complexity is it possible to move to the RDBMS ?
The same problem in other ways:
Is it possible to develop a web application only with an RDBMS ?
How could such an architecture be described ?
Does this have any advantage ?
Complexity location
client-tier middle-tier data-tier
Theoretically thin thin thin
(Koppelaars classification) thin thin fat ←Thick Database
thin fat thin ←Thick Middleware
- each tier can be thin or fat thin fat fat
- fat means “lots of code” fat thin thin
- 23 = 8 combinations
fat thin fat ←Almost C/S
- thin/thin/thin case has no interest
fat fat thin
- thin/thin/fat is “Thick Database”
- thin/fat/thin is “Thick Middleware” fat fat fat
Complexity location
client-tier middle-tier data-tier
In practice thin thin thin
(Koppelaars classification) thin thin fat ←Oracle APEX
thin fat thin ←Jakarta EE
- wide diversity out there thin fat fat
fat thin thin
fat thin fat ←Oracle Forms
fat fat thin
fat fat fat
Thick Database (ThickDB)
There are Thick Database
web applications
Lots of code in Database
Programming Language (DBPL)
They can be thin/fat/fat,
thin/thin/fat, …
… and thin/zero/fat ?
RDBMS & web listener
Presentation and business layers can be
implemented in the RDBMS with the DBPL
RDBMS only needs a listener to translate
from HTTP to DBPL and vice versa
DBPL Requests and Responses can have
the same logic as HTTP Requests and Responses
The curious case of Benjamin Oracle Button
Forms client/server architecture (fat/zero/fat)
The curious case of Benjamin Oracle Button
Forms web architecture (thin/fat/fat)
The curious case of Benjamin Oracle Button
APEX architecture (thin/zero/fat)
The curious case of Benjamin Oracle Button
Arrow of time ?
Complexity location (again)
Oracle says APEX has a “simple architecture”
Where did the complexity go ?
Complexity cannot be removed, it can only be moved
The physical view of the architecture is simple, the logical view is not
The RDBMS-only architecture
Logical view of the RDBMS-only architecture
Each component has its own complexity
Separation of concerns through schemas and permissions
The RDBMS-only architecture
Data Logic (DL) Code: the only layer that uses SQL,
provides access to data as Abstract Data Types
Can be generated and synchronized with the database schema automatically
The RDBMS-only architecture
Business Logic (BL) Code: consumes the DL Code layer’s operations and
contains the logic of the domain.
Offers high-level operations in procedural format with the data types of the
RDBMS.
The RDBMS-only architecture
Interface Wrapper: consumes the BL Code layer’s high-level operations.
It offers them to the upper layers, but with inputs and outputs in a standard
text-based format independent of the RDBMS data types and the interface,
such as XML or JSON.
The RDBMS-only architecture
Service Interface (SI) Code: planned for Web Services, tipically REST on top
of Interface Wrapper layer’s high-level operations
The RDBMS-only architecture
User Interface (UI) Code: designed for end customers through a web browser.
Should only be sufficient to offer interface elements, but this is not enough
to generate the browsing experience in a web application. For that, we must
have a navigation model.
The RDBMS-only architecture
The engine attends to requests, implements the navigation model between
pages, resolves authentication and authorization, maintains the state of the
sessions, etc.
The RDBMS-only architecture
The engine model needs to be complex,
even to support basic navigation functionalities
The main hierarchy to support user interface
navigation is:
Application → Page → Region → Item
Session variables are a must to maintain state
The prototype
We build a prototype using PostgreSQL as RDBMS and an Apache module
as web listener. Any request like [Link]
that arrives at the host and port where the Apache serves activates the
mod_plpgsql module’s handler and its code will process the request.
The prototype
URL of a GET Request
plpgsql/conf?g&p=app[:page[:ses]]
URL of a POST Request
plpgsql/conf?p
(parameters should be passed as a JSON map)
In both cases a getpage function is called
The prototype
Each call to getpage() returns the HTML code of a page, including
links or forms to navigate to other pages (we call the prototype webpg)
Experiments
A small but realistic application was developed from the prototype
We decided to implement the TPC Benchmark W (TPC-W) for two reasons:
1. It would allow to validate the feasibility of the technology
2. There was an implementation of TPC-W in Java Servlets,
which would allow to compare performance
Experiments
We run performance tests using:
- the same database
- the same schema
- the same data
- the same navigations (catch & reply strategy)
The two applications were identical in appearance
and behavior, but while the existing implementation
was Thick Middleware,ours was Thick Database
Experiments
Frequencies of loading times for two
of the most accessed pages were
compared during Shopping Mix
interactions
10 Emulated Browsers (EB)
running concurrently for one hour
No significant performance
differences
Open issues
Version control and change management
Availability of general-purpose libraries
Development tools like IDEs and debuggers
Conclussions
It is possible to develop a web application only with an RDBMS
This extreme database-centric architecture (RDBMS-only)
have not been previously addressed or described
Beyond Oracle APEX, there are no RDBMS-only
industrial-grade technologies
Much more research work is needed in this area
Conclussions
RDBMS-only architecture may be especially suitable when:
- There is a large business code base in the DBPL of an RDBMS
- There are developers who are experts in the DBPL
- You want to develop data-centric applications
- You want to reduce technological complexity
Questions ?
… and perplexities too
