.NET Remoting

. NET Remoting is a comprehensive, extensible framework for seamless communication between objects that are in different application domains or processes or on different computers. It allows so to speak, the communication between applications that reside locally on the same computer, on different computers on the same network or even on computers across networks. Remoting was incorporated into the Common Language Runtime ( CLR). This uniform interfaces are given to other technologies. NET.

The history of. NET communication

Previously, the interactive communication between programs with DCOM (Distributed COM) was done, the, easily and efficiently works on computers that are located in the same network. However, if a communication can take place over the Internet, must be taken with DCOM enormous hurdles. Furthermore, it is hardly possible to run DCOM through a firewall, because DCOM is trying to rebuild his compound on multiple ports that are usually blocked by default when a firewall.

. NET Remoting eradicates from the problems of DCOM by supporting multiple protocols.

MarshalByRefObject

With remoting, it is, as already mentioned above, it is possible to create distributed RPC-based object systems. The remoting application is very easy. The class library defines a class MarshalByRefObject is the base class for all the distributed objects. If you want to access by object reference to an instance of a class across process boundaries, it is sufficient to derive the class from MarshalByRefObject, as the following example shows:

Public class Foo: MarshalByRefObject {          ... } RPC

The basic communication in remoting systems is Remote Procedure Call ( RPC) -based. The architecture of Remoting identifies as essential elements:

  • Distributed Objects,
  • Proxies and
  • Transport channels

In this case, each of these elements is customizable and extensible. Distributed elements are unlike DCOM no longer registered in the registry of Windows, but published by a so -called service host. A service could, for example,

  • A simple console or Windows program,
  • A Windows system service or
  • Internet Information Server ( IIS).

Interfaces

Unlike DCOM interfaces of distributed objects need not be described in an IDL ( Interface Definition Language). It is possible to use interfaces or easy to transport the class of distributed objects to the clients. The use of interfaces is particularly attractive because the interface concept is an integral part of the platforms and thus can be understood by all. NET -compliant languages.

For example: a C # interface could also be represented by a Visual Basic.NET interface. It has the same effect:

Public interface IFoo {          void MachWas (string doit ); } Public Interface IFoo          Sub MachWas (ByVal doit As String) end Interface It is important that the C # interface can be implemented, for example, a Visual Basic.NET class, or vice versa. Due to the language interoperability. NET platform interfaces can completely replace to a certain degree an IDL.

Proxy objects

Proxy objects are created when activating the remote object by a client. The proxy object acts as a proxy of the remote object. It ensures that all calls sent to the proxy are forwarded to the correct remote object instance. When a client activates a remote object, the framework creates a local instance of the transparent proxy class that contains a list of all classes and the interface methods of the remote object. Since the transparent proxy class when creating the CLR is registered, all method calls are intercepted for the proxy of the CLR. Here the call is examined to determine whether it is a permissible method of the remote object and whether an instance of the remote object is in the same application domain as the proxy. If this is the case, a simple method call to the actual object is transferred. The object in another application domain is, the call parameters are packed in stacks in a IMessage object and passed to the real proxy class by calling its Invoke method. This class ( or rather an internal implementation of the class ) is responsible for forwarding the messages to the remote object. Both the Transparent Proxy class and the real proxy class are created protected when activating the remote object, but only transparent proxy is returned to the client. Transparent proxy is an internal class that can not be replaced or expanded. The real proxy class and the ObjRef class are public and can in turn be expanded and adjusted if necessary. The real proxy class is for example an ideal candidate for the implementation of load balancing, since it handles all function calls on a remote object. When Invoke is called a derived from real proxy class to retrieve information about the load of servers in the network and forward the call to the appropriate server.

Channel

On distant objects ("Remote objects" ) is accessed by means of so -called channels. Channels transport away the message to the object or from the object. There are two channels that are important: TcpChannel and HTTPChannel. These can also be derived, so that a separate channel can be created according to his needs.

Generation of distant objects

As already mentioned initially, there is the MarshalByRefObject of the class must be derived. However, there are two distinct procedures, as distant objects can be created:

  • Object creation by the server ( server -activated objects)
  • Object creation by client (client -activated objects)

For server -activated objects ( SAO) the object instances are created in the server. Alternative methods would be this:

  • Single -call object each returns a new object is created and then destroyed
  • On server farms can thus the load can be distributed
  • There is a single object instance for all clients
  • Object is created with ServerStart

For client -activated objects (CAO ) of the client generates the objects: an alternative method would be:

  • Direct generation
  • Generation via Factory ( Factory)

. NET Remoting 2.0

A newer version (. NET Remoting 2.0 ) already exists that provides support for IPv6 addresses and the exchange of generic types. Also new is the remoting IPC channel for local inter-process communication without using a network protocol stacks.

Software framework .NET Framework
18359
de