When developing a portal application, there is lot of confusion wrt Customization vs Personalization. What the client might be calling Personalization might in fact be Customization or vice versa. So, it is very important to understand the difference between the two.

The term "customization" is used to mean the rendering of portlet content based on users preferences or manipulating the portal layout based on the users security attributes.

The term "personalization" is used to mean delivering portlet content based on a business rule or collaborative filtering.

Customization centers around what resources (portlets and pages) you show the users based on their role. This is a core capability of Portal. There are tools provided that help administrators provision these resources. Typically, portlets allow users to specify what kind of information should display. For example, a weather portlet might be customized to show
weather in the users home town.

Personalization can deliver content to a user based on a profile and/or business rule, or determine characteristics of a user based on previous purchases, or pages viewed. Personalization then selects content that is appropriate for that profile. For example, if a person has a high salary range, personalization can be configured to retrieve information about premium products, the page is assembled with the proper information and the user sees his personalized page.

Personalization includes a rules engine, a recommendation engine and a resource engine. Although a full install of Portal installs and configures personalization functions by default, there are additional databases to consider. For example, personalization uses the DB2 Content Manager Runtime Edition for storage of rules, campaigns and other objects. There is a logging framework used to record information about web site usage to a feedback database. The LikeMinds recommendation engine also requires a database to store information gathered through the logging APIs.

To use personalization, you need content to display to your users. Therefore, personalization and content management go hand in hand. You will also need to understand where content is stored and how it is managed to optimize performance.

In all organizations, those concepts that drive IT to make decisions are ultimately driven by the needs of the organization at the business or enterprise level.
Each can be supported through the appropriate use of technologies that help implement the following goals:

* Minimize application complexity
* Minimize TCO
* Leverage existing skills
* Leverage legacy investment
* Integrate back-end application
* Minimize enterprise complexity
* Support maintainability
* Support scalability
* Support availability

Good portlet design follows from an understanding of the WebSphere Portal execution framework and portlet processing. Well-designed portlets should take advantage of the components and services available to them from the WebSphere Portal environment in order to help ensure good design.

Here are some considerations when designing your portlets.

1. Think of portlets in terms of application components that are built either independently or cooperatively and that collectively deliver portal function.

2. Use application development frameworks (Struts or JSF) as appropriate to reduce development effort and to facilitate good design.

3. When coding to the portlet API directly (either legacy API or JSR 168) use a good MVC design approach.

4. Use portlet services instead of developing similar functions. When a service you need is not available, consider writing it as a portlet service that can be reused in a consistent way by other portlet applications.

5. Use Toolkit services as appropriate to avoid custom code to solve problems that are already addressed. For example, use JSP tag libraries such as JSTL and the WebSphere Portal tag library; use available JSF UI components or render kits.

6. Use software design patterns to address common application problems in a way that has proven effective with good design characteristics

Filed in: WPS

A good design suggestion is to use portlet services and common components.
Portlet Services provide a clear service layer within the portal that is fully defined and accessible by all your portlets though the use of a JNDI look-up.
You can use portlet services to provide common function that is registered to WebSphere Portal and made available to portlets. The portlet service framework is extensible so that vendors and customers can develop additional services. Then, portlet developers have a consistent method for finding and accessing common services.

Good portlet design will take advantage of these defined services and, when necessary, develop and package local common function as a portlet service to be reused throughout the portal.

WebSphere Portal provides several portlet services.

* ContentAccessService enables portlets to access remote systems or to get content from a given URL and return the InputStream.

* CredentialVaultService helps maintain a single sign-on experience for the portal when it becomes necessary to access backend systems that require authentication. Any portlet that needs to access these systems can use CredentialVaultService to retrieve stored user credentials and authenticate on behalf of the portal user.

* PumaHome service is new with Fixpack 1 for WebSphere Portal 5.1 (that is, with WebSphere Portal 5.1.0.1) and provides access to portal user profile information. You can retrieve, update, create, or delete portal user and group information using PumaHome.

