User original: From n-tier to. NET detailed analysis principle

Original

Summary: Discusses Microsoft. NET application design and required changes: Examine the architectural knowledge learned from building N-tier applications using Microsoft Windows DNA, and how to apply that knowledge to applications built using the Microsoft. NET Framework. and provides architectural advice for applications that use XML Web Services.

　　Brief introduction

Today, N-tier applications have become the standard for building enterprise software. For most people, N-tier applications are applications that are divided into separate logical parts. The most common choices are divided into three parts: presentation, business logic, and data, and of course there may be other partitioning methods. N-tier applications were originally designed to address problems associated with traditional client/server applications, but as the Web age came, the architecture began to become the mainstream of new development projects.

Microsoft Windows? DNA technology has become a very successful foundation for N-tier applications. The Microsoft. NET Framework also provides a solid platform for building N-tier applications. However. NET makes it necessary for structural designers to reconsider some of the knowledge they have learned in the field of Windows DNA about designing N-tier applications. More importantly, the basic support for XML WEB services internally placed in the. NET framework allows developers to build new applications that break through the traditional N-tier approach. To learn how to better build the architecture of. NET applications, you need to understand what has changed in this new area and how to make the most of these changes.

These issues will be discussed in this article. First, review the key architectural knowledge learned from building N-tier applications using Windows DNA. This knowledge is then applied in the same order to the application being built using the. NET framework to test them. The last section provides some suggestions for the architecture of applications that use XML WEB services.

　　Windows DNA Environment

It is very uranium to have the application feared for multiple logical portions. Dividing a large software into smaller sections can be more beneficial to the construction, reuse and modification of software, as well as to adapting to different technologies or different code business organizations. At the same time, there are some comprehensive factors to consider. While modularity and reuse are effective, they can lead to winning programs that are not as safe, manageable, and fast as other methods. This section will review some of the 牸 from using Windows DNA to 豕 mushrooms? N-tier Application universal experience in the base 1 guilt Alex to the ?

　　Writing business logic

Windows DNA applications typically use one or more of the following three implementations to implement their business logic:

ASP page

COM group, may use other services provided by COM +

Stored procedures running in the DBMS

In general, it is not a good idea to write too many business logic in an ASP page. Because you must use a simple language, such as Microsoft Visual Basic? Script (VBScript) and interprets the code every time it executes, which can have an impact on performance. And the code in the ASP page is not maintainable, mainly because the business logic is usually mixed with the presentation code that creates the user interface.

Given this situation, it is recommended that business logic be implemented as a COM object when writing middle-tier business logic. This approach is a little more complex than writing a pure ASP application, but you can use a full-featured language to generate compiled executables, so the results are much faster. Wrapping business logic in a COM object can also separate the code from the presentation code contained in the ASP page, making the application easier to maintain.

From COM to COM +, the architecture is almost the same. However, as many Windows DNA architecture designers know, you should not use the core services that COM + provides, such as transactions, Just-in-time (JIT) activation, role-based security, and thread services, unless you really need them. COM + or similar services provided using other development platforms naturally lead to slower and more complex applications. It makes sense to use COM + only in the following situations:

Need to span distributed transactions across different resource managers, such as Microsoft SQL Server? and Oracle.

Applications can effectively take advantage of role-based security.

Can you enhance Microsoft Visual Basic? 6.0 of the thread operation.

JIT activation can improve performance, which is rare in browser clients, because ASP pages are active by JIT.

COM + 's configuration benefits greatly simplifies the deployment of applications.

The third way to write business logic is to create some code that runs as a stored procedure in the Database management system (DBMS). Although the main reason for using stored procedures is to separate the details of the database schema from the business logic to simplify code management and improve security, the proximity of code to data can also help optimize performance. Applications that must be independent of the DBMS, such as an application created by an independent software vendor, typically avoid this approach because it locks the application into a particular database system. Writing and debugging stored procedures can be harder than writing and debugging COM objects, and this approach reduces the chance of reusing code because COM objects are often easier to reuse than stored procedures. But most custom applications are still connected to the DBMS that originally created them, so the performance advantage of using stored procedures is great. In this case, Windows DNA applications that have to run as well as possible often use stored procedures for some or all of the business logic.

　　Building the Client

Windows DNA supports both local Windows clients written in languages such as Visual Basic and browser clients. The limitations of the browser client are large, especially when Microsoft Internet Explorer and Netscape are browsers. As a result, applications typically have both browser clients and local Windows clients. The browser client provides a limited interface, but it makes it easy to access the Internet, and Windows clients provide a fully functional interface. Use a downloadable Microsoft ActiveX? Controls can create more complex browser interfaces, but you must make sure that the browser is Internet Explorer and that users are willing to trust the creator of the application.

　　Managing State in Browser applications

ASP applications can use several different mechanisms to maintain information between client requests on a server. However, there is a strict rule in Windows DNA that if your application balances the load between two or more machines, you will never be able to use the ASP session object to store the state of each client. ASP's session object is locked on a single machine, so it cannot be used for load-balanced applications.

There is another restriction on ASP session objects and ASP application objects. Using any of them to store an ADO recordset can greatly reduce scalability because it limits the ability of applications to develop multithreading. Therefore, it is not a good idea to store recordsets in either of these two objects.

　　Distributed communication

In Windows DNA, the way to communicate with components that run on different machines is simple: DCOM is the only option. From a purely architectural perspective, DCOM is a simple extension of COM. In practice, however, DCOM has many other implications, including:

Because it is actually its own protocol, using DCOM to communicate with a remote COM + object is straightforward.

DCOM will be a very secure protocol as long as the configuration is correct. However, it is not easy to implement this configuration, so the protocol is not easy to use. However, DCOM itself still provides good distributed authentication, data integrity, and data confidentiality, especially within Windows 2000 domains.

Because DCOM needs to open any port, it is not suitable for use with firewalls. Therefore, DCOM is generally not available for applications that must communicate over the Internet.

　　Accessing stored data

The data access architecture built using ADO can be grouped into two categories: lightweight and heavy. The lightweight ADO client keeps the database connection as briefly as possible and writes it to the database using stored procedures. Lightweight clients retrieve data using one of the following three methods:

Fills a recordset by using a read-only, forward-only cursor;

Output parameters through stored procedures;

Use data flow (in a newer version of ADO).

Heavy clients keep the database connection for a long time. Such applications rely on open connections and stateful server-side cursors allowed by those connections to:

Make the recordset direct access to changes made by other users or applications;

Enable pessimistic locking;

Minimize the amount of data replicated to the ADO client to reduce network traffic. Unlike light clients, clients that use server-side cursors can keep the query results in the database until they are actually needed. In addition, this method copies less metadata to the recordset and keeps more data in the database.

Lightweight applications are the most scalable because they use the rare resource of database connectivity most efficiently. In contrast, heavy applications must maintain a long-term valid database connection, as this is required by stateful server-side cursors. This greatly limits the scalability of the application, especially for Internet server applications. Although it may be simpler to develop heavy applications with ADO, this is often not the best choice.

ADO is also not particularly useful for processing hierarchical data such as XML documents. The functional usage of ADO to complete this work is complex and difficult to understand. Similarly, ADO provides limited support only for XML features that access SQL Server 2000, so Windows DNA applications generally avoid using ADO to process hierarchical data.

　　passing data to the client

For all N-tier applications, moving data from the middle tier effectively to the client is a key step. When using DCOM to communicate with a Windows client, the Windows DNA application can use ADO to disconnect the recordset. This option is also available for browser clients when making sure that the browser is Internet Explorer. It is more difficult to send data to any browser. One approach is to explicitly convert the data to XML and then send the data and all the necessary scripting code to the browser.

　　. NET Environment

. NET supports traditional N-tier applications, Web Services applications, and applications that combine elements of both. This section first describes how. NET affects N-tier applications, and then describes several major architectural issues during the process of building a WEB services application.

Binding N-tier applications with. NET

Some of the issues described in the previous section also apply to Windows DNA applications and applications built using the. NET framework. For example, COM + (called Enterprise Services in the. NET framework) can be used only if one or more of the conditions listed earlier are met. Similarly, building business logic into stored procedures can achieve better performance in many N-tier applications.

Meanwhile,. NET framework is littered with new versions of new technologies and existing technologies. These enhancements bring a variety of changes to the optimized architecture of N-tier applications. This section describes how the. NET Framework changes the decisions that an architecture designer makes when creating an N-tier application, as described in the previous classification.

　　Writing business logic

Unlike the three alternative methods of creating N-tier business logic in Windows DNA (ASP pages, COM components, and stored procedures). NET Framework provides only two methods: assemblies and stored procedures. For browser applications, you can use the Microsoft asp.net. aspx page to create assemblies. Unlike ASPs, it is often a good practice to write business logic entirely using asp.net in this situation.

One of the reasons is the asp.net code option. In a traditional ASP page, it is not easy to mix business code and presentation code in a maintainable way, and. aspx pages can completely separate the two codes using the embedded code. Windows DNA applications may need to use both ASP pages and COM objects to achieve maintainability, while applications built using the. NET framework use only ASP. NET. In addition,. The business logic contained in the ASPX page can be written in any. NET based language, not limited to the simple scripting language supported by traditional ASP pages. Also, ASP.net is a compile page rather than an interpretation page, so the ASP.net application can be very fast. While applications built with Windows DNA can use ASP pages and COM objects to achieve high enough performance,. NET can build applications with the same fine performance with asp.net. Finally, business logic uses the ASP.net cache to reduce access to databases that contain commonly used data, which can greatly improve performance.

