Vermittlerrouter

Dieses Beispiel veranschaulicht die Implementierung eines Diensts, der grundlegende Routingfunktionen zur Verfügung stellt, die in Netzwerkkonfigurationen nützlich sind, bei denen Clients nicht direkt auf Dienste zugreifen können. Es handelt sich hier nicht um Beispiel für einen effizienten, skalierbaren Router mit zahlreichen Features.

Bei einem typischen Kommunikationsszenario, das SOAP-Vermittler einschließt, durchläuft eine von einem Client gesendete Nachricht mindestens einen zusätzlichen Dienst, bevor sie ihren endgültigen Bestimmungsort erreicht. Dabei handelt es sich um den Dienst, der für die eigentliche Verarbeitung der Nachricht und (sofern zutreffend) das Bereitstellen einer Antwort zuständig ist. Ein SOAP-Vermittler führt verschiedene Aktionen mit der Nachricht aus, die ihn durchläuft. Beispielsweise gibt ein zwischenspeichernder Vermittler eine zwischengespeicherte Antwort auf die Nachricht zurück, wodurch die Belastung des Diensts verringert wird, der die Anforderung sonst erneut bearbeiten müsste. Ein lastenausgleichender Vermittler leitet die Nachricht mithilfe eines Roundrobin-Algorithmus an einen von vielen potenziellen Diensten weiter. Ein Schemaüberprüfungsvermittler leitet nur Nachrichten weiter, die der XSD des Vertrags und (sofern zutreffend) anderen Protokollen vollständig entsprechen. Der für dieses Beispiel entwickelte Vermittler leitet Nachrichten anhand ihres Headers und Inhalts an einen geeigneten Dienst weiter.

Weitere Informationen zu SOAP-Nachrichten finden Sie unter XML Web Service Wire Formats.

In diesem Beispiel werden zwei Anwendungsdienste bereitgestellt, um Clientanforderungen zu verarbeiten: ein Rechnerdienst und ein Echodienst. Auf die Anwendungsendpunkte des Diensts kann nur über das interne Netzwerk zugegriffen werden. Auf die Metadatenaustausch-Endpunkte (MEX) des Diensts kann öffentlich zugegriffen werden. Der SOAP-Router gehört zum internen Netzwerk, und alle Anwendungsanforderungen von außerhalb des internen Netzwerks müssen ihn durchlaufen.

Der Client wurde durch das Ausführen von Service Model Metadata Utility Tool (Svcutil.exe) für beide Dienste erstellt, um zwei Codedateien (ein Client für jeden Dienst) und eine Konfigurationsdatei zu generieren, da "Svcutil.exe" die Konfigurationsinformationen des zweiten Diensts in die bereits vorhandene Konfigurationsdatei zusammenführt, die beim Ausführen von "Svcutil.exe" für den ersten Dienst erstellt wurde. Die von jedem Dienst bereitgestellte WSDL (Web Services Description Language) enthält die Adresse des SOAP-Vermittlers anstelle der Adresse des eigentlichen Diensts. Aus diesem Grund muss der Client die Konfigurationsdatei nicht ändern oder die Adresse des SOAP-Vermittlers kennen.

Außerdem wird der Routerdienst in diesem Beispiel mit zwei Endpunkten konfiguriert: einem zum Überwachen von textcodierten Nachrichten mit HTTP für SOAP 1.2 und einem zum Überwachen von binärcodierten Nachrichten mit TCP für SOAP 1.2. Die WSDL jedes Anwendungsdiensts verwendet die richtige Endpunktadresse des Routers. Der Router erhält Routinginformationen auch im Abschnitt "appSettings" der Konfigurationsdatei mit den folgenden Eigenschaften:

• prefixes und namespaces werden zum Aktualisieren des standardmäßigen XmlNamespaceManager in WCF verwendet, damit die Präfixe in den Xpaths des Routers aufgelöst werden können.
• xpath und epr werden zum Hinzufügen von Routingeinträgen zur Routingtabelle verwendet, die XPaths den EPRs zuordnet.

Der Router verwendet die Klasse XpathMessageFilterTable (XPathFilterTable<T>), wobei "T" eine EndpointAddress ist, in der die vom Benutzer angegebenen Routingeinträge gespeichert werden. Wenn eine Nachricht empfangen wird, ruft der Router die Methode MatchMultiple in einer Message-Instanz auf und ruft eine EndpointAddress ab, an die er die Nachricht weiterleitet.

Sowohl EchoService als auch CalculatorService verwenden die Eigenschaft ListenUri zum Festlegen des URI, den der Endpunkt überwacht. Die Adresse in der Endpunktdeklaration ist die Adresse des Routerendpunkts, der die Dienstnachrichten weiterleiten kann. Dies ist die Adresse, die in der WSDL des Diensts angezeigt und mit dem To-Header der WS-Adressierung jeder eingehenden Nachricht verglichen wird. Die von der Eigenschaft ListenUri bereitgestellte Adresse ist die tatsächliche physische Überwachungsadresse des Endpunkts, die nur vom Transport verwendet wird.

WCF stellt noch ein weiteres Verhalten bereit, das notmalerweise in SOAP-Vermittlungsszenarios verwendet und in diesem Beispiel nicht angewendet wird: das ClientViaBehavior-Kanalverhalten. Das ClientViaBehavior wird von Clients verwendet, um den URI anzugeben, für den der Transportkanal erstellt werden soll. Wenn ein solches Verhalten in der Verhaltensauflistung eines Clientendpunkts vorhanden ist, verwendet der Transport den angegebenen URI, während alle anderen Kanalschichten im Stapel die EndpointAddress verwenden, die zur ChannelFactory-Konstruktionszeit angegeben wird. Diese EndpointAddress wird auch als To-Header der WS-Adressierung verwendet. Der folgende Beispielcode zeigt die Verwendung dieses Verhaltens.

ChannelFactory<IContract> factory = new ChannelFactory<IContract>(new EndpointAddress("http://hostname/service"));
factory.Endpoint.Behaviors.Add(new ClientViaBehavior(new Uri("http://hostname/intermediary")));
IContract channel = factory.CreateChannel(); 

Ein anderes WCF-Feature, das von SOAP-Vermittlern verwendet wird, ist die AddressFilter-Eigenschaft. Der AddressFilter wird von WCF verwendet, um nur Nachrichten zu akzeptieren, die mit einem bestimmten Filter übereinstimmen. Wenn die Methoden des Dienstvertrags "*" als Action verwenden, wird nur die Adresse überprüft. In diesem Beispiel wird dieses Feature nicht genutzt, da die Adresse immer richtig ist. Der Router akzeptiert die Nachrichten des Clients, da die To-Header mit seinen Endpunktadressen übereinstimmen, und die Dienste akzeptieren an sie weitergeleitete Nachrichten, da ihr To-Header mit der logischen Adresse ihres Endpunkts übereinstimmt.

Die Datei "Contracts.cs" des Beispiels definiert die folgenden vier Schnittstellen, eine für jedes Transportmuster:

• ISimplexDatagramRouter. Diese Schnittstelle ist erforderlich, um Nachrichten über Simplexdatagrammkanäle zu akzeptieren. Fügen Sie einen Endpunkt mithilfe dieser Schnittstelle hinzu, wenn Sie Nachrichten über unidirektionale HTTP-Kanäle oder unidirektionale TCP- und NamedPipe-Kanäle erwarten.
• IRequestReplyDatagramRouter. Diese Schnittstelle ist erforderlich, um Nachrichten über Anforderung-Antwort-Datagrammkanäle zu akzeptieren. Verwenden Sie diese Schnittstelle für Nachrichten über einen bidirektionalen HTTP-Kanal.
• ISimplexSessionRouter. Diese Schnittstelle muss Nachrichten über sitzungsbasierte Simplexkanäle akzeptieren. Verwenden Sie diese Schnittstelle für Simplex-TCP- und Simplex-NamedPipe-Kanäle.
• IDuplexSessionRouter. Diese Schnittstelle ist für Duplexsitzungskanäle vorgesehen. Verwenden Sie diese Schnittstelle für Duplex-TCP- und Duplex-NamedPipe-Kanäle.

