Previous  Next          Contents  Index    Library

Oracle Self-Service Web Applications Architecture

The architecture consists of the following components:

Figure 1 - 1. Product Architecture

See the detailed sections below:

The following definitions will help you to understand the big picture of Oracle Self-Service Web Applications.

Definitions

Common Gateway Interface (CGI) The industry standard technique for running applications on a web server. Oracle WebServer supports this standard and offers additional functionality with the Web Request Broker.

Flow A series of web pages, each of which can display data. The pages that make up a flow are bound together by complex definitions. Specifically, flows are comprised of pages, page regions, and region items.

HTML (HyperText Markup Language) A format for encoding hypertext documents that may contain text, graphics, and references to programs, and references to other hypertext documents. HTML is a subset of Standard Generalized Markup Language (SGML).

HTTP (HyperText Transfer Protocol) A protocol used to request documents from the web server.

Javascript Javascript is a scripting language that adds significant power to HTML files without the need for server-based CGI programs.

Web Applications Dictionary An Oracle Forms-based tool used to create web inquiries.

Web Request Broker (WRB) Cartridges WRB applications, implemented as a shared library, uses the WRB API to handle HTTP requests from web clients. Cartridges can be developed in any language and then integrated with the WRB through the WRB API.

Web Browser The client user interface component. The browser you use must support tables and frames and be Javascript enabled. The embedded Javascript code in Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers provides a mechanism for client side caching of user-entered data during a transaction, and simple client side validation of user-entered data. Execution of simple Javascript code logic at the client side results in reduced network traffic between the web browser client and the web server.

Oracle WebServer Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers, Release 11 requires Oracle WebServer 3.0 or above. WebServer 3.0 is Oracle's standard HTTP server that offers an open, extensible application development platform for the Web. This enables secure, high speed transactions with the Oracle8 RDBMS.

Oracle WebServer is designed to be a scalable, high-performance network daemon. It is implemented as a multi-threaded, single-process asynchronous engine, allowing multiple concurrent requests to be processed at the same time using standard HTTP or HTTP over SSL.

Web Listener A component of Oracle WebServer responsible for delivering incoming requests to the Web Request Broker, where they are processed or dispatched to services built with the WebServer Software Development Kit (SDK). The HTTP server is the network layer component of Oracle WebServer. It listens for incoming HTTP requests, delivers static files, and runs simple CGI programs. The HTTP server transfers everything else to the Web Request Broker (WRB), where a request is handled by a server extension.

The first generation of web sites on the Internet only offered static HTML files to their visitors. To enable dynamic content, web designers usually use CGI to extend the capabilities of their web server. Although easy to use, CGI has limitations, primarily the high overhead of spawning a new process for each incoming request, which causes degradation in scalability and throughput.

Currently, several web servers have defined an API for implementing extensions to the basic HTTP engine. The typical HTTP API enables a custom extension to be linked into the HTTP server process and allows it to intercept and fulfill a client request. Examples of such APIs are Netscape NSAPI, Spyglass ADI, and Microsoft IS-API. These APIs are becoming increasingly popular because they address the shortcomings of the original CGI protocol.

To compensate, Oracle WebServer 3.0 is layered into two fundamental components: an HTTP engine (Oracle Web Listener) and a high-speed dispatch mechanism (the Web Request Broker) that routes requests to server extensions running in separate processes.

Web Request Broker (WRB) An asynchronous request handler with an API (Application Program Interface) that enables it to interface dynamically and seamlessly to various back-end technologies called "WRB Cartridges." It provides an architecture that allows server-side web applications to run under any HTTP server to which the WRB has been ported.

WRB applications, called cartridges, take advantage of the WRB's multi-process architecture to get higher performance than ordinary CGI scripts. The WRB architecture also makes WRB cartridges extremely scaleable--they can handle small request loads economically and large request loads efficiently.

The cartridge used by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers is the PL/SQL Agent. This cartridge executes PL/SQL commands stored in the database.

Other cartridges that are not used by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers, but are available through Oracle WebServer 3.0 are mentioned here for informational purposes:

