renzhi

Introduction

Developing web applications on portal platform has been made easier than the traditional method of web development, especially with the arrival of the drag-and-drop web page layout and web page assembly model. Nevertheless, first generation portal platforms have not really gotten out of the traditional web page development model, and as a result, the modular development of web systems that portal platforms promised have not realised. The original promise of portal platform was to simplify web applications development through modularisation of portlet components, and developers can assemble a complete web application by assembling web pages with portlets, and by creating page flow on the fly. However, due to the lack of a flexible, easy-to-use portlet communication mechanism, portlets can not interact with each other. In order to make portlets interact with each other, developers have to package different portlets together, and use ad-hoc hack to simulate very primitive communication mechanism. This results in a lot of waste of time, resources, cost, making code re-use and system maintenance very difficult.

Another even more severe consequence is that, it becomes extremely difficult to create complex page flow to satisfy application and business requirements. Due to these portal restrictions, portlets can not interact with each other, and developers can only create relatively simple, static web pages. To some developers, not only has portal not solved any of the traditional web development model, it has made the tasks on hand even more difficult to achieve, and developers would rather stick to the traditional, well-known path. However, the high cost, high risk and long development cycle of the traditional web development model, which more or less hard-code page flow in the source, have been a headache for project managers.

The problem lies in the JSR-168 specification, and its follow-up, JSR-286 specification, which defined the functionalities of portlet and portlet container. The first version of the specification didn’t even define a communication mechanism. The second version made a half-hearted attempt, but didn’t take the real use cases into consideration. This second version defined shared session, shared render parameters, or portlet events as portlet coordination mechanism. This line of reasoning assumed that all portlets in a system are designed and developed by the same group of developers, and they can easily share their source code. That goes against the original goal of making the system more modular, and having portlets developed by different groups. The second problem is that, except for the shared render parameters, this is a coordination mechanism, not really a communication mechanism, and there are differences between the two. The third problem is that it is not really declarative, and would make web application assembly quite hard to achieve.

Overall, JSR-286 attempted to fill in the missing functionalities in JSR-168, but didn’t go far enough. The solution could solve some the problems for some cases, but not as elegant as it could have been, and there are cases where you really feel your hands being tied up.

In order to solve the problems described above and complement what is defined in JSR-286, I’d like to propose a new model of portlet communication mechanism that is flexible, easy to use, easy to assemble, and easy to manage. Combined with the drag-and-drop page assembly model, it could make developer’s life much easier.

Concept of IPC

IPC (Inter-Portlet Communication) is the communication mechanism between portlets. Portlets can communicate with one or more portlets through the IPC system provided by portal platform, and a portlet can communicate with another portlet on the same page, or a portlet on another page. Another nice feature of the IPC framework is that a portlet can also communicate with another portlet which is not currently on any page.

It is not necessary that a portlet supports IPC. However, IPC provides the much needed flexibility for creating sophisticated web applications, and plays a critical role in the web software assembly model. The IPC framework should work like normal API calls. A portlet that supports IPC defines its communication functions and parameters in the portlet configuration file, just like normal software components define their API functions through libraries or web service definition language files. When an IPC-supporting portlet is deployed onto a portlet container, the system would know whether the portlet supports communication, which functions it is providing, with what parameters, etc.

Portlet communication is a mechanism of mapping output parameters to input parameters. When a portlet makes call to another portlet, it is sending its output parameters to a specific function of the target portlet, with the corresponding input parameters. The following diagram shows the concept:

As shown on the digram, Portlet 2 on Page 1 is trying to communicate with Portlet 6 and Portlet 7 on Page 2. Portlet 2 is sending its output parameters, which are mapped to the corresponding parameters of the specific function defined by Portlet 6 and Portlet 7. Parameters are mapped through the Parameter Mapping Rules Engine of the IPC framework. A portlet can define one or more input function, each function can have one or more parameters. A portlet can also define one or more output parameters.

The output parameters define what will be sent out to other portlets when users perform certain action on the originating portlet, e.g. clicking on a button. The input function and its corresponding input parameters define how a destination portlet will behave when the function is invoked.

Does that sound familiar? That’s right, this is exactly what every software developer does on a daily basis: making function call.

Portlet developer can define a default function call for the portlet’s output parameter. For example, the developer can define that when users click on a specific button in the portlet window, the portlet will send a parameter to a specific function of a second portlet. This is the default function call. However, the function call can be “re-wired” during web system assembly, by “re-wiring” the call to a third portlet. And you can even re-wire the call to more than one portlet, making the originating portlet communicate with more than one portlet at the same time.

When you define the default function call of a portlet, do you have to know where the target portlet is located, do you have to know on which page the target portlet is? If you have to, wouldn’t that be really inflexible? If you can reason along that line of thought, you are on the right track. I think that it would a nasty thing if you have to know where the target portlet is located. If that was the case, developers would be better off hard-coding everything. That’s why we want portlet communication to be totally transparent.

When a portlet defines its input functions and output parameters, it does not need to know where the output parameters will be sent to, and it does not need to know which portlet, on which page, is invoking its input function. The function calls can be wired, and re-wired, during web system assembly.

Let’s take a few minutes to think about how a computer is assembled. A computer is made up of many components, including a case, mother board, CPU, memory, graphic card, network card, CD-ROM or DVD-ROM drive, mouse, keyboard, etc. When a hardware designer designed these components, he/she does not need to care how the end product, the computer, really looks like, except the designer of the computer case, or maybe the designer of the mouse and keyboard too. The designers of the internal components don’t need to care which brand of mother boards the components will be plugged into, and don’t need to care in which brand of case the mother board will be installed in. For example, the designer of the network card just needs to know how to interface with PCI and the ethernet. The input and output of the network card are the PCI and ethernet interfaces. The network card just needs to know how to transfer packets between these two interfaces, but does not need to know which mother board it will be plugged into, which case it will be located in. Other components do the same. It’s up to the final assembly work to put everything together and make them work as a whole.

IPC should be designed with the same assembly model in mind. Portlet developers develop their portlets, with a specific set of features and functionalities in mind, and define input and output interfaces for portlet interactions. Questions such as on which page the portlet will be located, with which other portlets it will interact, etc, are not important. It’s up to the page assembly and system assembly work at the end to make everything work as a whole. Portlets are components, just like hardware components in a computer. A portlet provides a specific set of functionalities, performs specific task, and interacts with other portlets to form a larger solution.

As to how the output parameters of a portlet are sent to the target portlet, that is the portlet container’s responsibility. Regardless whether the target portlet is on the same page as the originating portlet, or on another page, the system will make sure to send the parameters to the right destination. With this flexible IPC mechanism, it is easy to create pages of portlets, then wire them quickly, and dynamically together to form complex page flow for any kind of business requirements, as the follow diagram shows:

Depending on the business requirements, page flow, hence business workflow, can be quickly created by wiring together the web pages. As requirements change as a result of business environment change, business workflow can quickly adapt to the changes by re-wiring the page flow.

That is a new generation of low cost, low risk web system assembly model.

As I have described above, portlet developers can define the portlet’s default function calls. But during the system assembly phase, the function calls may be re-wired to serve different purposes. This is called manual settings. Function calls created by manual re-wiring during the assembly phase will take precedence over the default function calls in runtime.

Use Case for IPC

In this section, I will describe the base use cases of IPC. More complex use cases can be easily created by combining the base use cases. After you fully understand these base use cases, you can create an unlimited number of complex use cases to satisfy any business requirements.

1. Case 1: Communicate with portlet on the same page

In this case, all the involving portlets are on the same web page. A portlet is communicating with one or more portlets on the same page, as shown in the following diagram:

Page 1 has three portlets, and Portlet 1 is communicating with other portlets on the same page. Portlet 1 can communicate with one or more portlets on the same page. The diagram above shows that Portlet 1 is communicating with two other portlets on the same page, namely, Portlet 2 and Portlet 3. The communication process happens in the same web page.

2. Case 2: Invoke another portlet and replace self

In this case, all involving portlets are on the same web page. A portlet is communicating with a target portlet, but the target portlet is currently not on the web page, as shown in the following diagram:

Page 1 has three portlets, Portlet 1 is trying to invoke Portlet 4, which is currently not on the web page yet. When communication process is performed and Portlet 4 is invoked, the window of Portlet 4 will show up on the same location where the window of Portlet 1 was located, replacing the Portlet 1 window. The communication process happens in the same web page, and as a result of that, the web page will have Portlet 4, Portlet 2 and Portlet 3 at the end.

Note that in this case, Portlet 4 was not activated yet before the IPC call. It is activated on the fly, and an IPC function call is invoked, and the portlet window is rendered in the location where Portlet 1 once was. Some people might consider this to be a second page already. But for us, this is still the same page. Rendering of the resulting page can be done via traditional page loading, or via AJAX, which simply swaps out Portlet 1 and replace it with Portlet 4.

3. Case 3: Invoke a portlet to replace another portlet on the same page

In this case, all involving portlets are on the same web page. A portlet is communicating with a target portlet, but the target portlet is currently not on the web page, as shown in the following diagram:

Page 1 has three portlets, Portlet 1 is trying to invoke Portlet 4, which is currently not on the web page yet. When communication process is performed and Portlet 4 is invoked, the window of Portlet 4 will show up on the same location where the window of Portlet 2 was located, replacing the Portlet 2 window. The communication process happens in the same web page, and as a result of that, the web page will have Portlet 1, Portlet 4 and Portlet 3 at the end.

Case 3 is a variant of case 2.

4. Case 4: Invoke another portlet, replace self and maximise the target portlet window

In this case, all involving portlets are on the same web page. A portlet is communicating with a target portlet, but the target portlet is currently not on the web page, as shown in the following diagram:

Page 1 has three portlets, Portlet 1 is trying to invoke Portlet 4, which is currently not on the web page yet. When communication process is performed and Portlet 4 is invoked, the window of Portlet 4 will show up on the web page, replacing Portlet 1, but is shown in a maximized mode. The communication process happens in the same web page, and as a result of that, the web page will have only Portlet 4 at the end, but in maximized mode.

Case 4 is a variant of case 2, except that the target portlet has its window maximised, therefore, all other portlets on the same are hidden.

5. Case 5: Invoke a portlet to replace another portlet on the same page, and maximise the target portlet window

This case is a variation of Case 4, as shown in the following diagram:

Page 1 has three portlets, Portlet 1 is trying to invoke Portlet 4, which is currently not on the web page yet. When communication process is performed and Portlet 4 is invoked, the window of Portlet 4 will show up on the web page, replacing Portlet 2, but is shown in a maximised mode. The communication process happens in the same web page, and as a result of that, the web page will have only Portlet 4 at the end, but in maximised mode.

6. Case 6: Communicate with a portlet on a different page

This is a very interesting case, showing the flexibility and power of the IPC framework. This case demonstrate the communication between portlets on different web pages, as shown in the following diagram:

Page 1 has three portlets, and Portlet 2 on Page 1 is communicating with Portlet 6 and Portlet 7 on Page 2. Portlets on Page 1 can communicate with one or more portlets on Page 2, the diagram above shows the communication with two portlets on Page 2. The communication process happens across web pages, and as a result of that, Page 2 will be shown.

7. Case 7: Invoke a portlet to replace another portlet on another page

This case demonstrates the communication across web pages, it also invokes a target portlet to replace another portlet on the destination page, as shown in the following diagram:

Page 1 has three portlets, and Portlet 2 on Page 1 is trying to invoke Portlet 8, which is currently not on the destination web page yet. When communication process is performed and Portlet 8 is invoked, the window of Portlet 8 will show up on Page 2, replacing Portlet 6. The communication process happens across web pages, and as a result of that, Page 2 will be shown with Portlet 5, Portlet 8, and Portlet 7.

8. Case 8: Invoke a portlet to replace another portlet on another page, and maximise the target portlet window

This case demonstrates the communication across web pages, it also invokes a target portlet to replace another portlet on the destination page, with the target portlet window shown in maximised mode, as shown in the following diagram:

Page 1 has three portlets, and Portlet 2 on Page 1 is trying to invoke Portlet 8, which is currently not on the destination web page yet. When communication process is performed and Portlet 8 is invoked, the window of Portlet 8 will show up on Page 2 in maximised mode, replacing Portlet 6. The communication process happens across web pages, and as a result of that, Page 2 will be shown with Portlet 8 in maximised mode.

In fact, in this case, Portlet 8 can replace any portlet on Page 2, and we still end up with the same final result.

Conclusion

Although developing web systems and web applications have been somewhat simplified by the portlet-based web framework, but the limitation of the JSR-168 specifications has made portlet development difficult, and portlet-based applications complicated. The question of IPC has not received its due attention, and as a result, developers have created only simplistic portlet-based applications with more or less static pages. This situation has resulted in a misconception among customers, mistakenly believing that portals are used mainly for displaying simple information. Customers have not realised that portals are in fact one of the most flexible web development platform, which can greatly help to shorten development cycle, reduce costs and risks in web projects.

JSR-268 made an attempt to remedy the issues, but didn’t fully solve the problems. As you can see, the use cases described above would be quite difficult to achieve with the portlet coordination mechanism described in JSR-286. You can achieve some of the use cases with shared render parameters, but it is not very flexible, and coordinating portlets would have to be tightly coupled.

The proposal here would provide a flexible, easy to use, and easy to manage IPC framework, making web software assembly model a workable model.

In a next post, I’ll discuss more about the technical details of the proposed IPC framework.