Rapid Portlet Development with WebSphere Portlet Factory: Communicating Between Portlets
- The Benefits of Inter-Portlet Communication
- The WebSphere Property Broker
- Creating a Service Provider
- Testing the Service Provider
- Creating a List Portlet
- Creating a Detail Portlet
- Configuring the WebSphere Property Broker
- Alternative Communication Methods
- When to Use Inter-Portlet Communication
- Summary
- Important Points
The ability to send information from one portlet to another adds considerable flexibility to your portlet applications, in both the way they are designed and in the way they are used. This chapter outlines the numerous ways that you can implement inter-portlet communication using WebSphere Portlet Factory (WPF). By the end of this chapter, you will understand the strengths and weaknesses of each approach and will have built a library loans portlet application to demonstrate them.
Each of the models in this chapter is available for download from ibmpressbooks.com/title/9780137134465 under the Chapter 7 folder (instructions for copying these files into your project are included in a readme.txt file in the same folder); however, to increase your understanding of the topics discussed, it is recommended that you create the models yourself by following through the example in this chapter.
Note that the example in this chapter does not go into detail about the service/provider consumer pattern; for more information on this pattern and on services in general, refer to Chapter 2, "Providing and Consuming Services."
The following topics are covered in this chapter:
- The benefits of inter-portlet communication
- The WebSphere Property Broker
- Creating a project
- Creating a service provider
- Creating a list portlet
- Creating a detail portlet
- Configuring the WebSphere Property Broker
- Alternative communication methods
- When to use inter-portlet communication
The Benefits of Inter-Portlet Communication
Working inter-portlet communication into your applications has several benefits from both a design perspective and a usability perspective. Some of the key benefits are listed below.
Extensibility
Inter-portlet communication makes your applications easier to extend and plug into other applications. For example, a portlet that displays a list of loans for a library database might allow users to click on a particular loan, and then send a loan ID off to other portlets to perform an appropriate action. One portlet might be used to display details for the loan, and another portlet might display a chart of overdue loans for the borrower. In this example, you could develop additional portlets that interact with either portlet, without having access to the source code for the loans portlets.
Maintainability
Inter-communicating portlets are easier to maintain because you can develop or modify a portlet without making changes to others, assuming that you do not change the nature of the content that is communicated. For example, you can change the user interface and services in the loans list portlet without worrying about affecting the loan detail portlet.
Usability
Because the interface for applications that use inter-portlet communication can be spread across several portlets, inter-portlet communication can be beneficial for users. Depending on their access rights, users can drag and drop these portlets around the portal page to suit their personal preferences, and they can add and remove portlets to further customize the interface to their application.
The example application discussed in this chapter demonstrates inter-portlet communication for a simple library system between a portlet listing library loans, and another portlet displaying details on an item in the list. The application utilizes three models: a list model, a detail model, and a service provider model. The list model is surfaced to a portal server as a portlet and displays the list of loans. The detail model is also surfaced as a portlet and displays details for a loan selected in the list model. Finally, the service provider provides the list and detail data for the list and detail models, which is stored in an XML document.