Java Cartridge Enables you to execute Java on the server to generate dynamic web pages.
LiveHTML Enables the inclusion of output from programs supported by your operating system in your web pages.
Custom Cartridges Since the WRB uses an open API, you can write your own cartridges to use it. Currently, only the C language is used to write WRB cartridges. In the future, however, the WRB API will also be available in other languages.
Third-Party Cartridges Various independent vendors write cartridges for the WRB's open API.

Web Request Broker Architecture

The WRB architecture consists of these components:

A WRB cartridge is implemented as a shared library that uses the WRB API to handle HTTP requests from web clients. The Dispatcher is a program that provides a CORBA (Common Object Request Broker Agent) interface between web listeners, the Web Request Broker, and WRB cartridges. The Dispatcher manages WRB cartridges and the requests directed to them. When the Web Listener receives an HTTP request directed to a WRB cartridge, it forwards the request to the Dispatcher. The Web Listener uses its configuration data to map URLs to WRB cartridges.

When the Dispatcher receives a request, it determines the WRB cartridge to which the request is directed, and directs the WRB to allocate an execution instance (WRBX) of that cartridge. The Dispatcher then dispatches the request to that WRBX. An execution instance of a WRB cartridge is a process running a program composed of two parts: a copy of the WRB application engine, and the WRB cartridge shared library.

The WRB application engine is the executable program that implements the WRB API and runs within each WRBX. It provides the interface between WRB cartridges and the Dispatcher, directs WRB cartridge flow of control, and provides services for WRB cartridges to use.

Figure 1 - 2. WRB cartridge instance creation in response to a request

The Dispatcher may then forward future requests directly to the cartridge instance and receive responses from the cartridge directly. The WRB configuration data specifies the maximum number of WRBXs that may run at once for each cartridge, and the minimum number of WRBXs that must always be running. You can tune the WRB performance by adjusting these values using the Web Request Broker administration pages.

PL/SQL Agent

The PL/SQL agent is responsible for connections to the database and executing stored procedures. When the Web Listener begins, it can start the WRBX (WRB Executable Engine) and interface with the PL/SQL agent based on how the Web Listener is configured. (The term PL/SQL agent refers to the WRBX interfacing with the PL/SQL agent cartridge.)

When the Web Listener receives a request for WRB, it forwards the request to the WRB dispatcher. The dispatcher works like a traffic director, redirecting requests to the appropriate cartridges. If the dispatcher determines that the URL is a request for the PL/SQL agent, the dispatcher forwards the URL to the PL/SQL agent.

Not only does the Dispatcher redirect requests, but it controls the number of WRBX processes running at any one time. If a request comes in for the PL/SQL agent and there is no WRBX running, the Dispatcher starts a WRBX. If many requests come in for the PL/SQL agent, the Dispatcher can distribute the load by starting multiple WRBX processes. If there are no requests coming in for a WRBX, the Dispatcher can shut down WRBX processes.

Figure 1 - 3. The web browser serving a dynamic page based on a PL/SQL request

illustrates the sequence of events:

Any request starting with the directory path of /owa will be recognized and handed off to the PL/SQL agent. The syntax of a string calling a PL/SQL cartridge is 

http://<machine>:<port>/<dcd_name>/<owa>/<stored procedure>

In the following example

http://19sun.us.oracle.com:9333/ic/owa/Oracle/OracleApps.VL

19sun.us.oracle.com:9333 is the pointer to the web server which is listening on port 9333, owa is the directory path which has an entry in the WRB configuration file and indicates the request should route to the PL/SQL agent, and OracleApps.VL is the stored procedure, which is executed.

The DCD name specifies which database to connect to, what user to connect as, and how to connect to the database. Different DCDs allow access to different databases or schema using the same Web Listener. Each DCD specifies a username, password, database to connect to, and specifies how to connect to the database.

When it is called, the PL/SQL agent executes a stored procedure. This procedure is responsible for retrieving data and returning results in HTML format. By writing to an extension to the database standard output, an HTML document is generated via a PL/SQL stored procedure containing the appropriate data retrieved from the database. Within this generated page, there may be embedded Javascript code. Once the page is generated, it is returned to the client for display on a standard browser.

