Portal Planning considerations

 

+

Search Tips   |   Advanced Search

 

Contents

  1. Overview
  2. Building a portal environment
  3. Software that can be installed on the portal machine
  4. Deployment Units

 

Overview

WebSphere Portal is not a simple plug and play application. It is a horizontal portal framework. Treat it like a complxes infrastructure project.

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.

For the pilot, just connect. Link/connect to existing systems. Little new functionality. Limited deployment. Plan 4 months minimum for first pilot release.

Average Portal project from 6-12 months.

 

Team Composition

Select a top notch project manager. Select an executive sponser who is merciless in bringing the teams to the negotiating table. 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 we've always done it". The project manager and 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 deadlnes.

Use a small architecture team with total systems responsibility. Empower this team to attach requirements to infrastructure. Architecture team members should be peceived 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. Only 1/4 of portal projects are development. the rest is testing, design, migration from stage to production, etc...

Best Practices

Since the portal will be the most visible element in your IT Infrastructure ensure success of this component. If the portal fails, your infrastructure is perceived as a failure. The portal will repeatedly cause turf battles.

Gather requirements

Most customers follow a requirements process that is inadequate to satisfy the needs of the portal. This does not mean throw away your process. You should think about adding portlet sourcing to your pocess.

To bring content into the portal we must identify the conent source (where the content is and who owns it). How we're going to get the content into the portal. It will take some time to finish the portlet sourcing exercise. Each portlet sourcing document should be the base for the portlet requirements and updated as decisions are made.

Portal Sourcing - Start with Wire frames

Draw out each portal page. Does not have to be fancy. Can do in Visio, HTML, whatever...

Create different portal pages based on role of user who pulls up the page. Also think about state transitions. If you click on one portlet, does it affect another.

Content and Document Management

What content do you want to display on WebSphere Portal. Where is the content stored? Who needs to create and change it, and who views it? What documents do you want to store. How many documents will be created each day. How large is each document. How many users will be accessing them (concurrently and total) and what will they be doing with them? What roles will they be assigned and how will workflow be used.

Single Sign-on Considerations

Portal is NOT VPN. Portal provides what we call pseudo-SSO. Do not put Portal accessible to the internet and then give access to backend applications. This is not best practices.

Portal is not a replacement for a pure SSO system like TAM, Netegrity Siteminder, Entrust, GetAccess, or RSA Clear Trust. Provide services like PKI, logon scripting, password reset, etc...

Validate your Plan

When you have your requirements and plans in place, validate them with an experienced 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.

 

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, ldap, db.

Do 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 your organization. Take the time to define the LDAP schema and replication strategy.

Integration at the glass means that the portal is highly dependent upon the availability of many other systems. Identify the people who own the systems with which you are integrating and establish service level agreemtns.

One of the first things to get budget-wise is the staging environment. This is wrong. A staging environment is critical. This is the only environment in which you can do true load testing.

Portal loves RAM. Allocate 2GBs per CPU. Max heap size in Windows and Linux is 1.3 GBs. Allocate 1 portal instance per 4 CPU. If multiple portlets on a page are access systems using SOA mediators, JDBC, JMS, or JCAs, you may need aonther instance. Minimum of 2 CPUs per instance of portal.

Use a portal monitor to help performance tuning and diagnosis. The entire portal environment is way too complex to understand without system management tools such as WSAM, Wily, etc... Wily tool is great because it lets you look at Porlets at the rendering level.

 

Security Best Practices

Do not externalize your 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. Like sign-on if no sign-on capability.

Carefully plan use of encryption, which is heavy and expensive. In Credential Vault there is 64-bit encryption. If you need 128-bit, you have to write a plugin.

Do not run WebSphere Portal as Root.

Give others only read access to the WAS_HOME and WP_HOME directories.

 

Best Practices Production Environment

A scalable and reliable production architecture is just one of the essential pieces of a WebSphere Portal architecture.

A well-desgned pre-preoduction architecture is critical to successful deployment and on-going portal operations.

have a development server.

have a test server server, but its role is vauley defined.

Some have an integration server for user for user acceptance testing.

Few have a staging environment, which is absolutely key to successful ongoing portal operations.

And lets not forget the authoring and rendering servers for WCM.

 

Best Practices Development

Integration with backend applications is costly . Enterprise bureacuracy increases exponentially with every integration point.

Avoid the use of bleeding edge technologies. WSRP and JSF are great, but let somebody else harden them.

JSR-168 is no longer bleeding edit. It is THE standard for V5.1. Only limitation is you cannot use click-to-action.

Identify the clients you are going to support. Remember some don't support all JavaScript features or iFrames. Note the limitations of WAP clients.

 

Design Best Practices

Customizing the themes to match some exotic web site can be very time consuming. Educate the user interface design team on portal capabilities. Performance is the most important consideration. A beautiful site that is slow will be rejected faster than a utilitarian site that is fast.

Select an existing theme and modify it to meet your needs.

Keeping portlets small and simple makes them easier for other developers to understand and maintain. Improvise and adapt existing portlets to create new portlets.

 

WCM Best Practices

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

WCM is easy to use and easy to get yourself into a mess. Every hour of time spent on design will save ays of rework.

