Brief introduction
Remote method calls have evolved to now include the following framework implementations: Dce/rpc,corba,dcom,mts/com+,java Rmi,java ejb,web services/soap/xml-rpc,net Remoting, This article mainly introduces the. NET remote method calls the principle, realizes as well as with the Microsoft com/dcom realization similarities and differences point.
Framework
Microsoft. NET Remoting provides a framework that allows an object to interact with another object through an application domain. As we all know, Web services simply provide a simple and understandable way to implement Cross-platform, cross-language interactions, and dotnet remoting is a qualitative shift from a Web service to an ASP, as opposed to CGI. Dotnet Remoting provides an extensible framework for selecting different transport mechanisms (HTTP and TCP are built into), different encoding (soap and binary), security settings (IIS or SSL), and a variety of services, including activation and lifetime support.
Remote method call
For a remote method call, the most direct question is: a local method, by extension, a local object, if placed in a network environment, how to pass the call of this method, return, how to pass this object's request. Although this is not essential for application developers, I think it should be clear for us to learn about distributed operating systems. We know that the DCOM protocol is also known as Object RPC, which is based on the DCE RPC protocol, which means that it must use a special protocol at the network transport level. In addition, the Windows RPC mechanism requires familiar types and marshaling knowledge using the IDL tool, and exposes the management of RPC client and server stubs to developers. Remoting is much easier to provide for. NET RPC, and eliminates the type mismatch (a very large threat) that existed in the early RPC mechanism due to the use of simple, understandable. NET data types. Configured to use an HTTP or TCP protocol and communicate using XML-encoded SOAP or native binary message formats. The developer can build a custom protocol (channel) or message format (formatter) and be used by the Remoting framework when needed. Both the server and the client components can choose a port, just as you can select a communication protocol. One of the benefits of this is that it's easy to build and run basic communications.
The following figure describes the five elements of. Net Remoting:
Agent: The client side is disguised as a remote objects and forwarding calls to the remote objects.
Message: Messages object contains the necessary data parameters to perform a remote methods call.
Message Sink/channel Sink: In a remote call, the messages Sink allows you to customize the messaging process, which is a built-in extensible feature of the. Net Remoting.
Formatter: Also message Sink, which is used to serialize messages that are appropriate for network transmissions, such as soap.
Transport Channel: Also message Sink, used to transmit serialized messages to remote processes, such as HTTP.
When accessing a remote objects, client-side application does not handle references to real objects, but only to methods that invoke the proxy object. The proxy object provides the same interface as the remote Objects, disguised as a remote Objects. Instead of executing any method, the proxy object forwards each method call to the. Net Remoting Framework in the form of a Message object.
In the area of type support, DCOM provides a complex set of Lie and hashing mechanisms that he builds on the basis of RPC. Because RPC is defined as part of the DCE standard, DCE RPC defines the data expression method of all the commonly used data types, that is, the network data representation. In order for stub and proxy objects to correctly set and hash the parameters and return results, they should use a consistent data representation NDR to enable remote invocation in different operating system environments.
This figure was from named Advanced. Net Remoting.
In turn, we look at. NET Remoting powerful type operations,. NET Remoting supports all managed types, classes, interfaces, enumerations, objects, and so on, which is often referred to as "multiple-type fidelity." The key here is that interoperability of data types is not a problem if both client and server components are CLR-managed objects running in the application domain. Fundamentally, what we have is a closed system where the ends of the conversation can be fully understood, so we can take advantage of this fact and handle the data types and objects used for communication.
In the case of various systems, we need to consider interoperability between systems. For interoperable data types, we have to be careful with them. For example, the definition of a WEB service data type is based on an XML schema definition (XSD) Description of the data type. Any type that can be described using XSD and can interoperate on SOAP can be used. However, it does make certain data types impossible to use.
Agent
The proxy object is disguised as a remote object and provides the same interface to the remote object locally. Client applications and applications that handle remote "real" objects (including memory references, pointers, and so on) are implemented through proxy objects. The proxy object does not, of course, complete the method call itself, and it passes the request as a message object to the. NET Framework. In this regard,. Net Remoting and DCOM are in the same mindset. When a client activates a remote object, the framework creates a local instance of the TransparentProxy class that contains the list of all classes and the interface method of the remote object. Because the TransparentProxy class is registered with the CLR when it is created, all method calls on the agent are intercepted at run time. The system examines the call to determine whether it is a valid call to the remote object and whether the instance of the remote object is in the same application domain as the proxy. If the object is in the same application domain, the simple method call is routed to the actual object, and if the object is in a different application domain, it is packaged into the IMessage object and forwarded to the RealProxy class by the Invoke method of the calling parameter in the call stack. This class (or its internal implementation) is responsible for forwarding messages to remote objects. Both the TransparentProxy class and the RealProxy class are created in the background after the remote object is activated, but only the transparentproxy is returned to the client. When a proxy object is created, a reference to the first Sink object of the Messag Sink Chain,sink Chain that references the client side is saved to the identity property of the RealProxy object. As shown in the following illustration:
So, after the following code calls new or GetObject to get the object, object obj will point to the
TransparentProxy object.
HttpChannel channel = new HttpChannel ();
ChannelServices.RegisterChannel (channel);
SomeClass obj = (someclass) Activator.GetObject (
Type of (SomeClass),
"Http://localhost:1234/SomeSAO.soap");
News
When a function call refers to a reference to a remote object, TransparentProxy creates a MessageData object and passes it to the Privateinvoke () call to the RealProxy object. RealProxy generates a new message object and calls its Initfields () method with the MessageData object as an argument, the message resolves the MessageData object to the corresponding function call. When the process ends, a imessage object containing the response message is returned, RealProxy will call its own handlereturnmessage () method, which examines the parameters and invokes the Propagateoutparameters () method. When the processing is complete, RealProxy will return from its Privateinvoke () method, and imessage will return to TransparentProxy. The CLR guarantees that the function return value matches its return format, so for an application, it simply considers this a generic method call, and returns, which is exactly the final requirement of the distribution.
As you can see, the underlying mechanism of. NET Remoting and DCOM is completely different, and a method invocation of DCOM requires the processing of a column set (marshaling) and a hash (unmarshaling), including creating proxy objects and reproducing stub code. But you can see. NET as the next generation of DCOM, in the basic ideology and DCOM is the same. In my learning to the present experience seems,. NET-oriented Web services RPC mechanism is indeed a major innovation, let's see how imessage is delivered:
This is an instance of a message passing through the transport Channel (that is, messages Sink).
The first is the HTTP request for the SOAP remote invocation:
Post/myremoteobject.soap http/1.1
user-agent:mozilla/4.0+ (compatible; MSIE 6.0; Windows 5.0.2195.0; MS. NET
What a beautiful form it looks like, completely out of the misery of parsing RPC, but I still have a problem with Microsoft sticking to the unified of Windows operating system. NET's true cross-platform nature is truly achievable.
A common Microsoft theory is that if you need to interoperate between different systems, you should choose to use a Web service method of open standards (SOAP, XML, HTTP), and using. NET Remoting is by no means an interactive solution If all the components in the various systems are CLR-hosted,. NET Remoting "may" be the right choice.
I think I missed one important question: serialization (serialization). This is the key technology for implementing cross process calls. Serialization in COM is accomplished by a column set (marshaling) and a scatter (unmarshaling). The complexity of the column set process varies depending on the parameter type, and simply entering word or float is simply a binary sequence filled into the packet, and complex parameters like pointers need to consider the entire pointer hierarchy And get all the data. A hash is a process that corresponds to a column set, and after the stub code of the remote machine accepts the column set data, the process of the rebuild stack is a hash, with at least two sets of columns and two hashes per remote call, because the return value also requires the column set to come back and scatter. One of the problems with COM is that it's too complex a complex set of parameter-passing problems to understand, not to mention the customization of the code.. NET Remoting processing of serialization is done through a formatter,. Net The Remoting framework provides you with two default Formatters,soapformatter and BinaryFormatter, all of which can be transmitted over HTTP or TCP. After the message completes the preprocessing chain of the IMessageSink object, it will reach formatter via SyncProcessMessage (). On the client side, SoapClientFormatterSink passes the imessage to the Serializemessage () method. This function sets the Transportheaders and requests its nextsink (Httpclienttransportsink), which creates a chunkedmemorystream and passes to channel sink. The real serialization begins with Corechannel.serializesoapmessage (), which creates a soapformatter and calls its serialize () method, and the following is a Obj.setvalue (42) Method's soap output
This approach is much clearer and easier to understand than COM, and is also really easy to develop, for example, we can implement a compressed sink. The following is the development of a compressionsink skeleton routines, from this point of view, COM is really out of the way.
Using System;
Using System.Runtime.Remoting.Channels;
Using System.Runtime.Remoting.Messaging;
Using System.IO;
Namespace Compressionsink
{
public class Compressionclientsink:basechannelsinkwithproperties,
IClientChannelSink
{
Private IClientChannelSink _nextsink;
Public Compressionclientsink (IClientChannelSink next)
{
_nextsink = Next;
}
Public IClientChannelSink Nextchannelsink
{
get {
return _nextsink;
}
}
public void Asyncprocessrequest (Iclientchannelsinkstack sinkstack,
public void Asyncprocessresponse (Iclientresponsechannelsinkstack sinkstack,
Object state,
ITransportHeaders headers,
Stream stream)
{
Todo:implement the post-processing
Sinkstack.asyncprocessresponse (Headers,stream);
}
Public Stream GetRequestStream (IMessage msg,
ITransportHeaders headers)
{
Return _nextsink.getrequeststream (msg, headers);
}
public void ProcessMessage (IMessage msg,
ITransportHeaders Requestheaders,
Stream Requeststream,
Out ITransportHeaders Responseheaders,
Out Stream Responsestream)
{
Todo:implement the pre-processing
_nextsink.processmessage (MSG,
Requestheaders,
Requeststream,
Out Responseheaders,
Out Responsestream);
Todo:implement the post-processing
}
}
}
Summary
That's what I've learned in a few days about. NET Remoting. My study focuses on the remote method delivery in. NET remoting, because I think this is the most critical technology for RPC. From a few days of learning, you can see that the. NET framework is indeed a technology, a very advanced framework. My only suspicion is that Microsoft's so-called platform independence, in this respect, Java may always win a chip.
This article, version 0.1, is on my blog http://blog.csdn.net/drizt/
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
