A Strategy for Assembling Enterprise Web Applications

I have been rethinking web development.

Most web development is focused on building and maintaining the 'site'.  These 'sites' are massive, it's no wonder things go wrong.  Architecturally, SOA didn't change a lot in terms of site scale and complexity, offering some value while becoming another man in the middle.  But still the 'site' must do all business processes that the consumer interacts with.

For each business process on each site there is a corresponding implementation, and each of those implementations are different,  Additionally every one of these implementations requires its own separate development and maintenance track.  Getting enterprise wide changes replicated across the brands web presence is a slow process.  Building web sites this way results in an incredible amount of duplicated effort and waste.

My solution strategy presented here takes a different approach.

Instead my strategy is to build smaller components each representing a business process.  Where a component would offer a silo of functionality including web resources for containing applications. Components can offer forms and widgets for inclusion by the containing application. These components then could be used across brands in addition to multiple sites within a brand.  For example within a booking component we might find widgets for making payments, creating and modifying bookings.

We must recognize that there won't be a 'site' but rather an ecosystem of sites, most undoubtedly deployed on a cloud infrastructure.  A brand digital presence is represented by the collection of web applications the consumer interacts with.  And as with anything consumer facing those applications should be able to react quickly to changes in the customers behavior.  In this type of environment agility determines how quickly a organization can react to changes in its environment.

Application Assembly

With components organized along business lines assembly of web applications can be rapid.  Where assembling of a web applications consists of defining the container, and adding the components needed.  From there the remaining task is to define the page layouts.

Providing an implementation that allows modular construction of web applications like this is remarkably easy.  Conversion into a modular web component consists of moving the view definitions into the /META-INF folder.

With this strategy then the minimal structure of a web application would be;

• A business process component -- this component would provide tiles definitions, controllers, and tags to enable a business process.  
• A brand component, this component would provide cross brand layout and style design elements associated to a brand.
• Site specific component, this component provides the application container and is responsible for application launch.  

An actual production deployment application would require multiple business process and infrastructure components (security, content) to be complete.

Component Structure

To tie these components together to provide a coherent site we need to follow an extensible structure.

 Rather then reinvent we can use applications generated by Spring Roo.  This is an excellent scaffold to structure our applications on.  First the application is an modular framework, adding and removing models is built into the scaffold.  Additionally a huge advantage is Roo's code development assistance, allowing the agile development of business functionality.  Repetitive cross enterprise development operations could also be automated using Roo's add on capability.

This scaffolding along with the SpringMVC infrastructure provides the usual Spring IOC infrastructure, along with component scanning for controllers and tiles view definitions.  The result is a component that can offer;

• Tiles definitions - During startup the Spring WebMVC does a web resource path scan looking for tiles definition files.  These definition files allow for registering of views offered by the module.
• Tags - Custom tags expressed in JSP can now be exposed for consumption by the containing application.  For example a check in status widget could be placed on a page using a tag.
• Controllers - during component scan controllers will be registered with Spring WebMVC.  Components can offer services associated with a request.
• Aspects - scaffolding structure makes injecting functionality via aspects easier and more structured.  

Using Spring Roo as the scaffolding provider we can sketch out applications quickly.  Take for example the PetClinic application, this application can be up and running within a half hour and that is with rudimentary security.

I will explore building modular web components in more detail in future posts.  An important part of this strategy is re-skinning the applications constructed by Roo to provide responsive design.  This work is part of another track Porting Roo Web MVC ApplicationsTo Foundation.

Regards