|Oracle® Fusion Middleware Portal Development Guide for Oracle WebLogic Portal
10g Release 3 (10.3.4)
Part Number E14243-06
Proper planning is essential to portal development. While bypassing planning and moving straight to development might reap short-term benefits in development speed, your projects may suffer from confusion and inconsistency, have poor scalability and performance, and require more time to manage.
The planning and design tasks that mark the architecture phase occur at multiple levels: the domain and enterprise application, the web application, and the individual WebLogic Portal feature areas.
Global inter-portal planning information is provided in the Oracle Fusion Middleware Overview for Oracle WebLogic Portal, which summarizes the types of issues to consider in the architecture phase at all levels. The various WebLogic Portal feature guides describe planning issues in detail for each feature area.
This chapter includes the following sections:
Production operations encompasses the tools, procedures, methodologies, and best practices that provide the backbone for managing the portal life cycle, from portal development to staging and testing to live production environments. As Figure 2-1 shows, portals are typically developed in a team development environment by developers using Oracle Enterprise Pack for Eclipse. Portal components are then moved to a staging environment, where portal administrators use the WebLogic Portal Administration Console to create desktops, add entitlements, set up content repositories, and perform testing. The production environment is the live environment, where users access and interact with portal applications. The arrows between environments indicate that you can move portals and portal resources back and forth between each of these environments using utilities provided by Oracle. WebLogic Portal Utilities such as the WebLogic Portal propagation tools allow you to easily and reliably move and merge changes between environments.
Just as you consider the architecture of a network or a software system, also consider and carefully plan how you will address production operations for your portal system. It is important to consider your particular portal system configuration, how your development team is organized, how you will test and configure portals, how your server is configured, and how you plan to manage the life cycle of your portal applications.
The Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal describes the specific methodologies, tools, and best practices to help you achieve the goal of creating solid, manageable environments for portal development, staging, and production.
If you will be creating portals within an environment that includes a remote (distributed) development team, you must carefully plan your implementation. Considerations for team development include:
Use of shared resources – You share common portlets, such as the login portlet.
Sharing a common domain – Several techniques exist for sharing a common domain among team members with different Oracle home directories.
Integrating remotely developed portlets into the portal – Settings that are common to the portal application must match across the entire development project.
Team development of a WebLogic Portal web site revolves around well-designed source control and a correctly configured shared domain for development. For detailed instructions on setting up your development environment, refer to the Team Development chapter of the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.
A federated portal is a portal that includes remotely distributed resources, such as remote portlets. These remote resources are collected and brought together at runtime to a portal application called a consumer, which presents the federated portal to end users.
To implement a federated portal environment, you need to make decisions about how to organize your applications. For example, rather than bundling all of a portal's portlets into a single application, you can deploy portlets in separate web applications running on remote systems while the federated portal consumes them using WSRP. Because the federated portal is decoupled from its portlets, you do not need to redeploy the portal every time a portlet changes. For most WebLogic Portal projects, this decoupling represents an immediate and significant savings in time and money. You also might find it useful in some situations to federate a portal within the same server.
The Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal provides detailed instructions on how to set up a federated portal environment.
You can control access to portlet resources for two categories of users:
Portal visitors – You control access to portal resources using visitor entitlements. Visitor access is determined based on visitor entitlement roles.
Portal administrators – You control portal resource management capabilities using delegated administration. Administrative access is determined based on delegated administration roles.
During the Architecture phase, you plan how to organize security policies and roles, and how that fits into your overall security strategy. For an overall look at managing security for your portal environment, refer to the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal. Recommendations for security in WSRP-enabled environments are contained in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.
WebLogic Portal's content management system allows you to store content, track its progress, and incorporate content in your portal applications. It provides an easy integration between creating content and delivering that content to your users. Content creators can use WebLogic Portal's repositories to create content and portal developers use the content API and JSP tools to deliver content to portal visitors.
You can use either a WLP repository or a third-party repository with your portal. Some third-party content management vendors have built integrations (Content Service Provider Implementations or SPIs) that allow you to connect third-party repositories to the Virtual Content Repository. If you are using a third-party repository from a vender that has not written an implementation for the WLP Virtual Content Repository, you can write your own using Oracle's Service Provider Interface (SPI).
For detailed information on managing the content for your portal, refer to the Oracle Fusion Middleware Content Management Guide for Oracle WebLogic Portal.
You use Oracle WebLogic Portal's Interaction Management features to control and enhance portal visitor interactions with your portal application. You can set up personalized content that is targeted to specific users or audiences. You can guide users through a process (such as signing up for employee benefits or shopping online) that takes them to different locations based on their personal preferences or characteristics. You can even record the path users take through your portal to gauge the effectiveness of the portal, its design, or your process flows.
Developing Interaction Management features involves several interdependent tasks. For example, if you want to target users with personalized content in an ad campaign, you have to add content to the WLP Virtual Content Repository, create placeholders that display the content, set up properties (such as user profile or session properties) that are used to define the conditions under which users will be targeted with campaign content, and finally, create the campaign.
For detailed instructions, refer to the Oracle Fusion Middleware Interaction Management Guide for Oracle WebLogic Portal.
Try to plan for good performance within your portal architecture to minimize the fine-tuning that is required in a production environment. Many performance issues can be resolved and significant performance improvement can be realized by making just a few critical design decisions.
Here are some examples of performance optimizations that you can plan into your overall portal strategy:
Enable control tree optimization.
Use entitlements judiciously; too many can impact performance. Avoid the temptation of granting a different role to every user. Instead, use WebLogic Portal's personalization capabilities to focus the user experience.
If your portal is small or relies only on static resources, you might experience some performance boost by using a file-based portal rather than a streaming portal.
If you are using page flows in your portal, ensure their session footprint is optimized to deliver the best performance. Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See Section 5.1, "Apache Beehive and Apache Struts Supported Configurations."
Plan performance optimizations before you begin developing your portal so that you can implement any prerequisites that are required. For detailed instructions on developing a high-performance portal, refer to Chapter 13, "Designing Portals for Optimal Performance." For overall WebLogic Portal performance recommendations that you can implement in a production environment, refer to the Performance Tuning Guide, which will be available in a future documentation release.
WebLogic Portal can provide specific portal views based on device and browser detection, allowing a single portal application to serve content to diverse browsers and devices. The portal's campaign and personalization features can also detect device types, directing users to device- or channel-specific business processes and content (or restrict access). Device specific content operates in tandem with the portal user interface to provide device-specific views of applications.
For instructions on how to implement your portal for use on mobile devices, refer to Chapter 12, "Creating Portals for Multiple Device Types."