Oracle Workflow

Workflows can be defined for business flows so users can be sent automatically all the information they need to make a decision and have other business processes run automatically based upon their responses. See: Oracle Workflow.

Workflows are defined using the Workflow Builder, a Windows GUI interface that enables users to design the business process, the activities, items, messages and lookup lists, and roles (the approval chain). This workflow is then integrated into the business transaction process. For Web Employees, it is integrated with the requisition approval process.

Notifications generated in the workflow chain can be viewed with the Oracle Self-Service Web Applications or a Workflow-supported email system.

Oracle Web Employees includes a predefined workflow process to generate offer letters.

All workflow processes are customizable. See: Oracle Workflow.

Web Applications Dictionary

This is an Oracle Forms-based data dictionary used to define flow content and formatting for web inquiry pages. When users query for data, information is displayed on a web page, complete with hypertext links that enable the user to drill down to more detailed information. The pages that are linked in this way constitute a flow, alternatively referred to as an inquiry. Using the Web Applications Dictionary, you specify the content of, and links between the pages that make up a flow. Specifically, you can specify:

Web Applications Dictionary also serves as a real time execution engine to retrieve information from the database. Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers reference the data dictionary at run time to retrieve data from the database and generate dynamic HTML pages.

The Web Applications Dictionary provides a means of defining business flows which can then be web-enabled using the existing functionality provided by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers. All inquiry flows shipped with Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers were built using Web Applications Dictionary. These can be customized as needed.

The Web Applications Dictionary is part of Oracle Applications, Release 11, and is part of the named "AK Common Modules". Once installed, it is accessed in the same manner as all of the core Oracle Applications.

See: Web Applications Dictionary.

Web Inquiries and Web Transactions

Web Inquiries correspond to the query, or "read only", mode access to information stored in the Applications Server. Users are provided with a structured way of performing queries. The retrieved data is structured so that users can easily navigate through pages of closely linked information.

Web Transactions enable users to perform two simple transactions: place an order and enter a requisition. These transactions insert data into open interface tables. Data is then validated and then loaded into the core Oracle Applications production tables.

Web Inquiries

Figure 1 - 4. Web Inquiries

A web inquiry, or "flow", is a series of hyperlinked web pages. Standard flows are predefined to allow users to easily navigate through web pages to access relevant information. These navigation flows are designed based on common business inquiry processes, and are built using Web Applications Dictionary. For example, a user can log in and request the View Purchase Orders inquiry. Once the data displays, the user can hyperlink to invoices and receipts related to the retrieved purchase orders.

Oracle Self-Service Web Applications (product code "ICX") packages contain PL/SQL functions and procedures that access Web Applications Dictionary (product code "AK") objects to retrieve information for the display elements and actual applications data. The Web Applications Dictionary has a run time execution engine that generates dynamic PL/SQL based on the ICX views. These views are based on those provided by the standard Oracle Applications.

Web Transactions

Figure 1 - 5. The process of performing a web transaction

The diagram above depicts the process of performing a web transaction (e.g., order entry) and the key components involved. A user who wants to enter a sales order uses a web browser to access the Web Store component of Oracle Customers. When the user enters lines on the order, the line data is stored at the client using Javascript technology. When the user submits the order, data is passed to the PL/SQL agent, which executes PL/SQL procedures to store the sales order data in the ICX shopping cart temporary tables. Finally, the data is loaded into the standard Order Entry Open Interface tables.

The batch interface OrderImport program in Oracle Order Entry then reads the open interface tables, performs necessary validations, and finally loads the data into Order Entry production tables. A source parameter can be set for the OrderImport program so that only imports those records entered via the web.

Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers only provide the logic to insert data into the open interface tables, leaving all validation logic to existing open interface programs.

The coding logic provided by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers is mainly for building the user interface elements of the web. There is little transaction code; only limited Javascript logic for data caching at the client. Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers leverage the applications business logic provided by standard Oracle Applications by using its open interfaces.

         Previous  Next          Contents  Index    Library