Einführung in die Windows Communication Foundation (WCF)

Transkript

1 Einführung in die Windows Communication Foundation (WCF) Seminarvortrag Mark Foti Matrikelnummer:

2 Gliederung 1 Einleitung 2 Das A-B-C (Address, Binding, Contract) Prinzip 3 Bindings und Protokolle 4 Aufbau eines WCF-Servers 5 Ein einfacher WCF-Client 6 Bidirektionale Verbindungen 7 Fazit Seite 2

3 Einleitung WCF ist eine API im.net Framework (ab Version 3.0) zur Entwicklung von verteilten Systemen (vgl. SOAP) Quelle: Aufteilung in Server und Client: Server bietet Operationen an Client kann diese von einem anderen Rechner aus ausführen Übergabeparameter und Rückgabewerte werden über ein Netzwerk gesendet (z.b. Ethernet und HTTP) Seite 3

4 Einleitung WCF als Nachfolger von.net Remoting WCF ist eine Weiterentwicklung / Ablösung der.net Remoting Technologie (Remoting) Remoting hat sich nie richtig durchgesetzt: Schlechte Performance Keine Kompatibilität zu anderen Implementierungen (nur.net wurde unterstützt) WCF ist kompatibel zu der WS Architektur (WebServices) WCF kann erweitert werden: eigene Protokolle und Übertragungsmethoden können implementiert werden. Seite 4

5 Einleitung - Kompatibilität WCF ist zu anderen SOA Architekturen kompatibel Quelle: Ein WCF-Client kann mit einem Java-Server kommunizieren und umgekehrt Seite 5

7 Das A-B-C Prinzip WCF verwendet bei der Kommunikation das sogenannte ABC Prinzip: A = Adresse B = Binding C = Contract Adresse beschreibt Protokoll sowie Endpunkt (Hostname oder IP-Adresse). Mit dem Binding wird das Protokoll konfiguriert. Contract beschreibt die Schnittstelle, die vom Server zur Verfügung gestellt wird. Seite 7

8 Die Adresse Adresse ist eine URL. Sie identifiziert welcher Endpunkt auf welchem Rechner angesprochen werden soll. Beispiel: "net.tcp://localhost/icomplexcalculator" Endpunkt auf dem lokalen Rechner mit dem Namen "IComplexCalculator" TCP wird als Übertragungsprotokoll verwendet Seite 8

9 Das Binding Mit dem Binding wird das verwendete Protokoll konfiguriert. Der Sicherheitsmechanismus kann ausgesucht und eingestellt werden. Die Art, wie Nachrichten übertragen werden, kann festgelegt werden (z.b. "gepuffert" oder "gestreamed"). Binding muss zur Adresse passen! Es kann also kein HTML-Basiertes Binding mit der Adresse "net.tcp://localhost/icomplexcalculator" verknüpft werden. Seite 9

10 Der Contract Contract beschreibt die Schnittstelle, die vom Server implementiert wird. Der Client kann auch nur genau die Methoden aufrufen, die im Contract festgelegt wurden. Der Server kann den Contract bei Bedarf auch an die Clients schicken (in Form von Metadaten). Daraus kann der Client ein Proxy für den Server erstellen (dynamisch) Seite 10

12 Bindings und Protokolle Das Übertragungsformat auf Byte-Ebene hängt vom verwendeten Binding ab. Einige mögliche Bindings sind: BasicHttp-, WSHttp- und das WSDualHttpBinding verwenden das HTTP-Protokoll. Das NetTcpBinding verwendet lediglich das TCP Protokoll. Beim NetNamedPipeBinding werden die Named Pipes von Windows verwendet. Seite 12

13 HTTP Bindings Bei den HTTP-Bindings werden die Daten im XML-Format verschickt und haben dadurch die höchste Kompatibilität. Anfragen werden als HTTP-Request geschickt. BasicHttpBinding hat den geringsten Overhead (ist also am schnellsten), bietet aber keine Sicherheit. WSHttpBinding bietet Sicherheit: Transport Security Mode (Verschlüsselung auf Übertragungsebene (HTTPS)) Message Security Mode (Nachrichten werden einzeln verschlüsselt) WSDualHttpBinding erlaubt zusätzlich Callbacks (Methodenaufrufe, die vom Server aus asynchron initiiert werden können) ist aber am langsamsten. Seite 13

14 Schnellere Bindings NetTcpBinding verwendet das TCP-Protokoll NetNamedPipeBinding verwendet die Named Pipes von Windows als Übertragungsprotokoll. Beide Bindings verwenden einen "BinaryFormatter". Das heißt, Daten werden binär übertragen (und nicht im XML-Format). Die Nachrichten werden mit weniger Metadaten dekoriert. Unterstützen die Sicherheitsmechanismen als auch Callbacks. Sind in der Regel nicht zu anderen SOAP Implementierungen kompatibel. Seite 14

15 Geschwindigkeitsvergleich der Bindings Bindung Anzahl der Aufrufe in 10s. BasicHttpBinding WSHttpBinding WSDualHttpBinding NetTcpBinding NetNamedPipeBinding Quelle: Seite 15

17 Aufbau des Servers Ein WCF-Server besteht aus drei Teilen: 1. Eine Schnittstelle (Contract) die beschreibt, was der Server "kann" 2. Die eigentliche Implementierung der Schnittstelle 3. Und die Konfiguration, in der sowohl die Adresse als auch das Binding ausgewählt und konfiguriert werden. Beispiel-Interface: Seite 17

18 Implementierung der Schnittstelle Die Implementierung der Schnittstelle erfolgt ganz normal und muss nicht mit weiteren Attributen versehen werden. In diesem Fall wird für jeden Methodenaufruf eine neue Instanz vom Typ MyCalculator erstellt. Selbst dann, wenn der Client eine Methode bereits aufgerufen hat. Seite 18

