Skip Headers
Oracle® Database Concepts
11g Release 1 (11.1)

B28318-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

10 Application Architecture

This chapter defines application architecture and describes how the Oracle database server and database applications work in a distributed processing environment. This material applies to almost every type of Oracle Database system environment.

This chapter contains the following topics:

Introduction to Client/Server Architecture

In the Oracle Database system environment, the database application and the database are separated into two parts: a front-end or client portion, and a back-end or server portion—hence the term client/server architecture. The client runs the database application that accesses database information and interacts with a user through the keyboard, screen, and pointing device, such as a mouse. The server runs the Oracle Database software and handles the functions required for concurrent, shared data access to an Oracle database.

Although the client application and Oracle Database can be run on the same computer, greater efficiency can often be achieved when the client portions and server portion are run by different computers connected through a network. The following sections discuss possible variations in the Oracle Database client/server architecture.

Distributed processing is the use of more than one processor, located in different systems, to perform the processing for an individual task. Examples of distributed processing in Oracle Database systems appear in Figure 10-1.

Note:

This chapter applies to environments with one database on one server. In a distributed database, one server (Oracle Database) may need to access a database on another server.

Figure 10-1 The Client/Server Architecture and Distributed Processing

Description of Figure 10-1 follows
Description of "Figure 10-1 The Client/Server Architecture and Distributed Processing"

Oracle Database client/server architecture in a distributed processing environment provides the following benefits:

See Also:

Overview of Multitier Architecture

In a traditional multitier architecture environment, an application server provides data for clients and serves as an interface between clients and database servers. This architecture is particularly important because of the prevalence of Internet use.

This architecture enables use of an application server to:

An example of a multitier architecture appears in Figure 10-2.

Figure 10-2 A Multitier Architecture Environment Example

Description of Figure 10-2 follows
Description of "Figure 10-2 A Multitier Architecture Environment Example"

This section includes the following topics:

Clients

A client initiates a request for an operation to be performed on the database server. The client can be a Web browser or other end-user process. In a multitier architecture, the client connects to the database server through one or more application servers.

Application Servers

An application server provides access to the data for the client. It serves as an interface between the client and one or more database servers, which provides an additional level of security. It can also perform some of the query processing for the client, thus removing some of the load from the database server.

The application server assumes the identity of the client when it is performing operations on the database server for that client. The application server's privileges are restricted to prevent it from performing unneeded and unwanted operations during a client operation.

Database Servers

A database server provides the data requested by an application server on behalf of a client. The database server does all of the remaining query processing.

The Oracle database server can audit operations performed by the application server on behalf of individual clients as well as operations performed by the application server on its own behalf. For example, a client operation can be a request for information to be displayed on the client, whereas an application server operation can be a request for a connection to the database server.

Oracle Database as a Web Service Provider

Beginning in Oracle Database 11g, Oracle Database can serve as a Web service provider in traditional multitier or service oriented architecture (SOA) environments. SOA is a multitier architecture in which application functionality is encapsulated in services. Services are designed to support interoperable machine-to-machine interaction over a network. They can be dynamically discovered, and can be queried on available functions and calling sequences.

SOA services are usually implemented as Web services. Web services can be accessed with the HTTP protocol and are based on a set of XML-based open standards, such as WSDL and SOAP.

The Oracle Database Web service capability, which is implemented as part of XML DB, must be specifically enabled by the DBA. Applications can then accomplish the following through database Web services:

  • Submit SQL or XQuery queries and receive results as XML.

  • Invoke standalone PL/SQL functions and receive results.

  • Invoke PL/SQL package functions and receive results.

In a multitier environment, both clients and application servers can invoke database Web services.

Note:

Database Web services provide a simple way to add Web services to your application environment without the need for an application server. However, invoking Web services through application servers such as Oracle Fusion Middleware offers more in the way of security, scalability, UDDI registration, and reliable messaging in an SOA environment. Nevertheless, because database Web services integrate easily with Oracle Fusion Middleware, they may be an appropriate way to help optimize SOA solutions. See the Oracle Fusion Middleware documentation for more information on SOA and Web services.

See Also:

Oracle XML DB Developer's Guide for information on enabling and using database Web services.

Overview of Oracle Net Services

Oracle Net Services provides enterprise-wide connectivity solutions in distributed, heterogeneous computing environments. Oracle Net Services enables a network session from a client application to an Oracle database.

Oracle Net Services uses the communication protocols or application programmatic interfaces (APIs) supported by a wide range of networks to provide a distributed database and distributed processing for Oracle Database.

After a network session is established, Oracle Net Services acts as a data courier for the client application and the database server. It is responsible for establishing and maintaining the connection between the client application and database server, as well as exchanging messages between them. Oracle Net Services is able to perform these jobs because it is located on each computer in the network.

Oracle Net Services provides location transparency, centralized configuration and management, and quick out-of-the-box installation and configuration. It also lets you maximize system resources and improve performance. The Oracle Database shared server architecture increases the scalability of applications and the number of clients simultaneously connected to the database.The Virtual Interface (VI) protocol places most of the messaging burden on high-speed network hardware, freeing the CPU for more important tasks.

See Also:

Oracle Database Net Services Administrator's Guide for more information about these features

This section includes the following topics:

How Oracle Net Services Works

Oracle's support of industry network protocols provides an interface between Oracle Database processes running on the database server and the user processes of Oracle Database applications running on other computers of the network.

The Oracle Database protocols take SQL statements from the interface of the Oracle applications and package them for transmission to Oracle Database through one of the supported industry-standard higher level protocols or programmatic interfaces. The protocols also take replies from Oracle Database and package them for transmission to the applications through the same higher level communications mechanism. This is all done independently of the network operating system.

Depending on the operation system that runs Oracle Database, the Oracle Net Services software of the database server could include the driver software and start an additional Oracle Database background process.

See Also:

Oracle Database Net Services Administrator's Guide for more information about how Oracle Net Services works

The Listener

When an instance starts, a listener process establishes a communication pathway to Oracle Database. When a user process makes a connection request, the listener determines whether it should use a shared server dispatcher process or a dedicated server process and establishes an appropriate connection.

The listener also establishes a communication pathway between databases. When multiple databases or instances run on one computer, as in Oracle Real Application Clusters, service names enable instances to register automatically with other listeners on the same computer. A service name can identify multiple instances, and an instance can belong to multiple services. Clients connecting to a service do not have to specify which instance they require.

Service Information Registration

Dynamic service registration reduces the administrative overhead for multiple databases or instances. Information about the services to which the listener forwards client requests is registered with the listener. Service information can be dynamically registered with the listener through a feature called service registration or statically configured in the listener.ora file.

Service registration relies on the PMON process—an instance background process—to register instance information with a listener, as well as the current state and load of the instance and shared server dispatchers. The registered information enables the listener to forward client connection requests to the appropriate service handler. Service registration does not require configuration in the listener.ora file.

The initialization parameter SERVICE_NAMES identifies which database services an instance belongs to. On startup, each instance registers with the listeners of other instances belonging to the same services. During database operations, the instances of each service pass information about CPU use and current connection counts to all of the listeners in the same services. This enables dynamic load balancing and connection failover.

See Also: