Introduction

Portlet environment expert Birga Rick answers your questions on developing and running portlets in WebSphere Application Server v6.1. She answers questions on JSR 168 portlet programming and portlet application features on WebSphere Application Server, WebSphere Portal programming model differences, aggregation concept, and general architecture and strategy. IBM WebSphere Application Server is a Web application server built on open standards that helps you deploy and manage Web applications, ranging from simple Web sites to powerful e-business solutions. A portlet is a Java™-based Web component that generates dynamic content for UI compositions like portals or mashups. WebSphere Portal offers a single point of personalized interaction with applications, content, processes, and people. For more information, see the developerWorks WebSphere Portal zone.

Question: Is it possible to run JSR 168 portlets on a standalone WebSphere Application Server v6.1? If so, what is the procedure?

Answer: Yes, the JSR 168 portlet runtime is integrated into WebSphere Application Server 6.1 that allows you to run JSR 168 portlets on a standalone server. An introduction on how to work with this portlet runtime is provided by a four-part article series starting with Exploiting the WebSphere Application Server V6.1 portlet container: Part 1: Introducing the portlet container.

Question: What is the strategy beyond the integration of the portlet container into WebSphere Application Server?

Answer: JSR 168 portlets are the IBM recommended programming model for user facing Web applications. IBM makes this programming model available for single components with the JSR 168 portlet container provided by Websphere Application Server 6.1. You can use the same component programming model to define business mashups (also known as composite applications) within WebSphere Portal. IBM is supporting the JSR 168 standard for portlets and is currently leading the JSR 286 expert group that defines the follow on version of the Java Portlet API. The JSR 286 Portlet Programming model will be supported by WebSphere Application Server and WebSphere Portal Server after the standard is finalized within the JCP. A good understanding of the differences is also provided by the following article, Exploiting the WebSphere Application Server V6.1 portlet container: Part 4. Migrating portlets between WebSphere Application Server and WebSphere Portal.

Question: Can I deploy a portlet on WebSphere Application Server and then expose it in WebSphere Portal via Web Services for Remote Portlets (WSRP)?

Answer: We provide a WSRP producer for download via the portlet catalog. It runs as a Web application on top of the portlet container in WebSphere Application Server. With this producer, WebSphere Portal customers can display their portlets running on remote WebSphere Application Servers within the portal pages of their portal.

Question: Where are my portlet preferences stored within the portlet container of WebSphere Application Server?

Answer: Usually, the portal stores the preferences into a back-end system. On WebSphere Application Server, portlet preferences are stored on the client-side into cookies. If the user disables the cookie cache in his browser, no user preferences are stored.

Question: How will the JSR 168 standard address some of the bleeding edge framework to be integrated, such as AJAX?

Answer: Currently, asynchronous rendering of portlets is not mentioned in the Java Portlet Specification JSR 168. With JSR 286, the next generation of this Java Portlet Specification, the new challenges for AJAX support will be addressed. A new portlet lifecycle method is planned to enable a portal framework to leverage AJAX technologies. According to the current proposal, a serveResource method will serve specific parts of the portlet markup, or to selectively change the state of a portlet. I recommend to take an early look at Java Portlet Specification V2.0 (JSR 286), and at the newest proposal for JSR 286.

Question: What is the recommended way to use AJAX in portlets on WebSphere Application Server?

Answer: Compared to other portal frameworks, WebSphere Application Server provides a very simple portal with URL addressability. Based on the portlet URL, it is easy to refresh a single portlet fragment. An AJAX request can call a portlet action, or include a specific portlet content.

Question: Why does a portlet application fail to install on WebSphere Application Server that uses the same name for a portlet and a servlet?

Answer: Each Web component requires a URL that uniquely identifies the portlet in the system. A servlet with the same name as a portlet results in the same URL /context-root/name for both components. Therefore, the installation of such an application is prohibited to ensure that URLs uniquely map to one specific Web component. By disabling the portlet serving that portlet application within an ibm-portlet-ext.xmi, you can configure so that the portlet URL does not get registered. This way, the portlet is not accessible via the URL, but the URL uniquely identifies the servlet and the installation of the application is successful.

Question: What do you suggest for our portlets to reference Java classes outside of our portlet application war file?

Answer: You can make the Java classes accessible to all portlet applications by putting them as jar files into a shared library. For WebSphere Portal, you can put it into the <PortalServer>/shared/app directory for WebSphere Application Server to create a shared library via the AdminConsole.

