Einführung in Microsoft .NET Remoting Framework

Paddy Srinivasan
Microsoft Corporation

Zusammenfassung: In diesem Artikel werden die Grundlagen von Microsoft .NET Remoting Framework erläutert. Zusätzlich zur Beschreibung der Standard Komponenten, aus denen .NET Remoting Framework besteht, werden in diesem Dokument verschiedene Szenarien beschrieben, in denen .NET Remoting für die Kommunikation mit verteilten Objekten verwendet werden kann. (11 gedruckte Seiten)

Hinweis Dieser Artikel enthält aktualisierten Beta 2-Code.

Inhalte

Einführung
.NET-Remotingobjekte
Hosten von .NET-Remotingobjekten
.NET-Remotingmetadaten und -Konfigurationsdateien
.NET-Remotingszenarien
Zusammenfassung
Weitere Informationen

Einführung

Microsoft® .NET Remoting bietet ein umfassendes und erweiterbares Framework für Objekte, die sich in verschiedenen AppDomains, in verschiedenen Prozessen und auf verschiedenen Computern befinden, um nahtlos miteinander zu kommunizieren. .NET Remoting bietet ein leistungsstarkes, aber einfaches Programmiermodell und Laufzeitunterstützung, um diese Interaktionen transparent zu machen. In diesem Artikel werfen wir einen Blick auf die verschiedenen Bausteine der Remoting-Architektur und untersuchen einige der gängigen Szenarien, in denen .NET-Remoting genutzt werden kann. Eine Übersicht über .NET-Remoting finden Sie im Artikel Microsoft .NET Remoting: Eine technische Übersicht.

.NET-Remotingobjekte

Es gibt drei Objekttypen, die als .NET-Remoteobjekte konfiguriert werden können. Sie können den Typ des Objekts abhängig von den Anforderungen Ihrer Anwendung auswählen. In diesem Abschnitt werden die folgenden Objekte ausführlich erläutert:

• Einzelner Anruf
  Single Call Objects service one and only one request coming. Einzelne Aufrufobjekte sind in Szenarien nützlich, in denen die Objekte eine begrenzte Menge an Arbeit erledigen müssen. Einzelne Aufrufobjekte sind in der Regel nicht erforderlich, um Zustandsinformationen zu speichern, und sie können keine Zustandsinformationen zwischen Methodenaufrufen enthalten. Einzelne Aufrufobjekte können jedoch auf Eine Art und Weise mit Lastenausgleich konfiguriert werden.
• **Singleton-Objekte
  **Singleton-Objekte sind Objekte, die mehrere Clients bedienen und daher Daten gemeinsam nutzen, indem Zustandsinformationen zwischen Clientaufrufen gespeichert werden. Sie sind nützlich in Fällen, in denen Daten explizit zwischen Clients freigegeben werden müssen, und auch in denen der Aufwand für das Erstellen und Verwalten von Objekten erheblich ist.
• **Clientaktivierte Objekte (CAO)
  **Clientaktivierte Objekte (CAO) sind serverseitige Objekte, die auf Anforderung des Clients aktiviert werden. Diese Art der Aktivierung von Serverobjekten ist der klassischen COM-Coklassenaktivierung sehr ähnlich. Wenn der Client eine Anforderung für ein Serverobjekt mit dem Operator "new" übermittelt, wird eine Aktivierungsanforderungsnachricht an die Remoteanwendung gesendet. Der Server erstellt dann eine instance der angeforderten Klasse und gibt eine ObjRef an die Clientanwendung zurück, die sie aufgerufen hat. Anschließend wird auf clientseitiger Seite mithilfe von ObjRef ein Proxy erstellt. Die Methodenaufrufe des Clients werden auf dem Proxy ausgeführt. Vom Client aktivierte Objekte können Zustandsinformationen zwischen Methodenaufrufen für den jeweiligen Client und nicht für verschiedene Clientobjekte speichern. Jeder Aufruf von "new" gibt einen Proxy an eine unabhängige instance des Servertyps zurück.

