N-tier distributed application development based on the. Net Framework

Distributed topics: Building maintainable, scalable sites, developing efficient, highly scalable applications, creating n-tier distributed applications, Cross-platform, and cross-Internet application integration is a task for countless developers. Traditional development methods and technologies are facing difficulties.

Many of the new technologies introduced by the. Net framework provide a relatively simple solution to the implementation of these tasks. Among them, SOAP based Web service has the obvious advantages over traditional dcom/corba in processing distributed applications, combining web-based asp.net page development technology and SQL Server data storage technology (or XML document) in. NET, it is no longer difficult to develop n-tier applications.

I. Overview of distributed processing

Distributed processing is the distribution of the application logic to 2 or more computers, in a physically or logically detached unit. This concept is not new and has been widely used in large scale projects. Just as the advent of the Internet has given new features to distributed processing, the characteristics of the Internet's internal connectivity can make hundreds of computers work for one task, making it possible to implement distributed processing on a larger scale, and spanning traditional B/s (client/server) models.

Distributed processing thought has undergone a long process, different it times of developers, vendors at all levels to do a lot of work, so that support distributed processing protocol is extremely rich.

1, Dcom/corba

Prior to the. Net Framework, the main protocol for Component-based distributed computing was CORBA (Common object Request Broker architecture, common Objects Solicitation Agent architecture), which came from Object Management Group (object Management Group), as well as Microsoft's DCOM (distributed Component object model, distributed component objects models).

DCOM is connection-oriented. The DCOM client holds a connection to the DCOM server. This connection method has led to technical problems. For example, a client might hold reference information and generate a call only when the user clicks a button. For a long time, the server will be idle waiting for a request from the client. When a client crashes and cannot request a server, it can have serious consequences. In addition, on the Internet, DCOM or CORBA servers are used by thousands of clients, and because each client has a connection to the server, valuable server resources should be protected for clients that rarely use the server or are no longer using the server at all.

Although DCOM has the means to handle these problems, it adds a lot of complexity, which is one of the problems that Web services are trying to solve.

2, Web Services

With the introduction of Microsoft. Net Framewwork, there is a new technology for implementing distributed processing, namely Web service (Web services). Web services are able to provide data for another application, not just for browsers, and to perform operations through external data to allow other clients to use standard protocols such as HTTP that function at the same port and transport layer.

Second, the Web service-.net framework of distributed processing technology

In the. Net framework, a Web service is an application logical unit that can be accessed by a program in a platform-independent manner through a standard web protocol.

Developers of the. Net Framework set Web services to be based on open standards that can be used on any platform. It has the potential to be an integrated technology across platforms and across vendors. Once a Web service and Web service architecture is implemented, users can take advantage of many of the existing technologies on the Internet. The key to the success of Web services is that it is based on open standards, which are supported by major vendors such as Microsoft, IBM, and Sun.

1, Dcom/corba facing the difficult solution--web Service

DCOM and CORBA are excellent at creating enterprise applications using software that runs on the same platform and tightly managed LANs. However, they are powerless to create cross-platform, Internet-resilient applications that adapt to the Internet. They are not designed to accomplish these goals.

Most companies face the reality that they have multiple platforms from multiple vendors. Communication between application systems running on different platforms is difficult. When working with business partners, it is difficult to collaborate on a traditional, distributed architecture.

The problem with DCOM and CORBA is that the user basically relies on a vendor. If you want to use DCOM, you must use Microsoft Windows to run the server and the client. Although there are implementations of DCOM on other platforms, they are not widely accepted. Although CORBA is a specification that is implemented by multiple vendors, interoperability can only be done in a simple way, and the integration between DCOM and CORBA is needless to say.

Technically, Web services are trying to solve the problem of using technologies that are tightly bundled such as CORBA and DCOM. These issues include how to use firewalls, protocol complexity, heterogeneous platform integration, and more.

2, the application of Web services in distributed processing

Web service is a kind of excellent distributed processing technology.

The following illustration shows a general scenario for distributed processing under the. Net Framework. As a client application, it can be a traditional Windows Form application, a web-based asp.net application, a cellular mobile application, and so on, and can be another Web service program. These client applications form the presentation layer in the N-tier model (the left column in the figure) for data display. The middle column is the middle tier, which handles the business logic; the right column is the data layer, processing the data store.



With the constant standardization of an xml-based name for simple Object Access Protocol soap (easy Access Protocol), Web services are becoming a viable way to interact with other servers and applications.

3. Client consuming Web services under N-tier model

The following illustration shows the scenario of a client consuming Web service. A client can be a Web application, another Web service, a word processing program such as Microsoft Word, and so on.



The consumer of a Web service invokes a method on a Web service named methods (). The actual call to the downward layer propagates as a SOAP message over the network and propagates to the top of the Web service. The Web service executes and responds (if any).

It is possible to implement a two-way notification or publish/subscribe function between a Web service and a client, but it must be done manually. The client can implement its own web service and pass a reference to the Web service in a call to the server. The server can save the reference and then callback to the client.

Design of n-tier architecture based on the. Net Framework

object-oriented, modular design of components requires the ability to easily modify parts of the application. A good way to accomplish this is to work on the layer, separating the primary functionality of an application into different tiers or levels. The. Net framework provides rich support for creating maintainable, scalable layer patterns that allow n-tier racks to replace traditional clients/ Server mode and is tightly integrated with the Internet.

1. Layered model

Essentially, a layer represents the primary function of an application. Generally, we divide the application functionality into three aspects, corresponding to the 3-tier schema pattern. They are the data layer (layer), the business layer (business layer), and the presentation layer (presentation layer).

Data tier: A component or service that contains a data store and interacts with it. These components and services are functionally independent of each other (although they are physically not necessarily independent-they can be on the same server).

Middle-tier: Includes one or more component services that apply business rules, implement application logic, and complete the data processing required for application execution. As part of this process, the middle layer is responsible for processing data from the data store or sent to the data store.

Presentation layer: Get information from the middle tier and display it to the user. The layer is also responsible for interacting with the user, comparing the returned information and sending the information back to the middle tier for processing.

Visible, the data layer obtains the relatively original data from the database, the business layer transforms the data into conforms to the business rule the meaningful information, the presentation layer transforms the information to the user meaningful content.

This layered design approach is useful because each layer can be modified independently. We can modify the business layer, constantly accept the same data from the data layer, and pass the data to the presentation layer without worrying about ambiguity. We can also modify the presentation layer so that changes to the site's appearance do not have to change the following business layer logic.

2, the common N-tier model design

It is already known that a layer in an n-tier application is not defined by the physical structure (hardware) that runs the application. Layers are a logical feature of the application's operation and define the different task phases that the application will perform. The N-tier design here is quite different from the classic client/server architecture.

1), the design of a simple 3-storey

The simplest n-tier model is 3 layers. Here, we already have a network-separated server and client. The server contains data storage and data access components that make up the data tier, which already constitutes the business logic of the middle tier. The client as the presentation layer only needs to provide an interface to the application.



In this simplest case we might have a relational database or a set of components or stored procedures to access the data. Then we should have a ASP.net page that accesses the component or stored procedure to extract the information, process and format the information to fit the specific client, and then pass the information over the network to the client. What the client does is display the information, collect the user's input, and send the information back to the middle tier.

2), design a closer to the reality of the 3-storey

The previous example, however, is a general case of a very small application that is difficult to meet in the real world. Data stores are typically located on specially selected and specially set hardware. It may be on a windows-based set of servers running SQL Server, but it may also be running on a non-Windows platform or Oracle or other database server.



In this case, the separation between the data layer and the middle tier is more obvious-they are connected over the network. Also, business logic is limited to servers that perform all middle-tier data processing.

3), Design N-tier

Obviously, the above scenario assumes two things: one is that the client is a low-end device (so it does not participate in the actual data processing required in the application), and there is only one set of business rules.

However, these assumptions do not conform to the actual application. For example, we usually expect business rules to be in some other place rather than in the middle tier. It is appropriate to implement a business logic early in the process of extracting data, and of course we can implement business logic in the component that accesses the data store. The business logic "package" can therefore be stored on the same server as the data, or even (in a grouped environment) on another intermediate routing server.