19 Konfiguration des Servers Nachdem die Schnittstelle deklariert und definiert wurde, wird der eigentliche Server erzeugt. Dazu sind folgende Schritte notwendig: 1. Bekanntgabe der Klasse, die die Schnittstelle implementiert. 2. Ein Binding muss ausgesucht und konfiguriert werden. 3. Schließlich muss dem Framework mitgeteilt werden, welche Schnittstellen der Server anbietet. Seite 19

20 Konfiguration des Servers 1. Parameter 1: Bekanntgabe der Klasse, der die Schnittstelle implementiert. Parameter 2: Die Uri, unter welcher Adresse der Server ggf. Metadaten zur Verfügung stellen kann. 2. Da der Taschenrechner möglichst einfach aufgebaut werden soll, wird als Binding das BasicHttpBinding verwendet. Die Standardkonfiguration des Bindings reicht für den Anfang. Seite 20

21 Konfiguration des Servers 3. Letztlich wird mit dem Aufruf ein ServiceEndPoint der Host-Instanz hinzugefügt. Hierbei handelt es sich um die eigentliche Schnittstelle, die zur Verfügung gestellt wird. ServiceEndPoint wird mit dem Binding verknüpft. Da ein Server mehrere Schnittstellen anbieten kann, muss jeder ServiceEndPoint mit einer Uri gekennzeichnet werden. Anschließend kann der Server gestartet werden (mit Open()). Ab diesem Zeitpunkt wartet der Server auf einkommende Anfragen. Seite 21

22 WSDL und Metadaten Bei der Entwicklung eines WCF-Clients wird in der Regel ein Proxy erstellt, welcher die Kommunikation zum Server kapselt. Dieser Proxy kann automatisch von Visual Studio erstellt werden. Dabei werden die notwendigen Metadaten automatisch vom entsprechenden WCF-Server runtergeladen. Damit der Server Metadaten liefern kann, muss dieser angepasst werden: Seite 22

24 Benutzung des Proxies Wurde der Proxy automatisch generiert, so ist der Aufruf der serverseitigen Methoden sehr einfach. Es muss eine Instanz des Proxies erstellt werden, die eine Verbindung zum Server aufbaut. Danach können die Methoden ganz normal verwendet werden (der Proxy implementiert die gleichen Schnittstellen wie der Server). Seite 24

25 Konfiguration des Clients Soll eine andere IP-Adresse oder Binding verwendet werden, als beim erstellen des Proxies eingestellt wurde, so kann der Konstruktor des Proxies überladen werden. Soll zum Beispiel explizit das BasicHttpBinding und die IP-Adresse verwendet werden, muss der Konstruktoraufruf verändert werden: Einige weitere Konfigurationsmöglichkeiten betreffen verschiedene Timeouts z.b. wie lange das Senden höchstens dauern darf. Zudem können weitere Einschränkungen definiert werden, z.b. die maximale Größe eines Pakets. Seite 25

27 Bidirektionale Verbindungen Bis jetzt wurde jede Anfrage vom Client initiiert und der Server hat geantwortet. Nun soll der Server auch die Möglichkeit haben, eine Anfrage an den Client asynchron senden zu können. Dazu stellen sich zwei Fragen: 1. Welche Methoden kann der Server beim Client aufrufen? 2. Welcher Client soll angesprochen werden? Mehrere Clients können schließlich mit dem gleichen Server verbunden sein. Seite 27

28 Die Callback-Schnittstelle 1. Welche Methoden kann der Server beim Client aufrufen? Dazu wird beim Server eine sogenanntes Callback-Interface definiert. Diese Schnittstelle muss später jeder Client implementieren, der mit dem Server kommunizieren will: Die Schnittstelle, die der Server nach außen anbietet, muss leicht geändert werden: Damit wird gekennzeichnet, dass jeder Client, der die IComplexCalculator-Schnittstelle verwenden will, die Schnittstelle ICalculatorCallback implementieren muss. Seite 28

29 Das OperationContext 2. Welcher Client soll angesprochen werden? WCF verschickt bei jedem Methodenaufruf implizit eine Session ID damit kann der Client ermittelt werden, der diesen Aufruf getätigt hat. ID kann mit OperationContext.Current abgefragt werden. Darüber hinaus kann mit dem aktuellen OperationContext auch der zugehörige Callback-kanal ermittelt werden: Mit der Methode GetCallbackChannel<Schnittstellen-Typ>() kann eine Referenz auf die Schnittstelle ermittelt werden. Damit kann die Methode beim Client aufgerufen werden. Seite 29

30 Der Client mit Callbacks Der Client muss lediglich die Callback-Schnittstelle implementieren. Diese Implementierung wird beim Konstruktoraufruf des Proxies übergeben. Seite 30

32 Fazit Die vorgestellten Codebeispiele decken lediglich die Grundlagen von WCF ab. Durch die einfache Implementierung wird WCF auch attraktiv: sie ist mächtig und "Plattformunabhängig" erlaubt aber trotzdem rapid Prototyping. WCF ist stark abstraktionsfähig soll die gewünschte Applikation möglichst einfach sein, reichen die hier erwähnten Klassen. Auf der anderen Seite können auch eigene Bindings erstellt sowie andere Übertragungsprotokolle gewählt werden die an die eigenen Anwendungsfälle angepasst sind. Durch die automatisierte Erstellung des Proxies muss bei der Programmierung des Clients relativ wenig redundanter (und damit fehleranfälliger) Code selber geschrieben werden. Seite 32

33 Gibt es noch Fragen? Seite 33

34 Vielen Dank für die Aufmerksamkeit! Seite 34