Logical architecture Logically, you need to plan a solution to identify the "boundary" between data storage, data access, business rules, and user interfaces ". Generally, Web developers select a two-phase model and use web forms to store all the code used to access an existing data storage system (such as Microsoft SQL Server. A more effective method is to create an intermediate layer component library between the web form user interface and the SQL server data storage system. This three-tier method (web forms, components, databases) is usually required by most applications. However, in some cases, another layer may be required to process data transmitted between servers. This transport layer can be implemented using platform-independent protocols, such as XML-SOAP. However, if you use Microsoft. NET technology from start to end, you can use the binary version of the. NET remote protocol to complete this task, and the speed is much faster than using the XML-SOAP. For our example, we will define three logical boundaries: User Interface (web form), middle layer (A. NET Component Assembly), and data layer (SQL Server database ). Figure 1 shows how to represent this content. Figure 1: Three Layers Now we have a simple logic model. How does it work? It helps us to consider the boundaries between logical groups. Each logic layer should be independent from other layers as much as possible. Ideally, the changes in the layer should have a minimal effect on the whole. For example, if you change the data storage from SQL Server to an XML data file, the only affected layer should be the intermediate layer. You do not need to consider changing the user interface. This will make you think: How to Implement the actual coding of the solution to achieve this principle. In addition, the logic layer helps us to consider security issues. The boundaries between layers have potential security vulnerabilities. In addition, each layer may have its own specific security measures (SQL Server permission,. Net runtime permission, ASP. NET security, etc ). Similarly, we will discuss this issue in detail later in this section. Physical Architecture After determining the logic layer, it is also important to consider the physical layer. For example, you can implement this application on a single real computer that has SQL Server, Internet Information Server, ASP. NET, And. net installed at the same time. This is a physical layer. But the more reliable and scalable method is to deploy web forms on clusters composed of three web servers and deploy them on two application servers.. NET Component Assembly. Deploy the database on the SQL server in two fault recovery modes. The resulting physical architecture includes seven Windows servers in three main groups: web clusters, component clusters, and database clusters. If you know that different logical components of the system can be located on different computers, you may implement different codes. For our example, we adopt an effective and powerful two-layer model: Web server hosting user interfaces and components, and database server hosting SQL server data storage. If the traffic is very large, this model allows us to flexibly add more servers to the cluster and make it concise enough for processing. The following image shows the ing between the physical architecture and the previously defined logical architecture. Figure 2: ing between physical architecture and L3 Architecture As you can see, the logical and physical architectures do not have to be the same. In the planning stage, security should also be considered. Security Planning Microsoft has a topic about security and software: "secure by design, secure by default, and secure by deployment (design security, default security, and deployment security )". That is, the system is designed to be secure by default and a solution that can be successfully deployed in the security environment is created. Security is always important. Since more and more software needs to "survive" on the public Internet, it is more important to write secure software. Fortunately, the. NET runtime and Windows operating systems provide a wide range of security options and features that we can easily include in our applications. You do not need to focus too much on identifying and eliminating security vulnerabilities in online solutions. We can point out some of the most common vulnerabilities and how our application plans to handle them. Buffer Overflow This may be the most common security vulnerability in compiled applications. Because we will use. Net runtime, which is designed to run securely in the memory, it is unlikely that a buffer overflow will occur. In addition, we use Microsoft Visual Basic. Net to encode the solution, while Microsoft Visual Basic. NET is not as vulnerable to the buffer overflow issue as C or C ++. However, even if we plan to use C ++ to create components, we can also use the special features of the Compilation Program, GS conversion, to protect us from most buffer overflow attacks. Database attacks Another common security vulnerability may allow malicious users to access the raw data stored in the database. To prevent hackers from gaining control of data, we only use SQL Server Stored Procedures, rather than "inline query ". This greatly reduces the number of attacks that try to insert other SQL commands into the input stream. We also use input verification at multiple locations in the program to ensure that all input only contains valid characters. Cross-Site Scripting There is also a common attack on Web applications, which involves adding client scripts to the input stream, these attacks will execute additional conversations and trick users into sending personal data to the hacker's own web site. To solve this problem, we use a new feature of ASP. NET 1.1 to filter out all input of this malicious code and prevent it from being placed into the system. The display screen also contains additional code that will automatically disable any script or display tags that may be inserted into the data storage. So far, we have obtained the logic model and physical model of the application, as well as a list of security functions included in the implementation solution. With these and target declarations and user solutions, we can start the last part of the "Before encoding" adventure.
|
