Is it using the ASP.NET web service or use .NET Remoting: How to choose

Is it using the ASP.NET web service or use .NET Remoting: How to choose

Release Date: 4/1/2004

| Update Date: 4/1/2004

Establish a distributed application using Microsoft .NET

Priya Dhawan Tim Ewald Microsoft Developer Network

September 2002

Applicable to: Microsoft? ASP.NET Web Services Microsoft? Net REMOTING Microsoft? Net Remoting

Summary: Understanding how Microsoft .NET Remoting infrastructure and how Microsoft ASP.NET Web services perform cross-trip communication, understand the working principle of these two technologies, and how to select appropriate technologies for your application. (Page Page Print Page)

This page

Overview Serialization and Metadata Distributed Application Design: ASP.NET Web Services and .NET Remoting Select Architecture Structure Structure

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 needs to have component / object technology, such as a Microsoft® Distributed Component Object Model (DCOM), Object Management Group Public Object Request Agent Architecture (CORBA) or SUN 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 know all of these 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. The .NET framework supports two distinct distributed programming models - Web services and distributed objects, which causes 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.

Back to top

Serialization and metadata

All distributed communication lines must eventually do two things: Send the program data type instance to messages that can be passed on the network, and provide a description of the message style. 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 also adjust the ASP.NET web services to describe the message with a text XSD or SOAP coding rule (eg, 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-inbound implementation program of the IFormatter interface used by the System.Runtime.Serialization Engine to encapsat data. There are two formatting programs, system.runtime.serialization.formatters.binary.binaryformatter and system.Runtime.SoapFormatter. 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 features data, it includes all public and proprietary members in the class, correctly handles object graphics and supports all container types (for example, system.collections.hashtable). However, dependent runtime metadata also limits the range of use of .NET Remoting system - The client must understand that the .NET architecture can communicate with the .NET Remoting endpoint. In addition to the plug-in formatted program, the .NET Remoting layer also supports the insertable channel, which removes details of the message transmission method. There are two standard channels, an original TCP, a use of HTTP. The message can be used independently in the format, transmitted by any channel.

Stiring: Remoting and Web Services

SOAP formatting procedures and HTTP channel existers an avoiding question: Can I use .NET Remoting to establish web services? The answer is both 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 {

// the now Method Returns The Current Date and Time

Public String Now ()

{

Return system.datetime.now.tostring ();

}

}

IF you generate WSDL from this class, the binding information incruds .NET Remoting-Specific 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 named space for "Datase" type 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/nseth/system.data/system.data, Version=1.0.3300.0, CULTURE=NEUTRAL, PublicKeyToken=B77A5C561934E089 This WSDL defined client Understand the special meaning of this "well-known" URI - it is the strict name of the specific rule of runtime 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 other web service kits (including ASP.NET) defined by the schema defined for the "Datase" type, this WSDL will be useless for other Web service kits (including ASP.NET) defined for the "Datase" type.

The problem is still not resolved: Can I use .NET Remoting to establish a web service? Yes, it is strictly. However, can users who do not 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 another 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 "Datase" .NET framework type), and Avoid client activation 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.

Back to top

Distributed Application Design: ASP.NET Web Services and .NET Remoting

The ASP.NET Web Services is biased towards the XML Schema type system, providing a simple programming model for cross-platform support with wide range of use. .NET Remoting is biased towards the runtime system, providing more complicated and smaller programming models. 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 transport 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 assistance 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 thread secure, for example, thread a cannot activate the object after thread b begins to shut down the process. 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 authentication scenarios (including basic, brief, digital certificates, or even Microsoft® .NET Passport). (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 the XML Web Service Security Language (WS-Security), which defines the framework for the message level credential transfer, 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 in the process (not 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 structure; 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 status between requests, you can use the same technique (for example, session and Application property packages) used by the ASP.NET page, or you can implement custom solutions yourself.

.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 the relative performance of the ASP.NET Web service and .NET Remoting, ASP.NET Web services exceed the "SOAP formatted program of the HTTP or TCP channel" performance. Net Remoting endpoint . More interesting is, using binary formatting procedures and ASP.NET and .NET Remoting endpoints in HTTP channels are very similar. (For more information, see Performance Comparist: Net Remoting vs. 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, you can use the .NET Enterprise Services (also known as COM ) published (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 this feature is really required, a simple solution is to deploy a class derived from System.EnterpriseServices.serviceDComponent in the server application of .NET Enterprise (see COM Integration: How .Net Enterprise Services Can Help You Build Distributed 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.

Back to top

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 channel 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, a 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 run in the ASP.NET assist process aspnet_wp.exe. Three different types of clients use the HTTP access server field. Browser-based client calls an ASP.NET web page; fat client (eg, Windows Form Application, Microsoft? Visual Basic? 6 Application) and other web services use ASP.NET web services; and .NET fat customers Large (eg, Windows Form App) and Web services, like expectations, through HTTP channels and binary formatting programs (assuming it is not in a sandbox) using the ASP.NET web service or .NET Remoting. Figure 2, an 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 also provides functions via the ASP.NET.

Figure 3, using the N-layer architecture of enterprise services (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 the .NET framework. However, it provides an appropriate foundation for your system.

Back to top

summary

Although the .NET Remoting infrastructure and ASP.NET Web services can communicate across the process, each design applies to different users. ASP.NET Web services provide a simple programming model and has a wide range of use. .NET Remoting provides a more complex programming model and has a narrow use range. 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.

Go to the original English page