The Oracle9iAS Portal Architecture is designed around a three-tier architecture that allows essentially any browser to connect to it. This flexible architecture allows each component (Browser, Web listener, Oracle database, and Oracle9iAS Portal) to be upgraded individually based on need. This article describes the flow of a request and the steps needed to return an Oracle Portal page to the browser.
ARCHITECTURE
When a page is requested from Oracle9iAS Portal, the request is made from the browser to the listener. The page returned is made up of
many types of portlets each containing information for the user. The following information describes the steps that Oracle9iAS Portal follows to display a page after a request is made.
Step 1: Browser
An initial request is made from a standard web browser to retrieve a portal page. The browser sends a URL request to the server and port specified. The request is received by HTTP listener, also known as Oracle HTTP Server powered by Apache.
Step 2: Middle-tier
Apache Server receives the request and maps it to the appropriate destination. There are generally two main destinations where requests are sent.
ModPL/SQL which is generally indicated by a "/pls" virtual path points to the ModPLSQL plug-in. (For this document, we will assume that this is the path taken initially.) ModPL/SQL is a plug-in attached to Apache that makes calls to a database server. It then executes PL/SQL procedures and returns the their result to the browser.
ModPL/SQL receives the request from iAS. It uses the Database Access Descriptor (DAD) name specified in the wdbsvr.app file to send this request to a procedure called "portal" in the schema specified. This procedure is the entry point to the Portal Server.
Parallel Page Engine which is generally indicated by a "/servlet" virtual path points to the JSERV (Java Servlet Engine). Parallel Page Engine is a multi-threaded engine which collect the content from various portlets, and builds the pages viewed in the Portal system.
The Portal Repository is comprised of the schema definition, PL/SQL packages, and database objects such as tables, views, etc. When a page is requested, the Portal Repository constructs the definition of portal page using the Page Engine and the Provider Engine.
When the Portal Repository receives the page request from ModPL/SQL, it sends a 305 redirect back to the browser. The browser is redirected to the Parallel Page Engine.
When the Portal Repository receives a page request from the Parallel Page Engine, it retrieves the page definition with any user customization from the user preferences. The page definition is comprised of two sections. The first section contains all of the information that will be needed to retrieve the individual portlets for the page. The second section is the actual layout of the page as it will appear in the browser. This data, known as the meta-data, is returned to the Parallel Page Engine for processing.
Step 4: Parallel Page Engine
The Parallel Page Engine is a Java Servlet which takes a proprietary set of meta-data, and processes it to create a portal page. The meta-data that it receives is parsed and held in a structure. As data is collected for a portlet, that portlet is retrieved through an HTTP connection. The portlets are retrieved in parallel as they are found. Thus if a page contains five portlets, they may be retrieved at the same time, thus cutting the amount of linear processing being done.
When a request is received for a page, the Parallel Page Engine retrieves the meta-data by making a request to the Portal Repository.
The resultant meta-data is parsed and acted upon.
If a user needs to be logged in, then the Parallel Page Engine makes a request to the Portal Repository to retrieve a second set of meta-data which holds the login information.
Once the login is complete, portlet requests begin to be served in the order they are found in the meta-data. The Parallel Page Engine checks the Portal cache to see if the request is still valid. If the cache is valid or has not expired, the Parallel Page Engine uses the cache to render the page. Otherwise, it makes a request to execute the invalid or expired portlets.
The portlet results are collected in parallel, and inserted into the page in the appropriate locations.
Finally, the completed page is returned to the requesting browser.
Note: If no portlet on the page requires authentication then the login step above is never taken. If a portlet requires authentication, the portal notes that it needs to communicate with a provider that requires a user name mapping. It calls an API to retrieve the username mapping from the Login Server. The Login Server contains a SSO user name mappings to External Application user names. Once a valid mapping is returned, the portal stores this mapping for future use in this portal session. It then calls the do_login method over HTTP.
The Provider Engine receives the request from the Page Engine to deliver portlet information. It executes a provider initialization call for each Database or Web Provider represented in the page definition. There is a provider setting which determines whether this call is made at all, once per session, or for each page rendered. These portlet method calls are made in parallel. The need for this login call is indicated in the meta-data, and will not be made if this indication is not present.
Step 5: Providers
Providers are the back-bone behind the Portlets being displayed on each page. Each provider contains a number of enabling functions which communicate with the Page Engine and give a framework for the portlets to work within.
When the Parallel Page Engine requests a PL/SQL portlet, it makes a call to the Provider API called execute_portlet over http. This routine formats the request into a style which the provider recognizes and then calls show_portlet in the provider package. More information about PL/SQL Portlets can be found in the Understanding Database Providers article.
In the case of the Web Provider, the call is made a little differently. Web Providers can exist on any server, and therefore must be called differently than the PLSQL providers. In this case, the meta-data contains an actual URL for the provider. Whatever that URL is, the Parallel Page Engine will use it along with the parameters it has available for this particular type of provider, and retrieve the data through that call. More information about Web Portlets can be found in the Primer on Web Providers article.
Step 6: Browser
The browser displays the newly constructed page and the user receives the information pertinent to their needs.
Revision History: