Blog Host: Tony Higham - executive IT architect, IBM READ ENTIRE BIO

To that end, I'd like to present an analogy that describes what I have seen with several customers, including those who are very experienced with both WebSphere and J2EE technologies. This analogy is based upon a number of customers who have experienced difficulty in implementing the portal and eventually reached out to the Portal Technology Team at IBM (which I am proud to be a member of) to get direction and position themselves for success. I also want to point out that this isn't a ploy have an army of IBMers implement your portal. Simply put, what I am suggesting is that you leverage the experience that we've gained from hundreds of portal projects to identify the gaps and risks and mitigate them early.

The analogy
Implementing a portal is rather like driving from point A, a point you know, to point B, a place that you've never been to before. Your boss is waiting at point B for you to arrive at a specific time and for a specific cost. If you're lucky, you get to estimate how long it will take you to get there and influence how much money you're allocated for the journey. As an experienced technologist, you're going to collect information about what you need to do and how you're going to get there and set out a plan for success. Let's say, for argument's sake, that you need to go from New Hampshire to Georgia -- not an easy trip, but one that can probably be accomplished in a reasonable amount of time. So you go out to MqpQuest, or perhaps to AAA, and get directions. You get your car serviced for the long journey, decide where you're going to rest overnight and book a hotel in advance. In essence you're as prepared as you can be, and you're ready to go!

If everything goes to plan, you'll be in great shape. But as the old saying goes (according to the Hitchhikers Guide to the Galaxy, at least) "expect the unexpected." In other words, use whatever means are at your disposal to anticipate issues and plan for them, and have a plan in place for dealing with the inevitable changes that we need to deal with on the fly.

On such a long journey it's almost impossible to avoid road construction, which diverts you away from the route that you're following. So what do you do at that point? Do you take the typical male approach and drive around and around just "knowing" that you're heading in the right direction, but not willing to stop at a gas station and validate that belief? What is the time delay and cost of doing so? What happens if your boss calls when you've made it as far as Washington D.C. and asks you what the implication of heading to Colorado is? While it's relatively easy to stop and get new directions, what are the additional challenges that you're going to face? For example, will you have to calculate for tornadoes going through the Midwest -- tornadoes you hadn't planned on facing and don't have time to anticipate because you have to make a course correction right now. Changes in the business goals and technical challenges are going to happen. The key to success is what tools you arm yourself with to deal with those challenges.

A tool that would help your journey immensely is a navigation system. Not something that does all the work for you, but a tool that helps you plan out the route and deal with unexpected situations by anticipating them and routing you around issues with the least disruption. When we hit construction and are routed to a detour, the navigation system automatically figures out the most efficient way to get to your destination. If your destination has to change, then you simply put that information into the navigation system and it automatically calculates the more efficient way to get there based upon where you are right now. Integrated with a weather alert system like XM Radio, you can even be aware of what's changing around you and avoid those frustrating pitfalls (political landmines) like tornados that can get in the way of progress.

Bottom line
Having access to an experienced portal architect who can help you plan your route, anticipate issues based upon experience and deal with unexpected issues as they arise, is the most effective tool that you can leverage to improve the success of your portal project. Good luck with your portal journey, and I hope to see you along the way.
Posted by Tony Higham So why are companies implementing WebSphere Portal?
11 AUG 2005 13:10 EDT (17:10, GMT)
Most people define WebSphere Portal by what it does rather than what it's used for. What WebSphere Portal does is provide a single point of access to a role-based environment, which delivers the content and applications that people need to get their jobs done. WebSphere Portal is used for managing relationships with people, and, therefore, the portal must meet the needs of the people it serves. For example, providing employees with a self-service solution to benefits information and enrollment, etc., brings costs savings in many areas such as printing, mailing and call center staffing. Giving employees access to the information that they need when they need it not only results in improved productivity, but also in a reduction in internal call center activity -- both of which are important metrics for solid ROI.

But it doesn't stop at the employee community because the same technology platform can be used to manage relationships with customers and also business partners. Partner portals are typically focused on meeting the individual needs of each partner that a company has to interact with, and giving them a self-service way to do business with the company. As with the business-to-employee portal, increased revenue or cost savings in areas such as customer service staffing are key to proving that the portal can pay for itself within a given timeframe.

Though is it typically one of the above communities that drives the initial implementation, more often than not, the investment is made upon the fact that portal infrastructure will be used to meet all of these needs over time. Being able to leverage the same portal infrastructure to meet very different needs of each of the different groups of people is key to maximizing software investments.

