renzhi

In previous articles, I have described the concept of an Inter-Portlet Communication (IPC) framework, its technical details in portlet configuration, and the IPC framework in live action. In this article, I will try to describe how a good IPC framework can affect design and development model.

Inter-portlet communication framework is a messaging middleware for portlets. Like the effect that other messaging middleware has on distributed systems, it has very subtle, yet very measurable, impact on the design, overall system architecture, and development model, and release cycle.

I would not go as far to say that this is paradigm shifting, but after a good IPC framework is available, it changed the way we designed and developed our portlet-based web applications. If we are looking at the traditional waterfall model, then after the IPC framework, we actually had added another step to the process:

A new step called Assembly is added, just before system deployment. Other steps in the model have been greatly affected as well.

Impact on Design

The impact on the requirements and analysis is negligible, there two steps are basically the same regardless of your development model. But the impact on the design phase is probably the greatest.

As IPC has the effect of making a portlet-based web application more modular, it changes the way we design the application architecture. Although it is still a three-tier web application, but we certainly spend more times on defining the boundary, responsibility and communication interface of each portlet, and we do spend more time designing portlet interaction.

While web applications, including portlet-based applications, used to be quite monolithic, they are now more modular. Now that we don’t need to make portlets interact through shared states and shared parameters, it is much easier to separate them into smaller, more or less independent components. Web applications become a series of components, assembled according to the requirements of the customer.

Designers who were used to the “traditional” way of web development need a little adjustment, but become very productive once the thinking process is shifted over.

Impact on Development

While the impact on design is qualitative, the impact on development is quantitative.

As web applications were monolithic, it was more difficult to distribute the workload among developers. Groups of developers were tightly coupled, collaboration and coordination were more intensive. Altough it is not necessarily a bad thing to have tightly coupled interaction, it is more difficult to parallelize the workload.

Requirements on developers were much higher too. Anyone who is familiar with extreme programming knows that in order to reap the benefits of extreme programming, developer skill level should be on par with each other. Uneven skill levels would not help in this case, but would rather hinder the development process. In a large and complex project, it would be an impossible feat to assemble a large group of equally talented developers under one roof.

Once the system architecture becomes modular, and components well defined, it becomes easy to offload development work among developers. Even junior developers, and developers who are not so talented, can fully participate in the development process. That means, it is asier to have a group of the pejoratively called code monkeys crank out codes, as long as they can follow design specifications.

In large and complex projects, it is bound to have a lot of peripheral works which, although requiring many many man hours, are not core system components, and do not necessarily require the work of a highly competent developer. And in any large group of developers, it is bound to have uneven level of skills. The question is, how would you maximize your group’s productivity and shorten the development cycle?

It is true that if a hen needs 30 days to hatch the eggs, it would be impossible to require ten hens to hatch the same eggs in three days. Some physical laws simply can’t be broken, not at the current technological advancement level anyways. But as your workforce can be put to better use as a result of a modular architecture and a better division of work, the development process becomes more productive, and faster. We had seen positively quantifiable results in many projects.

Impact on Testing

The impact on the testing phase is quite similar to those in the development phase. It is much easier to test smaller portlet components. And as the functionalities and boundaries of portlets are better defined, it is also easier to locate problems, should any problem arises.

Like the development work, testing work can be distributed to more testers. As a result, we also saw shorter test cycles.

The interesting part is the iteration between development and testing. As porltets are smaller and more specialized now, testing can start ealier, and feedback from testers are returned more quickly to developers.

Impact on Assembly

Regardless of whether the web application is IPC-based or not, application assembly is a required step. The only difference is the amount of works needed, and where the work is performed.

In web application where portlets need to share states and parameters to coordinate, a lot of assembly works are performed by developers during the development cycle. All the portlets must be coded and get ready at the same time to perform integrated testing. By the time portlets are ready for assembly, all the communications are already coded into the systems and hopefully should work as designed.

In IPC-based application, developers do not have to worry about portlet communication, as long as he/she can follow the design specification. There is a group of people, usually formed by designers, developers, testers, and project managers, who would participate in the system assembly work. The assembly phase would assemble all the components together, according to the design and functional specifications, into a holistic application.

The assembly phase consists of page creation, portlets layout, portlet re-wiring for communication, and final integrated testing.

When changes are required in this phase, it is much easier and faster to go into the iteration loop of design, code, test, and assemble.

Impact on Deployment

When portlets need to coordinate through shared states and shared parameters, they have to be packaged in a gigantic war package. And when you have many groups of developers working on the same complex application, and especially with virtual teams, it becomes messy very quickly. And it is not uncommon to see the war package grow to several hundred megabytes.

When you deploy and undeploy a huge war package, all the portlets must be deployed and undeployed at the same time. This adds unnecessary risk and overhead to the process.

With IPC-based application, the application consists of modular portlet components. As portlets do not have to share states and parameters to communicate, they can be packaged and deployed in independent war package. Once a portlet is stable and deployed, changes to other portlets would not affect it. And it is much faster to deploy and undeploy a single portlet, in a small war package.

Portlet upgrade is easier to manage too. Just throw the portlet war package into the deployment directory, and the older version is undeployed and the new version deployed in seconds, without affecting others.

Not only does this save time to developers during the development cycle, it makes maintenance, changes, and upgrade manageable and less risky.

Impact on Changes

Requirement changes. That’s a matter of life, and that is especially true for software developers. We just to learn to deal with it, and we valiantly invent methodology that can handle changes in a more controllable manner, as previously unknown requirements and changes come a long the way. Hence the Scrum approach, and the agile development model.

For small changes that require only changes to page layout, page flow, and minor workflow, it is often possible to re-arrange the portlets and re-wire portlet communication, or re-arrange page flow to fulfill the requirements. This can be achieved without changing a line of code.

Other requirements may need code changes. But it is often possible to perform local changes to portlets, or add new portlets, and re-wire portlet communication for some page flow or workflow changes, and that would be it.

Even big changes are easier to handle when the architecture is IPC-based. As changes happen locally to small components, risk is reduced, time and overhead are more manageable.

Conclusion

We know that until software is tested, integrated, and released to production, we can’t really be sure that it will deliver its intended business value. Regardless of which project management model we relie upon, the traditional waterfall or Scrum model, iteration of different phases in the development cycle is bound to happens. And it must happen, or your project will derail. A good IPC framework can adapt to changes in a more controllable manner, and it should fit nicely in the toolbox of all designers and developers.