.NET Remoting demo (VBRemoting)

Introduction


.NET remoting provides an abstract approach to interprocess communication that separates the remotable object from a specific client or server application domain and from a specific mechanism of communication.

.NET remoting allows an application to make a remotable object available across remoting boundaries, which includes different appdomains, processes or even different computers connected by a network. .NET Remoting makes a reference of a remotable object available to a client application, which then instantiates and uses a remotable object as if it were a local object. However, the actual code execution happens at the server-side. Any requests to the remotable object are proxied by the .NET Remoting runtime over Channel objects, that encapsulate the actual transport mode, including TCP streams, HTTP streams and named pipes. As a result, by instantiating proper Channel objects, a .NET Remoting application can be made to support different communication protocols without recompiling the application. The runtime itself manages the act of serialization and marshalling of objects across the client and server appdomains.

VBRemotingSharedLibrary contains the remote object types shared by the .NET Remoting clients and servers.

VBRemotingClient is a .NET Remoting client project. It accesses the remote objects (SingleCall objects or Singleton objects or client-activated objects) exposed by the .NET Remoting server project, VBRemotingServer.

There are generally two ways to create the .NET Remoting client: using a configuration file or writing codes. The AccessRemotingServerByConfig method demonstrates the former and the AccessRemotingServerByCode method illustrates the latter method.

VBRemotingServer is a .NET Remoting server project. It contains the following remotable objects:

1. RemotingShared.SingleCallObject

URL: tcp://localhost:6100/SingleCallService

SingleCallObject is a server-activated object (SAO) with the "SingleCall" instancing mode. Such objects are created on each method call and objects are not shared among clients. State should not be maintained in such objects because they are destroyed after each method call.

2. RemotingShared.SingletonObject

URL: tcp://localhost:6100/SingletonService

SingletonObject is a server-activated object (SAO) with the "Singleton" instancing mode. Only one object will be created on the server to fulfill the requests of all the clients; that means the object is shared, and the state will be shared by all the clients.

3. RemotingShared.ClientActivatedObject defined in the shared assembly VBRemotingSharedLibrary.DLL:

URL: tcp://localhost:6100/RemotingService

ClientActivatedObject is a client-activated object (CAO) for .NET Remoting.

Client-activated objects are created by the server and their lifetime is managed by the client. In contrast to server-activated objects, client-activated objects are created as soon as the client calls "new" or any other object creation methods. Client-activated objects are specific to the client, and objects are not shared among different clients; object instance exists until the lease expires or the client destroys the object.

There are generally two ways to create the .NET Remoting server: using a configuration file or writing codes. The CreateRemotingServerByConfig method demonstrates the former and the CreateRemotingServerByCode method illustrates the latter method.

Running the Sample

The following steps walk through a demonstration of the .NET remoting sample.

Step1. After you successfully build the VBRemotingClient and VBRemotingServer sample projects in Visual Studio 2012, you will get the console applications: VBRemotingClient.exe and VBRemotingServer.exe.

Step2. Run VBRemotingServer.exe in a command prompt to start up the server project. The command 'VBRemotingServer.exe -configfile' creates and configures the .NET Remoting server using a configuration file. The command 'VBRemotingServer.exe -code' uses code to create the .NET Remoting server with the same configuration. You can choose either one. Because VBRemotingServer uses a TCP channel, you may be prompted that Windows Firewall has blocked some features of the application. You can safely allow the access when you see the Windows Firewall dialog.

Step3. Run VBRemotingClient.exe in another command prompt to start up the client project. Similiarly, the command 'VBRemotingClient.exe -configfile' reads a configuration file and configure the remoting infrastructure for the client project to connect to the .NET Remoting server (VBRemotingServer). The command 'VBRemotingClient.exe -code' uses code to connect to the server with the same configuration. You can choose either one.

By default, VBRemotingClient creates a SingleCall server-activated object, and invokes its methods and sets properties.

SingleCallObject is a server-activated object (SAO) with the "SingleCall" instancing mode. Such objects are created on each method call and objects are not shared among clients. State is not maintained in such objects because they are destroyed after each method call. Therefore, in the above output, the FloatProperty of the SingleCall object was set to 1.2 (Set FloatProperty += 1.2), but the next retrieval of the float property still returns 0.

You can try out other types of remoting objects (e.g. Singleton object, client-activate object) by uncommenting the corresponding code lines and rebuilding the client project.

VB
Edit|Remove
' Create a SingleCall server-activated object
Dim remoteObj As New SingleCallObject()
Console.WriteLine("A SingleCall server-activated proxy is created")
' [-or-] Create a Singleton server-activated object
'Dim remoteObj As New SingletonObject()
'Console.WriteLine("A Singleton server-activated proxy is created")
' [-or-] Create a client-activated object
'Dim remoteObj As New ClientActivatedObject()
'Console.WriteLine("A client-activated object is created")

 