In addition, to take advantage of some of the "fat client" performance to reduce network load and latency caused by access path loops, we can put some business logic on the client.

The following illustration shows this change, where business logic has been stripped from the middle tier and located on a data server or client.



Visible, this pattern has no intermediate storage and requires little intermediate data processing, so it is more efficient.

4), design a more realistic n-tier

Generally, we use one or more separate servers to maintain the data store we are using, when the distribution of business logic is more decentralized. The following figure shows three machines separated by two networks. As you can see, the business logic is now divided into three areas: some will run on the same server as the data store, others will run on the middle-tier server, and some will run on the client.



As you can see, it is not easy to define each layer accurately. The real meaning of "middle tier" is the business logic itself, and the different elements of business logic can justifiably exist in different servers.

3. The inter-layer (remote) Transfer object and technology under the. Net Framework

The. Net framework implements many new technologies to support multi-tier distributed processing, providing a rich class library, objects, and methods to make data transfers between different layers (physically or logically separate) simpler.

1), to support remote data transfer objects:

L Ado.net DataSet Object

L ado.net DataTable Object

L XmlDocument Object

L XmlDataDocument Object

2), support for remote data transfer classes/methods:

L Serialization Class

The serialization class describes the process of converting data to an object in a format that can be copied to another procedure. The remotely transmitted object mentioned earlier has the ability to serialize the entire content so that it can be routed through a single channel. This channel can be passed directly through TCP/IP, or via HTTP. Of course, they can also be serialized at the other end, so the client gets a full copy of the original object.

L System.Runtime.Remoting Class

System.Runtime.Remoting namespaces provide objects that can be used to create proxies for objects to enable remote data transfer. In this case, the object remains on the server, and the client receives only a reference to a proxy object. This proxy object represents the original Server-based object (this is how we use a DataReader method remotely), indicating the following figure:



For clients, this proxy provides the same methods and properties as the original object. However, when the client interacts with the proxy object, the call is automatically serialized and routed through the channel (the network) to the object on the server. Any responses and results are then routed back to the client via a channel.

Both of these remote technologies allow clients to use objects that were originally created on the server. We can serialize a DataSet object or XML document, and we can serialize other objects such as a collection such as a hash table (Hashtable) or an array.

Data processing and object selection in 4 and N-layer model

The first thing to consider is what do you want to extract from the data store? The answer to this question will have a greater impact on the basic choices of objects we use than anything else, even to some extent defining the kind of performance we want to accomplish.

1), only for display data

If you just want to display data in a fixed format for end users, there is generally no need to remotely transfer data. It is not necessary for us to send all the data to the client online-we can only pass the final display information in any format acceptable to their client devices.

In this case, the reader object provides a read-only, forward-only ideal and performance-optimized technique. When used with server controls that implement server-side data binding, we get an efficient way to display data.

2. Data to be transmitted remotely

However, there is a problem if we need to transmit data remotely. These fast and efficient "Reader" objects can be transmitted remotely only as a reference. When a DataReader is passed as a reference to a client, the DataReader is still on the server, but the client's application can use it as well. In this case, we did not actually transmit the data remotely, but instead used a remote transport object. This is the case in many cases.

To implement remote data transfer, data should be stored in an object that can store (or persist) data. It also allows code to extract data as needed and read it multiple times without the extra travel required to enter the data store. In Ado.net, this object is a DataSet object (or a DataTable object). When working with XML, there are also several objects to choose from. We are able to transmit XmlDocument and XmlDataDocument objects remotely. Both objects have the ability to maintain content and can be routed between tiers of an application.

Four-n-tier Distributed data processing architecture model

To further understand how to divide layers in your application, you need to determine how the data is displayed and whether you need to update the data and return it to the server in a timely manner.

1, all on the server to complete the display

The most common scenario for displaying data on a client is to perform all of the data processing on one or more groups of servers. The data tier and the middle tier are limited to servers, and clients only provide display interfaces. For a Web browser, the usual format is HTML, which may be represented in WML format for a cellular phone or similar device, and so on.

