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 Code .
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.
Note: For more information about available options, see Microsoft Security Developer Center.
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 code the solution, while Microsoft Visual Basic? . NET is not as vulnerable to buffer overflow 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.
Complete Design Documents
Before entering the coding part of the project directly, it is very important to take a little time to actually outline the logical components of the application. In our example solution, we need to implement three logical components of the solution: database,. NET data access component, and ASP. NET user interface. In the following sections Article . But now, we just outline the outline of each component and discuss the most important aspect in the process, that is, interaction between document components.
Database
For the dotnetkb application, we need to store the data in three tables: topic, question, and answer (SEE ).
Figure 3: topic, question, and answer table
We need to use stored procedures so that the middle layer components can also securely access data. We will discuss the database details in the next article. Here, we only pointed out that the database documents that list the table name, all column details, default indexes, and Stored Procedure lists should be included in a complete database design document. That is, the document should have the detailed information required to successfully implement the system data storage.
Note: If you pay attention, you may notice that we did not mention storing expert data in the database. To make the project more interesting (and give us a chance to use direct XML data storage), we store expert information in an XML data file.
|
