First I want to discuss terminology which you will encounter in Oracle Documentation.
The Oracle Applications Architecture is a framework for multi-tiered, distributed
computing that supports Oracle Applications products. In this model, various servers are
distributed among multiple levels, or tiers.
• Server - is a process or group of processes and provides a particular
functionality/service For example, Database Server listen and process database
requests, similarly Web Server listens for and processes HTTP requests.
• Tier - is a logical grouping of services, may be on single machine or
spread across more than one physical machine. For Example, Middle Tier in
Oracle apps consist Form,Web,Report...Services. Forms & Report can be one
machine 1 & Web Server can be on machine 2, still they will be part of same
tier called as Application Tier or Middle Tier.
• Node - is referred as Machine, Each tier may consist of one or more
node and each node can potentially have more than one tier.
• Server - is a process or group of processes and provides a particular functionality/service For example, Database Server listen and process database requests, similarly Web Server listens for and processes HTTP requests.
• Tier - is a logical grouping of services, may be on single machine or spread across more than one physical machine. For Example, Middle Tier in Oracle apps consist Form,Web,Report...Services. Forms & Report can be one machine 1 & Web Server can be on machine 2, still they will be part of same tier called as Application Tier or Middle Tier.
• Node - is referred as Machine, Each tier may consist of one or more node and each node can potentially have more than one tier.
Architecture:
The three disctinct “Tiers” in Oracle applications are:
1. Desktop Tier
2. Application Tier
3. Database Tier
The Desktop Tier:
The client interface is provided through HTML for the Self-Service interface, and a Java applet for the professional, forms-based interface using a Java-enabled Web browser. The desktop client with Oracle JInitiator downloads the applet on demand and the applet is cached locally for future use.
In Oracle Applications Release 11i, each user logs in to Oracle Applications through the E-Business Suite Home Page on a desktop client web browser. The E-Business Suite Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.
The Forms client
applet is a general-purpose presentation applet that supports all Oracle
Applications Forms-based products, including those with customizations and
extensions. The Forms client applet is packaged as Java archive (JAR) files.
The JAR files contain all Java classes required to run the presentation layer
of Oracle Applications forms. The Forms client applet and
commonly used JAR files are downloaded from the Web server at the
beginning of the client’s first session. Other less commonly used JAR
files are downloaded as needed. The JAR files remain in the disk cache on the
desktop, ready for future sessions, minimizing network traffic. All updates are
installed on the application tier and downloaded to the client automatically
through the use of the JInitiator-enabled Web browser.
Oracle JInitiator:
The Forms client
applet must run within a Java Virtual Machine (JVM) on the desktop. For
Oracle Applications, the JVM is supplied by Oracle JInitiator. Oracle JInitiator
works in conjunction with the Web browser. It is implemented on the desktop
client as a plug-in (Netscape Communicator) or ActiveX component (Microsoft
Internet Explorer). When a user enters the desired Oracle Applications
sign-on URL within the Web browser, Oracle JInitiator is executed. If
Oracle JInitiator has not been installed, the Web browser prompts the
user to download the necessary installation executable to the desktop client.
Once installed, Oracle JInitiator runs the Forms client applet and starts
an Oracle Applications session.
The Application Tier:
The application tier has a dual role: hosting the various servers that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier. Oracle9i Application Server (9iAS) provides the technology used on the application tier. Six servers comprise the application tier for Oracle Applications:
• Web server
• Forms server
• Reports server
• Discoverer server (optional)
• Concurrent Processing server
• Admin server
The application tier
supports load balancing among many of its servers to provide higher
availability, fault tolerance, reliability, and optimal scalability. Load
balancing occurs when there are multiple installations of the following:
■ Web server
■ Forms server
■ Reports server
■ Concurrent Processing server
■ Admin Server
Web Server:
The Oracle HTTP server (powered by Apache) acts as the Web server. It processes the requests received over the network from the desktop clients, and includes additional components such as:
• Web Listener
• Java Servlet Engine
• JavaServer Pages (JSP)
The Web listener component of the Oracle HTTP server accepts incoming HTTP requests from client browsers.
The Oracle Applications Framework is the development platform for HTML-based applications. It consists of a Java-based application tier framework and associated services, designed to facilitate the rapid deployment of HTML-based applications.
Notable Oracle Applications Framework components include:
• Business Components for Java (BC4J), included in Oracle JDeveloper, is used to create Java business components for representing business logic. It also provides a mechanism for mapping relational tables to Java objects, and allows the separation of the application business logic from the user interface.
• AOL/J supplies the Oracle Applications Framework with underlying security and applications Java services. It provides the Oracle Applications Framework with its connection to the database, and with application-specific functionality such as flexfields.
HTML Based Applications
Java Servlet Access with HTML-Based Applications
An HTML-based Applications module uses the following access path:
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
3. The Web listener contacts the Servlet engine (JServ) where it runs a JSP.
4. The JSP obtains the content from the Applications tables and uses information from
the metadata dictionary to construct the HTML page.
5. The resulting HTML page is passed back to the browser, via the Web server.
Forms Server:
The Forms server caches data and provides it to the client as needed, for example when scrolling through multiple order lines that exceed the limitations of a single screen. The Forms server communicates with the desktop client using these protocols:
• Standard HTTP network connection
• Secure HTTPS network connection
• TCP/IP connection
Forms Server Architecture
Reports Server:
The Reports server is automatically installed on the same node as the Concurrent Processing server, and its reports are contained in the same directory as the concurrent processing reports. However, reports generated by the Reports server are monitored and administered separately from concurrent processing reports. The Reports server dynamically selects the report language at run-time, so users see
their reports in their preferred language.
Reports Server Architecture
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
3. The Web listener contacts the Reports server through the reports Web CGI. The reports Web CGI allows the user to run reports and see the output through a Web browser.
4. The Reports server starts the Reports runtime engine.
5. The Reports runtime engine locates the necessary reports and connects to the database to query the requested information.
6. The queried information is presented to the user in the form of an HTML page
Concurrent Processing Server:
User interactions with Oracle Applications data are conducted via HTML-based Applications or the more traditional Forms-based Applications. However, there are also reporting programs and data updating programs that need to run either periodically, or on an ad hoc basis. These programs, which operate in the background while users continue to work on other tasks, may contain a very large number of data-intensive computations, and are run using the concurrent processing architecture. To ensure that resource-intensive concurrent processing operations do not interfere with interactive operations, they are run on a specialized
server, the Concurrent Processing server.
Concurrent Processing O/P
Processes that run on the concurrent processing server are called concurrent requests. When you submit such a request, either through HTML-based or Forms-based Applications, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads the applicable requests in the table, and starts the associated concurrent program. The Internal Concurrent Manager service monitors the database table for new requests, controls the other concurrent managers, and determines when a request should be processed and which concurrent manager should carry it out.
Parallel concurrent processing enables you to:
• Run concurrent processes on multiple nodes to improve concurrent processing throughput.
• Continue running concurrent processes on the remaining nodes when one or more nodes fail
• Administer concurrent managers running on multiple nodes from any node in the cluster
One or more concurrent managers can be specified to run on one or more nodes, to best suit your processing needs and fully utilize available hardware resources.
Admin Server:
• Upgrading Oracle Applications
• Applying database patches to Oracle Applications
• Maintaining Oracle Applications data
The Database Tier:
communications between the database server and the clients.
No comments:
Post a Comment