RouterBinding ist ein Beispiel für eine WCF-Bindung, die Sie für die Unterstützung des SOAP-Vermittlers erstellen können. Damit können Sie die am häufigsten verwendeten Einstellungen festlegen, die in diesem Szenario erforderlich sind. Außerdem stellt sie sicher, dass nur wirklich erforderliche Bindungselemente hinzugefügt werden. Auch eine grundlegende Konfigurationsunterstützung wird geboten.

In diesem Beispiel wird kein Webhosting verwendet, da andere Transporte als HTTP verwendet werden. TCP-Aktivierung ist derzeit nur für Windows Vista und IIS 7.0 verfügbar.

Wenn Sie das Beispiel ausführen, werden die Anforderungen und Antworten für den Vorgang im Clientkonsolenfenster angezeigt. Drücken Sie im Clientfenster die EINGABETASTE, um den Client zu schließen.

Echo("Is anyone there?") returned: Is anyone there?
Add(5) returned: 5
Add(-3) returned: 2

So richten Sie das Beispiel ein, erstellen es und führen es aus

1. Zum Erstellen der C#-, C++- oder Visual Basic .NET-Version der Projektmappe folgen Sie den unter Erstellen der Windows Communication Foundation-Beispiele aufgeführten Anweisungen.

2. Wenn Sie das Beispiel in einer Konfiguration mit einem einzigen Computer oder computerübergreifend ausführen möchten, befolgen Sie die Anweisungen in Durchführen der Windows Communication Foundation-Beispiele, mit den folgenden Ausnahmen.

   1. Bei Konfigurationen mit einem einzigen Computer oder computerübergreifend werden vier Projekte und vier ausführbare Dateien benötigt: eine für den Client, eine für den SOAP-Router und jeweils eine für jeden Anwendungsdienst.
   2. In einer computerübergreifenden Konfiguration müssen die folgenden Änderungen an den vier Konfigurationsdateien vorgenommen werden.
      Die Datei "App.config" für CalculatorService und EchoService muss in Zeile 21 geändert werden. Der "localhost " muss durch den echten Hostnamen des Vermittlers ersetzt werden.
      Die Datei "App.config" des Routers muss in Zeile 15 geändert werden. Die beiden (durch "|" getrennten) Adressen müssen in den Hostnamen von EchoService bzw. CalculatorService geändert werden.
      Die Datei "App.config" des Clients muss in den Zeilen 5 und 7 geändert werden. Der "localhost " muss durch den echten Hostnamen des Vermittlers ersetzt werden.
      Sie können auch das Service Model Metadata Utility Tool (Svcutil.exe) für die beiden Anwendungsdienste verwenden (sobald sie mit der richtigen Adresse aktualisiert wurden) und die "App.config"-Dateien neu generieren.

3. Stellen Sie sicher, dass der Router, EchoService, und CalculatorService ausgeführt werden, bevor Sie den Client starten. Jeder des drei Dienste beim Start zeigt die Endpunktadressen an, die sie überwachen.

   Tipp

   Die Anwendungsendpunkte von EchoService und CalculatorService verwenden die Adresse des Routers.

4. Führen Sie den Client aus. Der Client kontaktiert zuerst den EchoService und dann den CalculatorService. Der Router zeigt die WS-Addressierungsaktionen von Nachrichten an, die er in beide Richtungen weiterleitet.

   Tipp

   Wenn sich "Client.exe" und "Router.exe" auf unterschiedlichen Computern befinden, heben Sie die Auskommentierung des Abschnitts <identity/> in der Datei "Client.exe.config" auf und legen als Benutzerprinzipalnamen den Namen des Benutzers fest, der "Router.exe" ausführt.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.