Web Service and other remote interface design guide

Eb service and other remote interface design guide
Level: elementary
Android Fachat
IT architect, IBM Global Services
August 2004
The more applications are included in the interactive components and service networks, the more potential performance problems need to be considered. This is usually caused by the distributed architecture. The execution time of a specific function or method is of course very important, but the communication time between them is now affected by the impact of distributed components on performance problems.
Andre Fachat discusses distributed design through a shopping cart instance. This instance is very simple, but it also strongly proves what is good and what is bad. The instance shows that it is a good way to keep the coarse granularity of communication by reducing the number of remote calls. It also proposes the ID-Lists mode, which combines multiple remote calls into one.
Introduction
Implementing a distributed system usually involves integrating distributed applications through the network. In this network, each application provides a specific set of services. This introduces the concept of a Service-Oriented Architecture (SOA), for example, in [SOA, SOAD. Assuming that the new remote access specification is released and all products support it, like the old applications, IT architects need to handle a large number of different types of specifications for remote access in a single application. These services can be executed as remote Enterprise JavaBean (EJB) method calls, Web services, or CORBA calls (only a few are listed here. This article tries its best to maintain the general architecture point of view, rather than any specific implementation technology.
To call a remote service, you can package the request data in the format that can be transmitted by the service requestor, send the data to the service, and then release the request in the service response. The response process is the opposite. Therefore, the perceived response time of remote implementation depends not only on the Performance of remote implementation, but also on:
? Number of independent remote calls required to complete a specific function
? Time when a remote call is created
? Time required for package and package request and response
? The time required to send the request to the service and return the response (this time depends on the transmission delay, transmission speed, and data volume)
When designing an interface for remote access, you must remember whether it affects overall performance. Note that multiple remote services may be called to complete a specific function.
We usually need to reuse existing services. Remember, those services may be designed and developed using local applications and cannot be used for remote access. I have experienced a situation where the prices of items in the shopping cart are calculated individually in the Enterprise Resource Planning (ERP) system. When the Web-based store that we want to execute calls the price function, the performance is very poor because many remote calls request the ERP system. We have to execute an encapsulation in the ERP system to calculate the price for all items, and then call the package from our Web store to improve the performance.
In the following section, I will introduce the simple instance mentioned above, which reads a shopping cart and analyzes it to find a mode to improve performance. In Part 1, I will provide some specific modes.
Instance cases
This example discusses the use cases for reading a shopping cart from a remote system. You can see the instance in the context of the Web-based store. In the instance, the client application represents the interaction between the user and the distributed system, and the entries are concentrated in the shopping cart, finally, purchase the selected entry. The data read in the use case should be used to display the shopping cart to the user. A shopping cart consists of a message header (display delivery address and payment information) and a column of entries, each of which includes a single item and the quantity of the item.
Figure 1 shows the object model. This model is composed of a shopping Cart object ("Cart"), which contains the information about the message header of the shopping Cart. Cart can have multiple entries. The CartItem object contains references to the Article object and the quantity of the item in the shopping Cart (the attribute is intentionally omitted in the figure to better illustrate the problem. The Article object contains the general information about the product (such as price, weight, and image), and The ArticleDescription object contains the detailed language description about the product. An Auction table is attached to the system for future extension.
Figure 1. Shopping Cart Object Model.

Use Cases for reading a shopping Cart include reading Cart and CartItems, just as if the item information includes the Article and ArticleDescription objects. Therefore, the design should take into account that there will be transactions in the future, and the transactions involve commodities, and the commodity information should be read from the external ERP system.
In the following section, I will discuss the implementation of this case when a user (represented by a client application) interacts with a remote system. The implementation of the first instance uses the original design method. Because it is proposed according to the standard usage mode, it indicates that it is not the best access mode, which may cause performance problems.
Remote Entity bean
The Enterprise JavaBean Component is widely used to remotely access data and services. The main purpose of the entity EJB component is to remotely access persistent data, which is mainly stored in relational databases. In the shopping Cart Use Case instance, you must assume that you have a table for each object. These objects are Cart, CartItem, Article, and ArticleDescription. Define an object bean for each table. The client application searches for the Home Interface through the Java Naming and Directory Interface (Java Naming and Directory Interface, JNDI) service, and then retrieves bean instances using the finder method on the Home Interface. For the initial Home interface of the four tables, see Listing 1:
Listing 1. Home interface of the object table

Public interface CartHome extends javax. ejb. EJBHome {

Cart create () throws javax. ejb. CreateException;

Cart findByPrimaryKey (CartId id) throws javax. ejb. FinderException;
}

Public interface CartItemHome extends javax. ejb. EJBHome {

CartItem create () throws javax. ejb. CreateException;

CartItem findByPrimaryKey (CartItemId id) throws javax. ejb. FinderException;

Collection findByCart (CartId id) throws javax. ejb. FinderException;
}

Public interface ArticleHome extends javax. ejb. EJBHome {

Article create () throws javax. ejb. CreateException;

Article findByPrimaryKey (ArticleId id) throws javax. ejb. FinderException;
}

Public interface ArticleDescriptionHome extends javax. ejb. EJBHome {

ArticleDescription create () throws javax. ejb. CreateException;

ArticleDescription findByPrimaryKey (ArticleDescriptionKey id) throws javax. ejb. FinderException;

Collection findByArticle (ArticleId id) throws javax. ejb. FinderException;
}
Note that the CartItemHome interface has a finder method that searches for all entries in a specific shopping cart. Similarly, ArticleDescriptionHome also has a finder method to find all the descriptions of a specific product.
To execute this example, read the shopping cart and call the finder method of the shopping cart by calling findByPrimaryKey (CartId. This method returns an Entity bean for the columns in the shopping cart table. This entity bean has a given CartId. Then call CartItemHome. findByCart (CartId) to retrieve CartItem bean with the given CartId as the entry of the shopping cart. Each CartItem contains a number and an ArticleId. To read the item data, you must use the ArticleHome interface and call the findByPrimaryKey () method of this interface for each item in the shopping cart. The retrieved bean contains the information necessary to display the shopping cart.
But why is it not a good way to use object beans like this? There is a reason: the bean instance calls any method remotely, retrieves data from the server, or writes data to the server. Obviously, these remote calls have a high performance cost. Therefore, other mechanisms are usually used. Our instance uses the Session Layer of the transmitted value object (using the JavaBean Component to transfer data in the table, [TVO]), instead of directly calling the object bean, the application calls a session-layer bean [TopJ2EE]. The bean reads data from the database, fills the JavaBean Component with the read value, and then returns the component to the caller. This is similar when writing data to the database. In this instance, the caller fills in the transfer value object with the data to be written to the database, calls the write method on the session bean, and then executes the write function. For example, IBM compresses this mode in its AccessBeans component, while WebSphere? The AccessBeans component is used in Studio [AB] products. Currently, using various access bean modes is considered an art. I suppose this mode applies to all subsequent instances. Therefore, I only focus on the method of retrieving the transmitted object.
Theory
This EJB-based instance shows an important mode for improving performance when accessing remote components and services, that is, reducing the number of remote calls. But why does remote calls require such a high price? To some extent, understanding this can help avoid performance problems.
In the following section, I will study how to send messages from the service requestor to the service responder. Assume that the Message consists of the Information header and some entries. These entries are of the same size, but the number is not fixed. This method is the closest to messages of an indefinite size in arithmetic (forgive me, I will try to make it short ).
Figure 2: upper half of the Remote Call period

Figure 2 shows the different stages of sending request information to the remote service:
1. Construct remote calls (for example, the Home interface and the grouping program .)
2. package request data to convert the request to a format suitable for network transmission (for example, using Java technology to convert the request to XML for J2EE SOAP, java binary object used for IIOP ).
3. Transfer the packaged data to a remote terminal.
4. Build an acceptor (unmarshaller), for example, an XML Parser .)
5. Unpack the request into an object to call the remote service implementation.
Note that only some necessary stages are displayed, which do not include local calls.
It shows that some stages in the process depend on the number of items, that is, the Message Size, while other stages do not depend on the number of items:
T_setupTx
In the preceding example, the time set for the sender does not depend on the number of entries.
T_marshall = t_1_all_hdr + N * t_1_all_item
In the preceding example, the request packaging time depends on the number of items.
T_transport = T_latency + T_transport_hdr + N * T_transport_item
The interval between T_transport_hdr and T_transport_item depends on the network bandwidth (byte/second) and the size of each data (# byte ). T_latency is the time consumed to put the first byte of the sender on the transmission media and receive the byte on the receiver.
T_setupRx
In the above instance, the time for setting the receiver does not depend on the number of entries.
T_unmarshall = T_unmarshall_hdr + N * T_unmarshall_item
The time for request to unpackage depends on the number of items again.
A slight re-decomposition of the formula, the total time required for calling T_total is changed:

T_total = T_setupTx + t_1_all_hdr + T_latency
+ T_transport_hdr
+ T_setupRx + T_unmarshall_hdr
+ N * (t_transferall_item + T_transport_item
+ T_unmarshall_item)
This expression can also be written as follows:

T_total = T_fixed + N * T_item
Merge fixed parts:

T_fixed = T_setupTx + t_1_all_hdr + T_latency
+ T_transport_hdr + T_setupRx + T_unmarshall_hdr
Merge indefinite parts:

T_item = t_transferall_item + T_transport_item + t_untransferall_item.
It is worth noting that the total time of remote calls depends on a large number of different parts. When estimating the time of a remote call, for example, it is very important to use a trace statement to know where each part starts and where it ends, because it is possible to set a trace statement at an appropriate position. It is also important to measure remote calls by different message sizes, in this way, we can check whether the performance problem is caused by the fixed part or the variable part dependent on the message size (the Message Size refers to the number of items ).
The high-speed cache JDBC connection (of course, remote database calling is also a remote service) is an instance in which the above problems are found and solved. The cache connection reduces the setting time by avoiding the connection time to the database (except for the first time. Based on the same principle, the EJB Home interface retrieved from JNDI is also cached at high speed.
The formula also shows the main reasons for reducing the number of remote calls. It takes the following time to transmit the same number of entries using n remote calls:

T_multi = n * T_fixed + n * T_item
However, it takes the following time to transmit the same number of entries in a call:

T_single = T_fixed + n * T_item.
The difference between the two types of transmission is (n-1) * T_fixed. Because T_fixed includes network latency, network latency can be optimized only by using new hardware (if it is fundamentally optimized ), you will find that merging multiple calls into one call [FLDD] can easily reduce the number of remote calls.
Proper guidance
In this article, the Web-based store is also an EJB-based instance. I found out the factors that affect the performance of Distributed Remote calls. In this equation, which consists of fixed and indefinite factors, there are three main influences: data during packaging, transmission, and package settlement. The initialization process and network latency on the application sender and receiver further affect these aspects. This part describes some principles, and I will introduce some examples in Part 1. I will also use the sample cases described here to optimize the instance performance by reducing the number of remote calls. In this process, I will discuss factors related to remote access mode and separation, as well as high-speed cache, and finally provide appropriate guidance on how to design distributed applications.
Thank you
Thanks to Stefan Peuser, Olaf Zimmermann, Witold Szczeponik, and Frank Müller for their valuable comments.
References
? For more information, see the original article on the developerWorks global site.
? [SOA] Mark Colan, "service-oriented architecture extends Web Services, Part 1-service-oriented architecture features" (developerWorks, 1st)
? [SOAD] Olaf Zimmermann, Pal Krogdahl, Clive Gee, "service-oriented analysis and design principles-modeling methods across disciplines for SOA solutions" (developerWorks, June 2004)
? [TopJ2EE] Kyle Brown, Keys Botzum, Ruth Willenborg, "Developer technical journals: 10 (more or less) J2EE best practices" (developerWorks, May 2004)
? [DP] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, design pattern: Reusable object-oriented software principle, ISBN 0201633612, Addison-Wesley Pub Co.
? [SoC1] Edsger W. Dijkstra, "Separation of Concerns"

In enterprise application development, CORBA and EJB have obvious advantages, and the Java technology relied on by CORBA and EJB can complement each other well. The Network transparency of CORBA processing and the transparency of EJB processing. From this point of view, the close combination of CORBA and EJB technology is a major trend in the future development of multi-layer distributed systems.
References:
1. Analysis and Comparison of three component models: Tong hengqing, Yan Huiqin, and Li siyong. CORBA/COM/EJB [J]. Computer Application Research,; 66-67.
2. sover. Software Engineering [M]. Beijing: Machinery Industry Press, 2003.1.
3 Li Jiyun, Dong xiaoshe, Tong Rui. Research on Distributed object middleware technology [J]. Computer engineering and design, 170; 173.
4. Qiu Yan. Component Technology and analysis comparison [J]. Computer engineering and design,; 13-17.
5 Bam Bala. J2EE technology insider [M]. Beijing: Machinery Industry Press, 2002.
. Net Framework-based N-Layer Distributed Application Development

1. Distributed Processing Overview

Distributed processing is a unit that logically distributes applications to two or more computers and is physically or logically separated. This concept is not a new concept and has been widely used in large-scale projects. However, the emergence of the Internet has given new features to distributed processing. The internal connection feature of the Internet allows hundreds of computers to work as a task, making it possible to implement distributed processing on a larger scale, and spans the traditional B/S (Client/Server) model.

The idea of distributed processing has gone through a long process. Developers and vendors at all levels have done a lot of work in different IT times, making distributed processing rich in protocols.

1. DCOM/CORBA

In. before the. Net Framework, the main protocol for component-based distributed computing is the Common Object Request Broker Architecture (Common Object Request proxy structure), which comes from the Object Management Group (Object Management Group ), also, Microsoft's DCOM (Distributed Component Object Model, Distributed Component Object Model ).

DCOM is connection-oriented. The DCOM client holds a connection to the DCOM server. This connection method causes technical problems. For example, a client may hold reference information and generate a call only when the user clicks the button. After a long time, the server will be idle due to waiting for client requests. When the client crashes and cannot request the server, it will have serious consequences. In addition, on the Internet, the DCOM or CORBA server is used by thousands of clients, because each client has a connection with the server, for clients that seldom use the server or do not use the server at all, they should protect valuable server resources.

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

2. Web Services

With the launch of Microsoft. Net Framewwork, a new technology is available for distributed processing, namely, Web services ). Web services can provide data for another application, not just a browser, and allow other clients to use standard protocols (such as HTTP) that work on the same port and transport layer through external data) to perform the operation.

Ii. Distributed Processing Technology under Web Service-. Net Framework

In. Net Framework, Web services are the logical units of applications that can be accessed by programs through standard Web protocols in a platform-independent manner.

. Net Framework developers place Web Services on open standards and can use them on any platform. It has the potential to be integrated as a cross-platform and cross-vendor technology. After implementing the Web service and Web Service Architecture, you can use many existing technologies on the Internet. The key to successful Web services is that they are based on open standards, which are supported by major vendors such as Microsoft, IBM, and Sun.

1. solutions to difficulties faced by DCOM/CORBA-Web Services

DCOM and CORBA are excellent in creating enterprise applications using software running on the same platform and tightly managed LAN. However, they do not have the ability to create cross-platform, cross-Internet, and Internet-based scalable applications. 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. It is difficult to cooperate with business partners based on the traditional distributed architecture.

The problem with DCOM and CORBA is that users basically need to rely on a vendor. To use DCOM, you must use Microsoft Windows to run the server and client. Although there are DCOM implementation methods on other platforms, they are not widely adopted. Although CORBA is a specification implemented by multiple vendors, interoperability can only be achieved in a simple way. Integration Between DCOM and CORBA is unnecessary.

From a technical perspective, Web services try to solve problems encountered when using closely bound technologies such as CORBA and DCOM. These problems include how to use firewalls, protocol complexity, and integration of heterogeneous platforms.

2. Application of Web Services in Distributed Processing

Web Service is an excellent distributed processing technology.

Demonstrate the general situation of distributed processing under. Net Framework. Client Applications can be traditional Windows Form applications, Web-based Asp.net applications, cellular mobile applications, and other Web service programs. These client applications form the presentation layer (the left column in the figure) in the N-layer model for data display. The middle column is the middle layer, processing business logic; the right column is the data layer, processing data storage.

With the constant standardization of xml-based Simple Object Access Protocol (SOAP), web services are becoming a feasible way to interact with other servers and applications.

3. The client consumes Web Services under the N-Layer Model

Demonstrate how the client consumes Web Services. A client can be a Web application, another Web service, or a Word processing program such as Microsoft Word.

A Web service consumer calls a Method on a Web service named Method. The actual call is transmitted to the lower layer. As a Soap message, it is transmitted to the Web Service through the network and to the upper layer. The Web service executes and responds (if any ).

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

Iii. Design of A. Net Framework-based N-layer architecture

Object-oriented, modular-based component design requires convenient modification of each part of the application. A good way to accomplish this goal is to work on the layer and separate the main functions of an application from different layers or levels .. Net Framework provides a wealth of support for creating a maintainable and scalable layer mode, so that layer N is enough to replace the traditional Client/Server mode and is closely integrated with the Internet.

1. Layered Model

Essentially, the layer represents the main function of an application. Generally, we divide the application functions into three aspects, corresponding to the three-layer architecture model. They are data layer, business layer, and presentation layer ).

Data Layer: a component or service that contains data storage and interaction with it. These components and services are functionally independent from the middle layer (though physically independent-they can be on the same server ).

Middle Layer: includes one or more component services, which apply business rules, implement application logic, and complete the data processing required by the application program. As part of this process, the middle layer is responsible for processing data from the data storage or sent to the data storage.

Presentation Layer: obtain information from the middle layer and display it to the user. This layer is also responsible for interacting with users, comparing the returned information and sending the information back to the middle layer for processing.

It can be seen that the data layer obtains original data from the database, and the business layer converts the data into meaningful information that complies with business rules. The presentation layer converts the information into meaningful content for users.

This hierarchical design method 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 modifications to the site's appearance do not have to change the business layer logic below.

2. Common N-Layer Model Design

It is known that layers in an N-tier application are not defined by the physical structure (hardware) of the running application. The layer is a logical function of the application program running, and defines the different task stages that the application will execute. The N-layer design here is quite different from the classic client/server architecture.

1) Design a Simple Layer 3

The simplest N-layer model is Layer 3. Here, we already have a server and client separated by the network. The server contains data storage and data access components that constitute the data layer, which has formed the business logic of the middle layer. As the presentation layer, the client only needs to provide an interface for the application.

In this simplest case, we may have a relational database or a group of components or stored procedures that access data. Then we should have an asp.net page that accesses the component or stored procedure to extract information, process and format the information so that it is suitable for a specific client, and then transmit the information to the client through the network. What the client needs to do is to display information, collect user input, and send the information back to the middle layer.

2) Design a Layer 3 closer to reality

