Skript zum Seminar: Einführung in die Windows Communication Foundation (WCF)

Transkript

1 Aachen, Mark Foti - Tel Skript zum Seminar: Einführung in die Windows Communication Foundation (WCF) Autor: Betreuer: Mark Foti Dipl.-Ing. Mirco Vitr Datum: Seminar Windows Communication Foundation 1/37

2 Inhalt 1 Einleitung Motivation hinter SOAP Das A-B-C Prinzip Bindings und Protokolle im Detail BasicHttpBinding WSHttpBinding WSDualHttpBinding NetTcpBinding und NetNamedPipeBinding Aufbau eines WCF Programms Voraussetzungen Der Contract Die Implementierung Die Konfiguration WSDL und Metadaten Aufbau eines WCF Clients Erstellung der Service Reference Aufruf der serverseitigen Methoden Konfiguration des WCF-Clients Bidirektionale Verbindungen Die Callback-Schnittstelle Das OperationContext Der ConcurrencyMode Aufbau des Clients bei der bidirektionalen Kommunikation Fehlerbehandlung Seminar Windows Communication Foundation 2/37

3 13 Fazit A. Anhang Quelltext des Servers Quelltext des SimpleClients (ohne Callbacks) Quelltext des ComplexClients (mit Callbacks) Seminar Windows Communication Foundation 3/37

4 Seminar Windows Communication Foundation 4/37

5 1 Einleitung Die Windows Communication Foundation (WCF) ist eine API (application programming interface) in dem.net Framework zur Entwicklung von vernetzten Service-orientierten Applikationen (SOA). Ziel dieses Skriptes ist es, eine erste Einführung in die Welt der verteilten Systeme unter Benutzung des.net Frameworks zu geben. 1.1 Motivation hinter SOAP Die Grundidee hinter SOAP 1 ist, Operationen nicht nur auf dem lokalen Rechner auszuführen, sondern zu verteilen. Als einfachstes Beispiel kann ein Taschenrechner dienen, bei der die auszuführenden Operationen (z.b. 5+3) auf einem Rechner (Client) eingegeben und die tatsächliche Berechnung auf einem anderen Rechner (Server) ausgeführt werden und die Ergebnisse zurück an den Client gesendet werden. Abbildung 1 zeigt den grundsätzlichen Aufbau eines WCF Servers und Clients. Dieses Vorgehen kann große Vorteile mit sich bringen: sicherheitskritische Operationen werden nur auf einem Server ausgeführt und der Algorithmus kann nicht analysiert werden da das Binärprogramm nicht zur Verfügung steht bei rechenintensiven Programmen muss nicht jeder Client die erforderliche Hardware besitzen; stattdessen kann die Berechnung auf einem Großrechner erfolgen und der Client muss die Daten lediglich verwalten (Master/Worker- Prinzip) Abbildung 1: Schematische Abbildung eines WCF Servers und Clients 2 1 Service Oriented Architecture Protocol, 2 Quelle: Seminar Windows Communication Foundation 5/37

