10g (9.0.4)
Part Number B10356-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server Portal Configuration Guide 10g (9.0.4) Part Number B10356-01 |
|
This chapter introduces Oracle Application Server Portal and explains how it fits in the Oracle Application Server architecture.
This chapter contains the following sections:
Oracle Application Server is a completely standards-based application server that provides a comprehensive and fully integrated platform for running Web sites, J2EE applications, and Web services. It addresses all the challenges that you face as you refine your business processes to become an e-business.
Oracle Application Server provides full support for the J2EE platform, XML, and emerging Web services standards. With Oracle Application Server, you can simplify information access for your customers and trading partners by delivering enterprise portals that can be customized and accessed from a network browser or from wireless devices. It enables you to redefine your business processes and integrate your applications and data sources with those from your customers or partners. You can deliver tailored customer experiences through real-time personalization, and assess and correlate customer navigation, purchasing, ratings, and demographic data.
You can also implement a centralized management, security, and directory framework to manage and monitor all of your distributed systems and diverse user communities. Oracle Application Server maximizes your Web site infrastructure by deploying your fast, scalable Internet applications through built-in Web caching, load balancing, and clustering capabilities.
Oracle Application Server is actually a set of Oracle Application Server solutions. Each solution contains one or more components. A component can be a service, an API, or an application. The solutions provided by Oracle Application Server are:
All of these solutions are built upon a scalable and highly available infrastructure, as illustrated in Figure 1-1.
The next few sections explain a bit about each solution and the components they contain.
Oracle Application Server is built entirely on a J2EE framework that supports the latest industry standard technologies and programming languages, including J2EE API specifications, XML, and Web services. This comprehensive and flexible framework enables you to design, develop, and deploy dynamic Web sites, portals, and transactional applications using familiar programming languages and technologies. Oracle Application Server also provides comprehensive Web services to expose business functions to authorized parties over the Internet from any Web device.
The following Oracle Application Server components are configured to use the J2EE and Internet Applications solution:
Oracle Application Server provides an out-of-the-box portal that requires little programming and maintenance effort, if any. You can use Oracle Application Server to build, deploy, and maintain self-service and integrated enterprise portals. Oracle Application Server enables wizard-based development, as well as deploying, publishing, and consuming Web services on an extensible framework.
The following Oracle Application Server components are configured to use the Portals solution:
Oracle Application Server Wireless simplifies wireless development and deployment by providing the ability to deliver content to any device, to use any protocol, and to work across any wireless network. In addition, OracleAS Wireless includes wireless services, such as e-mail and location-based services that simplify wireless-enabling applications and portals. Oracle Application Server provides application developers independence from the underlying wireless infrastructure. OracleAS Wireless is built on the core Oracle Application Server infrastructure, leveraging open standards support in XML and J2EE to deliver a high-performance and scalable wireless infrastructure.
The following Oracle Application Server component is configured to use the Wireless solution:
Oracle Application Server provides comprehensive personalization and business intelligence services. Using Oracle Application Server business intelligence features, you can dynamically serve personalized content recommendations to both registered and anonymous visitors as they browse your site; perform dynamic, ad-hoc query reporting and analysis using a standard Web browser; and publish high quality, dynamically generated reports on a scalable, secure platform.
The following Oracle Application Server components are configured to use the Business Intelligence solution:
Oracle Application Server has a powerful set of features that provide communications and integration capabilities for e-business applications. Using Oracle Application Server, you can integrate enterprise applications, trading partners, and Web services, emphasizing scalability and manageability, and provide seamless query and transaction access to many non-Oracle data sources.
The following Oracle Application Server components are configured to use the E-Business Integration solution:
Oracle Application Server provides a flexible deployment model that enables you to architect your system for high availability and scalability. Oracle Application Server provides a variety of options for improving availability and scalability, and provides features for implementing fault tolerance, death detection, and failover. Additionally, Oracle Application Server supports such high availability options as cold failover clusters and Real Application Cluster (RAC).
Oracle Application Server Web Cache is a Web caching solution with the unique capability of caching both static and dynamically generated Web content. OracleAS Web Cache significantly improves the performance and scalability of heavily loaded Web sites. In addition, OracleAS Web Cache provides a number of features to ensure consistent and predictable responses. These features include page fragment caching, Edge Side Includes (ESI) and Edge Side Includes for Java (JESI) support, compression, dynamic content assembly, Web server load balancing, Web cache clustering, and failover.
The following Oracle Application Server component is configured to use the caching solution:
Oracle Application Server provides a set of management facilities that are based on industry standards to simplify all aspects of Web site administration. Using Oracle Application Server, you can:
The following Oracle Application Server components are configured to use the Management and Security solution:
The Oracle Application Server architecture consists of three basic tiers:
It's important to understand a bit about the overall Oracle Application Server architecture so you can more fully understand how your OracleAS Portal configuration fits within that structure. The next few sections provide some key concepts and terms you'll need as you plan your configuration strategy.
From the client computer, a user can connect to the middle-tier and the infrastructure tier to access the self-service tools for publishing information, build applications, deploy content management, and administer enterprise portal environment.
The middle-tier, or application server tier, is a set of Oracle Application Server components installed into a single Oracle home. A single enterprise can have one or more application server installations, either residing on one host or, for more complex installations, distributed across multiple hosts.
The infrastructure installation consists of several components that help authenticate users, store access control information, and pass on the required content to the user based on the privileges the user has on OracleAS Portal. Like the middle-tier components, infrastructure components can be distributed across multiple hosts to enable scalability and high availability.
Figure 1-2 illustrates the three parts of the Oracle Application Server architecture.
The middle-tier is the part of an Oracle Application Server architecture that contains several components responsible for accepting requests from clients, validating the requests, and providing content, while using intelligent data caching for faster and reliable performance.
For OracleAS Portal, the middle-tier handles all Web requests by forwarding them to the appropriate provider. This is also where Portal pages are assembled, and where the caching of Portal content is managed. The middle-tier also provides other functions for other Oracle Application Server components.
Some of the key components for OracleAS Portal in the Oracle Application Server middle-tier are:
For OracleAS Portal, OHS handles all incoming HTTP requests to OracleAS Portal, by forwarding them to the either the Parallel Page Engine (PPE) servlet or mod_plsql. The PPE is a servlet that assembles Portal pages, and runs in the Oracle Application Server Containers for J2EE. mod_plsql is an OHS module that is used to access Portal and page metadata by executing PL/SQL procedures residing in the Oracle Application Server database, as well as generating HTTP responses.
There are three types of middle-tier installations:
To use OracleAS Portal, you must choose Option 2, or Option 3.
Refer to the following sections for more information:
By default, the infrastructure tier handles all authentication requests and hosts the Oracle Application Server Metadata Repository, which contains schemas and business logic used by application server components (including OracleAS Portal) and other pieces of the infrastructure.
For the OracleAS Portal middle-tier installation, the infrastructure tier is a prerequisite.
The Oracle Application Server Infrastructure contains:
Text description of the illustration cg_archit_infratier.gif
You can install multiple instances of any of these components on multiple servers, and then connect the servers to suit your needs. Deployment configuration options for OracleAS Portal range from installing everything on a single machine to multitier configurations in which the pieces comprising OracleAS Portal are located across multiple servers.
There are three types of Infrastructure installations:
After your development team builds your Web portal, the next step is to deploy a production version of it. Successful deployment means that end users are able to access content in a timely manner, without delays, errors, or server downtime. Because OracleAS Portal can be installed in a variety of configurations on different machines, a successful deployment ultimately depends how you configure Portal to address the requirements of your site. This section provides some background information that should be useful to you as you plan your configuration.
Some Oracle Application Server components serve as portlet providersFoot 1 for OracleAS Portal, which means you can easily integrate information from various components into a single portal page. Other components provide essential services to OracleAS Portal, as described in the following list.
See Also:
OracleAS Portal developers also have access to a set of page design tools that help in creating portal pages that optimize the wireless experience. With these tools, developers can build a distinct portal structure for their wireless users. The wireless pages and portal pages can share portlet instances, which enables clients to reuse portlets on browser and wireless clients without reconfiguring each portlet.
Refer to Section 4.6, "Configuring Mobile Support in OracleAS Portal" for more information.
Oracle Directory Integration and Provisioning. Oracle Directory Integration Platform notifies OracleAS Portal upon the occurrence of any directory events (for example, user deletions) to which OracleAS Portal subscribes. In essence, the directory integration server informs OracleAS Portal when a change occurs in the directory that requires a change in OracleAS Portal. Refer to Section 6.1.6.3, "Relationship Between OracleAS Portal and Oracle Internet Directory" for more information.
You'll find additional information in the white paper titled "OracleAS Portal Architecture Overview" on the Oracle Technology Network, http://otn.oracle.com.
A portal is comprised of groups of pages, each page divided into regions. The regions specify how space on a given page is allotted to that page's items and portlets.
Each time a user requests an OracleAS Portal page, the page is dynamically assembled and formatted according to the portlets and layout chosen for that page. Keep in mind that the parts that comprise the page are typically drawn from a variety of sources. For example, the page's layout, look and feel, and user customizations are stored in the database as part of the overall page definition, completely separate from any page content. This information may, in turn, be cached by the middle-tier. (However, if full-page caching is used, pages are not assembled, because they are served directly out of the cache.)
The portlets that appear on the page can be written in XML, PL/SQL or Java. For PL/SQL portlets, the source is an OracleAS Metadata Repository database. This could be the database where the current instance of OracleAS Portal is installed, or some other OracleAS Metadata Repository database located on a remote server, which is accessed through the Federated Portal Adapter. If written in Java, a Web provider provides the portlet from any location accessible from the network, either Internet or Intranet. For example, you could create a Portal page that displays both the following types of content:
Figure 1-5 shows how a page is assembled. As you can see, when a client requests an OracleAS Portal page, many Oracle Application Server components must respond to various parts of the request:
The OracleAS Portal implements a distributed architecture consisting of multiple communication points and protocols. For complex configurations including the introduction of firewalls and proxies, you need to understand the communication points, and how the various components of OracleAS Portal integrate together. Likewise, to allow for the distribution of the various functions across multiple servers, it is necessary to be aware of the network protocols that are used in the internode communication.
The OracleAS Portal architecture consists of three basic tiers: the client browser (pictured at the far left) the middle-tier server (pictured on the bottom left), and the infrastructure server and repositories (pictured on the top left). Although the default installation places all servers and repositories on the same host, it is recommended that you install these functions on separate servers, for increased performance and high availability.
Figure 1-6 illustrates in great detail the communication flow between the various components of OracleAS Portal and Oracle Application Server.
The three tiers and the communication protocols used between them is described next:
The infrastructure tier consists of the Oracle HTTP Server, OracleAS Single Sign-On, Oracle Internet Directory, and OracleAS Metadata Repository.
The middle-tier consists of the OracleAS Web Cache, Oracle HTTP Server, Oracle Application Server Containers for J2EE, and other Oracle Application Server components.
OracleAS Portal uses three methods to cache Web pages and content:
OracleAS Web Cache is a powerful server acceleration and load balancing solution. Using OracleAS Web Cache is required for running OracleAS Portal. OracleAS Web Cache offers intelligent caching, page assembly, and compression features. OracleAS Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Application Server.
To increase the availability and scalability of medium to large deployments, consider configuring multiple instances of OracleAS Web Cache to run as members of a cache cluster. A cluster is a collection of cooperating OracleAS Web Cache instances that work together to provide a single logical cache. Cache clusters provide failure detection and failover, increasing the availability of your Web site. If an OracleAS Web Cache instance fails, other members of the cache cluster detect the failure and take ownership of the cached content of the failed cluster member. This is achieved because the nodes that receive requests hold the content, after forwarding the request to the owner cache node.
By distributing the Web site's content across multiple OracleAS Web Cache servers, more content can be cached and more client connections can be supported, expanding the capacity of your Web site. You make use of the processing power of more CPUs and, because multiple requests are executed in parallel, you increase the number of requests that are served concurrently
OracleAS Portal functions as a Web Cache origin server to take advantage of the following Web Cache features:
Portal sites can choose from the following deployment options:
To avoid a single point of failure in very high-volume sites, two or more nodes running OracleAS Web Cache may be deployed behind a Load Balancing Router (LBR). If you have multiple deployments of OracleAS Portal, each Portal site can have its own Web Cache server. One or more sites can also share a single Web Cache server. Similarly, a provider can share a Web Cache with a Portal site, or a dedicated Web Cache can be deployed in front of the Web server that hosts the provider. Refer to Section 5.7, "Configuring OracleAS Web Cache Caching in OracleAS Portal" for more information about configuring OracleAS Web Cache.
In addition to providing failover, an OracleAS Web Cache cluster also balances the load it forwards to the middle-tier, and can also act as a reverse proxy.
Text description of the illustration cg_topo_combine_mtier.gif
After the initial request to the owner node, the content is cached across all instances. In Figure 1-7, the LBR distributes incoming requests to the three OracleAS Web Cache instances. When the on-demand content is not available on the node receiving the request, the other instances are checked for the cached content, and the content matching the request is returned to the Browser.
To take advantage of OracleAS Web Cache's clustering capability, you must configure each instance as a member of a cache cluster. In this setup, there is no one-to-one relationship between an OracleAS Web Cache instance and a matching middle-tier instance. As shown in Figure 1-7, OracleAS Web Cache 1 provides load balancing between middle-tiers 1, 2, and 3. OracleAS Web Cache 2 and 3 do the same.
You'll find additional information about caching and performance on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
Portal cache is a file system-based cache for OracleAS Portal pages and portlets. Portal cache supports validation-based caching and expiry-based caching.
Portal cache consists of two kinds of caches:
The content cache contains user and system level content generated by OracleAS Portal, which includes page metadata, database portlets, Web portlets, documents, style sheets, images, and full-page caches.
OracleAS Portal uses session cookies to maintain session details for each portal user. This session cookie is encrypted and contains important information like the database username, lightweight username and Globalization Support characteristics of the session. In order for mod_plsql to execute a portal request, it must get the database username from the session cookie. To avoid an expensive decrypt operation with each user request, mod_plsql decrypts the session cookie once and maintains the relevant details in a session cache on the local file system.
Portal content and session cache content resides on the file system, typically under ORACLE_HOME/Apache/modplsql/cache, and is configured in the file ORACLE_HOME/Apache/modplsql/conf/cache.conf.
It is possible to increase performance by moving the session cache to a more performant file system. This takes the form of a memory-based file system that is commonly available on Windows and UNIX platforms. For more information on increasing the performance of the portal cache, refer to Section 9.6, "Tuning File System Cache to Improve Caching Performance".
In multiple middle-tier configurations, you can setup the portal cache for each middle-tier on a shared file system. This ensures that each middle-tier can share cached content, rather than each drawing from its own independent cache.
For example, one middle-tier might handle a request for an item by caching it in the portal cache. Because you typically use a load balancing router for configurations having multiple middle-tiers, the next request for the item could be handled by a different middle-tier. This middle-tier could access the cached version if the portal caches for each middle-tier are shared on a common file system.
Various parameters for configuring portal cache include:
See Also:
OracleAS Portal makes use of two caching systems - OracleAS Web Cache, and portal cache. OracleAS Web Cache supports invalidation-based caching and expiry-based caching. The portal cache supports validation-based caching and expiry-based caching.
Cache invalidations can be classified into two groups:
Hard invalidations are queued up over the duration of a single browser request and are then processed when the OracleAS Portal UI action completes. The results will be seen immediately. Most page edits and all portlet customizations are treated as hard invalidations.
Soft invalidations are queued up over many browser requests and are then processed later by the soft invalidation database job. Security related changes, for example, granting privileges on a page to a user or group, are treated as soft invalidations.
Large numbers of cache invalidations may slow down the system for the following reasons:
When either hard or soft invalidations are processed, a TCP/IP connection is established with the OracleAS Web Cache invalidation port to send invalidation messages.
For hard invalidations, all the messages queued in one browser request are sent using a TCP/IP connection to OracleAS Web Cache. For soft invalidations, all the messages processed by the soft invalidation job are sent to OracleAS Web Cache using a TCP/IP connection. OracleAS Web Cache receives these invalidation messages and attempts to invalidate cached data. This load may affect OracleAS Web Cache's ability to respond to requests for data.
Both hard and soft invalidation messages are queued into a database table in the OracleAS Metadata Repository. As the queue grows in size, more database resources are required to maintain the queue.
During the processing of hard or soft invalidation messages, queue optimization removes duplicate or unnecessary invalidation messages. For example, if a page group is being invalidated, individual invalidation messages for pages in the page group are unnecessary. If a large number of invalidation messages have been queued up, the optimization process may take a long time.
OracleAS Portal supports invalidation of data cached in OracleAS Web Cache based on the DAD for a given Portal instance.
Invalidation messages sent to OracleAS Web Cache require the DAD information to be included. This is because data cached in OracleAS Web Cache uses the URL as one of the cache lookup keys and the URLs used to access Portal data contain the DAD name. Therefore, the DAD name must be included explicitly in the invalidation message.
Now that you have a basic understanding of the Oracle Application Server architecture, how OracleAS Portal fits in, and the working of caching in OracleAS Portal, you're ready to move on to Chapter 2, "Planning Your Portal". By the end of that chapter, you should have a good idea of how you want to configure your installation.
1
Applications and information sources, represented as portlets, communicate with the portal through a provider. Each portlet only has one provider, and a provider can have one or more portlets that expose an underlying application or information source.
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|