That's all well and good, now here comes the big question: Why not build it yourself? Isn't a portal just like an ASP or a JSP page with a bunch of "holes" in it for content and applications? At a simplistic level, a portal is basically a bunch of windows that aggregate content and applications and deliver them to a Web browser. However, it's the services that the portal product provides such as multi-device, multi-lingual, search, content management, document management, rules-based personalization, authentication, authorization (just to name a few), that take many years to build.

Ok, I'll take my IBM hat off and play the devil's advocate. Let's say that I could cut down the amount of services because I don't need them for my employee portal. I can integrate with my existing content management system and build a bunch of code to do some personalization. This approach might work well for a single community of users, but it breaks down when attempting to repurpose the solution to meet the needs of different user communities or deliver content to different devices, or when lots of new services need to be built to meet the demands of the user community.

When considering a portal strategy, it's important to choose a technology that can meet the needs that are driving the initial portal implementation and is flexible and extensible enough to meet future needs at minimum cost and effort. The cost of taking a home-grown portal that is specific to a given business problem and generalizing it such that it can be used for multiple business solutions is likely to be much greater than purchasing an infrastructure component upon which multiple portal solutions can be built.
Posted by Tony Higham Maximize effectiveness of your portal implementation with applications that leverage portals
10 AUG 2005 12:14 EDT (16:14, GMT)
Most customers who are adopting WebSphere Portal already have a Web application platform of some sort. While it's technically possible to embrace WebSphere Portal as a single enterprise application environment, the reality is that it will take some time to get there and it's likely that the existing Web application platform and the portal environment will co-exist for some time.

A key challenge of implementing a successful portal project is to identify candidate applications that truly need and leverage the capabilities that portal provides. While this sounds like common sense, coming up with a process for identifying those applications is a little more complex. To help with this, here are some key questions (and rationale behind those questions), that can help you identify portal application candidates. This is by no means a complete list, I've included it to give you a flavor of the types of questions that can be used to identify application candidates that leverage the portal environment.

1. Does your application need to allow the end user to tailor the application?

   Portal applications typically comprise a number of individual portlets, each of which provides a specific functional component of the overall application. These individual portlets interact and create a complete application experience for the portal user. Portal users who are given privileged user access to a page (or a number of pages) can tailor the application experience to their specific needs. Privileged users can rearrange the layout of the portlets on the page, add portlets to the page and remove portlets from the page.

   Portal administrators can use shared pages to limit the amount of freedom that privileged users are given. For example, a shared page can be used to enforce a mandatory number of portlets for a specific application, along with their layout on the page if so desired. A regular page that inherits its content from the shared page allows the portal user to add and remove optional portlets to the remaining space on the page.

2. Does your application need to support multiple languages (e.g., English, French, Japanese, Chinese, etc.)?

   The portal provides native support for identifying the preferred language of the user (based upon browser and/or user profile settings) and serves up the portal interface and portlet content (if available) in the preferred language identified by the portal user. The portal interface is translated into a number of languages that are provided out-of-the-box. Customizable areas of the portal, such as page tree, which is used for navigation, allow the administrator to specify multilingual values for items that are displayed to portal users.

   Portlet developers can fully localize all of the content in portlet applications. Application strings can be stored in resource bundles, and portlet help text can be stored as separate JSPs (one per language) to simplify the translation of larger amounts of text. The portal identifies whether or not the portlet supports the preferred language of the portal user and serves the appropriate content to the user. If the user's preferred language is not supported by the portlet, the default language of the portal is used. The default language of the portal can also be customized.

3. Are users required to identify themselves (authenticate) with the application for the purpose of authorization to application resources?

   The portal provides authentication and authorization capabilities that portlet applications can leverage. Applications that require simple all-or-nothing access privileges can be implemented as either Web applications or portlet applications. However, applications that require roles-based access (authorization) are much stronger candidates for portal applications because the portal provides flexible authorization capabilities that do not have to be built into the application.

4. Will the application capture user profile information and tailor the output to those preferences?

   The portal provides user profile capabilities that portlet applications can leverage to create a highly personalized user experience. Applications that require personalization capabilities are strong candidates for portal applications because the portal provides flexible user profile and personalization capabilities that do not have to be built into the application.

