IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

Separation of infrastructure and application code

In the past, J2EE did not provide all the necessary components for an end-to-end application architecture, so a framework was much needed. Frameworks such as Struts, Spring or BTT had to be used to provide the extra functionality, mainly:
The present set of J2EE standards in combination with world-class WebSphere® products now provides very standard and robust implementations for each of these functionalities:

However, there is still much need for a framework: the focus of its importance is no longer in the functionality that its components provide, but in the order it brings to the complexity of J2EE. With only J2EE and standard development tools, an application developer needs to continuously make architectural decisions, because there are many ways to develop a given functionality, and many possible patterns to apply. This approach would pose a risk in the robustness and maintainability of an application. Even if all developers of a project were highly skilled J2EE architects, there should be a consensus on which patterns to apply, and these should be respected all over the application, otherwise, the application would be hard to maintain.

BTT is a framework that solves this problem by providing a well-defined architecture for an application and a set of patterns that can be applied in a repeatable way. However, BTT still needs to be adapted and extended to fit the target environment. The run-time and development architecture, BTT extensions, customized tools, and development patterns need to be carefully designed and implemented by skilled developers, as it will be the infrastructure used in the rest of the project. This infrastructure can then be reused in other projects and gradually improved according to changing demands.

This infrastructure is developed in two phases:
This approach divides the project team in two groups:
  1. Standard developers, who make use of the infrastructure "as-is", or make simple extensions to it if required. Most of the developers in a project fall into this group.
  2. A reduced group of architect-developers, who are continuously in contact with the standard developers, and expand the infrastructure driven by the project demands. The expansion points are decided under the criteria of productivity and robustness improvements.

When a standard developer needs a feature not yet available in the infrastructure, he or she should request it from the architect developers. If for any reason, he or she develops the extension himself or herself, he or she should submit the code to the architect developers for review and proper incorporation into the infrastructure codebase.

The best way to enforce this practice is by clearly defining a narrow set of code artefacts that the standard developers are allowed to create. Examples of such artefacts are BTT XML files, JSP files, and maybe a small set of Java classes extending from well-defined superclasses and with a strict code size limit. Declarative code such as XML is easy to constrain, which ensures that the developer is following a given set of rules. On the other hand, imperative code such as Java is dangerously versatile. Therefore, the advantages of declarative constrained code are the following:

This is the model followed by many banks using BTT, which has been extended to match the customer's particular requirements. Typical developer group sizes are 20 to 50 standard developers against 3 to 8 architect developers. The number of people in the latter group usually diminishes as the project matures.



Feedback