In this article, Skyler answers your questions about the architecture and design of IBM® WebSphere® Portal (hereafter called WebSphere Portal) applications, including hardware topologies and development and deployment architecture, security and single sign-on, content management and personalization, and generic WebSphere Portal best practices. WebSphere Portal is a middleware platform for building and managing secure business-to-employee (B2E), business-to-business (B2B), and business-to-consumer (B2C) portal applications.
Question: What is the most critical factor that determines a successful portal project?
Answer: There is almost a one-to-one correlation between a successful project and the amount of load testing done on the portal project. I have never seen a project fail because a portlet was too hard to build, or WebSphere Portal didn't do some bit of functionality. I have seen a number of cases where the failure to do adequate stress testing did not reveal a problem in a portlet, a backend system with incorrect configuration, or a lack of caching causing performance problems. These problems were only revealed in production and caused incredible pain for everyone involved.
When I talk about portal, I like to refer to Skyler's Laws of Portal:
- First law of Portal - Everything is now the portal's fault. If done properly, portals will eventually frontend everything in your organization. This means the portal team will be blamed for all IT issues.
- Second law of Portal (corollary to first law) - WebSphere Portal will test every organizational deficiency in your company. IT systems that are supported by different IT groups with very high walls between projects will cause friction between groups on a portal project.
The problem is this. A portal is the glue layer for many diverse IT projects. While not completely like a chain that is only as strong as its weakest link, there are some similarities with WebSphere Portal. Unless you specifically take action to prevent crashes, non-availability, low scalability, or performance in the backend system from affecting the portal, any of these failures have an impact on the perception of the portal in the enterprise. Also because portal is an amalgamation of all of the backend systems it uses, problems will normally cause a round of finger pointing within the organization. Therefore, we recommend the following stress testing procedure.
Begin stress testing even before you have any portal code written or have connected it to backend infrastructure. As you add new backend systems (for example, connect to Documentum or query SQLServer) or create new portlets, do a new stress testing iteration. This allows you to quickly isolate the problem components and it also allows you to isolate problems early in the lifecycle (when there is still time to fix them). I have had many customers allocate two or three weeks to stress testing at the end of a project. What happens is that as they find problems with a subsystem, they have to pull it out of the portal, and reconfigure tests without that component. This is time consuming and error prone. Usually they end up having to pull everything out and begin with a new baseline test. This occurs at a point in the lifecycle where everyone's tempers are on edge and teams are working 120-hour weeks. It is not conducive to an on time release.
So, I also refer to a third law:
- Third law of Portal - Stress testing early and continuously is the only way to prevent the first two laws of portal from wrecking your project.
Question: When implementing WebSphere Portal, I struggle with documenting the requirements. Is there a predefined set of use cases for WebSphere Portal? For example, Login, Update Profile, Admin Authorization, etc. If I want to integrate with Domino or a customer application, is each integration point (portlet) a use case?
Answer: Quite surprisingly, the requirements phase is one of the trickiest phases in a portal project. There are no predefined set of use cases for WebSphere Portal. However, there are certainly use cases that do come up again and again. Login, Update Profile, and so on, are certainly some examples of common use cases. However, when doing use cases, I do not believe that portal is any different than any other project and that you should follow generic best practices in deciding what is worthy of use case analysis. I do not believe that a single use case for each integration point is likely to be the right level of granularity. You should try to organize use cases around functional areas, and this would likely mean multiple use cases for each integration point.
That said, I would like to make a rather controversial point. Most portal projects that I have seen rely solely on use case analysis for requirements gathering tend to have many problems. First, because portals are all about user interfaces, the business people creating requirements care much more about these requirements than a traditional project. Use cases, because of their verbal nature and their focus on behavior rather than look and feel, can cause many requirements that are critical to users to be left out. Because the users care about these non-captured requirements, they will usually force the portal development team to make many iterations of changes to the portal. Some of these are simple cosmetic changes, some are radical reorganizations of functionality and content. This is not to say that use cases should not continue to play a role in your project. They are still very useful. However, I recommend an additional exercise that I refer to as Portlet Sourcing. The idea is to collect requirements from users in a visual manner. This is done either in a low fidelity way via a whiteboarding session, or in a high fidelity way via a set of wire frames.
This visual modelling accomplishes two things. First, it forces the business to think about look and feel issues early and provides them a forum to create these requirements. Second, it enables the development team to identify troublesome user interface requirements before things are locked into stone. Many times, you see users create a visual requirement that cause a good deal of development effort. In many cases a simple change to the requirement dramatically reduces development efforts. With a visual design methodology, it is easy for development to express a problem and propose an alternative that is acceptable to the user community. In a completely verbal methodology, the user's word tend to be taken with an almost holy reverence. Visual designs tend to be treated as malleable.
After the visual modelling occurs, our Portlet Sourcing methodology moves into a second excercise. Take each page created and break it down into individual components. For each component, development and business users should answer a long list of specific questions. Some of these questions include things like who owns the backend data for a particular component? I do not know how many times I have seen users request a News portlet, but haven't identified who is creating the news. Other reasons to understand backend ownership: What if the backend system is only available 6 days a week and you have a 99.999 availability requirement on the portal? What if the backend system loses funding? What if the interfaces change?
If you would like to schedule a workshop that includes a discussion on Portlet Sourcing, please have your Software Sales rep contact my group, IBM Software Services for Workplace, Portal, and Collaboration.
Question: When sharing customer data in a B2B portal, a common requirement from a client manager is to be able to see in the portal exactly what the client can see. What would be the best security approach to achieve this?
Answer: What you are describing is something we call "user impersonation". While I will describe how to implement this behavior, I would like to begin with a general warning. Any system implementing this behavior is inherently insecure. There are, of course, things we can do to ameliorate these security concerns to a degree, the fact remains that we are explicitly allowing someone to impersonate a user. Many security implementations make the fundamental assumption that the user interacting with it is a real user (think about auditing, and so on). WebSphere Portal is one of these technologies that makes this implicit assumption and you must be aware of what you are giving up when you decide to violate.
User impersonation is conceptually simple. We make WebSphere Portal think that we are actually the impersonated user. To do user impersonation properly, it is best to have an SSO system like Tivoli® Access Manager or Netegrity® Siteminder. Most SSO systems allow you to script the login event. You login as the client manager and select the name of the user that you would like to impersonate. The login script then checks access rights. Assuming everything worked properly, the SSO system writes three pieces of information to the HTTP header: the impersonated user id, a flag that this is an impersonated session, and finally, who the real user is. The Trust Association Interceptor installed into WebSphere Application Server for the SSO system takes the impersonated userid and creates a WebSphere identity that portal will use. You also want to create some additional code to use the other header values to alert portlets that they should not perform operations that are not available to client managers and to allow audit logging of the real user's credentials. Note that you are relying on your portlet authors to enforce alternative behaviors. This is not a safe thing to do for many types of applications. If you are writing an online banking portal, do you really want to trust portlet authors not to install a backdoor or create a bug that allows a user impersonator to drain someone's account? Admittedly, this is a bit of an extreme example so use this approach with care.
Question: How will you make installation of WebSphere Portal easy?
Answer: You sound like you had some bad experience with an older version of WebSphere Portal. I would argue that, today, WebSphere Portal is one of the easiest products to install. There are several reasons. Prior to version 5.0, we took an approach to installations that seemed good, but turned out to be very problematic. We tried to be to smart with the install. Our idea was that we should automatically try to configure the portal to fit your environment. Because every customer is unique (trust me, I have seen more than 200 environments), the portal installer had an almost infinite number of variables that we needed to juggle. This caused two major problems. First, if it made any mistake in assessing the environment, it had a good probability of wrecking the install. Second, to avoid situations that were ambiguous, it collected too much information upfront. You have to know all about your environments, such as Oracle®, LDAP, Domino, and so on, before you could even install WebSphere Portal.
In 5.0 of WebSphere Portal, development made a dramatic change to the install procedure. First, they split the install into two pieces: base install and configuration. The goal of the base install is to ensure that you never ever fail in the installation. We want to make sure a working copy of WebSphere Portal is installed that you can test. That way, when you move to the configuration step, any changes that you make (change DB to Oracle, move to LDAP, and so on) that cause a breakage are identified immediately. Their second major change was to make the configuration step user scriptable. They use ANT to do the configuration. Most J2EE development shops have some ANT scripting experience and those that don't can get a book and learn it quickly. In many cases for common environmental setups, you do not have to modify the configuration scripts, but it's nice to be able to if needed. The third change was to dramatically improve the installation logging. They tried to be more verbose in the logging and to capture information at the lowest level rather than logging a bubbled up cryptic message. In the field, we saw non-problematic installations go from 20% of users prior to 5.0 to 95% with these changes.
Development did not stop after 5.0. In 5.1, they added a number of items that made installs even better. They added archive installs (to help shops with large portal clusters), more GUI options for SMB customers who have less complicated environments, and some better packaging of components together.
Question: I want to test portlets or pages. But for that, I need to have real URLs. As WebSphere Portal 5.0 generates it dynamically, I don't have the URLs. How can I do the testing?
Answer: As you have noticed WebSphere Portal in version 5.0 and below, generate URLs is an unusual way. A portal URL contains a dynamic delta of the portal's state rather than a direct link to a portal resource. This means that it is impossible to make normal 5.0 URLs do what you want. However, you do have several options. In 5.1 of WebSphere Portal, URLs are handled very differently. Version 5.1 URLs are truly direct links to portal resources. This means that you would no longer have these difficulties. However, migrating to 5.1 just for testing is a bit drastic. Another option is to use different testing software that can handle dynamic URLs. While this is a useful option for other reasons, it is probably not the answer that you were looking for. A better idea is to use the Friendly URL feature within WebSphere Portal. With friendly URLs, you can create real URLs for portal resources.
Question: I recently installed WebSphere Portal 5.1 and I'm planning, together with my customer, to develop some portlets. How can we decide between standard portlets and JSR-168 ones? Have you any suggestions about that?
Answer: Assuming that you are using V5.1, JSR-168 portlets are our recommendation for all new portlets. If you are using a version of WebSphere Portal prior to 5.1 or migrating to 5.1, the answer may not be the same. One thing to point out is that there is an assumption that by using JSR-168 portlets, you can use them in non-WebSphere Portal servers. This is not really true. When building your portlets, take advantage of the many portal features and services, like click-to-action and people awareness, that are provided by WebSphere Portal server. It may seem like it is better to keep code from relying on any particular vendor's portal implementation. However, this is a false economy. We are in the portal world where the J2EE community was in 1999. We now have our version of the servlet specification and not much else is standardized between vendors. Expect over time that the situation will improve. In the meantime, you are just cutting your own throat by trying to prevent vendor lock in until more standards appear. You will massively delay your project by rewriting all of the services that the portal vendor provides for you. Unless you are a vendor of portlets, it is never worth the time or money to do this.
Question: What are the best practices or approaches for portlet unit testing? During the deployment process, we need to unit test all the portlets. We should be able to run the tests similar to Junit. Currently, there are no tools available to unit test the portlets. Is there any plan to support portlet unit testing in the near future?
Answer: This is a good question with no truly great answer. I am a huge advocate of unit testing and have always loved JUnit. Certainly, there is still value in JUnit even in the portal world. You will still want to use JUnit to create unit tests for logic that are called without a Web harness. For things that need a Web harness, there are a number of projects similar to JUnit. These are not unique to portal. My favorite is the Apache Cactus project. Cactus is not a panacea though. I am certainly waiting for the first inspired developer to create PortletUnit.
Question: We are trying to estimate the hardware requirements for WebSphere Portal 5.1 on a Solaris® platform. Any suggestions?
Answer: Yes, one major suggestion. Please talk with your Software Sales representative. They can help you setup a Techline sizing. IBM Techline will ask you to fill out a short survey describing your proposed portal and its estimated usage metrics. Techline will input this information and output a sizing recommendation based on your choice of hardware platform (including Solaris).
Question: I would like to know if we can allow the users to add only a specific set of portlets when they use the Edit Layout option in a portal page. Is this possible and how?
Answer: In the advanced properties for a page, you can specify a list of allowed portlets. See "Managing pages" in the WebSphere Portal Information Center.
Question: Currently RAD 6.0 does not allow development of portal projects that run on WebSphere Portal 5.1. When will this be enabled for 5.1?
Answer: You can download the RAD 22.214.171.124 fixpack. After you install the fixpack, you can build and test WebSphere Portal 5.1 projects.
Question: Could you please share details on the Websphere Portal server product roadmap? Is WebSphere Portal server 6.0 in the pipe line? What new features can we expect to see in 6.0 and when will it be released?
Answer: It's really no fun, but we can't discuss future unannounced products. WebSphere Portal today is an incredibly mature and feature rich product. You will be surprised at how much you can actually do to extend the product with a minimal amount of work. However, I can say that the development lab is cooking up a lot of new and interesting things. If you do need a roadmap, please talk to your Software Sales rep to set up a briefing. I will also say that there are a number of new capabilities that will be exposed even when the next fixpack appears. Be on the lookout for it, coming soon.
- WebSphere Portal zone contains technical information for developers and administrators.
- developerworks WebSphere Portal V5.x contains product documentation, online help, and more.
- WebSphere Portal Catalog contains portlets you can download.
- Best practices: Developing portlets using JSR 168 and WebSphere Portal V5.02 is a collection of best practices for portlet developers who want their portlets to conform to, and to leverage the WebSphere Portal infrastructure for, JSR 168.
About Meet the experts
Meet the experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.