Question: How can I look at my WebSphere Portal v6.0 configuration (for example, which database I'm using, and so on)?

Answer: Because WebSphere Portal is a sophisticated product on top of WebSphere Application Server, some configurations are settings within the WebApplicationServer that you can find out via the Admin Console. Others are configured within specific portal configuration files, which are explained in more detail in the Portal configuration topic in the WebSphere Portal Information Center.

Question: What do you suggest in order to integrate .NET applications into WebSphere Portal? What technology or tools may I use to do this?

Answer: There are several ways to integrate applications into WebSphere Portal. Depending on the application design and structure, another integration solution might be better. You can reach a fast integration using iFrames for client-side, or Web-Clipping for server-side integration. A higher integration level is achieved when using WSRP. Alternatively, you can use Mainsoft to recompile and use your applications as a native JSR 168 application on WebSphere Portal.

Question: How do I get the LTPA cookie on WebSphere Portal when trying to develop a portlet based on the JSR 168 specification?

Answer: On WebSphere Portal, the LTPA cookie is available to the portlet via the credential vault service. You can use the corresponding active credential to establish an authenticated HTTP connection as follows:

	
  JaasSubjectCredential credential = (JaasSubjectCredential)
vaultService.getCredential(vaultService.PREDEFINED_SLOT_USER_JAAS_SUBJECT,
     CredentialTypes.LTPA_TOKEN, new HashMap(), request);
After retrieving the credential object you can use the base class JaasSubjectCredential
to set up a connection. The LTPA cookie is set automatically.
 HttpURLConnection connection = credential.getAuthenticatedConnection(<url>);

Question: What is the best or common strategy to enable dual language content on WebSphere Portal with Web Content Management (WCM) support?

Answer: The best practice to enable multi-language content is to use one library per locale. There is a complete explanation in Best practices for using IBM Workplace Web Content Management V6.

Question: We have a requirement to implement dynamic titles in some of the portlets we implement. We would also like to use the JSR 168 programming model to stay with a standard. Currently, we are using the tip from this article, Tip: Changing a portlet title at run time in WebSphere Portal V6, and it is working fine. However, when we minimize portlets on a page, the dynamic attribute does not seem to be available. And if we have multiple portlets on a page and minimize one of them, it seems like the title of the minimized portlet is set to the value of the previous portlet. I guess this is because the setTitle() is not called when a portlet is minimized, and therefore the dynamic attribute is not set? Is there any solution for dynamic portlet titles that also supports minimized portlets?

Answer: JSR 168 portlets get called independently of their current window state. Also, the GenericPortlet is aware of this fact and ensures that the setTitle method gets called within the render method. Therefore, the dynamic title attribute should be available whenever a portlet gets called. If it does not work on your WebSphere Portal version, check for available fixes.

Question: Could you please let me know how to add Google gadgets to our portal page? (Google gadgets code to the portlet code)

Answer: A Google Gadget Portlet has been recently released on the WebSphere Portal Portlet catalog. Just install the portlet, drag and drop it onto your page, and select a gagdet in EDIT/CONFIG mode and enjoy. The portlet will soon run on WebSphere Application Server. You can also check the following article on how to use the IBM Portlet for Google Gadgets with WebSphere Portal V6.0 to easily integrate Google Gadgets into your portal-based business mashups, Enhancing your portal using Google Gadgets with WebSphere Portal V6.0.

Resources

Learn

• Exploiting the WebSphere Application Server V6.1 portlet container: Part 1: Introducing the portlet container
  
  
• Exploiting the WebSphere Application Server V6.1 portlet container: Part 4. Migrating portlets between WebSphere Application Server and WebSphere Portal
  
  
• Comment lines: Stefan Hepper: Why you should take an early look at the Java Portlet Specification V2.0
  
  
• JSR 286 Portlet Specification 2.0
  
  
• WebSphere Portal Information Center: Portal configuration
  
  
• Best practices for using IBM Workplace Web Content Management V6
  
  
• IBM Portlet for Google Gadgets
  
  
• Enhancing your portal using Google Gadgets with WebSphere Portal V6.0
  
  

Discuss

• WebSphere Portal discussion forum
  
  
• developerWorks WebSphere live chat on May 24, 2007: Stephan Hesmer and Stefan Behl on Web 2.0 and WebSphere Portal
  
  

About the author

Birga Rick is the technical lead for the portlet environment within WebSphere Application Server and a member of the WebSphere Portal development team at the IBM Boeblingen Lab in Germany. Currently, she is driving the implementation for the upcoming version of the Java standard portlet API (JSR 286).

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers