WebSphere Portal Best Practices

 

+
Search Tips   |   Advanced Search

 

Content

  1. Overview
  2. Team Composition
  3. Sample Project Plan
  4. Gather Portal Requirements
  5. Single Sign-on Considerations
  6. Validate the Plan
  7. Infrastructure
  8. Security
  9. Looking Beyond the Production Environment
  10. Portal Development
  11. User Interface Design
  12. Portlet Development
  13. WCM Development
  14. Customization vs. Advanced Personalization
  15. Caching
  16. Load Testing Your Portal Application
  17. Portal Application Deployment
  18. Testing
  19. Tuning
  20. Load Testing
  21. Monitoring

 

Overview

Choose a few critical components to deploy first

  • Database & LDAP servers
  • Back-end applications

Build the portal from the base components first and then install added functionality when the infrastructure is rock-solid. Plan 4 months minimum for first pilot release.

Do load testing. The best portal application can fail in production if you do not do adequate stress testing before going into production. Test to failure, identify and fix problems. Load testing should should be part of the iterative development process, as this simplifies the process of problem isolation

 

Team Composition

Select a top-notch project manager. Communication skills are an absolute priority.

Select an executive sponser who is merciless in bringing the teams to the negotiating table and resolving conflict. Many portal projects need organizations to communicate and collaborate in different ways to which they are accustomed

Some organizations that resist best practices based upon this is the way that weve always done it. The project manager and the executive sponsor must work as a team to resolve this before the project starts. Failure to resolve issues like this early on in the project results in uncooperative teams and missed deadlines

Use a small architecture team with total systems responsibility. Empower this team to attach requirements to infrastructure.

Architecture team members should be perceived as fair arbiters by the larger development team. Hidden agendas and political types are counter productive. Ruthlessness should be saved for the executive sponsor.

Most pilot portal projects are overstaffed with developers. Optimize the skill sets and reduce the staff count for the pilot.

 

Sample Project Plan

Here is a project plan that you can use as a start-point.

SamplePortalProject51a.mpp

This project plan contains tasks, people and timelines based on experience. Use this as a baseline. Refine tasks and timelines as needed. Add tasks as needed.

 

Best Practices

Since the portal will be the most visible element in you IT infrastructure, ensure success of this component. If the portal fails, the infrastructure is perceived as a failure. The portal will repeatedly cause turf battles, organize and manage the teams to address these unavoidable battles

Five key details that need to be addressed upfront...

  1. Pay special attention to the requirements process
  2. Select the proper team composition
  3. Avoid unnecessary complexity
  4. Choose the proper components to deploy
  5. Create an effective testing plan and environment

 

Gather Portal Requirements

Most people follow a requirements process that is inadequate to satisfy the needs of the portal. This does not mean throw away the process. You should think about adding portlet sourcing to the process. It can save you an average of two months

Portlet sourcing is a critical activity for a successful project. The primary basis for accurate project sizing. Great way to communicate the organizations needs effectively. The primary source of portlet requirements for developers.

 

Source the Portal Content

To bring content into the portal, we must identify the content source (where the content is and who owns it) and how you are going to get the content into the portal. You can use the Portlet Sourcing worksheet to do portlet sourcing.

It will take some time to finish the portlet sourcing exercise. Plan a week for wire frames and a half day per unique portlet. Each portlet sourcing document should be the base for the portlet requirements and should be updated as decisions are made.

 

Content and Document Management

  1. What content do you want to display on WebSphere Portal?
  2. Where is the content stored?
  3. Who needs to create and change it, and who views it?
  4. What documents do you want to store?
  5. How many documents will be created each day?
  6. How large is each document?
  7. How many users will be accessing them (concurrently and total) and what will they be doing with them?
  8. What roles will they be assigned and how will workflow be used?
  9. What are the expectations regarding time to access, view, and store a document?

 

Single Sign-on Considerations

Portal is not a VPN. Single Sign-on is a holy grail for most organizations. However, it is misunderstood in the portal context. Portal is not a replacement for a pure SSO system like TAM, Netegrity Siteminder, Entrust, GetAccess, or RSA Clear Trust. Nor does it provide services like PKI, logon scripting, password reset, etc.

Portal provides what we call pseudo-SSO which can be used in conjunction with an SSO system.

 

Validate the Plan

When you have the requirements and plans in place, validate them with an experience portal architect. Leverage the Portal Architecture Workshop to review all major aspects of the portal project. Identify gap items which introduce project risk. Get recommendations for mitigating gap items.

 

Conceptual Portal Infrastructure

 

Real Portal Infrastructure

 

Infrastructure Best Practices

Integration with other systems and configuration is the most complex and time-consuming part of the project.

