Released on: 4/1/2004 | updated on: 4/1/2004
Use Microsoft. NET to create distributed applications
Priya dhawan Tim Ewald Microsoft Developer Network
Applicable to: Microsoft? ASP. NET web service Microsoft? . NET Framework Microsoft? . Net remoting
Abstract:Learn how Microsoft. NET remoting infrastructure communicates with Microsoft ASP. NET web services across processes, how these two technologies work, and how to select the appropriate technology for your applications. (12 page printing)
Content on this page
Serialization and metadata
Distributed Application Design: ASP. NET web service and. Net remoting
Over time, it has formed a convention that builds applications into a group of components distributed across computer networks and runs together as part of the entire program. In the past, distributed application logic required component/object technologies, such as Microsoft? Distributed Component Object Model (DCOM), Common Object Request proxy architecture (CORBA) of Object Management Group, or remote method call (RMI) of sun ). These technologies provide a reliable and scalable architecture to meet the growing needs of applications.
Although these component-based technologies run well in the Intranet environment, if you try to apply them to the Internet, there will be two major problems. First, these technologies cannot interact with each other. Although these technologies can process objects, the details are different. For example, lifecycle management, support for constructors, and support for inheritance. Second, more importantly, they all focus on RPC communication, which usually builds a tightly coupled system around explicit calls to object methods.
On the contrary, browser-based web applications are loosely coupled with strong interoperability. They use HTTP for communication and exchange many mime-type data in different formats. Web services make traditional WEB programming models suitable for various applications, not just browser-based applications. They use HTTP and other Internet protocols to exchange soap messages. Because Web services rely on HTTP, XML, SOAP, WSDL, and other industry standards to display the functions of applications on the Internet, they are independent of programming languages, platforms, and devices.
The basic structure of ASP. NET Web Services provides simple APIs for Web Services by ing soap messages to method calls. This mechanism is implemented by providing a very simple programming model (based on ing SOAP message exchange to method calls. Clients of ASP. NET web services do not need to understand the platform, object model, or programming language used to create them. Services do not need to know the clients that send messages to them. The only requirement is that both parties should recognize the SOAP message format being created and used, which is composed of the WSDL and XML architecture (XSD) web Service Contract definition.
Net remoting provides a basic structure for distributed objects. It uses flexible and scalable pipelines to provide full object semantics of. Net to remote processes. ASP. NET Web Service provides a very simple programming model based on message transmission. net remoting provides complex functions, including passing objects, callbacks, and multi-object activation and lifecycle management policies through values or references. To use. Net remoting, the client needs to understand all the details. In short, you need to use. Net to create a client. (Or use other frameworks that support. Net remoting. the only framework we know is intrinsyc's Ja. Net for Java .). The net remoting pipeline also supports soap messages, but note that this does not change the client requirements. If the remoting endpoint provides. Net-specific object semantics, the client must understand them whether or not they are using soap.
The. NET Framework supports two completely different distributed programming models-Web Services and distributed objects, which creates great confusion for developers. When should the system use ASP. NET web services and. Net remoting be used? To answer this question, you must understand the working principles of these two technologies.
Back to header serialization and metadata
In the end, all distributed communication pipelines need to do two things: encapsulate program data-type instances into messages that can be passed over the network, and provide a description of the message style. The former is completed using a certain form of serialization engine (or called the mail collector), and the latter is completed through some form of metadata. For example, for most (modern) DCOM interfaces, the serialization engine is a type library blocker, while the Type Library provides metadata. The main difference between ASP. NET web services and. Net remoting is how they serialize data into messages and the format they select for metadata.
ASP. NET web service, xmlserializer, and XSD
ASP. NET web services depend onSystem. xml. serialization. xmlserializerClass to send data to and from soap messages during runtime. For metadata, they generate the WSDL and XSD definitions to describe the content contained in the message. Fully dependent on WSDL and XSD To Make ASP. net web service metadata is portable. It represents the data structure method and can be understood by other Web Service toolkit that use different programming models on different platforms. In some cases, this limits the types that can be provided from Web Services-XmlserializerOnly data that can be expressed by XSD can be sent. That is to say,XmlserializerObject images cannot be enclosed, and container type support is limited.
Although these limitations seem important from the perspective of traditional distributed objects, they help to ensure interoperability with other Web service frameworks-this is the basic goal of a loosely coupled web service model. A large number of custom attributes allow you to annotate data types to controlXmlserializerThe method to mail them, thus enhancing the support for interoperability. Therefore, you can carefully control the XML shape generated when the object is serialized. In addition, you can adjust ASP. Net-based web services to describe messages using text XSD or soap encoding rules (for example, section 5th of soap. Text XSD is the default and will become a standard in the future. It also supports soap encoding to facilitate interoperability with existing toolkit. This is very helpful to users, especially when users need to communicate with existing web services or clients (they need to communicate with predefined message formats.
. Net remoting, iformatter, and public Language Runtime Library
Net remoting depends onSystem. runtime. serializationTheIformatterThe interface's pluggable implementation program sends data to/from messages. There are two formatting programs,System. runtime. serialization. formatters. Binary. binaryformatterAndSystem. runtime. serialization. formatters. Soap. soapformatter. As the name suggests,BinaryformatterAndSoapformatterThe messages are respectively sent in binary and soap formats. For metadata,. Net remoting depends on the set of common language runtime libraries that contain all the information about the data types they implement and provide it through reflection. For metadata, relying on the Assembly makes it easier to retain the system fidelity of the full runtime type. Therefore, when the. NET remoting pipeline sends data, it includes all public and proprietary members in the class, correctly processes the object graphics and supports all container types (for example,System. Collections. hashtable). However, the dependency on runtime metadata also limits the scope of use of the. NET remoting system-the client must understand the. NET architecture to communicate with the. NET remoting endpoint. In addition to the pluggable formatting program, the. NET remoting layer also supports the pluggable channel, which removes the details about the message sending method. There are two standard channels, one for original TCP and the other for HTTP. Messages can be sent through any channel independently of the format.
Muddy Water: remoting and Web Services
The existence of the soap formatting program and the HTTP channel avoids the following problem: Can I use. Net remoting to create a web service? The answer is both positive and negative. The standard Web Service technology stack depends not only on soap-based messages, but also on the description of messages based on WSDL and XSD. The remoting pipeline can truly generate the WSDL definition that describes the messages generated and used by the endpoint. However, if you follow this idea, several problems will arise.
First, the generated WSDL file always uses soap encoding rules instead of text XSD to describe the message. Although this is not a problem, as more and more tools focus entirely on the architecture, this problem will become more and more serious.
Second, the generated WSDL file includes the extension function dedicated to. Net remoting. For example, the following is a simple class that uses. Net remoting to provide its behavior.
public class Methods : MarshalByRefObject
// The Now method returns the current date and time
public string Now()
If you generate WSDL from this class, the binding information includes des. Net remoting-specific details, as shown below.
<binding name='MethodsBinding' type='ns0:MethodsPortType'>
<suds:class type='ns0:Methods' rootType='MarshalByRefObject'></suds:class>
These additional elements are valid because the WSDL specification supports scalability. Any well-functioning Web Service toolkit will simply ignore them if they are not understood. However, some Web Service toolkit cannot be ignored. For example, the following is a response to Microsoft? Ado. netSystem. Data. DatasetThe remoting endpoint.
public class Methods : MarshalByRefObject
public System.Data.DataSet GetEmptyDataSet()
return new System.Data.DataSet();
The following is the WSDL definition generated for the output message of this method:
<part name='return' type='ns3:DataSet'/>
Generally, a wsdl message refers to the type defined in a specific namespace using the XML architecture. However, in this case"Dataset"Type namespace prefix NS3NoDefined in XSD, but implicitly defined at runtime. In this example, the prefix NS3 should be bound to the XML namespace determined by the following URI:
The client defined in this WSDL needs to understand the special meaning of this "well-known" URI-it is the strict name (consisting of four parts) of a specific runtime Assembly included in the. NET Framework ). This type of WSDL is very useful for clients implemented using. Net remoting, because they can generate a proxy assembly using messages suitable for sending. However, if you do not understand this Uri and want"Dataset"Type to find other Web Service Toolkit (including ASP. NET) defined by the architecture, this WSDL will be useless.
The problem persists: Can I use. Net remoting to create a web service? Yes, strictly speaking, yes. But can users who do not use the. NET remoting pipeline use them? The answer is: Maybe you can, if you are careful to reduce the endpoint to the basic data type and semantics. That is to say, if you want to interoperate with other Web Service toolkit, You need to restrict the parameters to the built-in simple type and your own data type (not available"Dataset"Such. NET Framework type), and avoid objects and events activated by the client. In short, if you are concerned about the scope of use, you need to restrict yourself to those functions supported by ASP. NET web services.
Or take a better way to use ASP. NET web services, because this is exactly the purpose of designing them.
Back to Top Distributed Application Design: ASP. NET web services and. Net remoting
ASP. NET web services prefer XML Schema systems and provide simple programming models that are widely used across platforms .. Net remoting tends to be a runtime system and provides a more complex programming model with a much smaller scope. This essential difference is the main factor that determines which technology to use. However, there are many other design factors to consider, including transport protocols, host processes, security, performance, status management, and transaction support.
Transmission protocol and host process
Although the SOAP specification does not require HTTP as the transmission protocol, the client can only access ASP through HTTP. net web service, because it is an ASP. net supports the only transmission protocol. The service is called through IIS and executed in ASP. NET's auxiliary process aspnet_wp.exe.
. Net remoting allows you to flexibly host remote objects in any type of applications (including Windows Forms, hosted Windows Services, console applications, or ASP. NET auxiliary processes. As described earlier,. Net remoting provides two transmission channels: TCP and HTTP. Both channels can use sockets to provide communication between any sending and receiving processes.
It can also integrate the HTTP channel with IIS and ASP. NET auxiliary processes. This is important for the following reasons. First, it is the only way to automatically start the. NET remoting endpoint when the client requests arrive .. The net remoting pipeline does not include the DCOM-type Service Control Manager (SCM) required to start the remote server ). If remote objects are provided from any process, ensure that those processes are running. They must also be thread-safe. For example, thread a cannot activate an object after thread B Closes the process. If you provide remote objects from ASP. NET, you can use the aspnet_wp.exe auxiliary process to enable automatic start and thread security. Second, integration with IIS is the only way to ensure cross-process. Net remoting calls, as described in the following section.
ASP. NET web services and. Net remoting infrastructures are scalable. You can filter inbound and outbound messages to control the generation of type messages and metadata. With. Net remoting, you can also implement your own formatting programs and channels.
Because ASP. NET web services depend on HTTP, they are integrated with the standard Internet security infrastructure. ASP. NET uses the security features of IIS to provide standard HTTP verification solutions (including basic, brief, digital certificates, and even Microsoft? . NET Passport) provides strong support. (Windows integration verification can also be used, but can only be used to trust clients in the domain .) One advantage of using the available HTTP verification scheme is that you do not need to change the code in the Web service. IIS performs verification before the ASP. NET web service is called. ASP. NET also supports. NET Passport-based authentication and other custom authentication schemes. ASP. NET supports access control based on the target URL, and supports access control through integration with the. NET code access security (CAS) infrastructure. SSL can be used to ensure communication security.
Although these standard transmission technologies are quite effective in ensuring web services, they can only do so. When multiple web services in different trust domains are involved, you must create custom special solutions. Microsoft and other companies are working to create a Security Specification that provides message-level security functions based on the scalability of soap messages. One of these specifications is the XML Web Service Security Language (WS-Security), which defines the framework for message-level credential transmission, message integrity, and message confidentiality.
As described in the previous section, the. NET remoting pipeline generally does not ensure the security of cross-process calls. Using ASP. NET to host. Net remoting endpoints in IIS, you can use all the security features available for ASP. NET web services, including support for SSL to ensure the security of wired communication. If you are using a TCP or HTTP channel (instead of aspnet_wp.exe) hosted in a process, you must perform authentication, authorization, and confidentiality on your own.
Another security issue to be concerned is the ability to execute code in an environment that is not fully trusted without changing the default security policy. ASP. NET web service client proxy can work in these environments, but. Net remoting proxy cannot. Special serialization permissions are required to use the. NET remoting proxy in an environment that is never fully trusted. By default, this permission is not granted to code downloaded from the Intranet or the Internet. If you want to use the. NET remoting client in an environment that is not fully trusted, you need to change the default security policy for the code loaded from those regions. When you connect to the system from a client running in a sandbox (such as a downloaded Windows Forms Application), ASP. NET web services are a simple choice because security policies do not need to be changed.
By default, the ASP. NET web service model adopts a stateless service structure. It is not instinctively related to multiple calls from the same user. In addition, each time the client calls the ASP. NET web service, a new object is created to serve the request. After the method is called, the object is destroyed. To maintain the status between requests, you can use the same technology (for example, the session and application attribute packages) on the ASP. NET page, or customize the solution by yourself.
. Net remoting supports many state management options and may be related to or irrelevant to multiple calls from the same user, depending on the object lifecycle architecture you have selected.SinglecallThe object is stateless (for example, used to call ASP. net web service object). The singleton object shares the status of all clients, the objects activated by the client are kept in the State on the basis of each client (with all related issues of scalability and reliability ).
In terms of raw performance, the. NET remoting pipeline can provide the fastest communication when using TCP channels and binary formatting programs. In our comparison ASP.. NET web service and. in almost all tests of net remoting's relative performance, Asp. the performance of the Net web service exceeds that of the soap formatting program using the HTTP or TCP channel. net remoting endpoint. More interestingly, the performance of ASP. NET and. Net remoting endpoints using binary formatting programs is very similar to that of HTTP channels. (For more information, see Performance Comparison: Net remoting vs. ASP. NET web services .)
ASP. NET web services or objects provided through. Net remoting can use local transactions to coordinate work based on a single database. If you need to coordinate the work based on multiple resources, you can use the. NET Enterprise Service (also known as COM +) published transactions (DTC distributed transactions managed by COM + pipeline ). However, ASP. NET web services and. Net remoting pipelines cannot spread published transactions. Therefore, neither of these endpoints can inherit published transactions through cross-process calls.
This is not necessarily a bad thing. In general, published transactions are more costly than local transactions, and published transactions need to be spread across processes at a higher cost. If this feature is required, a simple solution is to deploy a slaveSystem. enterpriseservices. servicedcomponentDerived classes (for more information, see COM + Integration: How. NET Enterprise Services can help you build distributed applications ). Cross-process calls to such objects are processed using DCOM to ensure correct propagation of the transaction environment. The more difficult solution is to use the underlying API to manually spread distributed transactions.
It is worth noting that the traditional distributed transaction model is generally not applicable to loosely coupled Web Services. The model based on compensation transactions (that is, revoking the transactions submitted by other firms) is more meaningful because the isolation constraints are not very strict. There is a common saying among web service providers, including Microsoft, that is, the more flexible the transaction model is required by the web service space, the more work is done in the space. When you define a standard method for Web service transactions, you can use local or published transactions as needed to implement your own compensation architecture.
Back to Top select Architecture
If you are designing a. Net-based distributed application, consider all the issues discussed in this article and draw some conclusions on the expected results of the system architecture. Generally, this is easier than you think. However, there are always some special situations that require other methods. The following are some general assumptions you can make to simplify the situation.
First, ASP. NET web services are used by default. They are easy to execute and use. They can be used as wide as possible for the client platform, and can be called from the code running in the sandbox of the default security policy.. NET web service client proxy code.
If you want to use a traditional distributed object model with CLR type fidelity, you do not need to interoperate with other platforms, and you have control over the client and server configurations, consider using. Net remoting. If you select. Net remoting, it is best to integrate the HTTP channel 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, it makes sense to use a binary formatting program instead of a soap formatting program. Interoperability will not be a problem and performance will be significantly improved.
Finally, if you want to publish a transaction, use the Enterprise Service (COM + ). If you execute servicedcomponents, they are deployed in the library application by default for performance considerations. If they need to run on a remote computer, deploy them in the server application. (If you need to execute different process security tokens [instead of the token used by aspnet_wp.exe] Code, even on the same computer, you may also need to consider using the COM + server application .)
The following are three public architecture based on these concepts.
Figure 1. A simple layer-3 Architecture
Figure 1 shows a simple layer-3 architecture with a web server domain that supports a series of different clients. All the server code runs in ASP. NET auxiliary process aspnet_wp.exe. Three different types of clients use HTTP to access the server domain. Browser-based clients call ASP. NET web pages; fat clients (such as Windows Forms applications, Microsoft? Visual Basic? 6 applications) and other Web services use ASP.. NET web service, and. net fat clients (such as Windows Forms applications) and Web services use ASP through HTTP channels and binary formatting programs (assuming it is not in the sandbox) as expected. net web service or. net remoting.
Figure 2. A layer-N architecture using ASP. NET
Some very large applications use a set of computers to share their work from the outer layer of the Web server. The integration architecture 2 is shown in. Note: In this case, the second layer also provides functions through ASP. NET.
Figure 3 using the n-layer architecture of Enterprise Services (COM +)
Figure 3 shows another version of this architecture. Its second layer uses the servicedcomponents deployed in COM + to provide functionality.
Obviously, these are not all possible architectures supported by the. NET Framework. However, it provides an appropriate basis for you to design your own system.
Back to Top Summary
Although both the. NET remoting infrastructure and ASP. NET web services can communicate across processes, each design is applicable to different users. ASP. NET Web Service provides a simple programming model and has a wide range of application .. Net remoting provides a more complex programming model with a much narrower scope. Be sure to understand how these two technologies work and select the technology that suits your application. In either case, IIS and ASP. NET are used to manage the process lifecycle and provide general security.