renzhi

Introduction

In my previous post, I have proposed a framework for Inter-Portlet Communication (IPC) that made an attempt to remedy the shortfall of the Java Portlet Specification. Or at least, it is an attempt to complement the portlet coordination mechanism defined in the specification.

In this post, I will go into more technical details on how IPC can be defined in the portlet configuration file.

Portlet Configuration for IPC

Each portlet has its configuration parameters defined in an XML configuration file. When the portlet is deployed, portlet container will scan the configuration file to know to handle the deployment, portlet initialisation, portlet security, etc.

Using the same mechanism, we can also define portlet IPC in the configuration file. A portlet IPC configuration has three parts:

1. Inputs : which defines the IPC functions and parameters, allowing other portlets to make call to.
2. Outputs : variables that the portlet sends out as parameters to the IPC functions of the destination portlet when an action is performed, e.g. when user clicks on a button or a link, or when an event happens.
3. Default IPC : default function calls when an action is performed or when an event happens.

All three parts are optional, as portlets do not necessarily support IPC. A portlet can optionally define input functions, allowing other portlets to make call. A portlet does not have to define output, if it does not allow further action, or does not process any event. Portlet IPC can be wired and re-wired through manual settings, therefore, default IPC is not necessary. Default IPC defines the default behaviour when an action is performed or when an event happens, meaning that by default, that’s how the portlet is going to make IPC function call to the destination portlet, as specified by the developer. If default IPC is not defined, and if the portlet IPC is not wired through manual settings, nothing will happen as a result of when an action is performed or when an event happens. But it is a good habit to define default IPC properly.

To explain the IPC configuration, it would much easier to just give examples of real portlets. Let’s assume that we have a portal platform which can support multi-tenants and multi-communities, and the portal platform provides content management services (CMS) to all. Now, we have two portlets, the Journal List and Journal Content portlets. The Journal List will display a list of journals (or blogs, or articles) of a specific category of a specific community. The Journal Content portlet displays the content of a journal.

The Journal List portlet displays a list of journal titles, and maybe a summary of the journal article. When users click on the title, it will make call to the IPC function of the Journal Content portlet to display the contents.

The following shows the IPC configuration of the Journal List portlet:

Let us look at the inputs section first. This section defines a function such as:

displayList(group_id, category_id)

This means that any portlet can provide the group ID and category ID by calling this function, and the portlet will display a list of journals of that specific category in that specific group (or community). This is easy to understand, isn’t it?

Obviously, the portlet developer would want to document the API defined in his/her portlet, just like any good library developer would document his/her library API. Any number of methods can be defined in the inputs section.

The outputs section defines a list of output parameters that the portlet will pass as parameters to the input method of the destination portlet. The portlet developer would document which parameter(s) would be sent out when a specific action is performed or when an event happens. The assembly line people down the line (those who would wire the portlets together to build larger web solutions) would then know how to wire the portlets.

The ipcs section defines the default IPC behaviour of the portlet. In this case, we have only one defined, but you can have as many as you want, if your portlet is very complicated and can handle many actions and events. This section is also quite easy to understand. What it means is that, when users click on a journal title in the Journal List portlet, pass the variables articleId, groupId, companyId, version to the function

displayContent(articleIdFromIpc,
               groupIdFromIpc,
               companyIdFromIpc,
               versionFromIpc)

of the Journal Content portlet, and the destination portlet will display the journal content accordingly. Note that the order of the output variables do not have to match the order of the input method parameters. All we have to do is to map the parameters correctly.

The configuration part that says

tells the portlet container that when the destination Journal Content is invoked, it should be rendered at the location where the current Journal List portlet is found. And the part that says

tells the container that the destination portlet should be rendered with its window maximised.

This corresponds to use case 4 in my previous post. As we can see, IPC configuration of a portlet is quite simple.

Now, let us look at the configuration of the Journal Content portlet:

This portlet could have other IPC configuration too, but for the purpose of demonstration, I only show the section that illustrates our example.

This specifies a framework for portlet IPC, but the implementation is left to the developers of portlet container. Through a flexible parameter mapping mechanism, the IPC framework acts as a message broker between communicating portlets. To make daily administration and web assembly work easier, portal platform developers would want to provide graphical tool to wire the communicating portlets, and a way to persist the configuration settings.

Depending on the implementation of the portlet container, page rendering when a portlet communication happens can be done via traditional page loading, or via AJAX which is favoured by many developers nowadays.

Conclusion

This paper describe the technical details of portlet IPC configuration. As we can see, it is quite simple, and can easily be understood by any programmer. It’s just like defining API of a library, or web service interface of a system. Portlets communicate with each other by making function calls.

Complex web system can be divided into small, modular components using portlets, and complex page flow can thus be designed through a series of communicating portlets. The potential is not hard to visualise.

In a next post, I will show portlet IPC in action.