However, the previous example is just a very small application, which is hard to come across in the real world. Data storage is usually located on specially selected and specially set hardware. It may be running on a Windows-based Server group running SQL Server, but it may also be running on a non-Windows platform or Oracle or other database servers.

In this case, the separation between the data layer and the middle layer is even more obvious-they are connected through the network. In addition, the business logic is restricted on the server that processes all intermediate layer data.

3) design N layers

Obviously, the above situation assumes two things: one is that the client is a low-end device (so it is not involved in the actual data processing required by the application), and the other is that 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 somewhere else rather than in the middle layer. It is more appropriate to implement a business logic in the early stage of the data extraction process. Of course, we can also implement business logic in the components that access data storage. Therefore, this business logic package can be stored on the same server as the data, or even (in A group environment) on another intermediate routing server.

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

4) Design a more realistic N-Layer

Generally, we use one or more isolated servers to maintain the data storage we are using. In this case, the distribution of business logic is more dispersed. Displays three machines separated by two networks. It can be seen that the current business logic is divided into three zones: Some will run on the same server as the data storage, and some will run on the intermediate server, some will run on the client.

From this we can see that it is not easy to accurately define each layer. The real meaning of "middle layer" is the business logic itself, and different elements of business logic can exist in different servers without question.

3. Inter-layer (remote) transmission object and technology under. Net Framework

. Net Framework implements many new technologies to support multi-layer distributed processing. It provides a wide range of class libraries, objects, and methods to enable physical or logical separation at different layers) data transmission between them is simpler.

1) objects that support remote data transmission:

L ADO. NET DataSet object

L ADO. NET DataTable object

L XmlDocument object

L XmlDataDocument object

2) classes/methods supporting remote data transmission:

L Serialization class

The Serialization class describes a process of converting data into an object that can be copied to another format. The objects that can be remotely transmitted previously have the ability to serialize the entire content so that it can be transmitted through a channel. This channel can be directly through TCP/IP or HTTP. Of course, they can also be de-serialized on the other end, so the client gets a complete copy of the original object.

L System. Runtime. Remoting class

The objects provided by the System. Runtime. Remoting namespace can be used to create a proxy for objects for remote data transmission. In this case, the object is retained on the server, and the client receives only one reference from the proxy object. This proxy object represents the original server-based object (this is how we remotely use a DataReader method), as shown in:

For the client, this proxy provides the same methods and attributes as the original object. However, when the client interacts with the proxy object, the call is automatically serialized and transmitted to the object on the server through a channel (network. Then, any response and results are transmitted back to the client through the channel.

Both remote technologies allow the client to use the objects originally created on the server. We can serialize A DataSet object or Xml document, and serialize other objects such as a set, such as a hash table or Array ).