Build a single portal node (system) and integrate with the fewest systems that are necessary to make it functional Web server, directory server (LDAP), database server. Perform load tests to get a baseline on performance. Build another node, cluster, then retest to get performance baseline.

LDAP is the most critical component in the organization. Take the time to define the LDAP schema and replication strategy.

In Oracle environments, 90% of install failures in are due to insufficient database privileges for the portal ID. Ask the DBA to give the portal ID all permissions during install.

Integration at the glass means that the portal is highly dependent upon the availability of many other systems. When a system upon which the portal is dependent becomes unavailable, all users perceive is that the portal is broken. Accept that and plan for dealing with the consequences. Identify the people who own the systems with which you are integrating and establish service level agreements with them.

The staging environment is a key infrastructure component. Without it you can't load test new portal releases to ensure that the performance remains within an acceptable range. This is the last chance to ensure that the deployment process will run successfully and avoid portal outages.

Portal loves RAM. Allocate 2 Gbytes per CPU. Max heap size in Windows and Linux is 1.3 Gbytes.

Allocate 1 portal instance per 4 CPU. If multiple portlets on a page are accessing systems using SOA mediators, JDBC, JMS, or JCA.s, you may need another instance. Minimum of 2 CPUs per instance of portal.

Use a portal monitor to help performance tuning & diagnosis. The entire portal environment is way too complex to understand without system management tools such as WSAM, Wily, etc.

 

Security Best Practices

Do not externalize the authorizations for portal resources.

WebSphere Portal should be behind a firewall.

Change the default passwords and establish a password expiration policy.

Remove unused portlets and components such as sign-on if no sign-on capability is required.

Carefully plan use of encryption.

Do not run WebSphere Portal as user root.

Give "others" only read access to the WebSphere Portal installation directory, WebSphere Server, and the Web server.

Limit access to the logs.

Do not use generic ids such as wpsadmin and wpsbind.

 

Looking Beyond the Production Environment

A scalable and reliable production architecture is just one of the essential pieces of a WebSphere Portal architecture. A well-designed pre-production architecture is critical to successful deployment and on-going portal operations

  • Development server
  • Test server
  • Integration server for user acceptance testing
  • Staging environment (absolutely key to successful ongoing portal operations)
  • Authoring and rendering servers for WCM

 

Portal Development Best Practices

Integration with back-end applications is costly. Enterprise bureaucracy increases exponentially with every integration point. Database integration difficulty is related to the authorization model; i.e.. Permissions

Avoid the use of bleeding edge technologies. WSRP and JSF are great but let somebody else harden them. JSR-168 is no longer bleeding edge, it is the standard. Identify the clients you are going to support. Remember some don't support all JavaScript features or iFrames. Note the limitations of WAP clients.

 

User Interface Design Best Practices

Customizing the WebSphere Portal themes to match some exotic Web Sites can be very time consuming. Educate user interface design team on portal capabilities. Designers who understand the functional capabilities of the portal are much more likely to design the interface to leverage those capabilities rather than work around them.

Settle on the functionality that the portal will provide. Select an existing theme and modify it to meet the needs. Get users interacting with the site as quickly as possible. Focus on refining the themes as the last step.

Only use a single style sheet (Styles.css) to get started. Use the WSRP style classes consistently In all themes

Avoid using more than 3 or 4 navigation levels.

Carefully manage amount of content and complexity of layout. Be realistic in the amount of portlets users have access to. Keep the layout simple! Avoid placing portlets in rows, use columns only. Keep lightweight portlets on pages everybody accesses. Heavier portlets go on pages users select.

Only associate skins with themes they are designed to work with.

 

Portlet Development Best Practices

Throwing away code and duplicating effort are not that bad. Consider portlets to be a collection of tools in the tool box. Keep the portlets simple and specific in their purpose. Designing portlets to be flexible with configuration is good but it is also Ok to create multiple portlets that perform specific tasks. An adjustable wrench is great for certain situations, but better results are often achieved faster by selecting a specific wrench.

Avoid creating the ultimate configurable multi-purpose portlet. Finding a single tool for all household tasks is unattainable. Remember how much simpler a job can be with the right tool. Improvise and adapt existing portlets to create new portlets. Keeping portlets small and simple makes them easier for other developers to understand, and to maintain.

Rational Application Developer (RAD) and Portal Toolkit are tightly integrated with WebSphere Portal - use them. MVC compliant code for IBM and JSR-168 APIs.

Consider the use of rapid application development tools such as WPAI, Alphablox and Bowstreet.

Use Struts for portlets that require a Wizard interface.

Start learning JavaServer Faces (JSF). JSF will radically change portlet development in the future. The InfoCenter and developerWorks and the WebSphere. Developer Domain are excellent sources of information.

 

WCM Development Best Practices