6 WCF, ursprünglich unter dem Codenamen Indigo bekannt, wurde mit Version 3.0 des.net Frameworks im Dezember 2006 eingeführt und sollte als Ablösung für die bis dahin aktuelle.net Remoting Technologie dienen. Die Motivation dahinter war eine bessere Interoperabilität sowie Performance. Während.NET Remoting nur auf Windows Rechnern lief, auf denen das.net Framework installiert war, erlaubt WCF den Austausch von standardisierten SOAP Nachrichten (z.b. zwischen WebServices) und ist dadurch nicht mehr an eine Programmierumgebung gebunden (somit kann ein unter C# geschriebener Server mit einem unter Java entwickelten Client problemlos kommunizieren). Abbildung 2 stellt dabei die Kompatibilität zwischen den verschiedenen Implementierungen von SOAP dar. Abbildung 2: Darstellung der Flexibilität und Kompatibilität 3 Zudem wurde die Leistung gegenüber.net Remoting wesentlich verbessert, indem verschiedene Encoder, also Mechanismen, wie Nachrichten auf Byte-Ebene kodiert werden, benutzt werden können. Soll das Programm möglichst viele Daten zwischen zwei WCF Applikationen austauschen, kann ein Binaryformatter benutzt werden, der ohne viele Metadaten auskommt und die Daten binär formatiert. Wenn dagegen höchste Interoperabilität gefragt ist, kann auf einen XML-Serializer zurückgegriffen werden der dementsprechend mehr Metadaten zu den Nachrichten hinzufügt. 3 Quelle: Seminar Windows Communication Foundation 6/37

7 1.2 Das A-B-C Prinzip WCF verwendet bei der Kommunikation das sogenannte ABC Prinzip: A = Address B = Binding C = Contract Die Adresse ist dabei eine URL ähnlich wie die Links im Internet. Diese sagt aus, welches Protokoll verwendet wird, wie der Endpunkt heißt (Hostname oder IP-Adresse) und zu welchem Endpunkt auf dem Server verbunden werden soll (auf dem gleichen Rechner können mehrere WCF-Server laufen). Mit dem Binding wird das verwendete Protokoll konfiguriert. Hier kann eingestellt werden, welche Sicherheitsmechanismen verwendet werden sollen oder wie die Übertragung funktionieren soll (z.b. ob Daten "gestreamed" oder "gepuffert" übertragen werden sollen). Da sowohl die URL als auch das Binding das verwendete Protokoll beschreiben, muss eine URL zum verwendeten Binding passen; andernfalls kommt es zu einer Exception beim Verbindungsaufbau. Beispiel: Die Adresse "net.tcp://localhost/icomplexcalculator" beschreibt ein NetTcpBinding. Somit würde ein Fehler auftreten, wenn der Server versuchen würde, als Binding das BasicHttpBinding zu verwenden. Letztlich beschreibt der Contract die Schnittstelle, die vom Server zur Verfügung gestellt wird. In anderen Worten: der Server kann dem Client mitteilen, was für Methoden auf ihm ausgeführt werden können (mit allen notwendigen Metadaten wie z.b. Übergabeparameter und Rückgabetypen) und stellt intern eine oder mehrere Klassen zur Verfügung, die die Schnittstellen implementieren. Seminar Windows Communication Foundation 7/37

8 2 Bindings und Protokolle im Detail Das Übertragungsformat auf Byte-Ebene hängt vom verwendeten Binding ab. Einige mögliche Bindings sind in Abbildung 3 dargestellt.: Abbildung 3: Darstellung einiger Bindings 2.1 BasicHttpBinding Das BasicHttpBinding ermöglicht die höchste Kompatibilität. Eine Anfrage wird als HTTP-Request geschickt (wie der Web-Browser) und die Daten werden im XML-Format verschickt. Mit diesem Binding ist auch die Kompatibilität mit anderen SOAP Implementierungen gewährleistet ein Java SOAP Client kann also mit einem WCF SOAP Server kommunizieren und umgekehrt. Von allen HTTP-Bindings hat das BasicHttpBinding den geringsten Overhead, ermöglicht dabei aber weder Verschlüsselung noch eine bidirektionale Kommunikation. Somit muss jede Anfrage immer vom Client stammen. 2.2 WSHttpBinding Sicherheit bietet das WSHttpBinding-Binding. Es basiert auf dem BasicHttpBinding mit dem Unterschied, dass die Daten verschlüsselt werden können. Unterstützt werden dabei mehrere Sicherheitsmechanismen: Transport Security Mode Message Security Mode Beim Transport Security Mode wird die Nachricht in der Übertragungsebene, z.b. HTTPS, verschlüsselt. Damit ist zwar die Übertragung verschlüsselt, die Daten sind vor Seminar Windows Communication Foundation 8/37

9 dem Versenden bzw. nach der Ankunft allerdings ungesichert. Der Vorteil von diesem Mechanismus liegt in der geringen Komplexität und damit in der Geschwindigkeit. Mehr Schutz bietet der Message Security Mode. Hierbei werden die SOAP Nachrichten einzeln verschlüsselt, was eine höhere Sicherheit gewährleistet, da nur die entsprechende Applikationen die Nutzdaten sieht. Dies wird allerdings mit einem höheren Aufwand bezahlt, da jede Nachricht einzeln angepasst werden muss. Die Verschlüsselung basiert dabei auf der WS-Security Spezifikation und ist dementsprechend auch normiert 4. Damit wird ebenfalls eine Kompatibilität zu anderen Implementierungen ermöglicht. 2.3 WSDualHttpBinding Bei den beiden zuvor genannten Bindings können Daten nicht bidirektional gesendet werden: der Client schickt eine Anforderung an den Server und dieser antwortet. Auf asynchrone Ereignisse kann der Client nicht reagieren. Das WSDualHttpBinding bietet Unterstützung für sogenannte Callbacks, also Methodenaufrufe, die vom Server aus initiiert werden. Dabei wird im Contract festgelegt, welche Methoden der Client implementieren muss und dieser startet automatisch ebenfalls einen WCF Server. Verbindet sich der Client zum eigentlich Server, so wird eine zweite Verbindung vom Server zum WCF-Server des Clients aufgebaut. Somit ist eine Vollduplexverbindung (gleichzeitiges Senden und Empfangen) möglich. Da das WSDualHttpBinding auf dem WSHttpBinding aufbaut, werden die dort implementieren Sicherheitsmechanismen ebenfalls unterstützt. Dieses Plus an Flexibilität wird ebenfalls mit einem höheren Overhead bezahlt und das WSDualHttpBinding gehört somit zu den langsamsten Bindings, welche auf das HTTP Protokoll aufbauen. 2.4 NetTcpBinding und NetNamedPipeBinding Spielt die Übertragungsgeschwindigkeit bzw. der Aufwand eine größere Rolle als die Kompatibilität, kann das NetTcpBinding oder das NetNamedPipeBinding Binding verwendet werden. Bei diesen Bindings werden die Daten binär übertragen (d.h. nicht mehr im XML-Format und nicht im Klartext) und somit geht die Kompatibilität zu 4 Quelle: Seminar Windows Communication Foundation 9/37

10 anderen SOAP Implementierungen verloren. Die Übertragung verläuft entweder über das TCP/IP Protokoll bzw. über Named Pipes von Windows. Bei beiden Bindings sind die zuvor genannten Sicherheitsmechanismen als auch die bidirektionale Kommunikation vorhanden. Die folgende Tabelle 5 zeigt einen groben Geschwindigkeitsvergleich zwischen den einzelnen Bindings (jeweils mit ausgeschalteten Sicherheitsmechanismen) Bindung Aufrufe in 10 Sekunden BasicHttpBinding WSHttpBinding WSDualHttpBinding NetTcpBinding NetNamedPipeBinding Wie der Tabelle entnommen werden kann, sollte bei reinen WCF Applikationen entweder das NetTcpBinding oder das NetNamedPipeBinding aus Performancegründen gewählt werden. Damit sind durchaus Übertragungsraten möglich, die ähnlich hoch sind wie reine TCP/IP Übermittlungen ohne Nachrichten (also Übermittlungen bei denen ausschließlich reine Nutzdaten übertragen werden). 5 Seminar Windows Communication Foundation 10/37

11 3 Aufbau eines WCF Programms Eine WCF-Applikation besteht aus drei Teilen. 1) Eine Schnittstelle (Contract) die beschreibt, was der Server "kann" 2) Die eigentliche Implementierung der Schnittstelle 3) Die Konfiguration, in der sowohl die Adresse als auch das Binding ausgewählt und konfiguriert werden Nachfolgend werden diese drei Aspekte anhand eines einfachen Beispiels erklärt. Dabei wird ein Server erstellt, der einfache Rechenoperationen ausführen und die Ergebnisse anschließend dem Client mitteilen kann. Um Missverständnissen vorzubeugen, wird folgendes vereinbart: Variablen einer Klasse, die als üblicherweise Attribute bezeichnet werden, werden (private / public) Membervariablen genannt. Attribute hingegen bezeichnen die Codeabschnitte in eckigen Klammern (z.b. [Serializable]). Seminar Windows Communication Foundation 11/37