Übergeben von Objekten mithilfe von .NET-Remoting

In .NET Remoting können Objekte auf folgende Weise von einer Anwendung an eine andere übergeben werden:

1. Als Parameter in Methodenaufrufen

   Beispiel: public int myRemoteMethod(MyRemoteObject myObj)

2. Rückgabewert von Methodenaufrufen

   Beispiel: public MyRemoteObjectmyRemoteMethod(String myString)

3. Werte, die sich aus dem Eigenschafts- oder Feldzugriff einer .NET-Komponente ergeben

   Beispiel:myObj.myNestedObject

Für Objekte, die Marshall by Value (MBV) sind, wird eine vollständige Kopie des Objekts erstellt, wenn das Objekt von einer Anwendung an eine andere übergeben wird.

Für Objekte, die Marshall by Reference (MBR) sind, wird ein Verweis auf das -Objekt erstellt, wenn es von einer Anwendung an eine andere übergeben wird. Wenn der Objektverweis (ObjRef) in der Remoteanwendung eintrifft, wird er in einen "Proxy" zurück zum ursprünglichen Objekt umgewandelt.

Beispielcode für ein einfaches .NET Remoting-Serverobjekt

using System;
using System.Runtime.Remoting;
namespace myRemoteService
{
    // Well Known Web Service object
    public class myRemoteObject : MarshalByRefObject
    {
        // Method myRemoteMethod
        public String myRemoteMethod(String s) 
        {
         return "Hello World";
        }
    }
}

Beispielclientcode für den Zugriff auf dieses Objekt

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using myRemoteService;
public class Client
{
    public static int Main(string[] args)
    {
        ChannelServices.RegisterChannel(new HttpChannel());
      // Create an instance of a myRemoteObject class 
   myRemoteObject myObj = ( myRemoteObject)Activator.GetObject(typeof(myRemoteObject),
            "http://myHost:7021/host/myRemoteObject.soap");
      myObj. myRemoteMethod ("Hello World");
        return 0;
    }
}

Leasebasierte Lebensdauer

Für Objekte mit Objektverweise, die außerhalb der Anwendung transportiert werden, wird eine Lease erstellt. Der Mietvertrag hat eine Leasezeit; Wenn die Lease null erreicht, läuft sie ab, und das Objekt wird vom .NET Remoting Framework getrennt. Nachdem alle Verweise auf das Objekt in der AppDomain freigegeben wurden, wird das Objekt bei der nächsten Garbage Collection erfasst. Die Lease steuert die Lebensdauer des Objekts.

Objekte verfügen zwar über einen Standardmäßigen Leasezeitraum, aber es gibt viele Möglichkeiten, den Leasezeitraum zu verlängern, um das Objekt am Leben zu halten, falls der Client den Zustand im selben Serverobjekt beibehalten möchte.

1. Das Serverobjekt kann seine Leasezeit auf unendlich festlegen, wodurch Remoting angewiesen wird, es während der Garbage Collection-Zyklen nicht zu sammeln.
2. Der Client kann die RemotingServices.GetLifetimeService-Methode aufrufen, um die Lease des Serverobjekts aus dem Lease-Manager der AppDomain abzurufen. Über das Lease-Objekt kann der Client dann die Lease.Renew-Methode aufrufen, um die Lease zu erweitern.
3. Der Client kann einen Sponsor für die spezifische Lease beim Lease-Manager der AppDomain registrieren. Wenn die Lease des Remoteobjekts abläuft, ruft der Lease-Manager den Sponsor zurück, um eine Leaseverlängerung anzufordern.
4. Wenn die ILease::RenewOnCallTime-Eigenschaft festgelegt ist, wird bei jedem Aufruf des Remoteobjekts die Lease um den von der RenewOnCallTime-Eigenschaft angegebenen Zeitraum verlängert.

Hosten von .NET-Remotingobjekten

.NET Remoting-Objekte können in gehostet werden:

1. **Verwaltete ausführbare Datei
   **NET Remoting-Objekte können in jeder regulären .NET-EXE oder einem verwalteten Dienst gehostet werden.