Critical aspects of design that need to be done up front are the content model (including site model and taxomoney) and security.

Do not do personalization during phase 1. Wait for second version. Plan early for performance. Keep your rules to 2-3 in the beginning.

 

Caching Best Practices

Art. Not a science. Got to cache all over the place. Just do load testing and proceed from there. This will take at least a month of time to configure.

 

Deployment Best Practices

to deploy a portal release, the following resources must be synchornzied, packaged, and deployed to a portal server. Portal ocnfiugration, portal ocntent tree, portal application configuratin and settings and data, portlet access control information, portal artifacts (stored in the file sytsem) portal configuration (property files)

 

Testing Best Practices

Do an iterative type of process. Start with small load. Try to do on first with simple set of components, See the WebSphere Portal 5.1 Tuning Guide for details.

 

Building a portal environment

  1. Create a portal environment for unit testing

  2. Create portal environments for staging

    This environment should mimic the intended production environment, including the platform, OS, traffic, and load.

  3. Create a portal environment for production.

    Design for redundancy, scalability, failover, capacity, performance, and workload distribution.

  4. Configure security

    Choose an LDAP directory, an LDAP directory + Lookaside database, a Member Manager database-only configuration, or a custom user registry for authentication. To plan appropriately for security configuration, read the topics in the Enable security section before you

    If you plan to use Cloudscape as your database, you cannot use a custom user registry or a Member Manager database-only configuration for authentication. install and configure other supported database software, such as DB2.

    If you plan to use external manager security software, use an LDAP server or an LDAP + Lookaside database for authentication.

  5. Plan for backup and recovery.

  6. For performance and redundancy reasons, use separate servers for the database and LDAP

  7. Use both vertical and horizontal clustering in a production environment.

    Vertical clustering to take full advantage of the resources of a multiprocessor system; horizontal cloning to allow for upward scalability.

    Horizontal clones should reside in different geographic locations to guard against natural disaster or site outages.

 

Software that can be installed on the portal machine

Software Required? Recommendation
WebSphere Application Server Required. WAS and WebSphere Portal must be installed on the same machine. None.
Web server Optional. You can install the Web server on the portal machine or on a separate machine. To reduce points of failure and to offload processing, consider centralizing the Web server. The WebSphere Application Server plug-in that is installed on the Web server can take care of load balancing between remote Application Server instances in a cluster.
Database server Required for Cloudscape. Cloudscape is automatically installed with WebSphere Portal.

Optional for other database servers. You can install the database server on the portal machine or on a separate (remote) machine.

If you are not using Cloudscape, install the database server on a remote machine. Using a remote database server can improve performance and security, and can reduce the impact of server failure.
Database client Optional. If you use a remote database server, install the client software for the database server on the portal machine. Use a remote database server to improve performance and security, and install the appropriate database client software on the portal machine.
Directory (LDAP) server Optional. You can install the directory server on the portal machine or on a separate (remote) machine. Use a remote directory server to improve performance and security, and to reduce the impact of server failure.
Directory (LDAP) client Optional. If you use a remote directory server, client software for the directory server might be required on the portal machine. Use a remote directory server to improve performance and security.
IBM Lotus Domino Enterprise Server Not recommended. Install IBM Lotus Domino Enterprise Server on a separate machine to improve performance and to reduce the impact of server failure.
IBM Lotus Instant Messaging and Web Conferencing Not recommended. Install IBM Lotus Instant Messaging and Web Conferencing on a separate machine to improve performance and to reduce the impact of server failure.
IBM Lotus Team Workplace Not recommended. Install IBM Lotus Team Workplace on a separate machine to improve performance and to reduce the impact of server failure.
IBM Tivoli Web Site Analyzer Optional. You can install IBM Tivoli Web Site Analyzer on the portal machine or on a separate machine. Install IBM Tivoli Web Site Analyzer on a separate machine to improve performance and to reduce the impact of server failure.
WebSphere Translation Server Optional. You can install WebSphere Translation Server on the portal machine or on a separate machine. Install WebSphere Translation Server on a separate machine to improve performance and to reduce the impact of server failure.
IBM Lotus Extended Search Optional. You can install IBM Lotus Extended Search on the portal machine or on a separate machine. Install IBM Lotus Extended Search on a separate machine to improve performance and reduce the impact of server failure.
External security manager Not recommended. Install the external security manager software, such as IBM Tivoli Access Manager for e-business, on a different machine.

Refer to Components overview for more information.

 

Deployment Units

The supported products of a full-scale WebSphere Portal environment each need the attention of a member of the team of IT specialists and software engineers responsible for implementation.

  1. Dispatcher
  2. HTTP Server
  3. WebSphere Portal
  4. Portal search
  5. WebSphere Portal content publishing
  6. Directory server
  7. Database server
  8. Reverse caching proxy
  9. Forward caching proxy
  10. Reverse security proxy
  11. Security server
  12. Deployment Manager
  13. TivoliŽ Intelligent Orchestrator
  14. Back-end systems
  15. Domino
  16. Host systems
  17. Web applications
  18. Sametime
  19. Web Services for remote portlet providers
  20. Web Content Management Systems

Next

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

 

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