4. Data Processing and object selection in the N-Layer Model

The first thing to consider is what data is extracted from the data storage? The answer to this question has a greater impact on the basic choice of the objects we use than anything else, and even defines the type of performance that we want to accomplish.

1) only used for displaying data

If you only want to display data for end users in a fixed format, generally there is no need to transmit data remotely. We do not need to transmit all the data online to the client-we can only transmit the final display information in any format acceptable to their customer devices.

In this case, the "Reader" Object provides a read-only, forward-only ideal technology with optimal performance. When used together with a server control that can bind server data, we can obtain an efficient way to display data.

2) data to be remotely transmitted

However, if we need to transmit data remotely, there is a problem. These fast and efficient "Reader" objects can be remotely transmitted only when they are referenced. When a DataReader is transmitted as a reference to a client, the DataReader is still on the server, but the client application can also use it. In this case, we do not actually transmit data remotely, but use a remote transmission object. This is often the case in many cases.

To achieve remote data transmission, you should store the data to an object that can store (or maintain) the data. It also allows the code to extract data and read the data multiple times as needed without having to enter the additional steps of data storage. In ADO. NET, this object is a DataSet object (or DataTable object ). When using xml, there are several objects to choose from. We can remotely transmit XmlDocument and XmlDataDocument objects. Both objects have the ability to maintain content and can be transferred between layers of an application.

4. N-Layer Distributed Data Processing Architecture Model

To further understand how to divide different layers in an application, you need to determine how data is displayed and whether data needs to be updated and how to return updates to the server in a timely manner.

1. display all on the server

Display data on the client. The most common scenario is to execute all data processing on one or more sets of servers. The data layer and intermediate layer are limited to servers, and the client only provides the display interface. For a web browser, the common format is html. For a cellular phone or similar device, it may be represented in wml format.

Use a stored procedure or SQL statement to extract the required data, and then use asp.net for processing, or execute a web service. In addition, xml fragments are also used to extract data from the data storage, and then process the data and provide it to the client.

If you store data in the form of an xml document or in such a format: data is used as an external xml data layer, we have some other options.

Shows how to extract and process xml data for transmission to the client. In addition, data extraction is actually using a "Reader" object, and different technologies can be used to process data and provide the data to the client.

2. Expand the middle layer

Although data extraction and processing often occur in an object, such as an Asp. net page, but in order to effectively use the benefits provided by the use of component-based design, it is usually necessary to provide a more refined architecture. We should have business rules that apply to data before displaying data or transmitting it to the client. In other words, it may be for security reasons, or to achieve distributed processing, or simply to provide reusability and make application maintenance easier.

For example, you should have access to a data storage and extract multiple pages of a series of consumers. By establishing this process in a component independent of the asp.net page or other objects that provide data to the client, we can provide a layer for data extraction. Then, in the future, we need to change the data storage or data structure in some ways, or change the rules for accessing it. We only need to replace the component with a new version.

