How a good Inter-Portlet Communication framework impact development model

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.

Page 2 of 3 | Previous page | Next page