The Oracle Application Server :Oracle Server Technologies and the Relational Paradigm
02.03.2010 by admin - 0 CommentPosted in Oracle
With the emergence of the Web as the standard communications platform for delivering applications to end users has come the need for application servers. An application server replaces the client-side software traditionally installed on enduser terminals; it runs applications centrally, presenting them to users in windows displayed locally in web browsers. The applications make use of data stored in one or more database servers.
The Oracle Application Server is a platform for developing, deploying, and managing web applications. A web application can be defined as any application with which users communicate with HTTP. Web applications usually run in at least three tiers: a database tier manages access to the data, the client tier (often implemented as a web browser) handles the local window management for communications with the users, and an application tier in the middle executes the program logic that generates the user interface and the SQL calls to the database.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
Web applications can be developed with a number of technologies, predominant among which is Java. Applications written in Java should conform to the J2EE (Java 2 Enterprise Edition) standard, which defines how such applications should be packaged and deployed. J2EE and related standards are controlled by Sun Microsystems and accepted by virtually all software developers. Oracle Application Server is a J2EE-compliant application server. Oracle’s implementation of the standards allows for automatic load balancing and fault tolerance across multiple application servers on multiple machines though J2EE clustering. Clustering virtualizes the provision of the application service; users ask for an application that might be available from a number of locations, and the cluster works out from where any one session or request can best be serviced. If one location fails, others will take up the load, and more resources can be made available to an application as necessary.
The ability to separate the request for a service from the location of its provision and to add or remove J2EE servers from a cluster dynamically is a major part of the Oracle Application Server’s contribution to the Grid.
It is important to note that Oracle’s commitment to international standards is very strong. Applications running in the Oracle Application Server environment can connect to any database for which there are Java-compliant drivers; it is not necessary to use an Oracle database. Applications developed with the Oracle Application Server toolkits can be deployed to a third-party J2EE-compliant application server.
The simplest processing model of web applications is three tier: a client tier that manages the user interface; a middle tier that generates the interface and issues SQL statements to the data tier; and a data tier that manages the data itself. In the Oracle environment, the client tier will be a browser (such as Mozilla or Microsoft Internet Explorer) that handles local window management, controls the keyboard, and tracks mouse movements. The middle tier will be an Oracle Application Server running the software (probably written in Java) that generates the windows sent to the client tier for display and the SQL statements sent to the data tier for execution. The data tier will be an Oracle server: an instance and a database. In this three-tier environment, there are two types of sessions: end-user sessions from the client tier to the middle tier, and database sessions from the middle tier to the data tier. The end-user sessions will be established with HTTP. The database sessions are client-server sessions onsisting of a user process and a server process, as described in the previous section.
It is possible for an application to use a one-for-one mapping of end-user session to database session: each user, from their browser, will establish a session against the application server, and the application server will then establish a session against the database server on the user’s behalf. However, this model has been proven to be very inefficient when compared to the connection pooling model. With connection pooling, the application server establishes a relatively small number of persistent database sessions and makes them available on demand (queuing requests if necessary) to a relatively large number of end-user sessions against the application server. Figure 1-2 illustrates the three-tier architecture using connection pooling.
From the point of view of the database, it makes no difference whether a SQL statement comes from a client-side process such as SQL*Plus or Microsoft Access or from a pooled session to an application server. In the former case, the user process all happens on one machine; in the latter, the user process has been divided into two tiers: an applications tier that generates the user interface and a client tier that displays it.