As long as the component interface remains unchanged, all applications that use this interface will see the same output from the component and continue running as before. However, you can modify the method that the component uses internally to extract and process data from data storage as needed.
Obviously, this process can use multiple components. If the data extraction is quite complex, or the same data is used in multiple places, further data processing (decomposed into more component layers) makes sense. For example, you can use a component to treat data as a series of rows containing all required columns (arranged in the order of keywords). This component can become another component that stores data in different order, or only the data sources of Components in some columns of external data.

3. Move data to the client

Generally, to obtain the data sent to the client, we use client scripts (JavaScript, VBScript, and WMLScript) and client components written in Java or a specific platform language, you can also use client executable programs written in languages such as Visual Basic 6.0, C ++, and Delphi. Of course, all the features we need are part of the. Net Framework. (Users can use the Framework on the client by downloading and installing the allocable Framework (about 5 MB ).

4. Send the update back to the server

In many cases, if our requirement is to obtain the basis for sending data to the client as quickly and efficiently as possible, the above example can well complete the task. However, many applications require clients to find a more reasonable mode when sending data back to update data storage.

There are at least three methods for sending data back to the server. One is to send Html forms and query strings (implementation method is similar to the previous ASP); the other is to use client components (such as XMLHTTP components of IE5 and later versions ); there are also Windows form applications and services that can be executed by the client.

Therefore, the client only requires us to send some data and let the client complete all the data processing. That is to say, the client acts as a certain type of service and uses the application data as its own source data. Then, after the client processes the data, it submits the changes back.

Once the client completes data updates or has collected new user input data, the client application packs the data in a suitable format (or uses the correct technology to organize the data ), and submit it to the server for processing and storage.

This architecture is implemented using the "fat client", where data is processed on the client and then sorted and returned to the server to update the original data storage. Still, this is not a chart that contains all possibilities. The method for sending data back may be unrelated to the method for sending data. You should design an appropriate model based on the actual needs of the application.

V. Conclusion

Establish a maintainable and scalable site, developing efficient and highly scalable applications, implementing cross-platform and cross-Internet application integration, and creating N-layer distributed applications is a task for countless developers. Traditional development methods and technologies face difficulties.

Many new technologies released by. Net Framework provide relatively simple solutions for the implementation of these tasks. Among them, the SOAP-based Web Service has obvious advantages over the traditional DCOM/CORBA in processing distributed applications, combined with Web-based ASP. NET page development technology and SQLServer Data Storage Technology (or Xml document), in. it is no longer difficult to develop N-layer applications under. Net.

To complete the above tasks well, you need to design a reasonable application architecture model based on the actual situation. This article is for your reference in this regard.
Multi-layer structure, non-distributed, and distributed

Multi-layer structure

It refers to dividing the application logic into three basic layers (of course, you can split these three basic layers into more layers according to the actual situation .)

Understanding of layout and tier)

