ICEfaces In Portals

If you have ever used a portal page you have firsthand exposure to a very disruptive user experience. As you submit from one portlet, the entire page refreshes and the user context that you had in other portlets is lost - a severe departure from the Rich Internet Application (RIA) experience that is expected from modern web applications. If you want to bring the benefits of RIA to the portal world, you are going to need to leverage Ajax techniques, but doing so in a portal environment raises a host of complex issues that will severely impede your progress, and require extensive low-level Ajax programming. The ICEfaces framework allows you to transcend all those issues and build portal solutions using pure Java techniques that combat the disruptive experience with RIA features in your portlets, and cause no disruption to other portlets in the page.

How It Works

ICEfaces uses standard mechanisms in the portal container when the portlet is first loaded, but from then on circumvents normal interaction through the container, instead using the ICEfaces Ajax Bridge (see theICEfaces Architecture for more details) for all client/server interaction. The basic mechanism is illustrated below.



The ICEfaces Portlet never performs an HTTP POST through the portal container, so never causes the page to re-render, and never disrupts the user context in other portlets.

The Programming Model

As with all ICEfaces development, you build a JSF application using pure Java techniques, and the ICEfaces framework handles all the intricacies of Ajax in the portal environment - allowing you to focus on application development. ICEfaces provides a base portlet class that handles all of the initial communication with the portal container, so you simply need to build your ICEfaces portlet page and enclose its content in an ICEfacesportlet component. All of the other ICEfaces components and RIA features can be used within the portlet.

Inter-portlet Communication

While the Portlet 1.0 Specification does not include inter-portlet communications, ICEfaces provides a natural way for portlets to interact via ICEfacesAjax Push . Because the Ajax Push mechanism facilitates asynchronous updates from the server to the client, interaction with one ICEfaces portlet can trigger a state change to other portlets in the same web application. This mechanism is not restricted to portlets in the same page at a single client, but can include updating other clients that are interacting with the same portlets. The basic push mechanism between portlets is illustrated below.



Now if you introduce an inter-process messaging system like JMS, the Ajax Push model can be extended to support IPC between portlets in different Web Applications as well, making the push mechanism applicable to pretty much any situation. So if you need IPC in your portal environment, you don't need to wait on a Portlet 2.0 container implementation - you can get it today with ICEfaces.

Portal Standards

ICEfaces portal integration adheres to the Portlet 1.0 specification and supports most of the JSR 168 Portlet API. In certain cases, likeprocessAction , the Portlet API actually leads to the disruptive behavior that the ICEfaces integration overcomes, so those features of the API are not supported. ICEfaces also supports the Portlet themeing mechanism defined in JSR 168, and provides one example theme that you can use or customize to your liking.

Supported Portlet Containers

ICEfaces has been tested with a variety of open source and commercial portlet containers including:

• Liferay
• JBoss
• WebLogic
• Apache Jetspeed-2
• Apache Pluto

Need to Know More?

You can find more detailed information about ICEfaces Portal Integration in theICEfaces Developer Guide , and specifically in the advanced topic onDeveloping Portlets with ICEfaces .