From n-tier to. NET detailed profiling principle (2)

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.