If we look at the definition of three tier based solutions this solution consists out of a client tier, application server tier and an infrastructure (database / datastorage) tier. If we look at how this in general is implemented is that the communication between the client tier and the application server tier is commonly done by using a HTTP protocol. The communication between the application tier and the database tier is commonly done by an ODBC/JDBC connection which allows the application server to communicate with the database server. In essence nothing is wrong with this model and this implementation. However, as time progresses we find out that this might not always be the best and the most flexible way of doing. As we are slowly moving to more agile and flexible way and a way where we do use more and more API services in a service / micro-service architecture way the use of JDBC/ODBC connections is not always the standard way of doing things anymore.
By using Oracle REST Data Services (ORDS) you can now more easily connect to a data source (being an Oracle database) by not using JDBC/ODBC connections, however using a REST API. Oracle REST Data Services (ORDS) makes it easy to develop modern REST interfaces for relational data in the Oracle Database and now, with ORDS 3.0, the Oracle Database 12c JSON Document Store and Oracle NoSQL Database. ORDS is available both as an Oracle Database Cloud Service and on premise. ORDS 3.0 itself can now be installed independently of Oracle Application Express (ORDS was formerly known as the APEX listener) and more easily using a new installation wizard. More comprehensive support for the OAuth 2.0 security standard now supports a broader range of use cases.
When implementing a non-direct connection to your datastore you can build more agile applications that will connect to your datasource based upon a rest call rather than connection to it using (for example) JDBC/ODBC. This allows you to ensure your application server only connect to your datasource via REST calls and then communicate to your users, as shown in the diagram below.
As applications more and more demand to not only serve a graphical user interface however also an API (REST-API), it is good practice to also expose the services to your users, as you do want to have a certain level of control and security you most likely do not want to expose your databases or ORDS directly to the users. In this case you, could, create a specific API server. This could also be on the same application server which provides your users with a GUI. This is a decision you can make based upon a number of factors which we will not go into within this post.
Another area in which ORDS can be of great help is by breaking down data silo’s. Commonly enterprise data is hosted in a large number of systems, it is commonly hard to get access to them and quickly build new solutions which need data from multiple silo’s. If you implement a ORDS solution which has access to multiple silo’s you can expose the data in multiple silo’s to a large number of applications and applications servers in a more agile way. Implementing ORDS enterprise wide to help break down data silo’s is a great way of setting your data free to other departments and ensure you can really make benefit of all the data in your enterprise.