12 4 Voraussetzungen Soll das Beispiel nachimplementiert werden, so muss auf dem Zielrechner das.net Framework ab Version 3.0 installiert sein (aktuell:.net Framework 3.5 SP1). Zusätzlich muss dem Projekt eine Referenz auf die DLL "System.ServiceModel.dll" hinzugefügt sein. 4.1 Der Contract Die Operationen, die von einem Client später ausgeführt werden können, müssen zunächst deklariert werden. Dies geschieht in Form von einer normalen Schnittstelle (Interface), bei der die Deklarationen für die WCF Kommunikation mit bestimmten Attributen versehen werden. Im Fall des Beispieltaschenrechners würde das Interface so aussehen: [ServiceContract] public interface ISimpleCalculator [OperationContract] double Add(double Value1, double Value2); [OperationContract] double Subtract(double Value1, double Value2); [OperationContract] double Multiply(params double[] Values); [OperationContract] double Divide(double Value1, double Value2); Die Schnittstelle wurde mit dem Attribut [ServiceContract] versehen. Damit wird dem.net Framework mitgeteilt, dass diese Schnittstelle später von außen angesprochen werden kann. Jede Methode, die dabei aufgerufen werden können soll, muss mit dem Attribut [OperationContract] versehen werden. Der restliche Aufbau entspricht dem einer regulären Schnittstelle. In diesem Beispiel werden nur herkömmliche Datentypen übergeben; es besteht darüber hinaus auch die Möglichkeit, Datenklassen zu übergeben. Dazu genügt es, die Seminar Windows Communication Foundation 12/37

13 Klasse als public zu kennzeichnen; sämtliche public Membervariablen dieser Klasse werden dem Client somit mitgeteilt. Methoden bleiben unbekannt, da sie nicht serialisiert werden können. Dabei spielt es keine Rolle ob die Methoden public oder private sind. 4.2 Die Implementierung Im allgemeinen Fall muss bei der Implementierung nicht unterschieden werden, ob die Methode von außen oder von innen (also von der eigenen Assembly) aufgerufen wird. Für das obige Beispiel könnte die Implementierung so aussehen: class MyCalculator : ISimpleCalculator #region ISimpleCalculator Members public double Add(double Value1, double Value2) throw new NotImplementedException(); public double Subtract(double Value1, double Value2) throw new NotImplementedException(); public double Multiply(params double[] Values) throw new NotImplementedException(); public double Divide(double Value1, double Value2) throw new NotImplementedException(); #endregion 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. Siehe dazu auch Kap. Der ConcurrencyMode. Seminar Windows Communication Foundation 13/37

