ASP. NET Distributed Application development

Net Framework provides a relatively simple solution to the implementation of these tasks. The SOAP-based Web service has obvious advantages over traditional Dcom/corba in dealing with distributed applications, combining web-based ASP. NET page Development technology and SQL Server data storage technology (or XML document). NET development of N-tier applications is no longer difficult.
I. Overview of distributed processing
Distributed processing is the distribution of application logic across 2 or more computers, physically or logically separated units. This concept is not new, in large-scale projects have been widely used. However, the advent of the Internet has given new features to distributed processing, and the features of Internet connectivity allow hundreds of computers to work on a single task, making it possible to implement distributed processing on a larger scale and spanning the traditional B/s (client/server) model.
The idea of distributed processing has gone through a long process, and the developers and suppliers of different it times have done a lot of work, which makes the protocol of supporting distributed processing very rich.
1, Dcom/corba
Prior to the. Net Framework, the primary protocol for component-based distributed computing was CORBA (Common object request broker Architecture, generic object solicitation broker structure), 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 has led to technical problems. For example, a client might hold reference information and generate a call only when the user clicks the button. For a long time, the server will be idle waiting for the client's request. When a client crashes and cannot request a server, it can have serious consequences. Also, on the Internet, DCOM or CORBA servers are used by thousands of clients, and because each client has a connection to the server, it should protect valuable server resources for clients that rarely use the server or simply no longer use the server.
Although DCOM has a way 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 distributed processing, namely Web service (Web services). Web services can provide data for another application, not just a browser, and pass external data to allow other clients to perform operations using standard protocols such as HTTP, which operate on the same port and transport layer.
second, the distributed processing technology under the WEB service-.net framework
In the. Net framework, a Web service refers to an application logical unit that can be accessed by a program in a platform-independent manner through a standard web protocol.
The developers of the. Net framework are setting up Web services based on open standards that can be used on any platform. It has the potential to act as a cross-platform and cross-vendor integration technology. With the implementation of the Web services and Web services architecture, 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 that are supported by key vendors such as Microsoft, IBM, and Sun.
1, Dcom/corba face the difficult solution--web Service
DCOM and CORBA are excellent at creating enterprise applications with software running on the same platform and tightly managed LANs. However, they are overwhelmed by the creation of cross-platform, Internet-based, scalable 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 client computers. Although there are other ways to implement DCOM implementations on other platforms, they are not widely accepted. Although CORBA is a specification implemented by multiple vendors, interoperability can only be done in a simple way, as far as the integration between DCOM and CORBA does not have to be said.
Technically, Web services are trying to solve problems with tightly bundled technologies such as CORBA and DCOM. These include how the firewall, protocol complexity, heterogeneous platform integration, and so on.
2. Application of Web services in distributed processing
Web service is a kind of excellent distributed processing technology.
Demonstrates the general scenario of 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, or it can be another Web service program. These client applications form the presentation layer in the N-tier model (the left column in the diagram) for data display. The middle column is the middle tier, which handles business logic, and the right column is the data layer that handles the data store.

With the constant standardization of an XML-based named Simple Object-Access Protocol soap (easy Objects Access Protocol), Web services are becoming a viable way to interact with other servers and applications.
3, N-tier model of client consumer Web services
Demonstrates a scenario where a client consumes a Web service. The client can be a Web application, another Web service, a word processing program such as Microsoft Word, and so on.

The consumer of the Web service calls a method on a Web service named methods (). The actual call is propagated down the layer as a SOAP message over the network and propagated to the Web service to the top. The Web service executes and responds (if any).
It is possible to implement two-way notification or publish/subscribe functionality between a Web service and a client, but it must be done manually. A client can implement its own web service and pass the Web service in a call to the server.

The. Net framework-based n-tier Distributed Application development part 2nd:

Reference. The server can save the reference and then callback to the client.
Third, the N-tier architecture design based on the. Net Framework
Object-oriented, modular-based component design needs to be able to easily modify parts of an application. A good way to accomplish this is to work on the layer and separate the main functions of an application into different tiers or levels. The. Net framework provides rich support for creating a maintainable, extensible layer pattern, allowing n-tier scaffolding to replace traditional client/ Server mode and is tightly integrated with the Internet.
1. Layered model
Essentially, a layer represents the main function of an application. In general, we divide the application function into three aspects, corresponding to the 3-tier architecture pattern. They are the data layer, the business layer, and the presentation tier (presentation layer).
Data layer: Contains the data store and the components or services that interact with it. These components and services are functionally and in the middle tier independent of each other (although not necessarily physically 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 the application to run. As part of this process, the intermediate layer is responsible for processing data from the data store or sent to the data store.
Presentation layer: Information is obtained from the middle tier and displayed 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.
It can be seen that the data layer obtains the more primitive data from the database, the business layer transforms the data into the meaningful information which conforms to the business rules, the presentation layer transforms the information into the content which is meaningful to the user.
This layered design approach is useful because each layer can be modified independently. We can modify the business layer, continuously 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, commonly used n-layer 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. A layer is a logical aspect of the application's functioning and defines the different phases of the task that the application will perform. The N-tier design here is very different from the classic client/server architecture.
1), design a simple 3-layer
The simplest n-tier model is the 3 layer. Here, we already have a server and client that is separated by the network. The server has data access components that contain data stores and data layers, and the business logic of the middle tier has been formed. The client only needs to provide an interface to the application as the presentation layer.

In this simplest case, we may have a relational database or a set of components or stored procedures that access the data. Then we should have an ASP. NET page that accesses the component or stored procedure to extract the information, process and format the information to fit the particular client, and then pass the information over the network to the client. What the client has to do 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 layer
However the previous example is just a very small application of the general situation, the real world is difficult to meet. 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 on an 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-Layer
Obviously, the above scenario assumes two things: 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 earlier in the process of extracting data, and of course we can implement business logic in the components that access the data store. This 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, in order to take advantage of some of the performance of the "Fat client" to reduce network load and latency due to access path loops, we can put some business logic on the client.
Shows this change, where business logic has been stripped from the middle tier and located on the data server or client.

Thus, this mode has no intermediate storage and requires little intermediate data processing, so it is more efficient.
4), design a more realistic N-layer
In general, we use one or more separate servers to maintain the data store we are using, and the distribution of business logic is more fragmented. Shows three machines separated by two networks. As you can see, the business logic is now divided into three zones: 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 the "middle tier" is the business logic itself, and the different elements of business logic can be justifiably present in different servers.
3. Inter-layer (remote) Transfer objects and technologies under the. Net Framework
The. Net framework implements a number of new technologies to support multi-tier distributed processing, which provides a rich library of classes, objects, and methods to make data transfer between different tiers (physically detached or simply logically separated) easier.
1), the object that supports remote data transfer:
L ADO DataSet Object
L-ADO DataTable Object
L XmlDocument Object
L XmlDataDocument Object
2), a class/method that supports remote data transfer:
L Serialization Class
The serialization class describes a process that transforms data into 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 channel. This channel can be directly via TCP/IP, or via HTTP. Of course, they can also be de-serialized at the other end, so the client gets a full copy of the original object.

The. Net framework-based n-tier Distributed Application development part 3rd:

L System.Runtime.Remoting Class
The System.Runtime.Remoting namespace provides 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 the proxy object. This proxy object represents the original server-based object (this is how we use a DataReader method remotely), indicating that:

For the client, 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 (network) to the object on the server. Any responses and results are then routed back to the client through the channel.
Both 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 collections such as a hash table (Hashtable) or array.
4. Data processing and object selection in N-layer model
The first thing to consider is what data you want to extract from the data store? The answer to this question will have a greater impact on the basic choices of the objects we use than anything else, even in a way that defines the kind of performance we want to accomplish.
1), only for display of data
If you only want to display data in a fixed format for end users, there is generally no need to transfer data remotely. It is not necessary for us to transmit all the data to the client online-we can only pass the final display of the information to any format that the customer's device can accept.
In this case, the reader object provides a read-only, forward-only ideal and performance-optimized technique. When used with server controls that enable server-side data binding, we get an efficient way to display data.
2), data that needs to be transmitted remotely
However, there is a problem if we need to transfer data remotely. These fast and efficient "Reader" objects can only be transmitted remotely as a reference. When a DataReader is passed as a reference to a client, DataReader is still on the server, but the client's application can also use it. In this case, we actually did not transfer the data remotely, but instead used a remote transfer object. This is the case in many cases.
To enable remote transfer of data, the data should be hosted in an object that can store (or persist) data. and allows the code to extract data as needed and read multiple times without the need to enter the data store for extra trips. In ADO, this object is a DataSet object (or DataTable object). When using XML, there are also several objects to choose from. We are able to remotely transmit XmlDocument and XmlDataDocument objects. Both objects have the ability to maintain content and can be routed between tiers of an application.
four-n-layer Distributed Data Processing architecture model
To further understand how to divide different layers in your application, you need to determine how the data is displayed and whether you need to update the data and return updates 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 data processing on one or more sets of servers. The data tier and middle tier are limited to servers, and the client provides only display interfaces. For a Web browser, the usual format is HTML, for a cellular phone or similar device, it may be in WML format, and so on.
Use 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 then processes the data and provides it to the client.

If you store data as an XML document, or if you store data in such a format: data as an XML external data layer, we have some other options.
Shows how to extract and process the XML data for delivery to the client. In addition, data extraction is actually a "Reader" object, and different techniques can be used to process the data and provide the data to the client.

2. Extending the middle tier
Although the extraction and processing of data often occurs in an object, such as an ASP. NET page, it is often necessary to provide a more granular architecture in order to effectively exploit the benefits of using component-based design. We should have business rules that apply to data before the data is displayed or transmitted 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, there should be multiple pages that access a data store and extract a series of consumers. By establishing this process in a component that is independent of an ASP. NET page or other object that provides data to the client, we are able to provide a layer to extract the data. Then, in the future we need to change the datastore or data structure in some way, or change the rules to access it, just replace the component with a new version.
As long as the component's interface remains intact, all applications that use this interface will see the same output from the component and continue running as before. However, the method that the component uses internally to extract and process data from the data store can be modified as needed. This architecture was signalled.

Obviously, the process can use multiple components. If the extraction of data is quite complex, or if the same data is used in multiple places, it is meaningful to further decompose 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 of the necessary columns (in the Order of keywords), a component that becomes a data source for other components that store data in different order, or for some columns of external data only.
3, mobile data processing to the client
In general, to get the data 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 in the client executable program 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 the reallocated framework (approximately 5MB).)
Therefore, the following shows some methods for implementing the data that is sent to the client and processing it on the client.

The. Net framework-based n-tier distributed Application development Part 4:

4. Send updates back to the server
In many cases, if our requirement is to obtain the basis for sending to the client in a way that is as fast and efficient as possible, the above example will do a good job. However, many applications require clients to send data back in order to update data storage operations such as to find more reasonable patterns.
There are at least three ways to send data back to the server. The first is to return the HTML form and query string (implemented in a similar way to the previous ASP), and the other is the client component (for example, IE5 and later versions of the XMLHTTP component), and the Windows Forms applications and services that the client can perform.
Therefore, there should be a situation where the client simply asks us to send some data, and we let the client do all the data processing. That is, the client acts as a type of service that uses the application's data 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 packages the data in a suitable format (or organizes the data with the correct technology) and submits it to the server for processing and storage.
Shows how to implement this architecture using a "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 the data. You should design the right model based on the actual needs of your application.
v. Concluding remarks
Building a maintainable, scalable site, developing high-efficiency, highly scalable applications, enabling cross-platform, cross-Internet application integration, and creating N-tier distributed applications is a task facing 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. The SOAP-based Web service has obvious advantages over traditional Dcom/corba in dealing with distributed applications. In combination with Web-based ASP. NET page Development technology and SQL Server data storage technology (or XML document), it is no longer difficult to develop n-tier applications under.
To accomplish 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.
Resources: ASP. ASP.. NET Web Services Advanced programming, the inside of the framework technology. NET Distributed Data Application advanced programming, MSDN Online

Related information:

ASP. NET Distributed Application development