2. **IIS
   **Remotingobjekte können in Internet Information Server (IIS) gehostet werden. Remotingobjekte, die in IIS gehostet werden, empfangen standardmäßig Nachrichten über den HTTP-Kanal. Zum Hosten von Remotingobjekten unter dem IIS muss ein virtueller Stamm erstellt und eine "remoting.config"-Datei kopiert werden. Die ausführbare Datei oder DLL, die das Remoteobjekt enthält, sollte im Verzeichnis bin unter dem Verzeichnis platziert werden, auf das der IIS-Stamm verweist. Beachten Sie, dass der IIS-Stammname mit dem in den Konfigurationsdateien angegebenen Anwendungsnamen identisch sein sollte. Die Remoting-Konfigurationsdatei wird automatisch geladen, wenn die erste Nachricht in der Anwendung eingeht. Auf diese Weise können .NET Remoting-Objekte als Webdienste verfügbar gemacht werden.

   Beispieldatei Remoting.cfg:

   <configuration>
     <system.runtime.remoting>
       <application name="RemotingHello">
   
         <service>
           <wellknown mode="SingleCall" 
                      type="Hello.HelloService, Hello" 
                      objectUri="HelloService.soap" />
         </service>
   
         <channels>
           <channel port="8000" 
   type="System.Runtime.Remoting.Channels.Http.HttpChannel, 
   System.Runtime.Remoting" />
         </channels>
   
       </application>
     </system.runtime.remoting>
   </configuration>
   

3. **.NET-Komponentendienste
   **NET Remoting-Objekte können in der .NET-Komponentendienstinfrastruktur gehostet werden, um die verschiedenen COM+-Dienste wie Transaktionen, JIT und Objektpooling zu nutzen.

   Weitere Informationen finden Sie unter Microsoft .NET Framework Component Services, Part 1.

Kanaldienste (System.Runtime.Remoting.Channels)

.NET-Anwendungen und AppDomains kommunizieren über Nachrichten miteinander. .NET Channel Services stellt den zugrunde liegenden Transportmechanismus für diese Kommunikation bereit.

Die .NET Framework stellt die HTTP- und TCP-Kanäle bereit, aber Drittanbieter können ihre eigenen Kanäle schreiben und anschließen. Der HTTP-Kanal verwendet SOAP standardmäßig für die Kommunikation, während der TCP-Kanal standardmäßig binäre Nutzlast verwendet.

Die Kanaldienste können (mithilfe von IChannel) mit benutzerdefinierten Kanälen, die geschrieben werden können, um heterogene Anwendungen zu integrieren, pluggable (mit IChannel).

Beispielcode zum Laden der Kanaldienste

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  


    }
} 

Serialisierungsformatierer (System.Runtime.Serialization.Formatters)

.NET-Serialisierungsformatierer codieren und decodieren die Nachrichten zwischen .NET-Anwendungen und AppDomains. Es gibt zwei native Formatierer in der .NET-Runtime, nämlich Binary(System.Runtime.Serialization.Formatters.Binary) und SOAP (System.Runtime.Serialization.Formatters.Soap).

Die Serialisierungsformatierer können durch Implementieren der IRemotingFormatter-Schnittstelle und Einstecken in den oben genannten Kanal integriert werden. Dieser Prozess, der in einem späteren Abschnitt dieses Dokuments erläutert wird, bietet die Flexibilität, die Kombination aus einem Kanal und einem Formatierer auszuwählen, der am besten zu Ihren Anwendungen passt.

Beispiel: Sie können http-Kanal mit dem Binärformatierer verwenden, der Binärdaten serialisiert, und tcp-Kanal mit SOAP-Formatierung.

Remotingkontexte

Ein Kontext ist eine Grenze, die Objekte enthält, die Common Runtime-Eigenschaften gemeinsam nutzen. Beispiele für Kontextattribute sind Synchronisierung und Threadaffinität. Wenn ein .NET-Objekt aktiviert wird, überprüft die Runtime, ob der aktuelle Kontext kompatibel ist. Andernfalls wird ein neuer Kontext erstellt. In einem Kontext können mehrere Objekte gleichzeitig ausgeführt werden, und eine AppDomain kann mehrere Kontexte enthalten.