Content management requirements are typically discovered during the portlet sourcing exercise. Especially important for organizations who are sure that they have any need for a content management system.

WCM is easy to use - and easy to get theself into a mess with. Every hour of time spent on design will save days of rework.

Critical aspects of design that need to be done up-front. Content model (including site model and taxonomy). Workflow design and security. Defining who can see, edit and delete content items is critical. If you don't do it up-front, the content will be compromised.

 

Customization vs. Advanced Personalization

Customization is rendering portlet content based on user preferences or manipulating the portal layout based upon the users security attributes. What portlets and pages do I show to users based on their role? This is a core capability of WebSphere Portal.

Advanced personalization manipulates portlet content based on business rules or collaborative filtering. You can use a users profile but you are performing some transformation with rules created non-technical users. No coding required, all managed through the portal interface. What do I display in a portlet? Provided by the Personalization engine in the portal.

Plan early for performance. Personalization and content management are interdependent. Where is content stored and how is it managed? Do not scare the users. Consider privacy issues. New business rules must go through an expedited quality assurance process.

 

Caching Best Practices

Proper or improper use of caching can make or break performance. Use normal portlet caching to cache the output of portlets. This is the easiest way to cache content, no programming. Portlets can programmatically clear out the cache.

Use the CacheManager service to cache portlet data objects. Use this only for explicit cases when the portlet must cache the data rather than letting the portal cache portlet output. Shared caches are cluster aware.

 

Load Testing Your Portal Application

to do load testing, this is not a negotiable item. The best portal application can fail in production if you do not do adequate stress testing before going into production. Test to failure, identify and fix problems.

Load test as part of the iterative development process. This simplifies the process of problem isolation.

 

Portal Application Deployment

To deploy a portal release, the following resources must be synchronized, packaged, and deployed to a portal server

  1. Portal configuration (stored in the portal database)

    • Portal content tree
    • Portal application configuration, and settings, and data
    • Portlet access control information

  2. Portal artifacts (stored in the file system)
    • Portal configuration (property files)
    • Theme and skin file assets (JSPs, style sheets, images, etc)
    • Portlet code (Java classes, JSPs, XML files, etc)

  3. A manual process which involves many people and few tools
    • have to define and test the application deployment process!

Developers create portlets and other J2EE resources. Typically done with Rational Application Developer (RAD). Resources must be checked into a VControl System (VCS).

Web designers create themes, skins and perhaps portlet JSPs. RAD has a built-in theme and skin designer.

Administrators create the content tree (pages, labels, URLs). Done with the administration interface on the development server. Can also be automated with portal scripts and the wpscript tool. Portal configuration information must be exported to an XML file using XMLAccess and checked into the VCS.

Release manager creates a solution release package. Uses scripts to extract Java resources, design resources and portal configuration resources, from the VCS. Runs a build process to compile the Java code for portlets and other J2EE resources, and packages all assets into a solution release package ready for deployment. Checks the solution release package into the VCS.

Operator "stages" the solution release package into the staging environment for test, then finally into production. Checks out the solution release package from the VCS. Deploys file-based resources (portlet WARs, portal EAR, etc). VCS can synchronize the file-based resources automatically. Uses XMLAccess to update the portal configuration.

 

Testing Best Practices

Your test plan must include both functional and stress testing. The #1 reason for deployment delays and disappointments is an incomplete test strategy and lack of a staging environment.

Define acceptable performance requirements up-front. Use Techline to obtain initial environment sizing. Stress test the portal environment and application to ensure that it exceeds the performance requirements.

A staging environment is a critical infrastructure component 4Without it you can.t load test new portal releases to ensure that the performance remains within an acceptable range. This is the last chance to ensure that the deployment process will run successfully and avoid portal outages.

 

Tuning Best Practices

Before load testing, tune the portal environment:

  1. Operating system
  2. Network
  3. Directory server
  4. Web server
  5. Application server
  6. Database

 

Load Testing Best Practices

Load test the environment to failure and tweak individual components for optimum performance (including portlets). This gives you a performance baseline for future comparisons.

Suggested approach to load testing:

  1. Build a single node and deploy the portal application
  2. Remove portlets that require back-end access for initial test
  3. Add portlets that integrate with back-end systems and retest
  4. Document performance baseline for a single node
  5. Build additional portal nodes and cluster them
  6. Document performance baseline for the cluster

 

Monitoring Best Practices

Select a performance monitoring tool, Wiley Portal Manager, WSAM, etc...

Monitor everything:

  • Back-ends systems - Content servers, databases, security, etc
  • Mid-tier - Portal
  • Front end - HTTP servers, caching proxies, networks, test clients

Focus on database capacity, throughput, response time, and sessions created.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Rational is a trademark of the IBM Corporation in the United States, other countries, or both.