- Relationship to the Architecture Business Cycle
- Requirements and Qualities
- Architectural Solution
- How Luther Achieved Its Quality Goals
- Summary
- For Further Reading
- Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
17.4 How Luther Achieved Its Quality Goals
All but one of Luther's quality requirements came from its customers: wireless access; flexibile user interfaces and devices; support for existing procedures, business processes, and systems; and for distributed computing. The only one that came from Inmedius was ease of building applications.
The primary decision in achieving these requirements was to use J2EE, but only in a particular fashion. The user interface was clearly and cleanly separated from the applications, standards were used whenever possible, and a re-usable library of components was to be constructed opportunistically. Table 17.1 shows the strategies and tactics used in this effort.
Table 17.1 How Strategy Achieves Goals
|
Goal |
Strategy |
Tactics |
|
Wireless Access |
Use standard wireless protocols |
Adherence to defined protocols |
|
Flexible User Interface |
Support both browser-based and custom interfaces through HTTP |
Semantic coherence; separate user interface; user model |
|
Support Multiple Devices |
Use standard protocols |
Anticipate expected changes; adherence to defined protocols |
|
Integration with Existing Business Processes |
Use J2EE as an integration mechanism |
Abstract common services; component replacement |
|
Rapid Building of Applications |
Use J2EE as a basis for Luther and construct re-usable components |
Abstract common services; generalize module (in this case, J2EE represents the generalized module) |
|
Distributed Infrastructure |
Use J2EE and standard protocols |
Generalize module; runtime registration |