* Property Broker enables brokered cooperation for independently-developed portlets. Cooperating portlets exchange information, and portlets can change state as a result of that data exchange. Portlets register their intent to co-operate with a broker, which facilitates the exchanges at runtime. Registration can be done through WSDL files or can be performed programmatically by the portlet. PropertyBrokerService assists with the programmatic registration of brokered properties, and with other functions that can be programmatically controlled, such as activating and deactivating actions.

Filed in: WPS

WebSphere Portal supports several emerging standards. The Java Community Process (JCP) approved the technical specification for interoperability between portals and portlets in October of 2003. The Java Portlet Specification ( JSR 168) defines a set of APIs so that portlets can be written to be independent of the portal vendor on which they will execute. Continued work on this specification to improve upon the base set of spec requirements is underway.

WebSphere Portal supports two APIs for portlet development: the IBM Portlet API (hereafter called the legacy API) and the industry standard JSR 168. The legacy API is a proprietary API that was available with earlier versions of WebSphere Portal prior to the definition of the industry standard. When JSR 168 was defined, support was provided so that WebSphere Portal now supports both APIs.

We discuss both APIs in this article so that readers familiar with the legacy API can get a quick understanding of the standard API. The focus of ongoing WebSphere Portal and portal development tooling efforts are on the standard API; therefore, the recommendation is to use JSR 168 for all future portal development.

The legacy API extends the servlet API for many of the main interfaces (request, response, session). JSR 168 does not extend the servlet API; instead, it provides similar function by wrapping the base servlet container function. Both APIs restrict certain functions that are available with the servlet API to a subset that makes sense for portlets running in the context of a portal. For example, unlike servlets, portlets can not send errors or redirects as a response to a request. Only the portal can do that, because it controls the overall response page.

JSR 168 portlets can specify a scope for session data, to indicate whether session data should be unique to the portlet or can be shared with any other portlet or servlet deployed within the same WAR. Portlet filters, similar to servlet filters, are available in the legacy API but are not currently supported in JSR 168.

Unlike the legacy API, the JSR 168 permits portlets to write the customization data using the available API in any portlet mode. In the legacy API, updates to user customization data were limited to edit mode and updates to configuration data were limited to config mode. With JSR 168 API a portlet can modify this data in any mode.

JSR 168 specification does not provide inter-portlet communication, or messaging, capabilities. In WebSphere Portal, the legacy API provides Property Broker Service has been enhanced to provide this function for the standard API.

One of the key differences between servlet execution and portlet execution is the two-phase execution process in WebSphere Portal. Before the portlets of the active page are rendered, an event phase takes place during which the portlets can process events (such as actions and portlet-to-portlet messages) and update their internal state. The portlet programming model assumes that state changes in portlets take place during the event phase and that the subsequent render phase only generates markup based on the current state of the portlets. However, the generated markup could still change between multiple portlet render invocations, even if the portlet state stays the same; for example, a portlet displays information retrieved from a backend system.

This design difference is one area that needs specific attention when migrating servlets to portlets. With potentially many portlets getting executed as a result of a single Web page request, developers need to follow good programming practices to make sure that portlets can re-render themselves correctly, even when there is no user interaction with that portlet.

At the start and end of the event phase, optional listener methods of portlets on the page are invoked. User initiated interaction, portlet messaging, and property broker activities can invoke event phase processing over many portlets on a page. Of course, not all portlets will get invoked during the event phase. Only when all event phase processing has completed will the render phase begin.

Legacy portlets can access the same request and response objects between action and rendering phases. Portlet developers sometimes put objects on the request during the action phase that the subsequent rendering phase would reference. JSR 168 provides unique instances of the request and response for each phase, so you cannot share parameters between phases using those objects; instead, use render parameters. Render parameters are unique to JSR 168 and are encoded in the URL itself, so that action and state are represented in the URL and can be bookmarked. Browsers can then return a portlet to a specific rendering state or view. The portlet developer must properly use render parameters to fully represent the portlet state.

Filed in: WPS

When starting a new portal engagement, we need to ask questions which can help jump start our engagement. The answers to these questions will come from the Business and technical groups. The questions are as follows:

1. Where is the information in our organization located?

In order to aggregate information, the location of this information (applications, databases, external sources) must first be determined.

2. Does the information needed currently exist?

The business drivers will determine what information is needed.

