- Object-Oriented Technology
- Component-Oriented Technology
- Technology Ownership
- Client-Server Technology
- Internet Technology
- Architectural Layers and When to Use Them
- Software Application Experience
- Technology and Application Architecture
- Applying Standards to Application Systems
- Distributed Infrastructures
- Conclusions
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 Architectural Layers and When to Use Them
A two-tier system (Figure 3.12) is one where user interface and application code is allowed to access the APIs directly for database and network access. The application uses the data model stored in the database but does not create a logical model on top of it. A two-tier application is ideal where the system under development is a prototype or is known to have a short system life cycle where APIs will not change. Typically, this approach is used for small applications where development cost and time are both small.
)
Figure 3.12. Two-Tier Layered Architecture
In addition, a two-tier system makes sense in a component-oriented development environment where this approach is used in the implementation of a particular component. The component interface provides a layer of insulation against many of the negative consequences of this approach. Many applications that are created using scripting languages fall in this category as the development of multiple architectural layers could be cumbersome to the point of being impractical.
Finally, a two-tier approach will provide better performance and less need to add mechanisms that control resource locking. While it will have less of an upside in its ability to scale to many concurrent users for limited use applications, the simplicity of a two-tier model may far outweigh the benefits of the other alternatives. In addition, frequently database-stored procedures may be used to eliminate some of the simpler shared data issues by adding common data processing routines into the database application.
Three-tier applications have been common since the growth of the database. A three-tier system (Figure 3.13) satisfies the need for implementation isolation. Most frequently, this is desirable in any system where the storage/database layer of an application may need to be changed. However, this technological isolation is not restricted to just databases. It can, and should, be used whenever it is valuable to share code without requiring the application developer, or more importantly, the application maintainer, to have a detailed understanding of the implementation details of the lowest layer.
)
Figure 3.13. Three-Tier Layered Architecture
Quite frequently reuse is a major design consideration where the application model is created to allow part of it to be reused by multiple user interface view components. As a guideline, whenever an application needs multiple views of the same data, a developer should consider utilizing a three-tier approach instead of a two-tier approach.
Major issues to consider in moving from a two-tier model to a three-tier model include the availability of appropriate network resources and a locking solution to manage concurrent access to data.
A more recent trend has emerged as a result of an increased emphasis on network computing, and that is the four-tier system (Figure 3.14). A four-tier system is an alternative to consider when the application layer needs to support advanced behavior. A four-tier model is like a three-tier model where the application layer is split into a presentation layer and a session a layer. The presentation layer assumes the view portion of the application model along with the application logic that is constrained to the operations of a particular view. The session layer handles resources that are shared between presentation components, including communication with the potentially distributed business object model.
)
Figure 3.14. Four-Tier Layered Architecture
A four-tier development approach is needed when there is a significant amount of coordination required between presentation components as well as a requirement that many resources be shared between them. For example, it works well when caching is required for performance reasons. A session layer allows many different presentation components to take advantage of the performance gains caching provides. Also, if a client is forced to make multiple, potentially complex distribution decisions, it makes sense to encapsulate that logic in a session layer of the application.
Factors that may indicate the need to consider a four-tier development approach are many. Obviously, any four-tier system should be large with a long expected life cycle. Reuse of existing components and subsystems is frequently a sufficient reason to incur the overhead associated with a four-tier system. Along the same lines, environments where individual components are expected to change frequently the design goal is to insulate the majority of the system from changes in component implementations. A four-tier approach provides support for incremental migration of components and subsystems across technologies, both legacy and new. Also, a four-tier system can be more scalable than a three-tier system.
Other factors to consider include systems where the reliability of components is either unknown or variable. A four-tier system can easily incorporate runtime discovery mechanisms to roll over to different component implementations in the event of intermittent component failures. Many complex systems with four or more tiers provide at least some capability to discover new capabilities (e.g., they implement a UDDI registry for advertising new Web Service implementations). If the environment utilizes multiple, potentially conflicting technologies, a four-tier system provides mechanisms to manage differences in either the session management layer or in the business domain object layer. Also, a four-tier model may be desirable if the client has several diverse application models that all need to share common data resources. Frequently, some application components will be content to allow the business domain components to handle resource management issues and can afford to wait for most resources where others may not want to block and wait for resources and have to manage client access in the session layer.
A peer-to-peer (P2P) architectural approach is ideal for systems that need to be highly scalable. Also, they are useful when distributed components need to cooperate to accomplish a task and the reliability of communications and other components are variable. It is important when developing P2P systems that the operating environment be well understood because sloppy practices could result in major disasters. Also, when utilizing P2P technologies, it is important that the interfaces be standardized and highly unlikely to change. Having to cope with multiple incompatible versions of a P2P network is a nightmare.
N-Tier and/or a combination of these approaches (Figure 3.15) should be used only for significantly complex systems made up of subsystems and components that have differing software life cycles. This is true of most large-scale heterogeneous enterprise systems where, at any given time, components are being upgraded, replaced, or added to the system. With such a system, consideration must be given to the administration of the system components.
)
Figure 3.15. Combination of N-Tier and Peer-to-Peer Architecture
What are the features that may merit the complexity of an N-Tier system? In general, it includes systems that manage a variety of data to enhance the user experience. The requirements would include Web sites and applications that remember the profile information of users, allow users to set preferences that control Web pages and applications, manage complex security requirements such as access control lists for controlling resources, and allow users to make changes that require storage management and rule execution within the back-end applications.
With an N-Tier application, the application functionality is partitioned into a number of logical layers that can be maintained and deployed separately. The functionality of each layer is less standard than that of three-tier applications, and frequently many layers can be grouped together to provide presentation, application, and/or business logic and storage management functionality. The primary benefit of supporting many layers is that it is easier to make changes in one layer without having to alter many or, preferably in most cases, any of the other layers. Additionally, the application can be scaled to handle great loads of users and/or data by altering the distribution or load management of one or more layers. Frequently, this scaling can be transparent to other layers and even automated in many cases. In fact, often multitier is assumed to mean spreading processes across various processors and machines rather than defining software boundaries within an application.