However, it should be noted that for code contained in an. aspx page, reuse is more difficult than a standard assembly, even with embedded code. For example, accessing the code in an. aspx page from a Windows forms client encounters many problems.

　　Building the Client

Using the. NET framework reduces the need for Windows clients, and typically requires only one browser client. One reason is that asp.net Web controls allow you to build and/or purchase reusable browser graphical user interface (GUI) elements to make it easier to build more useful browser clients. You can also download components based on the. NET framework to an Internet Explorer client and then use partial trust to run these components (instead of using the full-trust mode required by ActiveX controls), which helps build a better user interface.

　　Managing State in Browser applications

Because the ASP session object is bound to a machine, it does not play its part, and the. NET framework avoids this limitation. Unlike ASPs, the ASP.net session object can be shared by two or more machines, so that the session object can be used to maintain state in the load-balanced Web server realm, making it more useful. Also, because the contents of the session object can be selected to be stored in the SQL Server database, this mechanism can be used in applications that have to maintain the state of each client in the case of a failure.

Another important change that affects the ASP.net application architecture is that the dataset can be stored in session and application objects without having to include threads, unlike the ASP. That is, rules that are strictly defined in Windows DNA that do not store recordsets in these objects do not apply to datasets in the. NET framework. This makes the storage of query results simpler and more natural.

　　Distributed communication

Compared to Windows DNA, the. NET Framework provides more choices for communication between distributed parts of an application, including:

. NET Remoting, providing TCP channel and HTTP channel;

asp.net supports XML Web services that can be invoked through SOAP in the. asmx page;

DCOM required to communicate with a remote COM object.

The more options, the more the choice of architecture, which means that there are more factors to consider when making a choice. Architectural issues to understand when using the. NET framework to create distributed applications include:

Communicating directly with a remote COM + object requires DCOM and cannot use. NET Remoting. Because of the complexity of the creation and use of DCOM, this communication should be avoided as much as possible. In some cases, it is necessary to handle existing COM + objects through managed code, although the COM interoperability required to do so will degrade performance.

. NET Remoting TCP Channel does not provide built-in security. Unlike DCOM, it does not provide strict authentication, data integrity, or data confidentiality services. But it's not useless, and TCP channels are easier to configure than DCOM.

DCOM does not work well with firewalls. NET Remoting HTTP channels, which are designed specifically for effective communication over the Internet. Also, because SSL can be used, this option provides a secure path to the data. In general, TCP channels are a good choice for Intranet traffic, and for Internet traffic, it is better to use HTTP channels or asp.net SOAP support.

. The NET Remoting HTTP channel and the ASP.net support for XML Web Services implement SOAP. But these two implementations are very different, each with its own specific purpose. NET Remoting focuses on maintaining the exact semantics of the common language runtime, so it is the best choice when the remote system is also running the. NET framework. ASP.net is focused on providing an absolute standard of XML WEB services, so it is the best choice when a remote system is based on a. NET platform or any other platform. And asp.net is faster than the. NET Remoting HTTP Channel. However, the HTTP channel also has the advantage of allowing arguments to be passed by reference and real asynchronous callbacks, which are not available in SOAP support in asp.net.

　　Accessing stored data

ADO can easily build heavy clients, but the client's scalability is poor, ado.net is different from ADO, it is more suitable for building lightweight clients. The Ado.net client uses a forward-only read-only cursor to read data. It does not support stateful server-side cursors, so its programming mode encourages a short time connection. Clients that read and process data directly can use the Ado.net DataReader object, which does not provide caching for the returned data. Alternatively, the data can be read into the DataSet object as a cache of data returned from SQL queries and other sources. However, unlike an ADO recordset, a dataset cannot explicitly maintain an open connection to a database.

As mentioned earlier, there are some other problems with the heavy methods generated by ADO. These problems can be resolved in Ado.net, as follows:

For ado.net clients that store data in a dataset and require access to changes made by other users or applications, you need to include explicit code to make these changes. The code typically also requires a database connection to be opened for each check that is made.

Although Ado.net does not directly support pessimistic locking, the client can still achieve the same effect by using Ado.net transactions or by implementing the required functionality in a stored procedure.

Unlike ADO, Ado.net does not allow partial query results to remain in the database (which can be accessed using server-side cursors). Although Ado.net does have less metadata than ADO retrieves, the application should still be designed to be able to pass all query results from the database to the Ado.net client.

