2 Portlet Planning

Proper planning is essential to portlet development. A properly planned portlet structure and organizational model can provide a cohesive and consistent portal interface, flexible scalability, and high performance without requiring frequent adjustments within your production system.

This chapter focuses on planning considerations and decisions that should precede the development of your portlets. Global portal-wide 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 across your portal environment. The various WebLogic Portal feature guides, such as the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal, describe architectural issues in detail for each feature area.

This chapter includes the following sections:

Section 2.1, "Portlet Development in a Distributed Portal Team"
Section 2.2, "Portlets in a Non-Portal Environment"
Section 2.3, "Planning Portlet Instances"
Section 2.4, "Security"
Section 2.5, "Interportlet Communication"
Section 2.6, "Performance Planning"

2.1 Portlet Development in a Distributed Portal Team

If you will be creating portlets within an environment that includes a remote (distributed) development team, you must carefully plan your implementation. Considerations for team development include:

Using shared resources – You can have common portlets, such as the login portlet.
Sharing a common domain – You can have a common domain among team members with different Oracle home directories.
Integrating remotely developed portlets into the portal – You need to manage settings that are common to the portal application, which 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.

2.2 Portlets in a Non-Portal Environment

In some cases, you might want to expose portlets in a web page even though that web application is not based on WebLogic Portal. For example, you might want to expose portlets with WSRP from a producer environment that does not include any WebLogic Portal components. You might be running a Struts web application in a basic WebLogic Server domain, or a Java page flow application in a basic Oracle Enterprise Pack for Eclipse domain. In either case, WebLogic Portal is not part of the server configuration. The exposed portlets can then be consumed by remote portlets running in a regular WebLogic Portal domain.

Note:

Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

For more information on developing portlets for a non-WebLogic Portal environment, see "Configuring a WebLogic Server Producer" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.

2.3 Planning Portlet Instances

In the Development phase, you use Oracle Enterprise Pack for Eclipse to create portlets and place them onto a portal. In the Staging phase, you use the Administration Console to add portlets to portal desktops. Each time you add a portlet to a desktop, you create an instance of that portlet. Portlet instances allow for multiple variations of the same portlet definition. By using portlet instances, portal users and administrators can configure multiple views of the same portlet through the use of portlet preferences, and reduce the overall number of distinct portlets; this portlet reuse improves portal performance and management efficiency. A common example of portlet instances is a stock watch portlet in which there is a single or multi-valued preference for ticker symbols such as ORCL, which would configure the portlet to display Oracle stock information.

Try to plan your portal hierarchy to reuse portlets when practical. For more information about portlet instances and how portlet instances are related to portlets in the Administration Console's portlet library, refer to Section 17.1, "Portlet Library."

2.4 Security

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 system-wide security strategy. You implement your security plans by setting up delegated administration and visitor entitlements using the WebLogic Portal Administration Console.

For an overall look at managing security for your portal environment, refer to the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal. Specific security considerations for feature areas are contained in those documents; for example, recommendations for security in WSRP-enabled environments are contained in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.

2.5 Interportlet Communication

Interportlet communication (IPC) allows multiple portlets to use or react to data. You can use interportlet communication within a single portal web application, or within federated portal applications.

For more information on interportlet communication within a single portal web application, refer to Chapter 12, "Configuring Local Interportlet Communication." For more information on interportlet communication within federated portal applications, refer to the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.

2.6 Performance Planning

Try to plan for good performance within your portlet architecture to minimize the fine-tuning that is required in a production environment.

Here are some examples of performance optimizations that you can plan into your overall portal strategy:

Portlet caching – You can cache the portlet within a session instead of retrieving it each time it recurs during a session (on different pages, for example).
Remote portlets – With remote portlets, any portal controls within the application (portlet) that you are retrieving are rendered by the producer and not by your portal. The expense of calling the control life cycle methods is borne by resources not associated with your portal. You must balance this advantage against the delay that might be caused by network latency issues.
Customized portlet properties – Customizing your portlet settings can help you improve performance; for example, you can set process-expensive portlets to be processed in a multi-threaded (forkable) environment.
Asynchronous portlet rendering - Asynchronous portlet rendering allows you to render the content of a portlet independently from the surrounding portal page. You can use either AJAX technology or IFRAME technology to implement asynchronous rendering.

Plan your performance optimizations before you begin developing portlets so that you can implement any pre-requisites that are required. For detailed instructions on developing high-performance portlets, refer to Chapter 10, "Optimizing Portlet Performance." For post-development WebLogic Portal performance recommendations, refer to the Performance Tuning Guide.