Jeder Aufruf eines Objekts in einem Kontext an ein Objekt in einem anderen Kontext durchläuft einen Kontextproxy und wird von der Richtlinie beeinflusst, die die kombinierten Kontexteigenschaften erzwingen. Der Kontext eines neuen Objekts wird in der Regel basierend auf Metadatenattributen für die Klasse ausgewählt.

Klassen, die an einen Kontext gebunden werden können, werden als kontextgebundene Klassen bezeichnet. Kontextgebundene Klassen können mit speziellen benutzerdefinierten Attributen zugeordnet werden, die als Kontextattribute bezeichnet werden. Kontextattribute sind vollständig erweiterbar, und Sie können diese Attribute erstellen und an Ihre Klasse anfügen. Objekte, die an einen Kontext gebunden sind, leiten sich von System.ContextBoundObject ab.

.NET Remotingmetadaten und Konfigurationsdateien

Metadaten

Die .NET Framework verwendet Metadaten und Assemblys, um Informationen zu Komponenten zu speichern und sprachübergreifende Programmierung zu ermöglichen. .NET Remoting verwendet Metadaten, um Proxyobjekte dynamisch zu erstellen. Die Proxyobjekte, die auf der Clientseite erstellt werden, verfügen über dieselben Member wie die ursprüngliche Klasse. Die Implementierung des Proxyobjekts leitet jedoch einfach alle Anforderungen über die .NET Remoting Runtime an das ursprüngliche Objekt weiter. Der Serialisierungsformatierer verwendet Metadaten, um Methodenaufrufe in den Nutzlastdatenstrom und zurück zu konvertieren.

Der Client kann die Metadateninformationen abrufen, die für den Zugriff auf das Remoteobjekt erforderlich sind, auf folgende Weise:

1. Die .NET-Assembly des Serverobjekts: Das Serverobjekt kann eine Metadatenassembly erstellen und an die Clients verteilen. Das Clientobjekt kann beim Kompilieren des Clientobjekts auf die Assembly verweisen. Dies ist sehr nützlich in geschlossenen Szenarien, in denen client- und serverseitig verwaltete Komponenten sind.
2. Das Remotingobjekt kann eine WSDL-Datei (siehe Web Services Description Language( WSDL) 1.1) bereitstellen, die das Objekt und seine Methoden beschreibt. Jeder Client, der SOAP-Anforderungen entsprechend der WSDL-Datei lesen und generieren kann, kann dieses Objekt aufrufen und mit SOAP kommunizieren. .NET Remoting Server-Objekte können das tool SOAPSUDS.EXE verwenden, das im Lieferumfang des .NET SDK enthalten ist, um WSDL-Dateien zu generieren, die als Metadaten dienen können. Dies ist nützlich, wenn ein organization einen öffentlichen Dienst bereitstellen möchte, auf den jeder Client zugreifen und diesen verwenden kann.
3. .NET-Clients können das SOAPSUDS-Hilfsprogramm verwenden, um das XML-Schema vom Server herunterzuladen (auf dem Server generiert), um Quelldateien oder eine Assembly zu generieren, die nur Metadaten und keinen Code enthält. Die Quelldateien können optional in die Clientanwendung kompiliert werden. Diese Methode ist nützlich in einer Anwendung mit mehreren Ebenen, in der Objekte von einer Ebene auf Remoteobjekte in einer anderen Ebene zugreifen möchten.

Konfigurationsdateien