Another change in ado.net that affects architecture selection is enhanced support for processing hierarchical data, especially XML documents. Converting a ado.net DataSet to XML is straightforward, just like XML functionality that accesses SQL Server 2000. Therefore, hierarchical data that may be forced into the relational model in Windows DNA can now be accessed in its original form.

　　Passing data to the client

Effectively passing data to the client is as important as an N-tier application built on the. NET Framework and an application built with Windows DNA. An important change is that the Ado.net dataset can be automatically serialized into XML, making the data transfer between tiers simpler. Although this approach can be used in Windows DNA,. NET makes the exchange of information through XML easier and more straightforward.

　　XML Web Services Architecture

In the process of building a distributed application, there are several ways to use the SOAP, Web Services Specification language (WSDL), and other technologies of XML WEB services. For example:

A WEB client that uses SOAP instead of just using HTTP to connect to an N-tier application. Once the connection is established, the client can be any device capable of making SOAP calls. The client can then provide more functionality to its users because it can call methods directly from the remote server.

Connect an N-tier application that might be built on a platform based on the. NET framework to another application built on another platform, such as a Java application server.

Connect two large applications, or connect an enterprise resource planning (ERP) system with another ERP system or any other application. As these examples show, XML WEB Services not only apply to N-tier applications, but they are very broad in scope.

Regardless of how it is used, XML WEB services can create many new architectural problems. Perhaps the main difference between the more traditional middleware technologies that XML Web services and N-tier applications typically use is that XML Web services provide "loose coupling." Unfortunately, the word has different meanings for different users. In this article, it refers to a communication application that has the following characteristics:

Applications are largely independent of each other, and are usually controlled by different organizations.

is not entirely reliable. There is no guarantee that each communication application will be available at all times.

Its interaction can be synchronous or asynchronous. The Web Services client may block the wait for a response to a request, or do something else after the request is made, and then check the response later.

These basic features provide a lot of architectural principles for applications that use XML WEB services. Although some issues may be resolved in future work, such as Microsoft Global XML Web Services Architecture (GXA) specifications, the current creation of a valid XML Web Servic Users of ES applications must be aware of these issues. These include:

Security can be more complex. It is important to plan for End-to-end authentication and effective authorization in advance. End-to-end data integrity and data confidentiality are also important for some applications. It may be necessary to map between different security mechanisms, but it is best to avoid this as much as possible. Interoperability can be a problem. Because the specification is still relatively immature, the SOAP implementations of different vendors do not always work well together.

Problems may occur when you modify an existing application so that you can access it through an XML Web services. When you connect a program that has never been intended to be used together, there is always a problem with speed, scalability, and security. Existing applications are typically not built as servers, so handling small requests can easily overwhelm them. Reducing the number of requests and increasing the data contained in each request may improve the performance of your application. In addition, existing applications typically do not handle unexpected workloads, such as the load that can occur when software is exposed to the Internet. If possible, it may be helpful to use some sort of queuing mechanism to store the request before the request is answered.

It is very important to adjust the fault. Especially if you need only one semantic request, you usually need to be extra careful. For example, a request may time out, triggering a retry, but the original request may have been delayed for some reason only. If there is a problem with two remote Web service execution for a single call, you must create a mechanism to resolve the problem.

It is not possible to provide end-to-end transactions that depend on distributed locking, which is persisted across organizational boundaries. Most organizations do not allow "foreign" applications to lock data, so it is not possible to implement two-phase commit-style transactions. You can only consider compensating transactions for any necessary rollback use.

Because the data that is received may span the application and organization boundaries, each end of WEB services communication may need to examine the data carefully. While the creator of an application may be very trusting of the accuracy of data generated by other parts of their own application, they cannot hold the same trust in other applications. The information received may even contain malicious code and must be examined carefully.

SOAP and the XML that it carries are very much data-defined. Passing too much data in one call can overwhelm a low-bandwidth network. Conversely, too little data is passed in one call, and the application that handles those requests is ruined. Although this is difficult, it is important to find the right balance point.

　　Summary

Architecture is the key. Choosing the right structure for applications, especially those distributed across multiple systems, is critical. If the wrong architecture is chosen, no matter how good the developer is, it is not always possible to fix it in the implementation process. Bad decisions can lead to reduced performance, reduced security, and fewer options available when an application needs to be updated.

Windows DNA provides a solid foundation for N-tier applications where Windows developers can build applications based on the knowledge they have learned from the field of DNA and apply most of them to the new. NET environment. However, understanding the changes recommended in this article will help you create faster, more secure, and more powerful applications. For N-tier applications and applications that adopt new WEB services technologies,. NET can provide a lot of functionality.