Basics of Client-Server and Applications and Component Configurations in Oracle 12c
The Oracle 12c database doesn’t simply exist in isolation; it acts as part of a computer system. Before installing the Oracle software and configuring your database, you need to know how your database fits into the overall system architecture. Some systems are more complex than others, but most fall into the following basic categories:
Knowing which category your database fits into will make a big difference during your system setup because you’ll know the specific needs of your database.
Client-server applications in Oracle 12c
Client-server applications (sometimes called two-tier applications) are those in which the user’s workstation has the application program installed and, during execution, the program accesses data stored on a remote database server. Although you have some wiggle room here, the workstation handles the presentation and application logic, and the database server acts as a data store. Here’s how a client-server configuration works.
The workstation (client-tier) handles the application logic and presentation to the user. Application logic may be implanted via many different languages, but common examples include PowerBuilder, MS Visual Basic, Java applications, and even some versions of Oracle Forms and Reports.
When these client-side applications need data, they access the database via ODBC (Open Database Connectivity), JDBC (Java Database Connectivity), or Oracle Net by using client-side tnsnames.ora files. These database communication protocols allow connectivity from any client to any database, including Oracle.
On the database tier, the database stores the data and, via users, roles, and permissions, it provides that data to the application in response to SQL queries and data manipulation language (DML) statements (which are simply SQL statements that manipulate, or change, the data). Depending on whether you’re using a fat or thin client, some of the application logic and processing may be off-loaded to the database tier.
Processing on the database server often makes sense because a database server can do much more intensive processing and number-crunching than even the largest workstation. Data processing is commonly executed via database procedures, functions, and packages, which process the data into a smaller result set to be returned to the client for presentation to the user.
Many people have claimed that client-server is dead. If it is, why are so many client-server applications still out there? The client-server architecture is older, and many newer applications exist in the multi-tier world. However, a simple client-server application still meets the immediate needs of a business in many situations. The client-server application may be a legacy application that does its job — so, the business has no need to upgrade.
Component configurations in Oracle 12c
In client-server and multi-tier systems, the Oracle database was the core of the system because it holds the data. Existing as the primary data store for the entire system is the most common use of an Oracle database, but it’s not the only time you’ll have to install Oracle.
For example, often, these databases are in a supporting role, acting as secondary data stores for larger Commercial Off-The-Shelf (COTS) applications. In these cases, Oracle databases act as repositories storing specialized data for use within a larger system. During installation of the larger system, the Oracle database is installed as a supporting component.
One common example of an Oracle repository you may be familiar with is Oracle Designer. You can use this Oracle developer tool to design, create, and store application code (among other things), and it resides on the user’s desktop.
When the user starts Oracle Designer, it prompts for an Oracle repository to connect to, and the user specifies that information. It is within that repository that all the objects to be used by the Designer desktop are stored.
Oracle Internet Directory (OID) is a more current example of Oracle acting as a subcomponent within a multi-tiered environment. OID is the Oracle implementation of an LDAP (Lightweight Directory Access Protocol).
LDAPs are hierarchically defined (not relational) data-stores (not databases) that allow systems quick lookup access of data. A common example is an e-mail address book, which doesn’t contain a lot of updates or deeply layered data — it’s just a need for quick lookups of a piece of data, which is the core use of an LDAP.
Another common LDAP use is to store users and their credentials so that web application servers can simply look up a person to see whether she is authorized to access a system. After all, you don’t want to allow just anyone into your system!
This credential verification creates a need for the Oracle Fusion Middleware products (OFM), and an LDAP is the solution. And, of course, with Oracle being a database company first and foremost, it opted to put its LDAP implementation inside an Oracle database, which is OID.
This is how a specialized Oracle database can provide authentication via OID/LDAP for a larger system that also happens to use Oracle for the backend database where traditional customer data is stored. The OID is just a necessary component in a larger system.