Step4. Exit the remoting server by pressing ENTER in the server application.

Sample Relation:

VBRemotingClient -> VBRemotingServer

VBRemotingClient is the client project of the VBRemotingServer server project.

VBRemotingServer -> VBRemotingSharedLibrary

VBRemotingServer references a shared library for the client-activated

remoting types.

Using the Code

VBRemotingServer:

1.       Adding remotable types on the service project.

For client-activated types, they must be defined in an assembly shared by both client and server projects, because client-activated types require not only the same namespace/class name on both sides, but also the same assembly.

Step1. Create a .NET class library project, exposing the type (ClientActivatedObject) that inherits MarshalByRefObject and implement the body of the type. MarshalByRefObject marks the type as a remotable type.

Step2. Add the reference to the class library in the server project.

For server-activated types, they can be either defined in a shared assembly, or defined on the server project and have an empty proxy of the type one the client projects. Please make sure that the server type and the proxy type have the same namespace/class name though it is not necessary to place them in the same assembly.

Step1. Add the server-activated types (SingleCallObject, SingletonObject) that inherits MarshalByRefObject to the server project. Implement the body ofthe types.

2.       Creating .NET Remoting server using configuration file.

Step1. Add an application configuration file to the project.

Step2. Define the channel to transport message.

Step3. Register the remotable types.

Step4. Read the configuration file and configure the remoting infrastructure for the server project. (RemotingConfiguration.Configure)

3.       Creating .NET Remoting server using code.

Step1. Specify the formatter of the messages for delivery. (BinaryClientFormatterSinkProvider, BinaryServerFormatterSinkProvider)Once message has been formatted, it is transported to other application domains through the appropriate channel. .NET comes with the SOAP formatter (System.Runtime.Serialization.Formatters.Soap) and Binary formatter (System.Runtime.Serialization.Formatters.Binary).

Step2. Create and register the channel to transport message from one project to another. (TcpChannel/HttpChannel/IpcChannel, ChannelServices.RegisterChannel)

.NET comes with three built-in channels:

TCP channel (System.Runtime.Remoting.Channels.Tcp)牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋 - good for binary

HTTP channel (System.Runtime.Remoting.Channels.Http)牋牋牋牋牋牋牋牋牋牋牋牋牋牋?- good for internet

IPC channel (System.Runtime.Remoting.Channels.Ipc)牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋 - based on named pipe

Step3. Register the remotable classes on the service project as server-activated types (aka well-known types) or client-activated types. (RemotingConfiguration.RegisterWellKnownServiceType, RemotingConfiguration.RegisterActivatedServiceType)

VBRemotingClient:

1.       Adding remotable types on the client project.

For client-activated types, they must be defined in an assembly shared by both client and server projects, because client-activated types require not only the same namespace/class name on both sides, but also the same assembly.

Step1. Add the reference to the .NET class library shared by the .NET Remoting server. The class library exposes the client-activated type (ClientActivatedObject) that inherits MarshalByRefObject.

For server-activated types, they can be either defined in a shared assembly, or defined in the server project and have en empty proxy of the type in the client projects. Please make sure that the server type and the proxy type have the same namespace/class name though it is not necessary to place them in the same assembly.

Step1. Add the proxy of the server-activated types (SingleCallObject, SingletonObject) that inherits MarshalByRefObject to the client project. There is no need to implement the body of the types.

2.       Accessing .NET Remoting server using configuration file.

Step1. Add an application configuration file to the project.

Step2. Define the channel to transport message.

Step3. Register the remotable types.

Step4. Read the configuration file and configure the remoting infrastructure for the client project. (RemotingConfiguration.Configure)

Step5. Create the remotable object.

Step6. Use the remotable object as if it were a local object.

3.       Accessing .NET Remoting server using code.

Step1. Specify the formatter of the messages for delivery. (BinaryClientFormatterSinkProvider, BinaryServerFormatterSinkProvider)Once message has been formatted, it is transported to other application domains through the appropriate channel. .NET comes with the SOAP formatter (System.Runtime.Serialization.Formatters.Soap) and Binary formatter (System.Runtime.Serialization.Formatters.Binary).

Step2. Create and register the channel to transport message according to the channel on the server project. (TcpChannel/HttpChannel/IpcChannel, ChannelServices.RegisterChannel)

Step3. Create the remotable object.

Step4. Use the remotable object as if it were a local object.

References

.NET Framework Remoting Architecture?

http://msdn.microsoft.com/en-us/library/2e7z38xb(VS.85).aspx

.NET Framework Remoting Overview?

http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.85).aspx