Remote Call of. Net Component Programming (1)

Remote Call of. Net Component Programming (1)

1 application domain

We know that the C # code we write is at the top of the logic architecture of the operating system, but the operating system itself does not know the C # code. It only knows the machine code. Then the program we wrote is compiled into IL after compilation. How does it run? It actually runs in a hosted environment and is supported by. NET. The operating system does not recognize IL, which requires a bridge: application domain. The processes in the operating system are resource units, and the execution and use of application domains also occupy space to use resources. Therefore, physical processes carry application domains, in addition, this bearer relationship is not one-to-one.

Figure: application domain

Using an application domain mechanism has many advantages. For example, a client can create an application domain when calling other components, and then load components in the newly created application domain for operations, even if some fatal errors occur to the called components, the client will not crash and error isolation is effectively implemented. There are also some performance differences in interactive data transmission, which are not described in detail here.

2. NET Remoting

. NET Remoting is a distributed system framework based on the. NET platform. It is used for data transmission. To put a few words, it has a lot of limitations and is limited by the platform. Of course, if it is just like this, it cannot be negated by its powerful and almost infinitely scalable framework system, you can implement custom functions at any stage. I will explain it later.

3. AppDomain

In. the AppDoMain class is used to represent the application domain, and the method to obtain the current application domain is also provided, you can directly use the static attribute CurrentDomain of the AppDoMain class to obtain the application domain of the current program. This is a method and an additional method is provided, that is, GetDomain () of the Thread class () static methods can also be obtained.

3.1 create an object in the current application domain

 1 namespace RemoteServer 2   public class class1 3     { 4         private string appDoMainName; 5  6         public class1() 7         { 8             appDoMainName = AppDomain.CurrentDomain.FriendlyName; 9         }10 11         public void Writer()12         {13             Console.WriteLine(appDoMainName);14         }15     }

In class1, the constructor is used to obtain the name of the current application domain and output it to the console interface in the Writer () method,

using RemoteServer;namespace RemoteCase{            AppDomain appDoMain = AppDomain.CurrentDomain;            class1 cls1 = (class1)appDoMain.CreateInstanceFromAndUnwrap("RemoteServer.dll", "RemoteServer.class1");            cls1.Writer();}

Figure 3-1

The static method CreateInstanceFromAndUnwrap () in AppDomain is used here. Because the RemoteServer assembly has been referenced in the current project, the first parameter is only a display name, not a full path, when a method is called, the application domain loads the Assembly for obtaining metadata.

3.2 Create an object in the new application domain

 1 namespace RemoteServer 2       public class class1:MarshalByRefObject 3       { 4         private string appDoMainName; 5  6         public class1() 7         { 8             appDoMainName = AppDomain.CurrentDomain.FriendlyName; 9         }10 11         public void Writer()12         {13             Console.WriteLine(appDoMainName);14         }15       }

1 using RemoteServer;2 3       AppDomain appDoMain = AppDomain.CurrentDomain;4       AppDomain newDoMain = AppDomain.CreateDomain("NewDoMain");5       class1 cls1 = (class1)newDoMain.CreateInstanceFromAndUnwrap("RemoteServer.dll", "RemoteServer.class1");6       cls1.Writer();

Figure 3-2

3.3 unpackage Remote Object

Figure 3-3-1

This code is the code in section 3.2. cls1 is not a class1 type, but a proxy. It is done by accessing remote objects through a proxy. NET, of course, provides optimization to separate the creation of remote objects from the creation of proxy on the client, so that you can create a proxy after creating a remote object. The AppDomain class provides a set of CreateInstance () methods to create objects, but all return a remote object handle in the form of ObjectHandle (that is, the unique identifier of the remote object, which can represent the remote object)

The ObjectHandle object implements the IObjectHandle interface in the System. Runtime. Remoting namespace:

 1 namespace RemoteServer 2 public class class1:MarshalByRefObject 3     { 4         private string appDoMainName; 5  6         public class1() 7         { 8             appDoMainName = AppDomain.CurrentDomain.FriendlyName; 9         }10 11         public void Writer()12         {13             Console.WriteLine(appDoMainName);14         }15 16     }

 1 using RemoteServer; 2  3             AppDomain appDoMain = AppDomain.CurrentDomain; 4             AppDomain newDoMain = AppDomain.CreateDomain("NewDoMain"); 5             IObjectHandle objecthandle; 6             objecthandle = newDoMain.CreateInstance("RemoteServer", "RemoteServer.class1"); 7  8             RemoteServer.class1 cls1 = objecthandle.Unwrap() as RemoteServer.class1; 9 10             cls1.Writer();

Generally, you do not need to manually unpack the object handle. The advantage of this is that the RemoteServer assembly can be postponed, only in objecthandle. A proxy is created only when Unwrap () is created, and object metadata is required to create a proxy.

4. Remote Object Type

Generally, the referenced object is in the same application domain as the client. In this case, no proxy is involved and no remote call is used,

Instead, it directly references objects. What if you need to call objects in another application domain? By default,. NET does not allow cross-application domain access,

Whether in the same process or not. However, if access is required, it is not impossible.. NET provides two data transmission methods: Value transmission and reference transmission.

4.1 send by value

When application domain A calls an object in application domain B, the object in application domain B will be copied and cloned to application domain A. At this time, there is no relationship between the two objects, this situation is called value-based delivery. Generally, the type uses the Serializable feature. serialization is supported to achieve value-based delivery through serialization. In this case, the caller serializes the data, to the caller for deserialization.

4.2 reference mails

In this case, when application domain A calls the object of application domain B, application domain A obtains the object reference in application domain B,

Where is this reference? Hanging on the object proxy of application domain A, it is more interesting to send A reference mail to A reference mail than to send A value mail. To meet the requirements of A reference mail, the object must inherit from the MarshalByRefObject type. the explanation given by the MarshalByRefObject type is that the object can be accessed across application domain boundaries in applications that support remote processing, in this way, as its subclass, it also enjoys such preferential treatment. There are two remote object activation modes in the reference mail. This content will have detailed sample code in the next section.

 

 

 

Author: Jin Yuan

Source: http://www.cnblogs.com/jin-yuan/

The copyright of this article is shared by the author and the blog Park. You are welcome to reprint this article. However, you must keep this statement without the author's consent and go to the Article Page.