It is also the best thing in IT design is that there are too many architectural components that can be selected. Web services and .NET Remoting are in this case, sometimes it is difficult to determine which technology should be selected for different purposes. Of course, the correct answer is the best technology for the problem to be solved. Do not use "Always use web services" or "Web service is a subset of remoting, so it is equal to all Remoting" and other instructions. This section will mainly introduce these two technologies, indicating why it is to choose this more meaningful rather than another.
ASP.NET Web Services and .NET Remoting
Let us start from the definition of the web service, the definition says the web service is the service that can be available on the Web. This definition is not very useful, and we may take it to refine it into a "addressable processing unit through SOAP and HTTP, this processing unit is described in WSDL, which can be released through UDDI." This definition is much more Because it is separated by the web service and the web server to send HTML back to the browser. In order to compare with .NET Remoting, we especially emphasize the definition of the web service, which is different from the programming services that can be provided on the Web. For example, according to our definition, you can use the remote host accessible from the client from the client through HTTP. In view of this (and emphasizing Microsoft ASP.NET Web Service implementation), what factors should be considered when selecting ASP.NET Web Services and .NET Remoting's "combination"?
Interoperability
One common Microsoft Theory is: If interoperability is required, you should choose a web service method using open standard (SOAP, XML, HTTP), and use .NET Remoting to be resolved in an interactive solution; If all components in the various systems are CLR hosted, the .NET Remoting "Possible" is the correct choice. This principle has a wide range of applications, but it is still very useful. The client of the .NET remote object should be the .NET client. If your feature must be implemented on the web (web, the Internet), the web service will be the correct choice. Of course, intranet is not subject to this restriction: all clients can be .NET clients, and do not exclude .NET Remoting in this configuration. Similarly, for the intermediate layer of the application in the firewall and directly communicate with the web layer, you can still select .NET Remoting.
Powerful type support
.NET Remoting supports all managed types, classes, interfaces, enumerations, objects, etc., which are often referred to as "multi-type fidelity". The key here is that if the client and server components are objects that are running in the application domain, the interoperability of the data type is not problematic. Fundamentally, we have a closed system, and both ends of the session can be fully understood, so we can make full use of this fact, handle data types and objects for communication.
In the case where various systems coexist, we need to consider interoperability between systems. We must be careful for interoperable data types. For example, the definition of the web service data type is based on the description of the data type based on the XML schema definition (XSD). Any types that can be described using XSD and can be used on SOAP. However, this is indeed enabled some data types that cannot be used. For example, for unsigned characters or enumerations, there is no corresponding W3C XSD representation. For different web services, the processing of the collection, the processing of exceptions and data sets is also different. Another problem is that private fields and attributes are not passed between web service calls, which is not a key issue for fields and attributes itself, but if your system requires interoperability between different technologies, it is designed and This is a factor to consider when testing the system, because it can be sent to receive it. Repeat again, if interoperability is required between different systems, you should not consider using .NET Remoting technology. If it is a closed, CLR hosted solution, you can use it.
Status management
We have seen many ways to implement status management using .NET Remoting based on activation (client activation or singleton). For .NET Remoting and Web services, manage each client's connection status by http (with unstertable timeless stateless state) is a cumbersome and unrealistic thing. However, if you need to maintain a state, Remoting provides a solution based on each object. The Web service does not provide this connection status management of each client, but provides access to the ASP.NET session and application objects.
Living management
About status management is survival management. As we have seen, transoting provides a powerful mechanism for managing the life of the remote object. Web service objects exist and disappear with the call of Web services (from conceptual speaking, both synchronization and asynchronous). In this regard, the Web Services is a single call type compared to Remoting. Remoting provides a greater level of control over the activation and termination of the remote object. This may be meaningful for your design or meaningless.
Press value call and call according to reference
The object that passes to the web service call is serialized and passed by value. Objects passing to remoting or called object itself can be passed by value or by reference. The serialized remote object method is to process on the client. These differences should be considered when you choose between Remoting and Web services. Of course, these considerations are important to you, but also depends on the nature of the problem to be solved.
Supported protocol
The Web service call is limited to the SOAP encoded XML on HTTP. Remoting can use TCP to transfer, or extend infrastructure to support custom protocols. For example, the Jhawk User Sample section on www.gotdotnet.com provides a Remoting implementation using Named Pipe.
Here is a fragment of NamedPipe readme file, which clarifies the scalability of Remoting:
By implementing an IChannel * interface, you can use the pluggable channel structure to insert the channel into .NET Remoting.
Named PIPE channel supports the following features:
* Communication via naming pipeline
* Synchronous message
* Asynchronous message
* One way message
* Callback
* Channel reception
* Channel properties
* Automatically generate pipe names
Therefore, if you need NAMED PIPE, Remoting can provide a solution. However, like SSPI NTLM authentication solutions, Microsoft does not support this solution, perhaps future Microsoft will meet this needs. performance
If performance is really critical to your design, Remoting, used TCP, indeed provides some significant performance advantages. For the results described herein, if you want to completely understand the test environment and tests that generate this result, see Performance Comparison: .NET Remoting with ASP.NET Web Services.
Here is some of the performance statistics summed up from this article:
Legend: ASMX - Web Services, Other Remoting Solutions WS represents a Windows service that integrates remote components. Figure 1: Performance statistics
The article is explained next to the performance chart, as described below:
"As shown above, for WS_TCP_BINARY, the object is configured to use TCP channels and binary formatting programs, and the host is Windows service, which is better than other distributed technology. This is because the method passes the original TCP The word transmission binary data (high efficiency than HTTP), and the data does not require encoding / decoding, thereby reducing system overhead. It can be seen that there is about 60% of the performance gap between WS_TCP_BINARY and the slowest method.
Although IIS_HTTP_BINARY is the same as the binary load generated by WS_HTTP_BINARY, it has a slower speed because there is an additional process hop from IIS (inetinfo.exe) to ASPNET_WP.EXE. The performance difference between IIS_HTTP_SOAP and WS_HTTP_SOAP is also caused.
The performance of WS_HTTP_BINARY and WS_TCP_SOAP is almost the same. Although the former has an additional system overhead of HTTP analysis, the latter has additional system overhead in SOAP analysis, but in this example, the system overhead of HTTP analysis is almost the same as the SOAP analysis system overhead.
The performance of the ASP.NET Web service is better than IIS_HTTP_SOAP and WS_HTTP_SOAP because the ASP.NET XML serialization is higher than the .NET Remoting SOAP serialization. As can be seen from the above, the performance of the ASP.NET Web service is almost the same. "
If the original speed is really very important, then this "60% performance gap" is very meaningful. The disadvantage is to integrate the server in a Windows service to use the TCP protocol (see the previous remote integration section). It effectively weighs performance security and is a method that best not used for Internet or unsafe intranet.
summary
The ASP.NET Web service is based on XML, which is used to request simple programming mode and powerful cross-platform support using HTTP (assuming their integration in IIS). It provides a certain degree of scalability by using SOAPEXTensions. For example, an encrypted data stream. Remoting's programming mode is more complicated, but in terms of protocol and message format, it has a significant advantage in terms of type fidelity, state management, and scalability. Remoting cannot be used for non-.NET clients, so the Internet client cannot be implemented directly to the remote host. Remoting cannot provide a security model when integrated outside IIS. When integrated in IIS, Remoting provides the same security features as ASP.NET, including security protocols such as SSL. If you don't need to consider interoperability with other platforms, and the client and server configuration is completely under your control, you can consider using .NET Remoting. Using Remoting, IIS integration using HTTP channels is better than non IIS integration so that it can benefit from the relevant security and scalability infrastructure. Of course, this means you have to interoperate with IIS in the solution. If this is unable to implement, then transnet "possibilities" is the difficult task that is unable to implement, which is related to the nature of the problem to be solved. Since .NET Remoting requires the use .NET client, it is necessary to use the fastest available formatting program, so that binary is selected without choosing SOAP will produce better performance. Remember the recommended recommendations of the best method of the above, use this formatting program while publishing, instead of using it during development. Summary
.NET Remoting is a valid tool used in some distributed solutions that provides scalable models in supported protocols and message formats and can provide performance advantages in specific situations. It should not be deployed directly on the Internet, and its server objects should be integrated under IIS to take advantage of the security and performance characteristics provided by IIS as the process running under its control.
For "closed" distributed solutions, the clients and servers are CLR hosting processes, and should consider using Remoting. For example, an Intranet solution uses a security TCP channel (such as IPSec) or any layer of any layer of HTTP, or through the firewall and an intermediate application component of the .NET Web layer component session. In this case, after confirming the application using the SOAP formatting program, you should select the binary formatter and HTTP channels.
For systems to interoperate with non-CLR clients, use the ASMX web service, but should be carefully handled (see powerful type support).
Please note that using TCP integration outside IIS will bring performance advantages, but you need to customize security.
Design and implementation
Realizing and configuring remoteing is a fairly easy process. In this process, first select the Remoting host, protocol, and activation mode. Please try to simplify the design and implementation process and carefully consider which interface publishing mechanism is the most meaningful for your solution. The recommended method is to release the interface as the most readily understood model, but this cannot be used to activate the object. Debugging procedures, event logs, and network monitoring are a very useful tool during the development process. When developing remote components, they can also help you.
Remoting's future
Issues that "when using remoting, when to use Web services" is difficult to answer, not to mention the definition of terms is not very clear. For example, if the definition of the web service is unclear, Remoting is likely to be configured as a Web service. Perhaps Remoting and ASMX technology will gradually fuse. But at present, we can at least reasonably explain to where to use which technique is used, as described above.
Current development focuses on providing GXA implementations for routing, security, and transaction support. This implementation is based on the use of the SOAP header, and the current direct goal is to extend the functionality of the web service. Although as described herein, from the traditional sense, GXA does not support .NET Remoting, but it supports many problems such as status and transaction management. Although the current GXA implementation can solve many of the problems faced by the Web service, its most fundamental purpose is to solve these problems in a way that does not require too high technical content. Seeing the impact of GXA's development on Web services and .NET Remoting, it will be a fun thing.
Other resources
Accessing Objects in Other Application Domains Using .NET Remoting (English)
Microsoft PAG Building Secure ASP.NET Applications, Chapter 11: Remoting Security (English)
ENTERPRISE: Remoting Reading List (English)
ASP.NET Web Services or .NET Remoting: How to choose
