Introduction to Microsoft. NET romoting framework

Abstract: This article describes the basic principles of the Microsoft. NET romoting framework. In addition to introducing the main components that constitute the. NET romoting framework, we also introduce several methods for. Net remoting to communicate with distributed objects.

Directory
Introduction
. Net remoting object
Integrate. Net remoting objects
. Net remoting metadata and configuration file
. Net remoting Solution
Summary
Other materials
Introduction
Microsoft. NET remoting is a rich and scalable framework that enables seamless communication between objects in different AppDomains, processes, and machines .. Net remoting provides powerful and easy-to-use programming models and runtime support for transparent interactive operations. This article will look at different construction blocks of the remoting architecture and study some common solutions for applying. Net remoting .. Net remoting object can be used as a Web Service (see the msdn magazine article "programmable Web: Web services are Microsoft. the. NET Framework provides a constructor block (in English) to allow access from any client that can execute soap calls. net remoting object. For an overview of. Net remoting, read the article "Microsoft. NET remoting: technical overview )".

. Net remoting object
Three types of objects can be configured as. NET remote objects. You can select an object type based on application requirements. This section describes these objects in detail.

A single call object serves only one request. A single call object is useful when the workload of an object is limited and the state information does not have to be stored. A single call object can be configured in load balancing mode. The status information of a single call object cannot be retained between method calls.

"Single element object" can provide services for multiple clients. Therefore, you can share data by saving the status information called by the client. This type of object is useful when the client needs to clearly share data and cannot ignore the overhead of creating and maintaining objects.

"Client-activated objects (CAO)" Are server-side objects that are activated when receiving requests from the client. This method of activating server objects is similar to the traditional com coclass activation method. When the client uses the "new" operator to request a server object, an activation request message is sent to a remote application. Then, the server will create an instance of the requested class and return objref to the client application that calls it. The client will use this objref to create a proxy. The client method is called on the proxy. Objects activated by the client can save status information between method calls for specific clients (different client objects cannot be crossed. Each "new" call will return the proxy of an independent instance of the server type.

Use. Net remoting to pass objects
In. Net remoting, you can pass objects between applications in the following ways:

Used as a method call Parameter
Example: Public int myremotemethod (myremoteobject myobj)

Return Value of a method call
Example: Public myremoteobject myremotemethod (string mystring)

The value obtained by accessing the properties or fields of the. NET component.
Example: myobj. mynestedobject

For objects of Marshal by value (mbv), a complete copy is created when it is passed between applications.

When an external Al by reference (MBR) object is passed between applications, a reference to this object is created. When the object reference (objref) arrives at the remote application, it is converted into a "proxy" to return the original object.

Simple. Net remoting Server Object code example
Using system;
Using system. runtime. remoting;
Namespace myremoteservice
{
// Famous web service object
Public class myremoteobject: marshalbyrefobject
{
// Myremotemethod
Public String myremotemethod (string S)
{
Return "Hello World ";
}
}
}

Client code example for accessing this object
Using system;
Using system. runtime. remoting;
Using myremoteservice;
Public class client
{
Public static int main (string [] ARGs)
{
Channelservices. registerchannel (New httpchannel (7055 ));
// Create an instance of the myremoteobject class
Myremoteobject myobj = (myremoteobject) activator. GetObject (typeof (myremoteobject ),
"Http: // myhost: 7021/host/myremoteobject. Soap ");
Myobj. myremotemethod ("Hello World ");
Return 0;
}
}
Lease lifetime
A lease is created for objects that reference objects that are transferred outside the application. The lease has a lease time. If the lease time is 0, the lease expires and the object is disconnected from the. NET romoting framework. Once all object references in the appdomain are released, the object will be recycled when the next GC occurs. Lease controls the lifetime of the object.

The object has a default lease phase. When the client needs to maintain status information in the same server object, you can use many methods to expand the lease phase so that the object can survive.

You can set the lease time of the server object to unlimited, so that remoting will not recycle the object during the garbage collection cycle.


The client can call the remotingservices. getlifetimeservice method to obtain the lease time of the server object from the appdomain lease manager. Then, the client can call the lease. Renew method through the lease object to prolong the lease time.


The lease manager of the appdomain available for the client is the specific lease registration owner. When the remote object lease expires, the lease manager will notify the owner of the application to update the lease.


If the ilease: renewoncalltime attribute is set, the lease time is updated with the time specified by the renewoncalltime attribute each time a remote object is called.
Single call/single element object client-activated object
Client activation code (Code required by the client)
For more information, see the configuration file section.
A) activator. GetObject ()
B) New () and CFG files

The customer's cfg file references the following urls:

Foo = http: // localhost: 80/objectzone/Foo. Soap
A) activator. createinstance ()
B) New () and CFG files

The customer's cfg file references the URL of the server database and server application, and provides the object Uri. The client has built-in references to these databases:

Assembly # myobjectlibrary # objectzone #
Myobjectlibrary. Baz

Remoteapplication # objectzone #
Http: // localhost: 80/objectzone