14 4.3 Die Konfiguration Nachdem die Schnittstelle deklariert und definiert wurde, wird der eigentliche Server erzeugt. Dazu sind folgende Schritte notwendig: Dem.NET Framework muss bekannt gegeben werden, welche Klasse die nach außen sichtbare Schnittstelle implementiert Ein Binding muss ausgesucht und konfiguriert werden. Schließlich muss dem Framework mitgeteilt werden, welche Schnittstellen der Server anbietet. Für den Beispieltaschenrechner könnte der erste Punkt so implementiert werden: var host = new ServiceHost(typeof(SimpleCalculator), new Uri(" Der erste Parameter im ServiceHost-Konstruktor sagt aus, in welcher Klasse die Implementierung für die Schnittstelle liegt. Die Uri (der zweite Parameter) sagt aus, unter welcher Adresse der Server ggf. Metadaten zur Verfügung stellen kann. Da der Taschenrechner möglichst einfach aufgebaut werden soll, wird als Binding das BasicHttpBinding verwendet, das so erzeugt werden kann: var binding = new BasicHttpBinding(); Letztlich wird mit dem folgenden Aufruf ein "ServiceEndPoint" der Host-Instanz hinzugefügt. Hierbei handelt es sich um die eigentliche Schnittstelle, die zur Verfügung gestellt wird. Diese wird mit dem eben erzeugten 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 (.Open()). Ab diesem Zeitpunkt wartet der Server auf einkommende Anfragen: host.addserviceendpoint(typeof(isimplecalculator), binding, " host.open(); Wichtig ist, dass die Klasse, die beim Erstellen der ServiceHost-Instanz bekanntgegeben wurde, die Schnittstelle auch tatsächlich implementiert. Andernfalls würde es bei diesem Schritt zu einer Exception kommen. Ein Host kann auch mehrere Schnittstellen mit verschiedenen Bindings anbieten wichtig ist hierbei, dass die Klasse diese auch implementiert. Seminar Windows Communication Foundation 14/37

15 5 WSDL und Metadaten Nachdem der Server gestartet wurde, kann mit einem Client auf den Server zugegriffen und die Schnittstelle benutzt werden. Dafür muss der Client jedoch wissen, welche Methoden und Datentypen die Schnittstelle überhaupt definiert. Zwar ist es grundsätzlich möglich, die Schnittstelle und alle verwendete Datentypen ein zweites Mal auf der Clientseite manuell zu definieren, doch ist dieser Vorgang fehleranfällig und zeitintensiv. Dieser Ablauf kann auch automatisiert werden: Der Server kann sogenannte Metadaten im WSDL 6 Format auf Anfrage verschicken, die die Beschreibung über die Schnittstelle und alle verwendeten Datentypen sowie Datenstrukturen beinhaltet. Damit der Server diese Daten auch verschicken kann, muss dem ServiceHost ein ServiceMetadataBehavior hinzugefügt werden: var metadatabehavior = new ServiceMetadataBehavior(); metadatabehavior.httpgetenabled = true; host.description.behaviors.add(metadatabehavior); Wird der Server anschließend gestartet, können die Metadaten mit dem Web-Browser unter der Uri angesehen werden. Visual Studio 2008 kann diese Daten auch herunterladen und somit bei der Entwicklung des Clients unterstützen (vgl. folgendes Kapitel). 6 Web Services Description Langauge, Seminar Windows Communication Foundation 15/37

16 6 Aufbau eines WCF Clients 6.1 Erstellung der Service Reference Dieses Kapitel widmet sich dem Erstellen eines WCF Clients anhand des Beispieltaschenrechners. Um an die Schnittstellendefinition des Servers zu gelangen, werden die vom Server bereitgestellten Metadaten verwendet. Dazu wird die eingebaute Funktionalität von Visual Studio 2008 verwendet: Nachdem ein neues Projekt für den Client erstellt wurde, wird durch ein Rechts-Klick auf "Service References" der Menüpunkt "Add Service Reference" ausgewählt (vgl. Abbildung 4). Abbildung 4: Kontextmenü des Service References unter Visual Studio 2008 Zu diesem Zeitpunkt ist es wichtig, dass der Server läuft, damit Visual Studio sich mit dem Server verbinden kann! Als nächstes wird in die Adressleiste die Uri eingetragen und auf "Go" geklickt. Unter "Services" sollte der ServiceHost SimpleCalculator und die Schnittstelle ISimpleCalculator gefunden werden. In diesem Beispiel wurde der Namespace auf "Calculator" geändert (vgl. Abbildung 5) Seminar Windows Communication Foundation 16/37

17 Abbildung 5: Add Service Reference - Dialog Mit "OK" wird der Dialog beendet und anschließend werden die Metadaten heruntergeladen. 6.2 Aufruf der serverseitigen Methoden Die Verwendung des Servers ist im Code dann relativ einfach: Console.WriteLine("--- Simple Client ---"); var client = new Calculator.SimpleCalculatorClient(); client.open(); Console.WriteLine("5 + 5 = 0", client.add(5, 5)); Console.WriteLine(" = 0", client.add(5, 10)); Beim ersten tatsächlichen Methodenaufruf wird die Verbindung zum Server aufgebaut und der Server erstellt eine neue Instanz vom Typ SimpleCalculator. Visual Studio erstellt zudem eine Applikationskonfigurationsdatei (app.config) in der die Adresse und die Konfiguration des Bindings eingetragen werden (die zuvor heruntergeladen wurden). Als Adresse wird dabei diejenige verwendet, die im Dialog "Add Service Reference" eingetragen wurde (in diesem Fall localhost). Seminar Windows Communication Foundation 17/37

18 6.3 Konfiguration des WCF-Clients Werden Client und Server nicht auf dem gleichen Rechner ausgeführt, würde es mit der erstellten Standardkonfiguration zu einem Fehler kommen. Auf der Clientseite ist es möglich, das Binding sowie die Adresse zu ändern. Angenommen, der Server läuft auf dem Rechner mit der IP-Adresse , würde der Aufruf so aussehen: var binding = new BasicHttpBinding(); var address = new EndpointAddress(" var client = new Calculator.SimpleCalculatorClient(binding, address); Das Binding wird an dieser Stelle nicht weiter geändert es werden die Standardeinstellungen verwendet. 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. Für sichere und zuverlässige Verbindungen bietet das NetTcpBinding eine Option für ReliableSessions. Hier wird intern die Tcp-Verbindung durch Keepalive-Pakete aufrecht gehalten und somit kann sowohl der Server als auch der Client auf ein Netzwerkproblem entsprechend reagieren (z.b. dass die physikalische Netzwerkverbindung unterbrochen wurde), ohne dass diese Funktionalität explizit implementiert werden muss. Seminar Windows Communication Foundation 18/37

19 7 Bidirektionale Verbindungen Bis jetzt wurden einfache Verbindungen behandelt, wobei jede Anfrage vom Client ausgeht und dieser solange wartet, bis der Server eine Antwort schickt. Bis auf das BasicHttpBinding unterstützen die Bindings auch sogenannte Callbacks; das heißt, der Server kann selbstständig eine Verbindung zum Client aufbauen. Dabei gibt es einige Fragestellungen, die geklärt sein müssen: Welche Methoden kann der Server beim Client aufrufen? Welcher Client soll angesprochen werden? Mehrere Clients können schließlich mit dem gleichen Server verbunden sein. Was passiert im folgenden Fall (Abbildung 6)? Abbildung 6: Gleichzeitige synchrone und asynchrone Anfragen Oder in Worten ausgedrückt: der Client sendet eine synchrone Anfrage an den Server und bevor dieser Antworten kann, kommt eine zweite, asynchrone Anfrage vom Server. Seminar Windows Communication Foundation 19/37

20 8 Die Callback-Schnittstelle Bei der Deklaration der Serverschnittstelle besteht die Möglichkeit, eine Callback- Schnittstelle bekanntzugeben. Mit diesem Konstrukt wird dem Framework mitgeteilt, dass jeder Client, der die Serverschnittstelle benutzen will, ebenfalls eine weitere Schnittstelle implementieren muss die Callback-Schnittstelle. Als Beispiel wird der einfache Taschenrechner so erweitert, dass Operationen zunächst nur in eine Warteschlange hinzugefügt werden, danach der Reihe nach asynchron ausgewertet werden und schließlich dem entsprechenden Client das Ergebnis zurückgeschickt wird. Als erstes wird die Callback-Schnittstelle deklariert: public interface ICalculatorCallback [OperationContract(IsOneWay = true)] void OperationCompleted(OperationResult Result); Das Attribut OperationContract kennzeichnet die Methode, dass sie über WCF aufgerufen werden kann. Der Parameter IsOneWay sagt aus, dass die Methode keinen Wert zurückliefert und somit der Server nicht auf eine Antwort warten muss. Die Methode kann also "blind" aufgerufen werden. OperationResult ist eine selbsterstellte Klasse, welche der Aufnahme der Ergebnisse dient und folgenderweise deklariert ist: mit public class OperationResult public Operator Operator get; set; public double Result get; set; public bool Succeeded get; set; public Exception Error get; set; public enum Operator Add, Subtract, Multiply, Divide, Seminar Windows Communication Foundation 20/37

21 Die eigentliche Serverseitige Schnittstelle sieht so aus: [ServiceContract(CallbackContract=typeof(ICalculatorCallback))] public interface IComplexCalculator [OperationContract] void StartOperation(Operation Operation); mit public class Operation internal OperationContext OperationContext get; set; public Operator Operator get; set; public List<double> Operands get; set; Wie bereits beim einfachen Taschenrechner, kennzeichnet das ServiceContract Attribut, dass es sich um eine Schnittstelle handelt, die von außen aufgerufen werden kann. Allerdings wird jetzt ein Parameter CallbackContract verwendet, welcher dem Framework mitteilt, dass jeder Client, der die IComplexCalculator Schnittstelle verwenden will, die ICalculatorCallback Schnittstelle implementieren muss. Die Operation Klasse dient wieder lediglich als Datencontainer und besitzt die zwei öffentlichen Membervariablen Operator und eine Liste von Operanden. Die Property OperationContext wird in dem nächsten Kapitel behandelt und ist nur innerhalb der Assembly sichtbar (da sie als internal gekennzeichnet ist) sie wird in Form von Metadaten (WSDL Daten) nicht übertragen. Seminar Windows Communication Foundation 21/37

22 9 Das OperationContext WCF verschickt bei jedem Methodenaufruf implizit eine Session ID damit kann der Client ermittelt werden, der diesen Aufruf getätigt hat. In einer Methode, die von einem Client aufgerufen wurde, kann diese ID über die statische Property OperationContext.Current abgefragt werden. Darüber hinaus kann mit dem aktuellen Operation-Context auch der zugehörige Callback-kanal ermittelt werden: OperationContext.Current.GetCallbackChannel<ICalculatorCallback>() Der Rückgabetyp dieser Methode ist vom Typ ICalculatorCallback und referenziert die Methode, die vom aufgerufenen Client implementiert wurde. Die StartOperation Methode, die in der IComplexCalculator Schnittstelle deklariert wurde, könnte so aussehen: public void StartOperation(Operation Operation) Operation.OperationContext = OperationContext.Current; lock (this.operations) this.operations.add(operation); Die Klasse Operation hat ein interne Membervariable OperationContext dieser wird auf den aktuellen OperationContext gesetzt und somit zwischengespeichert. Bei der späteren Auswertung besteht damit die Verknüpfung zwischen einer Operation und dem zugehörigen Callback-Kanal, womit das Ergebnis später zurückgeschickt werden kann: var result = ProcessOperation(operation); var callback = operation.operationcontext.getcallbackchannel<icalculatorcallback>(); callback.operationcompleted(result); Seminar Windows Communication Foundation 22/37

23 10 Der ConcurrencyMode Im Normalfall erlaubt WCF nur einen gleichzeitigen Aufruf. Zwei gleichzeitige Aufrufe von zwei verschiedenen Clients werden hintereinander verarbeitet (vgl. Abbildung 7) Abbildung 7: Mehrere Anfragen werden hintereinander abgearbeitet Client B muss warten, bis der Server die Anfrage von Client A verarbeitet hat. Dieses Vorgehen wird dann problematisch, wenn wie in der Fragestellung weiter oben, der Client eine Anfrage schickt, der Server die Anfrage verarbeitet aber bevor er fertig ist eine zusätzliche asynchrone Anfrage vom Server an den Client geschickt werden soll so ein Fall führt zu einem Deadlock des Clients. Und da der Server auf eine Reaktion des Clients wartet, kommt es beim Server ebenfalls zu einem Deadlock! Warum? Der Client schickt eine Anfrage, der Server akzeptiert sie. Damit ist eine Verbindung vom Client zum Server geöffnet. Der Server schickt eine asynchrone Anfrage an den Client, baut damit eine Verbindung vom Server zum Client auf. Der Client meldet allerdings, sie würde noch auf die ursprüngliche Antwort warten; somit wird die Anfrage des Servers in eine Warteschlange gesetzt. Seminar Windows Communication Foundation 23/37

24 Die ursprüngliche Anfrage, die der Server nun abgearbeitet hat, soll beantwortet werden doch nun meldet der Client, dass keine Daten empfangen werden können da in der Warteschlange bereits eine Anfrage steht. 7 Abhilfe kann dadurch geschafft werden, dass sowohl Server als auch Client so konfiguriert werden, dass sie gleichzeitig mehrere WCF Verbindungen erlauben. Der Nachteil: es müssen eigene Vorkehrungen getroffen werden, damit Zugriffe auf gemeinsame Variablen synchronisiert werden (der Aufruf erfolgt aus mehreren Threads) Die Konfiguration erfolgt erneut über Attribute. Diese sind beim Server und beim Client unterschiedlich. Beim Server: [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)] class ComplexCalculator : IComplexCalculator, IDisposable... Der Parameter ConcurrencyMode.Multiple sorgt dafür, dass die Methoden beim Server gleichzeitig von mehreren Clients aufgerufen werden können. Zusätzlich kann beim Server über den zweiten Parameter InstanceContextMode gesteuert werden, wie die Instanzen erzeugt werden sollten. Am Anfang wurde erwähnt, dass jeder Methodenaufruf eine neue Instanz anlegt. Soll der OperationContext zwischengespeichert werden, müsste eine statische Liste benutzt werden, da die Information nicht erhalten bleibt, wenn sie lediglich in einer privaten Membervariable zwischengespeichert wird. Mit InstanceContextMode.Single wird dafür gesorgt, dass es insgesamt nur eine Instanz von dieser Klasse gibt. Entweder wird diese von WCF einmal automatisch erzeugt, oder aber sie wird vom Entwickler erzeugt und dem Framework mitgeteilt, dass sie diese Singleton-Instanz verwenden soll. Dies geschieht im Konstruktor vom ServiceHost: instance = new ComplexCalculator(); host = new ServiceHost(instance, new Uri(" Wurde bislang nur der Typ der Klasse im Konstruktor des ServiceHosts bekanntgegeben, kann stattdessen auch eine Instanzvariable übergeben werden. Diese muss natürlich die entsprechende Schnittstelle implementieren. 7 Weitere Informationen: Seminar Windows Communication Foundation 24/37

25 11 Aufbau des Clients bei der bidirektionalen Kommunikation Der Callback-Client wurde bis jetzt noch nicht behandelt und soll nun anhand des erweiterten Taschenrechners beschrieben werden. Der Grundaufbau ändert sich dabei nicht, allerdings gibt es jetzt ein Interface, welches vom Client implementiert werden muss (die IComplexCalculatorCallback Schnittstelle). [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, UseSynchronizationContext = false)] class ResultReceiver : IComplexCalculatorCallback #region IComplexCalculatorCallback Members public void OperationCompleted(OperationResult Result) if (Result.Succeeded) Console.WriteLine("Operation 0 succeeded! Result = 1", Result.Operator, Result.Result); else Console.WriteLine("Operation 0 failed! Reason: 1", Result.Operator, Result.Error); #endregion Bei der Realisierung wird über ConcurrencyMode wie beim Server gesteuert (siehe dazu Kap. Der ConcurrencyMode), dass WCF Anfragen vom Server gleichzeitig erfolgen dürfen. Der Parameter UseSynchonizationContext = false sagt aus, dass die Synchronisation manuell erfolgt. Der restliche Aufbau unterscheidet sich nur im Konstruktor des ComplexCalculatorClients: var client = new ComplexCalculatorClient(new InstanceContext(receiver)); Der Konstruktor erwartet als ersten Parameter die Implementierung der IComplexCalculatorCallback Schnittstelle in diesem Fall die Hilfsklasse ResultReceiver. Seminar Windows Communication Foundation 25/37

26 12 Fehlerbehandlung Grundsätzlich können über WCF auch Exceptions geworfen werden. Normale Exceptions, also z.b. die Basisklasse Exception, aber auch abgeleite Exceptions wie FileNotFoundException, müssen zunächst explizit gefangen werden schließlich kann WCF nicht wissen, ob der Client sämtliche Stack-Traces und Fehlernachrichten erhalten soll. Über WCF können Exceptions vom Typ FaultException weitergeleitet werden. Soll keine besonderte Fehlerbehandlung auf Serverseite erfolgen und die Fehlerinformationen an den Client weitergeschickt werden, könnte die Realisierung so aussehen: public void StartOperation(Operation Operation) try Operation.OperationContext = OperationContext.Current; lock (this.operations) this.operations.add(operation); catch (Exception exp) throw new FaultException(exp.Message); Aus der ursprünglichen Exception wird eine neue Exception vom Typ FaultException erzeugt und über WCF an den Client geleitet. Da FaultException ebenfalls von der Basisklasse Exception abgeleitet ist, kann der Client ebenfalls auf gewöhnliche Ausnahmen reagieren. Wird auf Serverseite die Exception nicht gefangen, wird dem Client lediglich mitgeteilt, dass ein Fehler aufgetreten ist und die Verbindung wird als fehlerhaft gekennzeichnet. Seminar Windows Communication Foundation 26/37

27 13 Fazit Die vorgestellten Codebeispiele decken dabei lediglich die Grundlagen von WCF ab, sollten jedoch dem Leser die Gedankengänge hinter WCF näher bringen. Mit den vermittelten Informationen sollte die Erstellung von WCF Applikationen möglich sein, die erweitert werden können. Genau dadurch wird WCF auch attraktiv, da sie weder an eine Programmiersprache / -Umgebung noch an ein Betriebssystem gebunden ist und einfache Programme trotzdem schnell und einfach erstellt werden können. 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 8 sowie andere Übertragungsprotokolle gewählt werden die an die eigenen Anwendungsfälle angepasst sind. Theoretisch könnte ein eigenes Protokoll eingebunden werden, welches die Daten über USB oder die serielle Schnittstelle weiterleitet, ohne die Schnittstelle oder Implementierung des Servers verändern zu müssen. Ein andere Möglichkeit wäre, mehrere Übertragungsmethoden zu implementieren, um eine hohe Verfügbarkeit des Servers zu gewährleisten (z.b. sowohl über WLAN als auch über das Kabelgebundene Ethernet). Durch die automatisierte Erstellung des Proxies (für den Client) mit Hilfe von Visual Studio muss bei der Programmierung des Clients relativ wenig redundanter (und damit fehleranfälliger) Code selber geschrieben werden. 8 Erstellung eigener Bindings: Seminar Windows Communication Foundation 27/37

28 A. Anhang Quelltext des Servers namespace CalculatorServer.Contracts [ServiceContract] public interface ISimpleCalculator [OperationContract] double Add(double Value1, double Value2); [OperationContract] double Subtract(double Value1, double Value2); [OperationContract] double Multiply(params double[] Values); [OperationContract] double Divide(double Value1, double Value2); namespace CalculatorServer.Contracts public class Operation internal OperationContext OperationContext get; set; public Operator Operator get; set; public List<double> Operands get; set; public enum Operator Add, Subtract, Multiply, Divide, [ServiceContract(CallbackContract=typeof(ICalculatorCallback))] public interface IComplexCalculator [OperationContract] void StartOperation(Operation Operation); Seminar Windows Communication Foundation 28/37

29 namespace CalculatorServer.Contracts public class OperationResult public Operator Operator get; set; public double Result get; set; public bool Succeeded get; set; public Exception Error get; set; public interface ICalculatorCallback [OperationContract(IsOneWay = true)] void OperationCompleted(OperationResult Result); namespace CalculatorServer.Implementation class SimpleCalculator : ISimpleCalculator static int count = 0; public SimpleCalculator() var thiscount = ++count; Console.WriteLine("SimpleCalculator Constructor called 0 time(s)!", thiscount); #region ISimpleCalculator Members public double Add(double Value1, double Value2) try Console.WriteLine("Calculating 0 + 1", Value1, Value2); return Value1 + Value2; catch (Exception exp) throw new FaultException(exp.Message); public double Subtract(double Value1, double Value2) try Console.WriteLine("Calculating 0-1", Value1, Value2); return Value1 - Value2; catch (Exception exp) throw new FaultException(exp.Message); Seminar Windows Communication Foundation 29/37

30 public double Multiply(params double[] Values) try double ret = 1.0; foreach (double value in Values) ret *= value; return ret; catch (Exception exp) throw new FaultException(exp.Message); public double Divide(double Value1, double Value2) try Console.WriteLine("Calculating 0 / 1", Value1, Value2); return Value1 / Value2; catch (Exception exp) throw new FaultException(exp.Message); #endregion private static ServiceHost host; public static void StartSimpleCalculator() var host = new ServiceHost(typeof(SimpleCalculator), new Uri(" var binding = new BasicHttpBinding(); host.addserviceendpoint(typeof(isimplecalculator), binding, " var metadatabehavior = new ServiceMetadataBehavior(); metadatabehavior.httpgetenabled = true; host.description.behaviors.add(metadatabehavior); host.open(); public static void Stop() if (host!= null) host.close(); host = null; Seminar Windows Communication Foundation 30/37

31 namespace CalculatorServer.Implementation [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)] class ComplexCalculator : IComplexCalculator, IDisposable private List<Operation> operations = new List<Operation>(); private Dictionary<OperationContext, Operation> contexts = new Dictionary<OperationContext, Operation>(); private bool disposing = false; private Thread mythread; public ComplexCalculator() this.mythread = new Thread(ProcessOperations); this.mythread.start(); #region IComplexCalculator Members public void StartOperation(Operation Operation) try Operation.OperationContext = OperationContext.Current; lock (this.operations) this.operations.add(operation); catch (Exception exp) throw new FaultException(exp.Message); #endregion Seminar Windows Communication Foundation 31/37

32 private void ProcessOperations() try List<Operation> tempops; while (!this.disposing) lock (this.operations) tempops = new List<Operation>(this.operations); this.operations.clear(); foreach (Operation operation in tempops) try var result = ProcessOperation(operation); var callback = operation.operationcontext.getcallbackchannel<icalculatorcallback>(); callback.operationcompleted(result); catch (Exception exception) Console.WriteLine("Could not send result!\r\n0", exception.message); tempops.clear(); for (int i = 0; i < 60 &&!this.disposing; ++i) Thread.Sleep(100); catch (Exception exp) Console.WriteLine(exp.ToString()); Seminar Windows Communication Foundation 32/37

33 private OperationResult ProcessOperation(Operation Operation) OperationResult result = new OperationResult(); try switch (Operation.Operator) case Operator.Add: result.result = 0.0; foreach (var value in Operation.Operands) result.result += value; result.succeeded = true; break; case Operator.Subtract: result.result = Operation.Operands[0]; for (int i = 1; i < Operation.Operands.Count; ++i) result.result -= Operation.Operands[i]; result.succeeded = true; break; case Operator.Multiply: result.result = 1.0; foreach (var value in Operation.Operands) result.result *= value; result.succeeded = true; break; case Operator.Divide: result.result = Operation.Operands[0]; for (int i = 1; i < Operation.Operands.Count; ++i) result.result /= Operation.Operands[i]; result.succeeded = true; break; default: throw new Exception("Unsupported Operator!"); catch (Exception exp) result.succeeded = false; result.error = exp; return result; #region IDisposable Members public void Dispose() if (!this.disposing) this.disposing = true; this.mythread.join(); #endregion Seminar Windows Communication Foundation 33/37

34 private static ServiceHost host; private static ComplexCalculator instance; public static void StartComplexCalculator() instance = new ComplexCalculator(); host = new ServiceHost(instance, new Uri(" var binding = new NetTcpBinding(); host.addserviceendpoint(typeof(icomplexcalculator), binding, "net.tcp://localhost/icomplexcalculator"); var metadatabehavior = new ServiceMetadataBehavior(); metadatabehavior.httpgetenabled = true; host.description.behaviors.add(metadatabehavior); host.open(); public static void Stop() if (host!= null) host.close(); host = null; if (instance!= null) instance.dispose(); instance = null; Seminar Windows Communication Foundation 34/37

35 namespace CalculatorServer class ServerProgram static void Main(string[] args) try Console.WriteLine("--- Calculator Server ---"); Console.Write("Starting Simple Calculator..."); SimpleCalculator.StartSimpleCalculator(); Console.WriteLine(" Done!"); Console.Write("Starting Complex Calculator..."); ComplexCalculator.StartComplexCalculator(); Console.WriteLine(" Done!"); catch (Exception exp) Console.WriteLine("--- Exception ---"); Console.WriteLine(exp.ToString()); Console.WriteLine("------"); finally Console.ReadLine(); try catch SimpleCalculator.Stop(); ComplexCalculator.Stop(); Seminar Windows Communication Foundation 35/37

36 Quelltext des SimpleClients (ohne Callbacks) namespace SimpleClient class SimpleProgram static void Main(string[] args) try Console.WriteLine("--- Simple Client ---"); var binding = new BasicHttpBinding(); var address = new EndpointAddress(" var client = new Calculator.SimpleCalculatorClient(binding, address); client.open(); Console.WriteLine("5 + 5 = 0", client.add(5, 5)); Console.WriteLine(" = 0", client.add(5, 10)); Console.WriteLine("1 * 2 * 3 * 4 * 5 * 6 * 7 = 0", client.multiply(new double[] 1, 2, 3, 4, 5, 6, 7 )); catch (Exception exp) Console.WriteLine("--- Exception ---"); Console.WriteLine(exp.ToString()); Console.WriteLine("------"); finally Console.ReadLine(); Seminar Windows Communication Foundation 36/37

37 Quelltext des ComplexClients (mit Callbacks) namespace ComplexClient [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, UseSynchronizationContext = false)] class ResultReceiver : IComplexCalculatorCallback #region IComplexCalculatorCallback Members public void OperationCompleted(OperationResult Result) if (Result.Succeeded) Console.WriteLine("Operation 0 succeeded! Result = 1", Result.Operator, Result.Result); else Console.WriteLine("Operation 0 failed! Reason: 1", Result.Operator, Result.Error); #endregion namespace ComplexClient class ComplexProgram static void Main(string[] args) try Console.WriteLine("--- Complex Client ---"); var receiver = new ResultReceiver(); var client = new ComplexCalculatorClient(new InstanceContext(receiver)); client.open(); var operation = new Operation(); operation.operator = Operator.Add; for (int i = 1; i < 20; ++i) operation.operands = new double[] i,i+1,i*i,100/i,i%5; client.startoperation(operation); Console.ReadLine(); catch (Exception exp) Console.WriteLine("--- Exception ---"); Console.WriteLine(exp.ToString()); Console.WriteLine("------"); Seminar Windows Communication Foundation 37/37