Konfigurationsdateien (.config Dateien) werden verwendet, um die verschiedenen Remoting-spezifischen Informationen für ein bestimmtes Objekt anzugeben. Normalerweise verfügt jede AppDomain über eine eigene Konfigurationsdatei. Die Verwendung von Konfigurationsdateien trägt dazu bei, Standorttransparenz zu erzielen. Details, die in den Konfigurationsdateien angegeben sind, können auch programmgesteuert ausgeführt werden. Der Standard Vorteil der Verwendung von Konfigurationsdateien besteht darin, dass sie die Konfigurationsinformationen trennen, die für den Clientcode transparent sind, sodass zukünftige Änderungen nur durch Ändern der Konfigurationsdatei vorgenommen werden können, anstatt die Quelldatei zu bearbeiten und neu zu kompilieren. Konfigurationsdateien werden sowohl von .NET Remoting-Client- als auch von Serverobjekten verwendet.

Eine typische Konfigurationsdatei enthält unter anderem die folgenden Informationen:

1. Informationen zur Hostanwendung
2. Name der Objekte
3. URI der Objekte
4. Kanäle, die registriert werden (Mehrere Kanäle können gleichzeitig registriert werden)
5. Leasezeitinformationen für Serverobjekte

Im Folgenden finden Sie eine Beispielkonfigurationsdatei (beachten Sie, dass dieses Format in zukünftigen Versionen möglicherweise in XML geändert wird):

<configuration>
  <system.runtime.remoting>
    <application name="HelloNew">

      <lifetime leaseTime="20ms" sponsorshipTimeout="20ms" 
renewOnCallTime="20ms" />  

      <client url="https://localhost:8000/RemotingHello">
        <wellknown type="Hello.HelloService, MyHello" 
      url="https://localhost:8000/RemotingHello/HelloService.soap" />
        <activated type="Hello.AddService, MyHello"/>
      </client>
      
      <channels>
        <channel port="8001" 
      type="System.Runtime.Remoting.Channels.Http.HttpChannel, 
      System.Runtime.Remoting" />
      </channels>
      
    </application>
  </system.runtime.remoting>
</configuration>

.NET Remotingszenarien

Nachdem wir nun mit einem Verständnis der Funktionsweise von .NET Remoting ausgestattet sind, sehen wir uns verschiedene Szenarien an und untersuchen, wie .NET Remoting in jedem dieser Szenarien am besten eingesetzt werden kann. Die folgende Tabelle enthält eine Liste möglicher Client-Server-Kombinationen zusammen mit dem zugrunde liegenden Protokoll und der Nutzlast, die standardmäßig verwendet wird. Bitte beachten Sie, dass .NET Remoting Framework erweiterbar ist und es möglich ist, Ihren eigenen Kommunikationskanal und Serialisierungsformatierer zu schreiben.

ANY Client <–> .NET using HTTP-SOAP

Ein Webdienst ist eine URL-adressierbare Ressource, die programmgesteuert Informationen an Clients zurückgibt, die ihn verwenden möchten. Clients können Webdienste verwenden, ohne sich um ihre Implementierungsdetails kümmern zu müssen. Webdienste verwenden wohldefinierte Schnittstellen, die als Verträge bezeichnet werden, die mithilfe einer WSDL-Datei (Web Services Description Language) beschrieben werden. Weitere Informationen zu WSDL finden Sie unter Web Services Description Language (WSDL) 1.0.

.NET Remoting-Objekte können als Webdienst verfügbar gemacht werden, indem sie in IIS gehostet werden. Jeder Client, der eine WSDL-Datei nutzen kann, kann SOAP-Aufrufe des Remoteobjekts gemäß dem in der WSDL-Datei angegebenen Vertrag ausführen. IIS leitet die Anforderung mithilfe von ISAPI-Erweiterungen an das entsprechende Objekt weiter. Daher kann das Remoting-Objekt als Webdienstobjekt fungieren und die umfangreiche .NET Framework Infrastruktur nutzen. Diese Konfiguration ist nützlich, wenn Sie möchten, dass Programme von unterschiedlichen Plattformen/Umgebungen auf Ihre Objekte zugreifen. Weitere Informationen zu Webdiensten finden Sie unter Programmierbares Web: Webdienste stellt Bausteine für die Microsoft-.NET Framework bereit. Diese Konfiguration erleichtert Clients den Zugriff auf Ihre .NET-Objekte über die Firewall.