5. Will the application support multiple groups of users, each of which have different look and feel (branding) requirements (no matter how minimal the differences in the look and feel are between the groups)?

   The portal provides a flexible structure for creating, securing and branding different areas within the portal to meet the needs of different groups of portal users. Applications that require a different look and feel based upon the user identify can leverage the portal's ability to create multiple page structures, each of which have a different portal theme that controls the overall look and feel.

   The administrator can deploy the application(s) to both page structures, each having a different layout and application components (portlets) if so desired. Alternatively, shared pages can be used to make the same application(s) available to both page structures, while allowing each page structure to be secured and customized to the individual needs of the different groups.

6. Can your applications' functionality easily be divided up onto atomic components that can operate independently?

   Application functionality that cannot be easily divided up into smaller components may prove difficult to implement as a collection of individual portlets that interact to form a portlet application. While it's possible to have a portal page with a single portlet that requires a complex interface with multi-page (wizard-like) functionality, this might be a better candidate for the Web application platform.

   Consider portal applications to be a number atomic components that can operate independently in order to fulfill a specific piece of application functionality. These components (portlets) can also interact with other portlets on the same page to perform multiple pieces of functionality. Portlet application developers have no control over what portlets in the application are placed in what layout on portal pages. That decision is made by the administrator and can be delegated to portal users. Thus if the application cannot be broken down into autonomous units of functionality that can interact with each other if they happen to be placed on the same page, then it may not be an appropriate candidate for the portal platform.

Because the portal user interface is extremely dependent on the existence and definition of styles, modifying styles has to be done with great caution. A simple typographical error that changes the name or definition of a style or -- worse -- deleting styles, can cause the theme to display incorrectly or even break completely. Always create a backup copy of the portal style sheets before making any modifications.

All right. That's the background and the disclaimer over with, so let's get to the nitty gritty of how style sheets are used and how they can be optimized. When a portal user requests a page, the portal sends the style sheet (via the Web server) to the browser as part of the Web page. Browsers can reduce the performance impact of downloading style sheets repeatedly by caching them on the user's machine. This results in the style sheet being downloaded once, or whenever the style sheet changes.

Given that the default style sheet for WebSphere Portal (Styles.css) is 50 KB, optimizing the size of the style sheet can improve overall performance of the portal, especially for heavily used portals. By performing a number of simple steps, the default style sheet can be reduced to approximately 22 KB (more than 50% reduction in size). The style sheet should only be optimized when development is complete, and should only be installed on non-development servers (staging and production only). The main reason for this is to simplify the debugging of style-related issues on the development server.

To optimize the Styles.css file to its minimum size for use on non-development servers:

• Remove all comments. These include all text between and including the comment markers /* */ . These are similar to HTML comments, in that they are downloaded to the client with the styles and so are really only useful to a developer.

• Remove all white space (unnecessary formatting). A CSS file does not need to be "readable" by humans; therefore, all unnecessary formatting can be removed. This includes tabs, spaces and carriage returns.

