Introduction to Microsoft. NET Romoting framework
Paddy Srinivasan
Microsoft Corporation
January 2001
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 httpChannel;
TCPChannel tcpChannel;
Public void myRemotingMethod ()
{
HttpChannel = new HTTPChannel ();
TcpChannel = new TCPChannel ();
ChannelServices. RegisterChannel (httpChannel); // register the HTTP Channel
ChannelServices. RegisterChannel (tcpChannel); // register the TCP Channel