Select the correct. net Technology [translation]

Original article from:
Microsoft. NET Distributed Applications: Integrating XML Web Services and. NET Remoting
Part II Chapter 10 Choosing the Right. NET Technology

In this book, I have always stressed the principle that every. NET technology has an ideal application environment. To build a successful distributed application, you must not only understand how to use these technologies, but also know when to use these technologies.

Internal and external systems
An internal system is a relatively private software that manages certain parts of daily tasks that must be completed in business operations. It can include Bug tracking, project management software used by the Development Department, or customer sales tracking and investment management applications. In either case, we have two options:
The. NET Remoting-based solution provides the fastest communication speed. Of course, internal systems usually do not stay in this way. If the system is successful, you usually need a bridge to provide functions (interfaces) to other systems ). For this reason, if you need to open some functions to third-party software, the XML Web Service-based solution provides a simple integration approach. The XML Web Service also provides some ASP. NET services, such as cache verification, which can improve the running efficiency or simplify coding. Regardless of which of the two technologies, the client is usually created using Windows Form. It provides a very flexible user interface that allows you to create different application types, for example, a system tray program that runs for a long time.

The functions provided to external systems (such as e-commerce stores) can be supported by ASP. NET or XML Web Service. The most important consideration is whether you need to use an offline architecture that distributes customer requests through message queues or similar technologies. If you expect a relatively concentrated high throughput during peak hours and the customer does not need to respond immediately, this offline architecture maximizes the server's processing capabilities.

Hybrid internal/external systems
Some systems combine XML Web Services with. NET Remoting. They use. NET Remoting for internal customers and use XML Web Services as interfaces for communication with third-party software or platforms. Whether this method is successful depends on whether the XML Web Service and Remote components can use the same Service Provider component to complete a process similar to weight object, such as accessing the database. Although XML Web Services and Remote components run independently of each other, they still share service provider components of the same version, as shown in 10-6.

Figure 10-6

Note: Technically, it is possible to create an object with the common nature of XML Web Services and remote objects. You only need to derive a class from externalbyrefobject to allow. NET Remoting support and add the <WebMethod> feature to create a. asmx file to expose the Web method. However, this method is absolutely not recommended. You should still separate the components. Small differences between XML Web Services and. Net Remoting in processing problems, such as serialization, will cause more trouble for future development. Therefore, we should put the shared functions into independent components.

The Common Back-End)
The weakness of a hybrid system is that it is inefficient at loading large data volumes. For example, the connection between the XML Web Service and the Remoting object cannot be pooled. In addition, because we are dealing with two repeated object implementations, load balancing will become very complex.
One solution to this problem is to create a common backend processing component through. NET Remoting, as shown in 10-7. This additional layer will cause additional cross-process communication, so it will reduce performance by a small part. However, in the long run, this structure is more scalable.

Figure 10-7

Some offline systems (Partially Disconnected System)
Some offline systems contain clients that cannot maintain long-term connection, so they cannot always interact with server components. For example, you can create a program to record the overhead of employees on frequent business trips. When the computer reconnects to the network, these expense reports will be input to the central database. Another example of an offline system is a tool assigned to a third party. For example, you can provide sales order tools for authorized merchants. However, you cannot assume that these merchants are always connected to the Internet when using the program, or that they can be connected to their intranet.
In offline systems, there are more than one method for communication. One method is to use a Message Queue (as shown in Figure 10-8). In this example, when the connection is restored, the system automatically sends messages. This method is useful, it allows you to use the same design as the client of the real-time connection System to complete the client of the offline System. Messages are sent once the operation is completed, regardless of whether the system is connected in real time or in offline systems. The only difference lies in the way messages are sent in Windows.
Figure 10-8

In other cases, you may need to develop a customized solution for special needs. You can create an application that constantly queries whether the connection is available or waits for the user to manually tell the program whether a connection is available. This method works the same way as the email program. If you send an email message offline, exit the program, and reconnect, the information will not be sent before you reload the program.
One final method is to create a dedicated Windows service to send information to the central service. This service will always allow on the computer and check whether the connection is available. If available, it will send the information stored on the client. This method is similar to message queue. However, you cannot ensure that message queue software is installed on all clients and configured correctly. This is very common.

Upgrade from COM
In today's world, distributed systems usually need to evolve from an existing COM architecture. NET makes this work relatively simple. The migration from COM to. NET is the main task, but it must follow the principle that the system can work normally in a phased manner. For most organizations, this means spending a lot of time on a mix of COM and. NET components.
When you upgrade a traditional multi-tier application, it is best to start from tracing the client application, because. the communication between the. NET client and a COM component is better than that between a COM-based client and. NET component communication is much easier. The first phase of integration should be to use ASP. NET or Windows Form to rewrite the presentation layer, 10-9. You can use the. NET built-in COM interaction support to access the COM object on the middle layer.
Figure 10-9

It is very difficult to upgrade business components because the client communicates directly with the COM layer. In addition, if the component is located on another computer, you must use Distributed COM (DCOM) for remote communication. In the next stage, place the COM interaction layer on the server, as shown in 10-10. You can use the XML service or.. NET Remoting.. NET layer. The client directly communicates with the. NET layer.. NET component connection. This component is responsible for obtaining requests and obtaining results from the lower-level COM component.
Figure 10-10

The last phase is to use the. NET component to recreate the business layer, as shown in Figure 10-11. In the best case, you should be able to deploy your components one by one. You only need to update the client code without any changes.. net xml Web Service layer or remote components.
Figure 10-11