Applicable:
Microsoft ASP. NET Web Service
Microsoft. NET Framework
Microsoft. NET remoting
Abstract: understand the basic structure of Microsoft. NET remoting and how Microsoft ASP. NET Web Services communicate across processes, understand the working principles of these two technologies, and how they can be used for your applications. Program Select the appropriate technology.
Directory
Overview
Serialization and metadata
Distributed Application Design: ASP. NET web service and. Net remoting
Select Architecture
Summary
Overview
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) and Common Object Request proxy architecture (CORBA) of Object Management Group) or sun remote method call (RMI ). 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 Programming Language , Platform, and device.
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.
. 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.
Serialization and metadata
All the distributed communication pipelines finally complete two tasks: Mail Program Data-type instances to messages that can be transmitted over the network, and provide descriptions of those messages. 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 on the system. xml. serialization. xmlserializer class. data is sent 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 type that can be provided from the Web Service-xmlserializer can only send data that can be represented by XSD. That is to say, xmlserializer will not be able to block object images, and it has limited support for container types.
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 enable you to annotate data types to control how xmlserializer blocks them, thus enhancing 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 (that is, soap section 5. 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 on the insertable Implementation Program of the iformatter interface used by the system. runtime. serialization engine to send data to/from messages. There are two standard formatting programs: system. runtime. serialization. formatters. Binary. binaryformatter and system. runtime. serialization. formatters. Soap. soapformatter. As the name implies, binaryformatter and soapformatter are respectively delivered 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. when the net remoting pipeline sends data, it includes all the public and proprietary members in the class, correctly processes object graphics and supports all container types (such as 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 structure 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.
Advantages and disadvantages: remoting and Web Services
The existence of the soap formatting program and the HTTP Channel produces the following problem: Can I use. Net remoting to create a web service? The answer is yes and no. 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 ()
{
Return System. datetime. Now. tostring ();
}
}
If the WSDL is generated from this class, the binding information will include detailed information dedicated to. Net remoting, as shown below.
<Binding name = 'methodsbinding 'Type = 'ns0: methodsporttype'>
<Soap: Binding style = 'rpc'
Transport = 'HTTP: // schemas.xmlsoap.org/soap/http'/>
<Suds: class type = 'ns0: Methods 'roottype = 'externalbyrefobobject'>
</Suds: Class>
<Operation name = 'now '>
<Soap: Operation soapaction =
'Http: // schemas.microsoft.com/clr/nsassem/remsoap.methods/methods?now'/>
<Suds: Method attributes = 'public'/>
<Input name = 'nowrequest'>... </input>
<Output name = 'nowresponse'>... </output>
</Operation>
</Binding>
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 remoting endpoint that returns Microsoft ADO. Net System. Data. dataset.
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:
<Message name = 'Methods. getemptydatasetoutput'>
<Part name = 'Return 'Type = 'ns3: DataSet '/>
</Message>
Generally, a wsdl message refers to the type defined in a specific namespace using the XML architecture. In this case, NS3 is not defined in XSD, but is implicitly defined at runtime. In this example, the prefix NS3 should be bound to the XML namespace determined by the following URI:
Http://schemas.microsoft.com/clr/nsassem/System.Data/System.Data%2C%20Version%3D1.0.3300.0%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Db77a5c561934e089
The client defined by this WSDL wants 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, for other Web Service toolkits (including ASP. NET) that do not understand this Uri and want to find schema definitions for the dataset type, such WSDL will be useless.
The problem persists: Can I use. Net remoting to create a web service? Strictly speaking, yes. However, can people 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 (the dataset type cannot be used.. 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.
