Overview
Over time, such a convention has been formed: the application is integrated into a set of components, distributed between the computer network, and runs together as part of the entire program. In the past, distributed application logic requires component / object technology, such as Microsoft® Distributed Component Object Models (DCOM), Object Management Group Public Object Request Agent Architecture (CORBA) or Sun's Remote Method (RMI) . These technologies provide a reliable, upgraded architecture to meet the growing needs of applications.
Although these components-based technologies are well operating in the intranet environment, they will encounter two large questions if they try to apply them to the Internet. First, these technologies cannot be interactive. Although these technologies can handle objects, they do not have the same details. For example, life cycle management, support for constructor, and support for inheritance. Second, more importantly, they all focus on the communication of the RPC, which typically constructs a tightly coupled system around the explicit call of the object method.
Instead, a browser-based web application is loosely coupled, with strong interoperability. They communicate with HTTP to exchange many MIME type data in different formats. Web services make traditional Web programming models for a variety of applications, not just browser-based applications. They swap SOAP messages using HTTP and other Internet protocols. Since the Web service depends on industry standards such as HTTP, XML, SOAP, and WSDL, the application's function is displayed on the Internet, so they are independent of programming languages, platforms, and devices.
The ASP.NET Web Services The infrastructure provides a simple API for web services by mapping the SOAP message to method calls. This mechanism is implemented by providing a very simple programming model (based on the SOAP message exchange mapping to method call). The client of the ASP.NET Web service does not need to understand the platform, object model, or programming language for creating them. The service does not need to understand the client to send a message. The only requirement is that both parties must recognize the format of the SOAP message being created and used, which is defined by the Web service contract definition represented using the WSDL and XML architecture (XSD).
.NET Remoting provides an infrastructure for distributed objects. It uses both flexible and scalable pipelines to provide .NET full object semantics. ASP.NET Web Services provides a very simple programming model based on messaging, while .NET Remoting provides more complex features, including supporting values or reference delivery objects, callbacks, and multi-object activation and lifecycle management strategies. To use .NET Remoting, the client needs to understand the details, in short, you need to use the .NET to establish the client. (Or other frames that support .NET Remoting, the only framework we know is the JA.NET for Intrinsyc for Java.). Net Remoting line also supports SOAP messages, but must pay attention to this does not change its client Claim. If the Remoting endpoint provides .NET dedicated object semantics, whether or not through SOAP, the client must understand them.
.NET Framework supports two distinct distributed programming models - Web services and distributed objects, which caused great chaos to developers. When should I use the ASP.NET web service, when should I use .NET Remoting? To answer this question, you must understand the working principle of these two technologies.
Serialization and metadata
All distributed communication lines eventually completed two work: seal the instance of the program data type to the message that can be transmitted over the network and provides a description of those messages. The former is done using some form of serialization engine (or a sealed removal), which is completed by some form of metadata. For example, for most (modern) DCOM interface, the serialization engine is a type library to encapsulate the removal, and the type library provides metadata. The main difference between ASP.NET Web services and .NET Remoting is how they are sequenced as messages, as well as their format selected for metadata. ASP.NET Web Services, XMLSerializer and XSD
ASP.NET Web services depends on the System.xml.Serialization.xmlSerializer class, seal data to the SOAP message at runtime and seals data from the SOAP message. For metadata, they generate WSDL and XSD definitions, indicating what kind of content included in the message. It is completely dependent on WSDL and XSD to make the ASP.NET web service metadata have portability; it represents the method of data structure, and other web service kits that use different programming models on different platforms can also be understood. In some cases, this limits the types that can be provided from the web service - XMLSerializer can only be encapsulated with data that can be represented by XSD. That is, XMLSerializer will not be able to encapsulate object graphics, and support for container types is also limited.
Although these restrictions seem to be important from the perspective of traditional distributed objects, they help ensure that interoperability with other Web service frames - this is the basic goal of loosely coupled web service models. A large-scale custom property allows you to comment the data type to control the methods of XMLSerializer to enhance the interoperability support. Therefore, you can properly control the shape of the XML generated when the object is serialized. In addition, you can adjust the ASP.NET web services to describe the message with text XSD or SOAP coding rules (ie SOAP Section 5). Text XSD is the default, and will become a standard. It also includes SOAP coding support to interoperate with existing toolkits. This is even more helpful to users, especially when users need to communicate with existing Web services or clients (they need to communicate using predefined messages).
.NET Remoting, IFORMATTER, and Public Language Runture
.NET Remoting Depending on the plus implementation program of the IFormatter interface used by the System.Runtime.Serialization Engine to encapsip the data to / from the message. There are two standard formatting procedures: system.Runtime.Serialization.formatters.binary.BinaryFormatter and System.Runtime.Soap.Formatter. As the name suggests, Binaryformatter and SOAPFormatter are encapsulated in binary and SOAP formats. For metadata, .NET Remoting relies on the public language runtime assembly, which contains all the relevant information of their implementation, and provides it by reflection. For metadata, it is more likely to retain the system fidelity of the full-running type of system. Therefore, when the .NET Remoting pipeline encapsulates data, it includes all public and proprietary members in the class, correctly handles object graphics and supports all container types (such as system.collections.hashtable). However, dependent runtime metadata also limits the range of use of the .NET Remoting system - The client must understand the .NET structure to communicate with the .NET Remoting endpoint. In addition to the plug-in formatted program, the .NET Remoting layer also supports the insertable channel that removes details about the message transmission method. There are two standard channels, an original TCP, an HTTP. The message can be used independently in the format, transmitted by any channel. Each advantageous and disadvantages: Remoting and Web services
The existence of the SOAP formatting program and the HTTP channel produces such a question: Can I use .NET Remoting to establish a web service? The answer is affirmative and negative. Standard Web Services Stacks not only depend on SOAP-based messages, but also depends on the message based on WSDL and XSD. The REMOTING line can truly generate a WSDL definition that describes the message generated by the endpoint and used. However, if you walk along this idea, you will generate a few questions.
First, the generated WSDL file is always described with SOAP coding rules instead of text XSD to describe the message. Although this is not a problem now, this problem will become more and more serious as more and more tools are completely eye-catching.
Second, the generated WSDL file includes a .NET Remoting a dedicated extension feature. For example, the following is a simple class that provides its behavior using .NET Remoting.
Public Class Methods: MarshalByrefObject
{
// Now method Returns the current date and time
Public String Now ()
{
Return system.datetime.now.tostring ();
}
}
If WSDL is generated from this class, the binding information will include .NET Remoting Details, as shown below.
Transport = 'http://schemas.xmlsoap.org/soap/http'/> 'http://schemas.microsoft.com/clr/nsassem/remsoap.Methods/Methods#now'/> ... These additional elements are legal because the WSDL specification supports scalability. Any well-operated Web Services Kit If you don't understand them, you will simply ignore them. However, some are the Web Services Kit cannot be ignored. For example, the following is a Remoting endpoint that returns Microsoft® ADO.NET System.Data.DataSet. Public Class Methods: MarshalByrefObject { Public system.data.dataset getemptyDataSet () { Return new system.data.dataset (); } } Here is the WSDL definition generated for the output message of this method: Typically, the WSDL message refers to the type defined in a specific namespace using an XML schema. But in this case, the prefix NS3 for the DataSet type name is not defined in XSD, but is implicitly defined by runtime. The prefix NS3 in this example should be bound to the XML namespace determined by the following URI: http://schemas.microsoft.com/clr/nsassem/system.data/system.data, Version=1.0.3300.0, CULTURE=NEUTRAL, PublicKeyToken=B77A5C561934E089 This WSDL defined client is to understand the special meaning of this "well-known" URI - it is a strict name of the specific rule assembly included in the .NET Framework (consisting of four parts). This WSDL is very useful for clients implemented using .NET Remoting because they can generate an agent set with information adapted to be sealed. However, for this URI and want to find other web service kits (including ASP.NET) defined for the DataSet type, this WSDL will be useless. The problem is still not resolved: Can I use .NET Remoting to establish a web service? Strictly speaking, it can be. However, can people who don't use the .NET Remoting pipeline? The answer is: Perhaps, if you carefully reduce the endpoint to the basic data type and semantic. That is, if you want to interoperate with other Web Services Kit, you need to limit the parameters to the built-in simple type and your own data type (you can't use the .NET Framework type like Dataset), and avoid the client Activated objects and events. In short, if you care about the range of use, you need to limit yourself to those support supported by the ASP.NET Web service. Or take better ways, using the ASP.NET Web service, as this is the purpose of designing their purpose. Distributed Application Design: ASP.NET Web Services and .NET Remoting ASP.NET Web Services supports XML architectural type systems, providing a simple programming model with a wide range of uses, can be used across platforms. .NET Remoting supports runtime types of systems, providing more complex programming models, narrowing. This essential difference is the main factor in which technology to use. However, there should be many other design factors, including transport protocols, host processes, security, performance, status management, and support for transactions. Transport protocol and host process Although the SOAP specification does not require HTTP as a transport protocol, the client can only access Web services implemented using the ASP.NET Web service via HTTP because it is the only transport protocol supported by ASP.NET. The service is called via IIS and is executed in ASP.NET's auxiliary process ASPNET_WP.EXE. .NET Remoting enables you to hosted a remote object in any type of application, including Windows Forms, Hosting Windows Services, Console Applications, or ASP.NET Assist Processes. As mentioned earlier, .NET Remoting provides two transmission channels - TCP and HTTP. Both channels can use sockets to provide communication between arbitrary sending and receiving processes. It also integrates HTTP channels with IIS and ASP.NET assist processes. This is very important, with the following points. First, it is the only way to start the .NET Remoting endpoint when the client requests arrives. The .NET Remoting line does not include the Service Control Manager (SCM) of the DCOM type required to start the remote server. If you provide a remote object from any process, you need to make sure those processes are running. It is also necessary to ensure that they are threaded, for example, thread A cannot activate the object after starting thread b to shut down. If you provide a remote object from ASP.NET, you can use the ASPNET_WP.EXE assist process so that you can automatically start and have a thread security advantage. Second, integration with IIS is the only way to ensure cross-process .NET Remoting, as described in the following section. ASP.NET Web services and .NET Remoting infrastructure are scalable. You can filter into the station and outbound messages, from multi-faceted control type to encapsulate and the generation of metadata. Using .NET Remoting, you can implement your own formatting programs and channels. safety Since the ASP.NET Web service depends on HTTP, they integrate with standard Internet security infrastructure. ASP.NET provides powerful support for standard HTTP verification scenarios (including basic, brief, digital certificates, and even Microsoft® .NET Passport) for standard HTTP verification scenarios. (You can also use Windows integration verification, but only the client in the trust domain.) One advantage of the available HTTP verification scheme is that there is no need to change the code in the web service, IIS is called at the ASP.NET Web service Perform verification before. ASP.NET also supports the verification and other custom verification schemes based on .NET Passport. ASP.NET supports access control based on target URLs and supports access control through integration support with .NET Code Access Security (CAS) infrastructure. SSL can be used to ensure the security of communication. Although these standard transmission technologies ensure that Web services are quite effective, they can only do this. In complex situations involving multiple web services in different trust domains, they have to establish a custom special solution. Microsoft and other companies are committed to creating a security specification that will provide a message level security feature based on SOAP messaging scalability. One of these specifications is XML Web Service Security Language (WS-Security [English]), which defines the framework for message level credentials, message integrity, and message confidentiality. As mentioned in the previous section, in general, .NET Remoting line does not ensure the safety of cross-process calls. Using ASP.NET hosting in the .NET Remoting endpoint can utilize all security features available to ASP.NET Web services, including support for ensuring wired communication using SSL. If you are using TCP channels or HTTP channels hosted in the process (rather than ASPNET_WP.exe), you must perform your authentication, authorization, and confidentiality mechanism yourself. Another security issue to be concerned is that the ability to execute code from an incompletely trusted environment without changing the default security policy. The ASP.NET Web service client agent can work in these environments, but .NET Remoting proxy cannot. To use the .NET Remoting agent from an incomplete trusted environment, special serialization permissions are required. By default, this permission will not grant code from the intranet or the Internet. If you want to use the .NET Remoting client in an incompletely trusted environment, you need to change the default security policy of the code loaded from those regions. When you connect to the system from the client running in a sandbox (such as a downloaded Windows Form), the ASP.NET Web service is a simple choice because you don't need to change the security policy. Status management By default, the ASP.NET Web service model adopts stateless service architecture; it is not related to multiple calls from the same user. In addition, each time the client calls the ASP.NET Web service, all new objects are created to serve the request. After the method call is completed, the object is destroyed. To maintain the state of the request, you can use the technology (ie, sessions and application properties packages) used by the ASP.NET page, or you can perform custom solutions. .NET Remoting supports many status management options and may be associated with multiple calls from the same user, depending on the object lifecycle architecture you selected. SINGLECALL object is stateless (such as objects used to call ASP.NET Web services), Singleton objects share all client status, client-active objects remain status on every client (all related to it The upgradeability and reliability issues). performance In terms of primitive performance, when using TCP channels and binary formatting procedures, .NET Remoting line provides the fastest communication. In almost all of our comparison ASP.NET Web services and .NET Remoting's relative performance, ASP.NET Web services exceeds .NET Remoting endpoints of SOAP formatting procedures using HTTP or TCP channels. . More more interesting is that the use of binary formatting procedures and the ASP.NET and .NET Remoting endpoints in the HTTP channel are very similar. For more information, see Performance Comparison: .NET Remoting and ASP.NET Web Services. Corporate Services ASP.NET Web services or objects provided via .NET Remoting can use local transactions to work according to a single database. If you need to work according to multiple resource coordination, it can use the .NET Enterprise Services (also known as COM ) (DTC distributed transactions managed by COM pipeline). However, it should be noted that the ASP.NET Web service and the .NET Remoting pipeline cannot propagate published transactions, so both endpoints cannot inherit the published transactions through the call to call. This is not necessarily a bad thing. Generally speaking, the published transaction is higher than the local affairs cost, and the cost will be higher. If you really need this feature, a simple solution is to expand a class derived from System.EnterpriseServices.ServicedComponent in the .NET Enterprise Server application (see COM Integration: How .NET Enterprise Services CAN Help You Build Distribute Applications The cross-trip call for this class object will be processed using DCOM to ensure proper communication environments. A more difficult solution is to use the underlying API, manually propagate distributed transactions. It is worth noting that traditional distributed transaction models generally do not apply to loosely coupled Web services. The model based on compensation transactions (ie, the transaction to undo the work) is more meaningful because its isolation constraints are not very strict. There is a common statement in a Web service provider including Microsoft, the more flexible service models needed by web service space, the more work in this space. When you define a standard approach to a Web service transaction, you can implement your own compensation architecture according to the situation, using local or published transactions. Select architecture If you are designing a .NET-based distributed application, you need to consider all the questions discussed herein, and some conclusions are obtained for the system architecture. Generally speaking, this is easier than what you imagine. But there are always some special situations that require other methods. The following is some of the general assumptions you can do, you can simplify the situation. First, use ASP.NET Web services by default. Their execution and use are very simple, can provide the client platform to use as widely as possible, and can call the ASP.NET Web service client agent code from the code running in the scruggage in the default security policy. If you want to use a distributed object model with CLR type fidelity, you do not need to interoperate with other platforms, and by controlling the configuration of the client and server, consider using .NET Remoting. If you choose .NET Remoting, it is best to integrate HTTP channels with IIS and ASP.NET, otherwise you must establish your own process lifecycle management and security infrastructure. Assuming that .NET Remoting requires a .NET client, use binary formatting programs instead of SOAP formatting programs; interoperability will not be problematic, and performance will be significantly improved. Finally, if you need a public, please use the business service (COM ). If you execute ServicesDComponents, you will be deployed in the library applicator by default by default. If they need to run on a remote computer, they are deployed in the server application. (If you need to perform a different process security token [not the token used by the ASPNet_WP.exe, even in the same computer, you may also consider using the COM server application.) The following is three common architectures based on these ideas. Figure 1: Simple 3-layer architecture Figure 1 shows a simple 3-layer architecture that has a web server field that supports a range of different clients. All server-side code is executed in the ASP.NET assist process ASPNET_WP.EXE. These three different types of clients can use the HTTP access server field. Browser-based client calls the ASP.NET web page; multi-client (such as Windows Form Application, Microsoft® Visual Basic® 6 App) and other web services use ASP.NET web services; as needed, .net Client (such as Windows Form App) and Web Services use ASP.NET Web services, or using HTTP channels and binary formatted .NET Remoting (assuming it is not in the sandbox). Figure 2: N-layer architecture using ASP.NET Some very large applications use a set of auxiliary computers to work from the outer level of the web server. This architecture is shown in Figure 2. Note that in this case, the second layer is also available through the ASP.NET. Figure 3: N-layer architecture using enterprise service (COM ) Figure 3 shows another version of this architecture that provides features that provide serviceDComponents deployed in COM . Obviously, these are not all possible architectures supported by .NET Framework. However, it provides an appropriate foundation for your system. summary Although the .NET Remoting infrastructure and ASP.NET Web services can communicate across the process, each design applies to different users. The programming model of the ASP.NET Web service is simple and wide range of use. The programming model of .NET Remoting is more complicated and the range is narrow. Be sure to understand the working principle of these two technologies and choose technology that suits your application. In any case, use IIS and ASP.NET management process life cycles and provide general security.
