January 2009

« March 2009 | Main | December 2008 »

Federated versus Local Portal Development

Tuesday, January 27, 2009

A question that comes up from time to time at clients is what are the differences between developing a federated portal, using Web Services for Remote Portlets (WSRP), and a local portal. For those unfamiliar with the terms, a federated portal is one where the portal and portlets are typically running in different applications and containers where as a local portal is one where the portal and portlets are in the same application and container.

Some clients naively believe that developing a portal for a federated environment is identical to a local portal and that the WLP framework takes care of all the differences. While the WLP framework does do a good job of abstracting the differences between a federated portlet and a remote one, it is not perfect and I’ve seen more then one client get burned by assuming it was.

Given that, I thought it would be interesting to write a short post with regards to what you need to keep in mind when developing a federated portlet using WSRP. So with no further ado here are some thoughts, while not comprehensive, should provide you with some food for thought.

Behavior Issues. First understand that federated portlets and local portlets do not run in the same context and do not behave identically in all instances. There are many subtle nuances that crop up when attempting to convert a local portlet to a federated portlet that can be surprising to a developer new to remote portlets. For example, a common practice in backing files in a local portlet is to place information to be passed to the render objects (Page Flow controller, JSP, etc) as an attribute in the request object. This will not work in a federated portal since the backing phase and the render phase are actually two separate requests in a federated environment.

As a result, my personal recommendation is that if you are developing a federated portlet it should be run as a federated portlet in all environments, including on the developers workstation. Doing this does not require running a separate portal instance on the developers workstation since it is actually easy to do by simply creating a proxy portlet out of the same container and drop that in a test portal instead of a local portlet. I covered this topic in a previous blog post.

Governance. A federated portal is typically built by multiple development teams and spans multiple systems. Thus just like an SOA initiative, governance becomes a key factor in a successful rollout of a federated portal. A federated portal however is even more complicated then an SOA initiative because in addition to governing services one must also place governance around the user interface.

Without adequate governance and planning, different development teams could build portlets using different user interface paradigms leading to difficulties for users to navigate due to differences in UI. Another negative outcome you often see is different teams building the same style interface but using different artifacts (CSS, JS, images, etc) to do so. This leads to maintainability issues since any change in the Portal style requires multiple artifacts to be updated.

In short governance of the user interface must be a top priority in a federated portal implementation, particularly one that spans multiple lines of business in an organization.

Performance. The topic of performance is always a concern, regardless of whether the portal is local or federated. Federated portals had additional concerns since all access to the portlets is done remotely. Thus addressing items like keeping the size of the HTML in portlets small become more important since we are adding additional network hops.

Distributed Information. A significant issue in federated portals is that information is distributed across multiple pieces of infrastructure. For example, if multiple portlets are working with a specific customer then some of that customer information, such as first name and last name, can exist in multiple places at the same time. If this information is cached for performance reasons and another portlet changes that information then this information can become stale and out of sync with the proper state.

In a local portal addressing this issue is relatively easy, however in a federated portlet where the information resides in separate applications and infrastructure the problem becomes more complicated. A federated portal implementation should recognize if information is going to be shared and if it is mutable determine a strategy to ensure that information stays synchronized across all portlets and containers. Potential strategies here include using events to signal changes or adopting a distributed cache such as Coherence.

Versioning. Another key consideration is to have a versioning policy and plan for anything that couples the consumer and separate producers together. For example, it is very common in a federated portal implementation to use inter-portlet communication (IPC) to pass information between different components in the Portal. Any changes to this information or the structure of the information due to new requirements could result in the need to upgrade and redeploy multiple components of the Portal.

As an example, let’s imagine a federated portal implementation that provides insurance information. A consumer portlet allows the user to select a policy number to view while portlets provided by different lines of business provide different pieces of information about that policy. In this case the consumer portal tells the portlets which policy is selected by passing them a class that contains the policy number. This class is de-serialized, using Java serialization, on the producers where they retrieve the policy number to be displayed.

All well and good, however a new requirement for one of the portlets is that it display some additional information that requires the consumer to provide extended information about the policy. Using the example above, we cannot simply add the new information to the class because it will break the de-serialization of the class on all the other producers. This relatively simple change is now forcing us to upgrade all producers simultaneously.

There are a few ways around this such as making the serialization/de-serialization version resistant or by using XML and ensuring additional attributes can be added with no impact. The key take away though is to ensure that you have a strategy for versioning and this be taken into account from the start of development.

That concludes this post, while the list above is not comprehensive hopefully it includes enough to get you thinking.

Posted by Gerald Nunn at 10:58 AM | Categories: WebLogic | Permalink |