|
|
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 WebLogic Portal Overview, 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 Workshop for WebLogic. 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 Production Operations Guide 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:
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 Production Operations Guide.
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 Federated Portals Guide provides detailed instructions on how to set up a federated portal environment.
You can control access to portlet resources for two categories of users:
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 Security Guide. Recommendations for security in WSRP-enabled environments are contained in the Federated Portals Guide.
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 Content Management Guide.
You use 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 Interaction Management Guide.
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:
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 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 Creating Portals for Multiple Device Types.
|