3. Do you want to enable collaboration and human interaction across all areas of
business?

Processes and applications don't make decisions the users do. A collaborative portal environment allows you to integrate human interaction with processes and information. These are capabilities that, for example, let people get the just-in-time advice, education, consensus, and approval they need to respond quickly, to any business situation or emergency.

4. Do you want to enable widespread teams to work together efficiently in the
context of the business process?

The portal allows you to make your organization’s people, processes, and information readily available to individual teams so they can solve everyday business problems more efficiently.

5. What are the processes by which that information is collected, updated,managed, and disseminated?

Portals are based on information that has to be managed from a collection, update, and processing perspective. There are likely existing processes by which information (that already exists in the organization) is collected, and these will have to be examined to determine if they must be modified to support both the business and IT drivers.

6. What defines a portal user?

The definition of a user will impact the types of security, the types of data, and the types of client devices that need to be supported.

7. What is to be gained by implementing a portal?

This is a direct reference to the business drivers. Once an organization defines what they want to achieve or improve upon, then a discrete set of business goals, or drivers, can be identified.

Filed in: WPS

Setting up Portal Search in a clustered WebSphere Portal environment is not a trivial task. Several significantly different configurations are possible. This article describes how you can use Portal Search in clustered environments, several possible topologies, and the tradeoffs involved with each. It discusses installation procedures and configuration, as well as underlying architectural principles of Portal Search.

Filed in: WPS

This guide steps through a detailed procedure for installing, configuring, and building an IBM® WebSphere® Portal V5.1.0.1 cluster using IBM WebSphere Application Server 6.0.0.2, Windows® 2000 Server, Oracle 9.2.0.4 Server and client, IBM Directory Server 5.1, and IBM HTTP Server 1.3.26.1. The approach described is applicable for any WebSphere Portal V5.1.x and any WebSphere Application Server 6.0.x release. To perform the tasks described here you need basic WebSphere Portal and WebSphere Application Server knowledge and administration skills. Some steps might require the assistance of another system administrator, such as the database administrator or LDAP administrator.

This article describes how to develop JSR 168 Portlet API Specification 1.0 compliant portlets using the IBM® Struts Portlet Framework 5.1.0.1. It walks through creating a simple Struts portlet using Rational® Application Developer V6.0 (hereafter called Application Developer) as the development environment. You could deploy and run this portlet to WebSphere® Portal V5.1.0.1 (hereafter called WebSphere Portal). This is the first in a two-part series on developing JSR 168 Struts portlets. In this part, you see how to create a simple Struts portlet, how to validate content (using the Validation framework), and how to display the header and footer (using the Tiles extension).

Filed in: WPS

One of the biggest problems faced with the WPS portlets is, User adds data to a form on a portlet, and before submitting the data, navigates to some other portlets. Now, when the user comes back to the original portlet, how do we show the same data back to the user.

One of the techniques is to leverage simple JavaScript techniques that force the form submit so that the back-end application can take care of persisting the form data into a session object. In order to transparently submit the form, one can use the BODY tag unload() event. However, because there are no HTML or BODY tags in any of the portlet views as part of the portlet standard, one needs to add the unload() event to the theme's Default.jsp.

So, once the user navigates to another portlet, the unload() event submits the data to the back end application, that persists the data in the portlet session. When the user navigates back to the portlet, the portlet can use the data from the portlet session to paint the form data in the portlet.

Filed in: WPS

JBoss has announced their latest portal offering, JBoss Portal 2.2
JBoss Portal 2.2 offers new enhancements in the areas of standards support, ease of
development and deployment and enterprise functionality. These include:
* Content Management
* Security
* Advanced Interportlet Communication
* Failover/Clustering
* Themes
* Personal Dashboard Enhancements
* Admin GUI Interface
* Search Engine-friendly URLs

In addition, JBoss Portal users now have a growing library of portlets developed by the JBoss community to choose from. The launch of PortletSwap (www.portletswap.com) in October has fueled a growing number of contributed portlets, themes and layouts for use with JBoss Portal. These Java Portlet specification (JSR-168) portlets will make it easier than ever for developers to build and deploy on JBoss Portal.

Filed in: Portals