Abbildung 1. Beispiel für den Aufruf des Webdiensts eines Remotingobjekts über HTTP-SOAP

.NET<->.NET mithilfe des SOAP-HTTP-Kanals

Der HTTP-Kanal verwendet standardmäßig den SOAP-Formatierer und kann daher in Szenarien verwendet werden, in denen Clients über das Internet auf die Objekte zugreifen. Da bei diesem Ansatz HTTP verwendet wird, wird der Remotezugriff auf .NET-Objekte über eine Firewall durch diese Konfiguration aktiviert. Objekte, die auf diese Weise verfügbar gemacht werden, können einfach als Webdienstobjekte konfiguriert werden, indem sie diese Objekte einfach in IIS hosten, wie im vorherigen Abschnitt erläutert. Clients können dann die WSDL-Dateien dieser Objekte lesen, um mit dem Remote-Objekt mithilfe von SOAP zu kommunizieren.

.NET<->.NET Mithilfe des TCP-Kanals

Der TCP-Kanal verwendet standardmäßig den Binärformatierer. Dieser Formatierer serialisiert die Daten in binärer Form und verwendet unformatierte Sockets, um Daten über das Netzwerk zu übertragen. Diese Methode ist ideal, wenn Ihr Objekt in einer geschlossenen Umgebung innerhalb der Grenzen einer Firewall bereitgestellt wird. Dieser Ansatz ist optimiert, da Sockets verwendet werden, um binäre Daten zwischen Objekten zu kommunizieren. Die Verwendung des TCP-Kanals zum Verfügbarmachen Ihres Objekts bietet den Vorteil eines geringen Mehraufwands in geschlossenen Umgebungen. Dieser Ansatz kann aufgrund von Firewall- und Konfigurationsproblemen nicht über das Internet verwendet werden.

Abbildung 2. Beispiel für den Aufruf eines Remoting-Objekts über Computergrenzen hinweg durch einen Client mithilfe des TCP-Kanals

.NET <–> Nicht verwaltete COM-Komponente <–> .NET

Es ist möglich, nicht verwaltete klassische COM-Komponenten über COM Interop Services aufzurufen. Wenn das .NET Remoting-Clientobjekt eine instance eines COM-Objekts erstellt, wird das Objekt über einen runtime callable wrapper (RCW) verfügbar gemacht, der als Proxy für das echte nicht verwaltete Objekt fungiert. Diese Wrapper scheinen wie jede andere verwaltete Klasse für den .NET-Client zu sein, aber in Wirklichkeit marshallen sie nur Aufrufe zwischen verwaltetem (.NET) und nicht verwaltetem (COM)-Code.

Ebenso können Sie ein .NET Remoting-Serverobjekt für klassische COM-Clients verfügbar machen. Wenn ein COM-Client eine instance des .NET-Objekts erstellt, wird das Objekt über einen COM-aufrufbaren Wrapper (CCW) verfügbar gemacht, der als Proxy für das real verwaltete Objekt fungiert.

In beiden Szenarien wird DCOM für die Kommunikation verwendet. Diese Interoperabilität ist sehr praktisch in Szenarien, in denen es eine heterogene Mischung aus klassischen COM- und .NET-Komponenten gibt.

Zusammenfassung

Microsoft .NET Framework bietet ein leistungsfähiges, erweiterbares und sprachunabhängiges Framework zur Entwicklung robuster und skalierbarer verteilter Systeme. Das .NET Remoting Framework bietet leistungsstarke Möglichkeiten für die Remoteinteraktion, abhängig von den Anforderungen des Systems. .NET Remoting lässt sich nahtlos in Webdienste integrieren und bietet eine Möglichkeit, .NET-Objekte für den Zugriff auf mehrere Plattformen verfügbar zu machen.

Weitere Informationen

• Weitere Informationen zu .NET Remoting finden Sie unter Microsoft .NET Remoting: Eine technische Übersicht.
• Die neuesten Informationen zu Microsoft .NET finden Sie auf unserer Website unter https://msdn.microsoft.com/net/.