The following illustration uses a stored procedure or SQL statement to extract the required data, then process it with ASP.net, or execute a Web service. In addition, the data is extracted from the data store in the form of an XML fragment, which is then processed and provided to the client.



If you store data in an XML document, or if you store data in such a format: data as an external data layer of XML, then we have some other options.

The following figure shows how to extract and process XML data for transfer to client use. In addition, the extraction of data is in fact a "Reader" object, and can use different techniques to process the data and provide the data to the client.



2, the expansion of the middle tier

Although data extraction and processing often occur within an object, such as a asp.net page, it is often necessary to provide a more granular architecture to effectively leverage the benefits offered by using component-based design. We should have business rules that apply to data before it is displayed or delivered to the client. In other words, it may be for security reasons, or for distributed processing, or simply to provide reusability and make application maintenance easier.

For example, you should have multiple pages that access a data store and extract a range of consumers. By creating this process in a component that is independent of the ASP.net page or other objects that provide data to the client, we can provide a layer to extract the data. Then, in the future, we need to change the data store or structure in some way, or change the rules to access it, we just replace the component with a new version.

As long as the component's interface remains unchanged, all applications using this interface will see the same output from the component and continue to run as before. However, the methods used internally by components to extract and process data from the data store can be modified as needed. The following figure illustrates this architecture.



Obviously, this process can use multiple components. If the data extraction is quite complex, or if the same data is used in more than one place, it is meaningful to further decompose the data processing (decomposed into more component layers). For example, you can use a component to treat data as a series of rows that contain all the necessary columns (in the Order of keywords), and this component becomes a data source for other components that store data in different order, or only for certain columns of external data.

3, mobile data processing to the client

In general, to get the data that is sent to the client, we will take advantage of client-side scripting (JavaScript or VBScript and WMLScript), client components written in Java or a specific platform language, or with Visual Basic 6.0, C + +, Delphi and other languages written by the client can execute programs and so on. Of course, all the features we need are part of the. Net Framework. (Users can use the framework on the client computer by downloading and installing a configurable framework (approximately 5MB).)

Therefore, the following diagram shows some methods for implementing the data that is sent to the client and processing on the client.



4. Send the update back to the server

In many cases, if our requirement is to get the basis for sending to the client in a way that is as fast and efficient as possible, the example above can do a good job. However, many applications require that the client send the data loopback to update the data store and so on to find a more reasonable pattern.

There are at least three ways to send data back to the server. The first is the loopback HTML form and the query string (similar to the previous ASP), the other is the client component (for example, the IE5 and above versions of the XMLHTTP component), and the Windows Form applications and services that the client can perform.

So there should be a situation where the client simply asks us to send some data and we have the client complete all the data processing. That is, the client acts as a service of some kind, uses the data of the application as its own source data, and then submits the changes back after its client has processed the data.

Once the client has completed the data update, or has collected new data entered by the user, the client application packs the data in an appropriate format (or collates the data with the correct technology) and submits it to the server for processing and storage.

The following figure shows a way to implement this architecture using the "Fat client", where the data is processed on the client and then returned to the server to update the original data store.



Still, this is not a chart that contains all the possibilities. The method of loopback data may not be related to the method of sending data. You should design the appropriate model based on the actual requirements of the application.

V. Concluding remarks

Building maintainable, scalable sites, developing efficient, highly scalable applications, integrating cross-platform, cross-internet application integration, and creating N-tier distributed applications is a task for countless developers. Traditional development methods and technologies are facing difficulties.

Many of the new technologies introduced by the. Net framework provide a relatively simple solution to the implementation of these tasks. Among them, the SOAP based Web service has the obvious advantage over the traditional dcom/corba in processing the distributed application, Combined with web-based asp.net page development technology and SQL Server data storage technology (or XML documents), it is no longer difficult to develop n-tier applications under. NET.

To perform these tasks well, you need to design a reasonable application architecture model based on the actual situation. This article is to provide you with reference in this respect.