Inter-Portlet Communication in action
Introduction
In previous articles, we have described the basic use cases supported by the IPC (Inter-Portlet Communication) mechanism and the technical details of IPC configuration. I have also described how IPC plays a role in page assembly, page flow and in the web system. More importantly, I have described how IPC plays a critical role in the web assembly model.
The previous article provides a description of IPC on a conceptual level. This article will provide a detailed description of IPC in action. I will describe how IPC is configured and used, providing step-by-step, detailed instructions to do so.
IPC Use Cases
In this section, I will provide a detailed description of what IPC is capable of, through a few real use cases.
I am going to make a small assumption, assuming that you are familiar with the basic concepts of web page assembly, such as page creation, page layout design, and how to put portlets on web pages. Familiarity with the concepts of web page assembly will give you the insight of how IPC plays a critical role in the web assembly model, but is not a necessary condition to understand the current article.
Same Page IPC
This section describes how a portlet communicates with another portlet on the same page. This case corresponds to the use case #1 described in the previous article. I have created a page called “Test 1″ for this demo, on which I have put two portlets, namely the Journal List Portlet and the Journal Content Portlet, as shown in the following screenshot:
What we want to achieve here is to let Journal List Portlet interact with Journal Content Portlet through IPC. When users click on an article title in the Journal List Portlet in the left column, we want to display the article contents in the Journal Content Portlet in the right column. The Journal List Portlet is our source portlet, and the Journal Content Portlet is the destination portlet.
Now, let’s perform the IPC configuration of the Journal List Portlet:
- Click on the configuration icon on the title bar of the Journal List Portlet. When the portlet configuration page shows up, click on the Communication tab to get into the following communication configuration page:

In the portlet configuration page, the Communication tab is shown only if the current portlet supports IPC, and can send output IPC parameters to invoke the IPC function of another portlet.As shown in the screenshot above, we have not yet created any IPC configuration for the Journal List Portlet. At this point, if users click on the article title in the portlet, Journal List Portlet will use a default internal IPC mechanism to invoke another Journal Content Portlet to display the contents, but will not display the contents in the Journal Content Portlet instance in the right column on the page “Test 1″, as we would have wanted.
- We want to re-wire the IPC flow of the Journal List Portlet on the left column, so that the contents of clicked-upon article will be displayed in the Journal Content Portlet instance in the right column. Click on the Add button to enter the following page:

- This page shows all the output IPC parameters of the Journal List Portlet. IPC parameters are defined by the portlet developers according to its requirements. Developers define how many parameters, and which ones, are sent out when users perform a specific action on the portlet. The output parameters are used as input parameters to the IPC function of the target portlet. The software provider of the portlet would provide a manual describing IPC functions and parameters, just like a manual for library’s API, so that customers know to use the portlet to its full potential. According to the user’s guide, when users click on the article title, Journal List Portlet sends out the following 4 paramters:
- articleId: the unique ID of the article
- groupId: This ID indicates which group, or community, the article belongs to. As in my previous article, we assumed that the portal platform supports multi-communities management model, and each community can have its own content management system, managing its own articles and contents.
- companyId: This ID indicates which company, or organization, owns the article. Again, we have said that the portal platform supports multi-companies (or multi-tenants) management model.
- version: This is the version number of the article, as contents management system supports versioning control.
Describing the portlet’s functionalities and IPC paramters in details was not the main purpose of this article, a simple description is provided here to help understand the case.
For the purpose of this article, we just need to know which paramters are sent out by Journal List Portlet. Let’s select the first 4 parameters, then click on the Next Step button.
- The following wizard page shows:

In this page, we have to choose whether we want to communicate with a portlet on the same page, or a portlet on a different page. In this case, the interaction is between two portlets on the same page. Select the same page option, then click on the Next Step button to continue. - The following wizard page shows:

In this page, we have to decide whether we want to swap out an existing portlet or not. Select the “Do not swap” option, then click on the Next Step button to continue. - The following wizard page shows:

This page shows all portlets currently on the page “Test 1″ which support IPC. Any portlet that does not define any IPC function will not be listed here, even if it is on page “Test 1″.Select the Journal Content Portlet, then click on the Next Step button to continue.
- The following wizard page shows:

This wizard page shows all the IPC functions defined by the portlet that we have selected in the last step, namely Journal Content Portlet. The Journal Content Portlet only defines on function, let’s select it and click on the Next Step button. - The following wizard page shows:

This wizard page provides the parameters mapping functionalities, allowing us to map output parameters from the source portlet to the input parameters in the IPC function of the destination portlet. Parameter mapping provides the flexibility needed in the IPC framework, programmers do not need to hard-wire all IPC function calls during the development phase. Portlet communication can be re-wired during the assembly phase to satisfy any changing business requirements, creating new page flow by reconfiguring the IPC flow.Parameter mapping operation is quite simple. Select an output parameter in the Output list, and select a parameter in the Input list, then click on the Map button to map the output parameter to the input paramter. Output parameter is output by the source portlet, and the input parameter is received by the destination portlet. As the name of the output and input parameters look very similar, there is no need for further explanation. However, this is pure coincidence, as parameter names and order do not have to match.
After mapping is done, the page looks like:

