How a good Inter-Portlet Communication framework impact development model
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.
Page 1 of 3 | Next page
