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:
- Rich web component-based rendering
- View componentization and reuse
- Presentation flow management
- Data definition, validation, conversion, and mapping
- Business flows / Integration flows
- Back-end connectors
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:
- Rich web component-based rendering: JSF
- View componentization and reuse: JSR 168 Portlets / IBM® Portal
- Presentation flow management: JSF
- Data definition, validation, conversion, and mapping: JSF
- Business flows / integration flows: BPEL / IBM WebSphere Process Server
- Back-end connectors: JCA
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:
- An initial phase where the basic patterns are laid out according to the
architecture phase, providing the necessary code and tool extensions for it.
The functionality provided should enable the development of a relatively simple
but real part of an application, which can be developed alongside the infrastructure
extensions; both infrastructure and sub-applications are used to test each
other. At the end of this phase, normal application development can begin.
- During the rest of the project, the infrastructure is enriched, driven
by the demand of developer. The infrastructure grows in parallel with the
rest of the application.
This approach divides the project team in two groups:
- 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.
- 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:
- Ensure that the developer is following the rules set by the architecture
team, since each declaration must comply with a set of constraints.
- It is easier to maintain, as all its artefacts fit into a given predefined
pattern. BTT has many examples of this: Formats, Operations, Contexts, and
so on.
- It is easier to manipulate through tooling, as parsing and representing
its structure in memory is easier than doing the same task with a full-fledged
imperative programming language.
- Migration is simpler, since parsing and transforming the application code
is easier as compared with an imperative programming language.
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.