Click on the Save button to save the configuration, then click on the arrow icon on the right side of the portlet title bar to return. - Back to the Communication configuration page, it shows:

The IPC configuration list shows one configuration. The information shows that the current portlet, namely the Journal List Portlet, will communicate with the Journal Content Portlet on page “Test 1″. This is a one-to-one IPC configuration. It is also possible to create one-to-many IPC model by adding another configuration, if we want to. In a one-to-many communication model, when users click on the article title, the output parameters of the Journal List Portlet will be “broadcasted” to multiple target portlets at the same time. Of course, the source portlet does not need to do anything special in this case, IPC framework will take care of broadcasting IPC paramters to all destination portlets. - Click on the arrow icon on the right side of the portlet title bar to get out of the portlet configuration page.
That’s how easy IPC configuration is. We have just finished changing the way Journal List Portlet and Journal Content Portlet on page “Test 1″ interact with each other.
When we are back on page “Test 1″, click on the article title in the Journal List Portlet in the left column, and the article contents will be shown in the Journal Content Portlet in the right column, as shown in the following screenshot:
IPC configuration should be as easy as that, we have created a new page flow in a few seconds. We can also configure the destination portlet to interact with a third portlet, by becoming the source portlet of the third portlet. Portlets and pages can be chained together to form very complex page flow.
Same Page IPC, Replace Target Portlet
This section describes how a portlet communicates with another portlet on the same page. The difference between this case and the previous one is that the destination portlet is currently not on the page (yet), only the source portlet is. This corresponds to the use case #3 described in the previous article. We have created a page called “Test 2″, on which we have put two portlets, namely the Journal List Portlet and the Personal Image Album Portlet, as shown in the following screenshot:
What we want to achieve here is to let Journal List Portlet interact with Journal Content Portlet through IPC. When users click on an article title in the Journal List Portlet in the left column, we want to display the article contents in the Journal Content Portlet in the right column. However, as the screenshot above shows, the right column is occupied by the Personal Image Album Portlet, and the Journal Content Portlet is not even on the current page.
During portlet communication, we want to invoke a Journal Content Portlet, put it in the location occupied by the Personal Image Album Portlet, swapping out the Personal Image Album Portlet.
Now, let’s perform the IPC configuration:
- Click on the configuration icon on the title bar of the Journal List Portlet. When the portlet configuration page shows up, click on the Communication tab to get into the communication configuration page.
- We want to re-wire the IPC flow of the Journal List Portlet on the left column, so that the contents of clicked-upon article will be displayed in a Journal Content Portlet in the right column. Click on the Add button to start configuring.
- Select the output parameters of the Journal List Portlet, just like the previous case. Click on the Next Step button to continue.
- Select the option for same page communication, then click on the Next Step button to continue.
- The following wizard page shows:

Unlike the previous case, we want to invoke a new portlet to replace the Personal Image Album Portlet currently on the page. Select the swap option, and click on the Next Step button to continue. - The following wizard page shows:

This wizard page shows all portlets on the target page, allowing us to select the portlet to be swapped out. We want to swap out the Personal Image Album Portlet, so let’s select it and click on the Next Step button to continue. - The following wizard page shows:

This wizard page allows us to select the portlet to be swapped in. The tree on the left side shows all portlets currently deployed, and activated, on the system, grouped by categories. Find the Journal Content Portlet in the CMS category, click on the Select button. The name of the selected portlet is shown on the bottom. Click on the Next Step button to continue. - The following wizard page shows:

This wizard page shows all the IPC functions defined by the portlet that we have selected in the last step, namely Journal Content Portlet. The Journal Content Portlet only defines on function, let’s select it and click on the Next Step button. - Map all output parameters to the input parameters of the destination portlet, then click on the Save button to save the configuration.Click on the arrow icon on the right side of the portlet title bar to return.
- After returning to the Communication tab, the page shows:

The IPC configuration list shows the configuration that we have just created. - Click on the arrow icon on the right side of the portlet title bar to get out of the portlet configuration page.
Now, let’s try to see what would happen when we click on the article title. When we click on the article title in the Journal List Portlet, the page shows:
The screenshot above shows that during the communication process, the Personal Image Album Portlet that was in the right column has been swapped out, replaced by a Journal Content Portlet, and it is displaying the article contents, exactly the way we want it.
Cross-Page IPC
The two cases described in the previous sections are examples of same page IPC. In this section, we will show how a portlet on a page can communicate with another portlet on a second page.
This corresponds to the use case #6 described in the previous article.
We have created a page called “Test 3″, on which we have put two portlets, namely the Personal Image Album Portlet and the Journal Content Portlet, as shown in the following screenshot:
We want to create an IPC configuration to allow the Journal List Portlet on page “Test 1″ to communicate with the Journal Content Portlet on page “Test 3″. When users click on the article title in the Journal List Portlet on page “Test1″, we want to navigate to the page “Test 3″, and have the article contents displayed in the Journal Content Portlet on page “Test 3″.
- Let’s go back to page “Test 1″. Click on the configuration icon on the title bar of the Journal List Portlet. When the portlet configuration page shows up, click on the Communication tab to get into the communication configuration page.The IPC configuration list should show one configuration, which we have created in the first case. For the purpose of this demo, we want to re-use the current portlet, so let’s delete the old configuration.
- As described in the beginning of this section, we want to re-wire the IPC flow so that the article contents is displayed in the Journal Content Portlet on page “Test 3″.Let’s create a new configuration by clicking on the Add button.
- Select the output parameters of the Journal List Portlet, just like the previous case. Click on the Next Step button to continue.
- The following wizard page shows:

Unlike the previous case, we want to perform a cross-page communication. Select the “Different page” option, then click on the Next Step button to continue. - The following wizard page shows:

This wizard page allows us to select the destination page, i.e. the page where the destination portlet is located on. Click on “Test 3″ on the left, the name of the selected page is shown on the bottom, as indicated by the red arrow.Click on the Next Step button to continue.
- The following wizard page shows:

Select the “Do not swap” option, then click on the Next Step button to continue. - The following wizard page shows:

This wizard page shows a list of all portlets on page “Test 3″ that support IPC. We want to communicate with the Journal Content Portlet, so let’s select the right portlet from the list, then click on the Next Step button to continue. - This wizard page shows all the IPC functions defined by the portlet that we have selected in the last step, namely Journal Content Portlet. The Journal Content Portlet only defines on function, let’s select it and click on the Next Step button.
- Map all output parameters to the input parameters of the destination portlet, then click on the Save button to save the configuration.Click on the arrow icon on the right side of the portlet title bar to return.
- After returning to the Communication tab, the page shows:

The IPC configuration list shows the configuration that we have just created. The information indicates that this is a cross-page IPC, and the target page is “Test 3″. - Click on the arrow icon on the right side of the portlet title bar to get out of the portlet configuration page.
Let’s go back to page “Test 1″ to try it. When we click on the article title in the Journal List Portlet, the system should jump to page “Test 3″, and display the article contents in the Journal Content Portlet, as shown in the following screenshot:
Like the same page IPC, cross-page IPC can also support one-to-many communication, the source portlet can communicate with multiple portlets on the destination page. Cross-page IPC can also swap in a new portlet on the target page.
Conclusion
Through a few use cases in this article, I have shown the IPC mechansim in action. This provides a framework of IPC that is powerful, flexible and easy to use, in which portlets can communicate with each other by API calls. System designers can create modular architecture by creating a set of cooperating portlets, each portlet is responsible for a certain set of functionalities, and provides a well-defined IPC interface to interact with other portlets. The cooperating portlets are assembled together to form larger solutions.
The assembly model advocated here provides the following advantages:
- Code re-use: Increase code re-use by modular design. As portlets can cooperate with each other through IPC, a portlet is developed once, and can be used and re-used in different applications and projects.
- Reduce development risk: Traditional web development model piles up functionalities in a huge, complex monolithic system, and the complexities increase development risk. Modular architecture helps to break down complex system into smaller, simpler components, with well-defined boundaries of interface and functionalities.
- Reduce development cost: As system complexities are reduced, and each component has a well-defined interface, it is much easier to manage the development project, and easier to locate the problem should any problem arise. This helps to reduce the development cycle, and hence, reduce the development cost.
- Simplify system administration: Modular systems are easier to maintain, and as business needs are bound to change, changes in business requirements can be quickly satisfied by re-assembling page flow, or by adding new components to create new functionalities.
- Reduce total cost of ownership: Development cost is a one-time cost in a project, and might not be a large proportion of the total cost of ownership. Maintenance cost is an on-going cost that could drain your budget indefinitely, and should be considered carefully. Therefore, reducing the post-development maintenance cost helps to reduce the total cost of ownership, which this framework should excel at.
Although this article describes only a few basic use cases, this IPC framework can support other basic use cases as well. By combining or by chaining together the basic use cases, it is very easy to create more complex cases to meet complex requirements. Other use cases are left as an exercise to the readers.
In a future post, I will describe how portlet IPC affects web system development model.






This is very interesting indeed. Using your terminology, the way developers can re-wire portlets to form larger solutions is really cool. And the web UI with a very nice wizard is also really cool.
Thanks for sharing. Really excellent.
Andy
This seems very nice. I like the way you can really reconfigure portlet IPC on the fly, and rearrange the page flow.
Excellent post!
N.