The activation of server objects will not send activation messages on the network before the method is called for the first time. When the client creates an object and the client generates a proxy, the activation messages will be sent to the server. Constructors with parameters are supported.
The lifetime of a server object is set by the configuration on the server. the lifetime of a singlecall or Singleton can end when one of the following two events occurs:
A. the lease has expired.

B) when the customer releases a reference on the Server Object

Server Registration A) use the configuration file to specify the type (singlecall or Singleton)
B) Use registerwellknowntype () API to register the type
Use the configuration file to export the client-activated objects
For more information, see the configuration file section.

Model advantages a) You can use the basic class or interface of the server component to define the runtime metadata of the common language to compile the client.
B) It is useful to perform limited operations on the server.

C) a single call object does not save status information, so it is easy to configure in the Server Load balancer system.

D) a single element object can maintain state information among multiple customer objects
A) The server object calls are similar to the traditional com "coclass ".
B) The client can manage the lifetime of server objects more flexibly.

C) The client can pass constructor parameters to the created object.

D) The server object can retain the status information for its specific client between multiple method calls.



Integrate. Net remoting objects
. Net remoting objects can be integrated in:

Managed executable items:. Net remoting objects can be integrated into any common. Net EXE or managed service.


IIS: remoting objects can be integrated into Internet Information Server (IIS. By default, the remoting object integrated in IIS receives messages through the HTTP channel. To integrate the remoting object in IIS, you must create a virtual root directory and copy the remoting. cfg file to it. Executable files or DLL containing remote objects should be placed in the bin directory under the IIS root directory. Note that the IIS root directory name should be the same as the application name specified in the configuration file. When the application receives the first message, the remote configuration file is automatically loaded. This method can be used to provide. Net remoting objects as Web Services.
Example of the remoting. cfg file:

Name # helloservice
Wellknownobject # helloservice. Hello # helloservice/
Hello. Soap # singlecall

The format is:
Name # [name of the application]
Wellknownobject # [fulltypename] # [assemblyname] # [objecturi] # [objectmode]
. NET Component Service:. Net remoting objects can be integrated into the basic structure of. NET Component Service to utilize various COM + services, such as transactions, JIT, and object pools.
For more information, see Microsoft. NET Framework component service, section 1st ).

Channel service (system. runtime. remoting. channels)
. Net Applications and AppDomains use messages for communication .. Net "channel service" provides the underlying transmission mechanism for this communication process.

The. NET Framework provides HTTP, TCP, and SMTP channels, but third parties can also write and use their own channels. By default, HTTP and SMTP channels use soap for communication, while TCP channels use binary payload.

You can insert a channel service (using ichannel) by writing a custom channel that can be integrated into a hybrid application ).

Code example for loading channel service
Public class myremotingobj
{
Httpchannel;
Tcpchannel;
Public void myremotingmethod ()
{
Httpchannel = new httpchannel ();
Tcpchannel = new tcpchannel ();
Channelservices. registerchannel (httpchannel); // register the HTTP Channel
Channelservices. registerchannel (tcpchannel); // register the TCP Channel


}
}

Serialized formatting Program (system. runtime. serialization. formatters)
The. NET serialization formatter encodes and decodes messages between the. NET application and AppDomains. During. Net Running, there are two local formatting programs: binary (system. runtime. serialization. formatters. Binary) and SOAP (system. runtime. serialization. formatters. Soap ).

The serialized formatter is pluggable by instantiating the iremotingformatter interface and inserting it into the channel described above. In this way, you can flexibly select a combination of channels and formatting programs to adopt the most suitable solution for applications. This issue will be discussed in later sections.

For example, you can use HTTP channels and binary formatting programs (serialized binary data), or TCP channels and soap formatting programs.

Remoting Context
Context is the range of objects that share common runtime attributes. Some examples of context attributes are closely related to synchronization and threads. When the. NET object is activated, the runtime checks whether the current context is consistent. If the context is different, a new context is created. Multiple objects can be run in one context at a time, and one appdomain can have multiple contexts.

When an object in one context calls an object in another context, the call is executed through the context proxy and will be affected by the mandatory policy of the combination context attribute. The context of a new object is usually selected based on the metadata attributes of the class.

Classes that can be bound to the context are called context binding classes. The context binding class can have a special custom attribute called "context attribute. Context attributes are fully scalable. You can create these attributes and attach them to your own class. Objects bound to the context are exported from system. contextboundobject.

. Net remoting metadata and configuration file
The. NET Framework uses metadata and Assembly to store information about components, making multilingual programming technology possible .. Net remoting uses metadata to dynamically create proxy objects. The proxy object created on the client has the same members as the original class. However, the proxy object only forwards all requests to the original object during the. NET remoting runtime. The serialized formatter uses metadata to convert a method call to a payload data stream, and converts the payload data stream back to a method call.

The client can obtain the metadata required to access a remote object using the following methods:

The ". Net assembly" of the Server Object-the server object can create metadata assembly and distribute it to the client. When compiling client objects, client objects can reference these sets. This method is useful when both the client and server are hosted in a closed environment of components.