• Optimize styles. This is a task that can either be done automatically using a tool or manually. While a CSS optimization tool might produce the most optimized file, the file may not be readable (which, in this case, isn't too much of an issue), but it may also create additional problems. For example, there are some instances where removing trailing or leading white space from a style causes that style to render incorrectly in some browsers. Most tools are not intelligent enough to handle these exceptional circumstances. However, manually performing these tasks will obviously take longer.

• Put layout and look and feel information within the style sheet where possible, because of caching. It is better to have a larger style sheet containing reusable styles, then to duplicate the styles across pages.

The IBM Portlet API provides some capabilities (for example, click-to-action portlets), which are not yet supported by the JSR-168 API in WebSphere Portal. It's my experience that most people choose cooperative portlets, which are supported by JSR-168 and click-to-action. While they accomplish pretty much the same thing, click-to-action is specifically the ability to click on a field and have the portal give the user a drop-down list of values from which to choose. When one of those values is chosen, it can be communicated to other portlets on the page. Cooperative portlets can also take user input and share it with other portlets on the page or with other pages. Suffice it to say that click-to-action is essentially a deprecated term.

While the JSR-168 API is not yet as feature-rich as the IBM API, IBM is aggressively adding those capabilities as extensions to the JSR-168 API in WebSphere Portal. IBM is taking great care to implement these extensions to be portable across portal vendors. While WebSphere Portal 5.0.2 technically supports the JSR-168 API, its use in production deployments should be carefully considered, given that it's the first implementation. In WebSphere Portal 5.1, the JSR-168 implementation has been "hardened" and readied for production deployments. For example, the new interface for the Workplace Web Content Management product is written completely as JSR-168 portlets.

The JSR-168 API is the strategic direction for portlet development in WebSphere Portal. However, there are so many portal implementations based upon the IBM Portlet API, that IBM will support it for the foreseeable future. If your portlet requires specific capabilities that are only provided by the IBM portlet API -- such as click-to-action, portlet menus or portlet filtering -- those would be good reasons to use the IBM portlet API. In a WebSphere Portal 5.1 (or later) environment, IBM recommends the use of JSR-168 portlets wherever possible to eliminate the future effort of porting from the IBM API to the JSR-168 API. You can find detailed information on the differences between the IBM Portlet API and the JSR-168 API here.
Posted by Tony Higham Understanding the navigation challenge
05 AUG 2005 21:37 EDT (01:37, GMT)
When a user navigates to another portal page, either by using the portal's navigation or by clicking on a link inside a portlet, the portlets on the page are not notified of this action and, therefore, do not have the opportunity to perform any processing before the user navigates away from the page. The new page is rendered and the portlets on the new page can process any actions in the URI that the user selected and finally render their content.

The behavior presents some challenges, especially for portlets that perform transactions with users. For example, if a user is in the middle of a transaction in one portlet, then selects a link in another portlet that navigates to a different page, the portlet in which the transaction is taking place is not notified of the user's action, and the transaction state is lost. Effectively this may result in incomplete transactions that somehow need to be cleaned up.

One possible solution to this challenge is to implement a view JSP that manages such page transitions using JavaScript to refresh the present page then redirect to the new page. This gives the portlets notification that the page has been navigated away from and allows them to terminate transactions gracefully. While this is a simple solution, there is a high performance price of constructing the portal page, sending it to the browser and having the browser render the page in order to execute the redirection without displaying the contents of the refreshed page. The resulting performance overhead may prove unacceptable in terms of reduced response times, especially on a heavily used portal.

Some best practices related to portlet application design and navigation:

• Portlet application flow should be designed to process all interactions with portlets on a single portal page (and not by portlets on multiple pages).

• Portlet applications that have multiple portlets on the same page should be designed such that the layout of the portlets on the page is not known or controlled by the application (does not change based upon application state). Techniques such as Struts Tiles allow Web applications to pre-define tile layout and modify that dynamically based on application state. In contrast, the layout of portlets on the page is determined by the administrator (or user with sufficient access privileges) and cannot be controlled by the application.

The demand for software to run on lots of different types of platforms and interface with other bits of software from lots of different vendors is a mammoth challenge that most traditional engineers don't have to face to that extent. Along with that demand, we have an extremely high tolerance of failure or just inexplicable behavior. The famous "blue screen of death" has become common folklore at this point. Imagine driving down the highway and all of a sudden the windows start opening and closing or the lights and wipers just sort of randomly switch on and off. While these might not result in immediate danger, they are similar to the quirks that we face with software every day.

While we've made some amazing progress in the last 50 years, the software industry has a long way to go before engineers become licensed engineers who follow very strict approaches and have to adhere to extremely high standards or be personally accountable for the failures of our designs. Just recently I heard of a train disaster in Germany that resulted in the engineers being held personally accountable. That level of accountability is rather daunting, but, as the software industry evolves, I personally hope for it to become a reality, as it will drive great improvements in the quality of the software systems upon which we are increasingly reliant for our daily lives.
Posted by Tony Higham The paradigm shift of work
03 AUG 2005 21:55 EDT (01:55, GMT)
One of the most subtle, but in my humble opinion biggest, impacts of a global Internet is that is has driven a fundamental shift in the way that we work. Allow me to elaborate. In the previous generation, and in my generation up to a certain point in time, work was defined as a time and a place. I went to a place at a specific time, worked until another specific time and then went home. The idea of being in the computer industry and working from home was a lot more difficult before the advent of the PC.

Now we live in an "always connected" world in which we find ourselves hooked up to Sametime, Crackberry (yes, only you who have been truly assimilated by the Blackberry Borg will know of what I speak) and never-ending streams of e-mail into your inbox, which leave you feeling like you're stuck on that "It's a small world after all" ride. That's a fundamental shift that completely changes the time-and-place nature of work, which was commonplace when I entered the workforce. For the fortunate few, myself included, making that shift into the always connected world is eased by the fact that working with computers is a hobby, a passion and, last but not least, a job. However, for the majority of the computer industry (who actually have a life), the always connected world causes a great deal of anxiety.

While I don't know of a magical revelation that makes it all feel better, I did learn of a little bit of wisdom that helped me understand the paradigm shift and helped me a great deal. Work has changed from being a time and a place to a "state of mind." In this always connected world where we can literally always be working, especially for those of us who are either traveling or working from a home office, it's important to recognize that we have to make time for ourselves and our families. Dividing our time and switching effectively between the work and non-work state of mind is a skill that needs to be mastered so that we can use our time effectively. I am not saying that it's easy, but I will say that figuring out how to make some time in every day to do something for yourself is absolutely key to being effective and also enjoying life.

Personally I am just hoping that there is only one fundamental work paradigm shift in my lifetime, I couldn't cope with another one :)
Posted by Tony Higham Parallel portlet rendering: An integration risk mitigation strategy
02 AUG 2005 22:48 EDT (02:48, GMT)
One of great benefits of WebSphere Portal is that there are a great deal of pre-built portlets available for integration with existing backend systems. In addition to the ones that ship with the product, the Portlet Catalog contains around 600 pre-built portlets from IBM and third-party vendors (see IBM's WebSphere Portal catalog).

One of the challenges that was posed to me during a recent visit with a client was: How can I avoid a portlet that accesses a system that responds very slowly (or, worse, never) and stops the entire page from rendering? Parallel portlet rendering to the rescue! Parallel portlet rendering has been around since 5.0.2, and, when enabled, it allows individual portlets to be processed by separate threads in parallel rather than serially (which is the default behavior). At first glance, parallel portlet rendering could be perceived as a silver bullet to improve performance. While overall performance perception can be improved, parallel portlet rendering has to be used sparingly for such cases where one or two portlets on the page respond a good deal slower than the rest of the portlets on the page.

So what's this all got to do with integration risk mitigation? When you enable parallel portlet rendering (in the PortletContainerServices.properties file), you can also specify the maximum time that any portlets defined for parallel rendering must respond within. Portltes defined for parallel rendering that do not respond within the timeframe specified in the parallelRenderingTimeOut configuration variable are aborted by the portal, which allows the remaining portlets to be rendered.

As I've eluded to above, you have to use the Portal Administration interface to specify which portlets can be rendered in parallel. However, the timeout value is the same for all portlets.

Using the timeout can be particularly useful when using Web Services for Remote Portlets (WSRP) to bring portlets from a remote system into your portal as if they were running locally. WSRP is a great way to mitigate the risk of bringing "new" portlets into your portal environment since they run on another portal environment and only "appear" to be local to the user. Using parallel portlet rendering and a timeout value allows the portal to recover automatically (and gracefully) if for any reason the portlet on the remote portal does not respond.
Posted by Tony Higham Portals: Window to the IT world or window of blame?
01 AUG 2005 20:48 EDT (00:48, GMT)
Here are my thoughts on the benefits and technical reality of implementing a portal.

The benefits
The overall business goal of a portal is to provide a single place where users can access all the content and applications that they need, and where the content and applications are personalized to the user's role in relation to the organization. I use the words "role in relation to the organization" very explicitly, because while many portals are initial implemented as employee self-service vehicles to reduce HR costs, a great deal more value can be derived by rolling out the portal to customers, partners and other users who have different roles to play with your organization.

The technical reality
Implementing a portal basically means integrating the content and applications that you want to expose (and personalize) to users into the portal environment. At IBM, we call this "integration at the glass," because the content and applications that users have access to is calculated and delivered to users in real time by the portal. That makes portals extremely dependent upon the stability and availability of those applications, which can be a challenge. What this translates to in practical terms is that everything is now the portal's fault. If an application is out of service for maintenance, users report that "the portal is broken," and not that an application that the portal is reliant upon is unavailable.

The "everything is now the portal's fault" is a concept that you first have to accept (easier said that done) and, more importantly, that you need to define a risk mitigation strategy around. At a basic level you must establish an application owner and define a mutually agreeable service-level agreement (SLA) for each application. This will allow you to plan for outages and also react more effectively to unplanned application outages. Tomorrow I'll talk about leveraging parallel portlet rending as an integration risk mitigation strategy.
Posted by Tony Higham