Non-distributed

All components of the application system, including databases, are deployed on servers in the internal network of the enterprise (deployed on Intranet or LAN) and are deployed on a single server (deployed on a single computer) or network field (Multi-computer deployment) to complete the processing of the application system.
? Traditional B/S mode (two layers)
? Traditional C/S mode (two layers)
? Multi-layer structure based on B/S Mode
? Multi-layer structure based on the C/S Mode
In the Windows development system, there are three non-distributed system deployment solutions for B/S or C/S (enterprise applications generally do not consider adopting a two-layer structure.
? Single Computer deployment
? Legacy Interop deployment (Network farm)
? ISA Server deployment (Network farm)

Distributed

A system deployment method is used to deploy application system transactions across a wide area network (WAN), such as data reading operations on servers on a wide area network.
The distributed deployment scheme adopts a multi-layer structure, which is also called a multi-layer distributed structure.
There are three technologies for implementing distributed system deployment solutions in the Windows development system.
? DCOM [DCOM (NDR)]
? . NET Remoting [HTTP (Binary)/HTTP (SOAP)/TCP (Binary)]
? Web Services [SOAP]
There are three distributed system deployment solutions.
? External Web host/peripheral Network
? . NET to legacy Integration
? Old Interop
Related Technologies [previous Distributed Architecture: Microsoft Windows DNA (Distributed Internet Application Architecture)]