Remote objects can provide the WSDL (see the web service description language [WSDL] 1.0 [English]) file to describe the objects and their methods. All clients that can read and generate SOAP requests based on the WSDL file can call this object or use soap to communicate with it. With the soapsuds. exe tool distributed together with the. net sdk, the. NET remoting server object can generate a WSDL file with metadata functions. This method is useful when an organization wants to provide public services that all customers can access and use.


. Net users can use the soapsuds tool to download the XML architecture (generated on the server) from the server and generate source files or assemblies that only contain metadata (no code. You can compile the source file to the client application as needed. This method is often used if objects at a layer in a multi-tier application need to access remote objects at other layers.
The configuration file (. cfg file) is used to specify various remoting-specific information for a specific object. Generally, each appdomain has its own cfg file. Using the cfg file helps to achieve location transparency. The detailed information in the cfg file can also be specified through programming. The main benefit of using the cfg file is that it separates configuration information unrelated to the client code. In this way, you only need to modify the cfg file in the future, instead of editing or re-compiling the source code .. . Net remoting client and server object both use the configuration file.

A typical cfg file contains the following information and other information:

Integrate application information


Object Name


Object URI


Registered channels (you can register multiple channels at the same time)


Lease time of the Server Object
Sample configuration file (note that the XML format may be used in later versions ):

Name # myremoteapp
Myremoteobj = http: // mycompany: 80/myremoteapp/myremoteobj. Soap
Channel # system. runtime. remoting # system. runtime. remoting. channels. tcp. tcpchannel
Channel # system. runtime. remoting # system. runtime. remoting. channels. http. httpchannel
. Net remoting Solution
After learning how. Net remoting works, let's examine different solutions and analyze how to make full use of. Net remoting performance in different solutions. The following table lists possible combinations of clients and servers, as well as underlying protocols and server load by default. Note that the. NET remoting framework is scalable. You can write your own communication channels and serialized formatting programs.

Client Server payload Protocol
. NET component. NET Component soap/XML HTTP
. NET component. NET Component binary TCP
Hosted/unmanaged. NET web service soap/XML HTTP
. NET Component unmanaged traditional COM component NDR (Network Data Representation) DCOM
Unmanaged traditional COM component. NET Component NDR DCOM


Any client <->. net, using HTTP-SOAP
Web services are resources that can be addressed through URLs and return information to clients that need these resources through programming. When using Web Services, the client does not have to consider implementation details. A Web Service uses a strictly defined interface called a "contract", which is defined in the Web Service Description Language (WSDL) file. For details about WSDL, see Web Service Description Language (WSDL) 1.0 (English ).

You can integrate. Net remoting objects in IIS to use them as Web Services. Any client that can use the WSDL file can execute a soap call to a remote object according to the Conventions specified in the WSDL file. IIS uses the ISAPI extension to route these requests to the corresponding objects. In this way, remote objects can be used as Web service objects to give full play to the role of the. NET Framework infrastructure. This configuration can be used if you want programs on different platforms/environments to access objects. For more information about Web Services, see programmable Web: Web Services provide constructor blocks for the Microsoft. NET Framework ). This configuration method allows the client to access your. Net object through the firewall.



Figure 1 client example of a Web service that calls a remoting object through a HTTP-SOAP

. Net <->. net, using the SOAP-HTTP Channel
By default, the HTTP channel uses the soap formatting program. Therefore, if the client needs to access objects over the Internet, the HTTP channel can be used. Because this method uses HTTP, the client is allowed to remotely access. Net objects through the firewall. You only need to integrate these objects into IIS as described in the previous section to configure them as Web service objects. Then, the client can read the WSDL files of these objects, so that soap can communicate with the remoting object.

. Net <->. net, using the TCP Channel
By default, the TCP channel uses a binary formatting program. The formatter serializes data in binary format and uses the original socket to transmit data over the network. This method is ideal if the object is deployed in a firewall-protected closed environment. This method uses sockets to transmit binary data between objects, so the performance is better. Because it uses the TCP channel to provide objects, it has the advantage of small sales in a closed environment. This method cannot be used on the Internet due to firewall and configuration problems.



Figure 2 client example of calling remoting object between multiple machines through TCP Channel

. Net <-> unmanaged COM components <->. net
You can use the com InterOP service to call a traditional unmanaged COM component. When the. NET remoting client object creates a COM object instance, the object is provided by calling the package (RCW) during running, and RCW acts as a proxy for a real unmanaged object. These wrappers look the same as any other hosting class of the. NET client, but in fact they are only sending calls between hosted (. NET) and unmanaged (COM) code.

Similarly, you can provide the. NET remoting server object to a traditional COM Client. When a COM Client creates an instance of A. Net object, the object is provided through the com callable package (CCW), and RCW acts as a proxy for a real unmanaged object.

Both solutions use DCOM for communication. If the environment contains both traditional COM and. NET components, this interoperability will be convenient for you. For more information about this topic, see the com interoperability specification (English ).

Summary
The Microsoft. NET Framework provides a powerful, scalable, and language-independent framework for developing reliable and Scalable Distributed Systems .. The net romoting framework provides powerful means for remote interaction based on system requirements .. Net remoting implements seamless integration with Web Services, and there are some ways to provide. Net objects for multi-platform access.