Oracle APEX & Multi-Tier

Some month ago, I started a conversation at LinkedIn of Oracle Application Express- The Official group the terms of “Is APEX a 3-tire?” so it have gathered a lot of interesting comments about that. In this blog I have categorized and rewrite it again, and I hope this document help to better Understanding to all in Oracle Application Express community.

*Comment*

Three-tier is a user interface, business process (business rules) and data storage and data access are developed and maintained as independent modules or most often on separate platforms.

Fundamentally, there are 3 layers, first tier {presentation tier, GUI tier}, second tire {business objects, business logic tier} and third tier {data access tier}. These tiers can be developed and tested separately.
And eventually:

·         { Data Access Layer (it has Connection-string and Data read & execute process)}

·         { Business Object Layer (it has Queries)}

·         {User Interface (Forms & Code Behind)}

*Comment*

In most cases it is 2-Tier using the ORDS adds the 3rd tier and most development environments (if using EPG) are 1-tier. It's all about what you need it to do for you and knowing what how big is enough to accomplish that goal.

*Comment*

A simple installation of Oracle Apex is 2-tiers. But when install and configure Oracle ORDS in Oracle WebLogic or Oracle Glassfish. Your environment both development and production becomes 3-tiers,
because the Oracle Apex is run through Applications server. Is more in a production environment this should be the ideal settings...

*Comment*

I think it can be argued that it provides the benefits we want from three tiers. If we want the tiers to have separation of machines (virtual or physical) then it may not be. But is not the separation of duties (present, business, data logic) in developing and maintaining what we need? Or separation of it into separate code components?
If it is a model to layer system components then it is possible with APEX as presentation layer, PLSQL as business logic and tables/views/other packages as data layer.
Is it a layered development approach we need or is it separation of machines in a network? If it is the latter, then is virtual machines hosted on the same box adequate? If so, separation in different databases (PDBs?) would make it three tiers?

*Comment*

APEX is three tiers. And it may be "details" if everything is in one box or even in one database, there are three separately identifiable components. It is often an academic discussion about unlogical architectural business requirements, like “you should have three tiers", but it is remains true. Apart from the fact that they do or do not contribute to the workload being processed. If needed, they can be separated out later, on growth, but then comes the technical question... Why would you want to, but that's of another category.

*Comment*

If you accept that the data tier and the business logic tier both co-exist separately in the database, then it is a 3-tier architecture.

I have had to present APEX as being three tiers, as some clients blindly include this in their requirements. This is why I usually say that the data tier and the business logic tier are separate but co-exist in the database - which is true. Once they have overcome this conceptual hurdle.

*Comment*

So this isn't to say APEX architecture needs 3 tiers....However, Is it possible that Glassfish/ORDS scalability is limited due to limit on heap size (2, 3 or 4G dependent on OS)? If so, rather than purchasing WebLogic, might a 3rd "tier" be useful to run "n" number of Glassfish/ORDS, increasing scalability?

The 3rd server is clearly unnecessary if your database server is loaded with memory. However, in our cloud world, we can find it (Glassfish/ORDS) less costly and more easily managed to have a 3rd server.

*Comment*

Often times Glassfish/ORDS is on a separate server, if not for MEMORY/CPU reasons, then for security reasons. But the question is, if there's no real business logic in that tier, if the Glassfish/ORDS server is really acting as a proxy server and the business logic is all in the database (via SQL & PL/SQL) and in the front end (via Dynamic Actions and JavaScript), does the Glassfish/ORDS server really make it a 3-tier architecture?

*Comment*

In practicality 2 Tier (which it is) or 3 Tier is a moot point after implementation as moving a tier is not a decision made lightly and is not practiced in a Tier only BOX.
Lack of adoption for theorists often is that it is not three tier even though the database is in Oracle to which my response has always been do you plan to decommission these instances because if you do I agree.
The fact that it is two tier and most infrastructures are database heterogeneous is a drawback however not one that most issues I have run across cannot be overcome using other methods. (ETL, SERVICE, APIs ...)

*Comment*

APEX is a two-tier development environment. But really, the idea with APEX is that you shouldn't care if it was one tier or twenty. When used for its sweet spot, which is developing internal web applications on Oracle Database, no other application development framework will beat it. You do sacrifice some control, but the gains in productivity more than make up for it. Use it for the right projects and it can become your secret weapon that gets projects done!

(2-tier vs. 3-tier) In Oracle APEX:

*Comments*

• But before anyone criticizes this "2-tier approach", I'll leave you with a question - where do you think it's faster and more efficient to access, aggregate, and manipulate data in an Oracle Database - *in* the Oracle Database, natively in PL/SQL, or outside the Oracle Database, across the network wire?

• I think the performance, fast develop and fast modification are highly significant.

• 2-Tier architecture may have some limitations in general, however in case of APEX, it's a big advantage, especially to leverage all wonderful feature of Oracle DB, PL/SQL and SQL and to work with data-driven applications.

• In reality, whether APEX is two-tier or three-tier is not very important. What is important is that it works and scales well - which it definitely does.

• APEX is middle tier killer, since DB is strong enough in most cases.

Figure 1: two-tier

Figure 2: two-tier with mid-tier (Proxy Server)

Figure 3: two-tier with mid-tier (Proxy Server) and Web Server

Conclusion

*Comments*

• In the "typical" configuration, where APEX is co-located in the same database with the workspace application DB objects, then no - it's two-tier and not three-tier. The middle tier, in this configuration, isn't doing too much other than proxying requests between the browser and the APEX engine in the database.

• Sure - you can always access database objects remotely, across a database link, and I guess in that configuration it could be classified as "3 tier". But that is a suboptimal configuration in terms of performance.

• When we develop applications using APEX, we write all business logic in PL/SQL inside DB itself. And all APEX meta-data sits in DB as-well. So we can't separate business layer from data layer in this case (unless using DB links).

• I disagree with most statements here that "APEX is 3-tier" because it uses a Web server. That alone doesn't make it three tier. There is no processing or application logic occurring in the middle-tier, by design. APEX is a "thick database" type of Web application environment because, as stated earlier, rather than trying to reinvent in the middle-tier everything that the database already does well and has done well for 30 years, it simply does it *in the Oracle Database*.

Figure 4: it can be three-tier

Thanks to all involved in discussion:

Joel Kallman
Niall Mc Phillips
Srihari Ravva
Daniel McGhan
Miguel Angel Sipaque Juarez
Jason D Aughenbaugh
Mathias Magnusson
Jan Karremans
Ron Backmann
Yi Li
Dave Anderson