Layers and usage of software architecture training

In the above article, I introduced Internet technology, and Web Services provided us with more options at home, but what architecture is used in software design is still a headache.

Two-tier system (Figure 12) allows user interfaces and ApplicationsProgramCodeDirectly access the database and network storage APIs. The application uses the data model stored in the database, but does not need to establish a logical model on the model. When a developed system is a prototype system or has known that its lifecycle is short and the API does not change during this period, it is ideal for two-tier applications. In typical cases, this method is used for small applications with very little development cost and time.

Figure 12. two-tier architecture

In addition, the two-layer system also makes sense for the component-oriented development environment. This method is used in the implementation of specific components. The component interface provides an isolation layer, which is opposite to the consequence of this method. Most applications created using the scripting language belong to this category, because in this case, multi-architecture layer development may be very troublesome and impractical.

Finally, the two-layer approach will provide better performance and reduce the need to control the resource locking mechanism. Although the two-tier model lacks the ability to process multiple concurrent users using applications, its simplicity may be far better than other options. In addition, by adding common data processing programs to database applications, data stored procedures are often used to eliminate some simple data sharing problems.

With the development of the database, the layer-3 (three-tier) application is very common. The layer-3 system (Figure 13) meets the needs for isolation. It is basically ideal for any application system that the storage/database layer may be modified. However, the isolation of this technology is not limited to databases. It can and should be used in any environment where no application developer is required, or more important application maintenance personnel have a detailed understanding of the minimum layer to share the code.

Figure 13. Three-tier architecture

Frequent reuse is a major design consideration. In this case, you need to create an application model to allow some of it to be reused by multiple user interfaces. It has a guideline that developers should consider using three layers instead of two layers whenever an application needs multiple views with the same data.

The main considerations for migrating from a two-tier model to a three-tier model include the availability of appropriate network resources and the locking solution for managing concurrent data access.

As a result of increasing emphasis on network computing, a new trend has recently emerged, namely, four-layer systems (figure 14 ). When the application layer needs to support advanced behavior, you can consider a layer-4 system. The layer-4 model is similar to the layer-3 model, but its application layer is divided into presentation layer and conversation layer. The presentation layer presents the view part of the application model and the application logic restricted by the operations of a specific view. The dialog layer handles the issue of resource sharing between components, including communication with potential distributed business object models.

A layer-4 development method is required when a large amount of coordination is required between components and many resources need to be shared between them. For example, because of performance problems, buffering is necessary. The dialog layer allows many different presentation components to take advantage of the performance advantages provided by buffering. Similarly, if a client is forced to make multiple, potentially complex distributed conclusions, you can consider encapsulating this logic into a conversation layer of the application.

Many factors indicate that there are a large number of requirements for layer-4 development. Obviously, any layer-4 system has a long life cycle. Repeated use of existing components and subsystems is usually a sufficient reason to incur costs related to the layer-4 system. Similarly, it is expected that individual components will frequently change the environment of the design target, and the main part of the system needs to be isolated from the changes in the component implementation. The layer-4 mode provides support for the continuous transplantation of components and subsystems with the development of technology (including traditional and new technologies. In addition, the layer-4 system is easier to upgrade than the layer-3 system.

Other considerations include that the reliability of components is an unknown or variable system. In the case of intermittent component failure, the layer-4 system can easily combine the runtime discovery mechanism to switch to different component implementations. Many complex systems with four or more levels provide at least some of the capabilities of discovery (for example, when new Web Service implementations are involved, they implement UDDI records. If the environment utilizes multiple technologies that may conflict with each other, the layer-4 system provides a mechanism for managing the differences in the session management layer or the business domain object layer. Similarly, if the client has a variety of different application models that need to share common data resources, the layer-4 model may be ideal. Often, when other application components do not want to block and wait for resources, they have to manage the client access environment in the dialog layer, the application component allows the business domain component to handle resource management issues and be able to withstand waiting for most resources.

The peer-to-peer (P2P) architecture is ideal for most systems that require high upgrade. Likewise, distributed components are useful when they need to coordinate a transaction and the reliability of communications and other components may change. It is very important to easily understand the operating environment when developing a P2P system, because bad habits may lead to major disasters. Similarly, when P2P technology is used, it is important to standardize interfaces and prohibit modifications. Being forced to cope with incompatible versions of multiple P2P networks is a nightmare.

N layers and/or combinations of these methods (figure 15) should be used only for systems that are very complex and composed of subsystems and components with different software lifecycles. This is true for most large enterprise systems of different types. In this case, components are upgraded, replaced, or added at any time. For such a system, you must notify the management department of the system components.

Figure 15. Combination of layer N and peer-to-peer architecture

What features are worth using complex N-layer systems? Generally, it includes a system that manages a large amount of data used to enhance user experience. The requirements may include recording the user's summary information, allowing users to set parameters to control web pages and applications, and managing complex security requirements (such as the Resource Access Control List) allows users to require storage management and rule execution changes in backend applications and other web sites and applications.

With N-tier applications, the functions of applications are divided into a large number of logic layers, which can be maintained and configured separately. Features at each layer are less standard than those of layer-3 applications, and many layers are often combined into a group to provide performance, application, and/or business logic and storage management functions. The main advantage of supporting multiple layers is that it is easier to modify a level without changing many layers (in most cases, there is no need to change any other layers ). In addition, by changing the distribution or loading of one or more layers, the application can be expanded to process a large amount of user load and/or data. Generally, this scaling mode is transparent to other layers and is automatically used in many cases. In fact, a multi-tier architecture is conceived as distributing programs across multiple computers and processors, rather than defining software boundaries in an application.