14.05.2010, 21:55 Uhr

Was ist neu bei WCF 4.0?

Das .NET Framework 4.0 bringt auch für dieWindows Communication Fundation (WCF) einige wichtige Änderungen. Im direkten Vergleich mit der Workflow Foundation4.0 fallen die Änderungen der WCF allerdings nicht revolutionär aus. Die gute Nachricht ist, das Entwickler nicht umdenken müssen und trotzdem einige heute fast undenkbare Szenarien mit der WCF 4.0 realisieren können.
von Damir DobricDie wichtigsten Neuerungen von WCF 4.0 lassen sich in fünf Kategorien unterteilen:1. Eine vereinfachte Konfiguration 2. Service Discovery3. Routing Service4. Workflow Services5. REST-Support Da Punkt 1 in der DeveloperWorld unter [1] bereits ausführlicher erläutert wurde, wird das Thema vereinfachte Konfiguration in diesem Beitrag nur kurz beschrieben.Das Konfigurieren wird einfacherWCF 4.0 vereinfacht die teilweise komplexe Konfiguration von Services. Zum Beispiel durch die neu eingeführten Default-Endpoints. Diese werden per Definition immer dann verwendet, wenn ein Service nicht explizit konfiguriert werden soll oder kann. In solchen Fällen wird ein vordefiniertes (default) basicHttpBinding verwendet. Wird ein Default Binding (z.B. basicHttpBinding) mit einer abweichenden Konfiguration benötigt, wird dazu einfach ein basicHttpBinding ohne Namen in der Konfiguration eingetragen. Damit wird dieses Binding als Default von allen Services verwendet, die das HTTP-Protokoll verwenden. Jedes Protokoll besitzt einen sog. Scheme-Identifier (http, tcp, usw.), für den ein Default-Binding definiert ist. Das vorgegebene Mapping kann mithilfe des Protocol Mappings verändert werden.Bei WCF 4.0 können Services auch ohne eine Svc-Datei aktiviert werden. Diese neue Form der Aktivierung heißt "Service Activation". Die Konfiguration des Service "MyService" in Listing 1 führt eine solche Aktivierung durch. MyServiceAssembly, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>Listing 1: Service-Aktivierung ohne Svc-Datei Eine weitere Neuerung ist der Multiple Site Binding Support. In der Praxis muss nicht selten ein Service über mehrere Hostheader erreichbar sein, z.B. http://sample1/service.svc und/oder http://sample2/service.svc. Wer sich unter WCF 3.5 schon einmal an der Konfiguration eines solchen Service versucht hat wird festgestellt haben, dass dies nicht einfach zu realisieren war. Listing 2 zeigt, wie das per WCF 4.0 erledigt wird. Damit es funktioniert, müssen im IIS die Hostheader ("sample1" und "sample2") definiert und diese entsprechend im DNS registriert sein.Listing 2: Multiple Site Binding SupportWCF 4.0 bietet eine Reihe neuer Standard-Endpoints: announcmentsEndpoint, discoveryEndpoint, udpAnnouncmentEndpoint, udpDiscoveryEndpoint und workflowControlEndpoint. Diese Endpoints erweitern die Möglichkeiten des Services, die nicht unbedingt etwas mit der Business Logik des Services zu tun haben. Zum Beispiel dient der discoveryEndpoint dazu, den Service "discoverable" zu machen.Service Discovery WCF ist eine der mächtigsten und wichtigsten Technologien innerhalb der Microsoft-Plattform. Trotzdem gibt es immer noch nicht gerade unwichtige Anforderungen, für die WCF keine Lösung anbietet. Ein Beispiel ist ein Service, der mehrere Consumer bedienen soll. So lange es nur um einen oder zwei Consumergeht ist das kein Problem. Doch was ist, wenn ein Service mehrere hundert Consumerbedientund sich bei diesem Service plötzlich sein Binding oder gar seine URI ändert? War ein Service bislang unter http://domain.de/path/service.svc erreichbar und besitzt die neue Version auf einmal die URI http://domain.de/path1/newservicename.svc, muss der "Service-Verantwortliche" alle hundert Consumeranpassen. Man darf erwarten, dass eine Service-Infrastruktur im 21. Jahrhundert dazu in der Lage ist, das selber zu regeln. WCF 4.0 bietet tatsächlich einiges an, das dieses Problem automatisch lösen könnte. Die Betonung liegt auf "könnte", denn auch WCF 4.0 ist in diesem Punkt noch nicht perfekt. WCF 4.0 implementiert die aktuelle WS Discovery Spezifikation 1.1 [1], die auf der Basis von SOAP-Messages und UDP ein Protokoll definiert, mit dessen Hilfe sich Services Auffinden lassen[2]. Die Spezifikation beschreibt einen Ad-Hoc- und einen Managed-Mode. Im Ad Hoc-Mode (Abbildung 1) sendet der Consumer eine Resolution Request-Message zu einer Multicast-Gruppe. Die WS Discovery Spezifikation definiert den Discovery Port 3702 [IANA] und die IPv4 Multicast-Adresse 239.255.255.250, sowie die IPv6-Adresse FF02::C (link-local scope). Ein Consumer kann nach Type, Scope, Namen usw. suchen und der gesuchte Service antwortet direkt dem Consumer. Dieses "Pooling-Concept" ist einfach, kann aber bei einer großen Anzahl von Consumernund Services eine Netzwerküberlastung zur Folge haben. Um das zu verhindern, können Services ihre Announcment-Messages beim Start oder beim Beenden senden, so dass der Consumer nicht laufen "pollen" muss. Abbildung 1: Der Discovery Add-Hoc Mode Da die UDP-Pakete nur im eigenen Netzwerk Segment übertragen werden, ist dieses Konzept unzureichend. Abgesehen davon ist auch das beschriebene "broadcasting" eine Belastung für das Netzwerk. Die Spezifikation sieht für solche Fälle den Managed-Mode (Abbildung 2) vor. Dabei wird ein Discovery Proxy eingesetzt. Ist ein Discovery Proxy im Spiel, senden alle Services Unicast Messages zum Proxy, der diese Informationen verwalten muss. Die Consumer melden sich in diesem Modus stets per Unicast-Message beim Proxy an. Dadurch wird das Netzwerk nicht durch Multicast Messages belastet. Abbildung 2: Der Discovery Managed ModeWCF Routing ServiceDurch die steigende Anzahl von Services im Unternehmen wächst logischerweise die Komplexität der Gesamtlösung. Damit stößt man manchmal an Anforderungen, die nicht immer einfach lösbar sind. Zum Beispiel könnte es eine Service-Instanz geben, die im Unternehmen unter einer speziellen Sicherheitsrichtlinie läuft. Eines Tages soll dieser Service z.B. im Extranet eingesetzt werden, wo in den meisten Unternehmen andere Sicherheitsrichtlinien gelten. Für diese Situationen bietet WCF 4.0 einen Routing Service. Dabei werden die Messages aus dem Extranet an den Router geschickt und nach Extranet-Sicherheitsrichtlinie behandelt. Der Router agiert beim Empfang einer Message als Client und leitet die Message nach der üblichen Sicherheitsrichtlinie an den Service weiter. Der Einsatz des Routing Service erfordert auf der Client-Seite keine größeren Anpassungen, außer dass die Messages direkt an den Router geschickt werden. Auf der Service-Seite wird ebenfalls keinen Code benötigt, denn das Routing wird in der Konfiguration des Routing Service vollständig beschrieben. WCF Workflow Services und AppFabricBei .NET 4.0 wurde die Windows Workflow Foundation (WF) bekanntlich komplett neu implementiert. Eine der wichtigsten Neuerungen ist, dass bei WF 4.0 Workflows auch deklarativ beschrieben werden können. Durch die erweiterten XAML-Möglichkeiten von .NET 4.0 kann eine WF-Anwendung damit komplett auf Assemblies verzichten. Darüber hinaus ist WF 4.0 vollständig mit WCF 4.0 integriert. WF 4.0 erhält damit einen echten Host mit dem Namen AppFabric.AppFabric ist Microsoft neues Server Produkt, das die Orchestrierung von Business-Prozessen, die auf der Basis von WCF 4.0 oder WF 4.0 implementiert werden, übernimmt. WF-Anwendungen, die in der AppFabric gehostet werden, werden über Messages aktiviert. Da diese Mechanismen auf der Basis von WCF implementiert werden, sind solche Workflows im Grunde Services auf einem höheren Abstraktionslevel. Sie können z.B. sehr lange laufen und ihren Zustand persistieren. Dank AppFabric sind sie auch clusterfähig. Allerdings wurde die aktuelle Version von AppFabric noch nicht wirklich für Windows Azure implementiert und sollte deshalb (noch) nicht mit der AppFabric Cloud-Varianten verwechselt werden. REST-SupportDie meisten REST Features von WCF waren bislang nahezu ausschließlich im WCF Starter Kit zu finden. Mit .NET 4.0 wurden sie zum festen Bestandteil von WCF 4.0. Die Templates des WCF Starter Kits sind allerdings kein fester Bestandteil von VS 2010, sondern müssen, z.B. über die Projektkategorie "Online Templates" nachträglich installiert werden. Möchte man unter VS 2010 einen REST-Service erstellen, verwendet dazu die Vorlage "WCF Rest Project". Ein REST-Service Projekt enthält eine Global.Asax Datei damit die Routing Table für den Service angelegt werden kann:RouteTable.Routes.Add(newServiceRoute("Service1", newWebServiceHostFactory(), typeof(Service1))); Diese Registrierung definiert eine Route für den Service1 mit gegebener HostFactory. Definiert der Service die folgende Operation[WebGet(UriTemplate = "")]publicListGetCollection() kann diese mit der folgenden URI erreicht werden: http://host/service1. Besitzt ein Service Eingabeparameter, werden deren Werte an die URI angehängt. Für die Operation [ebGet(UriTemplate = "{id}")]ublicMyResource Get(string id)lautet der Aufruf mit für den id-Parameter mit dem Wert 123 wie folgt: http://host/service1/123 . Etwas komplexer ist das folgende Beispiel mit zwei Argumenten:[WebGet(UriTemplate = "gettime/{zone}/{format}")]PublicDateTimeGetTime(string zone, string format) Die URI für diese Operation lautet entsprechend: http://host/service1/gettime/berlin/YYYYMMDD.Mit Hilfe URI-Templates kann man Service-Abfragen beliebig "stylen". Am einfachsten ist es, einen URI zu verwenden, der verschiedene HTTP-Methoden einsetzt. Um zum Beispiel eine Ressource zu erzeugen, wird die Create-Operation definiert:[WebInvoke(UriTemplate = "", Method = "POST")]publicMyResourceCreateResource(MyResource instance) Ausgeführt wird die Operation über den URI http://host/service1. Allerdings müsste der HTTP-Body die Definition von MyResource enthalten. Im JSON würde dies wie folgt aussehen:{"Id":2147483647,"StringValue":"String content"} Damit ist es möglich, auch HTTP-Methoden wie PUT (für UpdateResource) oder DELETE (für DeleteResource) anzuwenden. Zu einem WCF-REST-Projekt gehört eine automatisch generierte Hilfeseite, die unter http://host/service1/help aufgerufen wird. Sie beschreibt die zur Verfügung stehenden REST-Services und ist eine hilfreiche Ergänzung zu den fehlenden WSDLs. Beispiele für REST-Services gibt es vom Autor unter [6]. Abbildung 3: Auch für VS 2010 stehen WCF-REST-Templates über die Online-Templates zur Verfügung Damir Dobric ist Mitinhaber des Systemhauses Daenet in Frankfur a. M./Deutschland, das sich auf die Realisierung von Lösungen im Microsoft-Umfeld und anspruchsvolle, verteilte Anwendungen spezialisiert hat.Links[1] http://www.computerworld.ch/_misc/article/print/index.cfm?pid=170&pk=49928&op=prn [2] Discovery Spezifikationhttp://docs.oasis-open.org/ws-dd/ns/discovery/2009/01 [3] OASIS Standard, SOAP-over-UDP Version 1.1http://docs.oasis-open.org/ws-83 dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.docx, July 2009[4] Service Discovery:http://developers.de/blogs/damir_dobric/archive/2008/10/19/ws-discovery-messaging-enhancements-in-net-4-0.aspx [5] WCF REST Project Template fuer Visual Studio 2010http://visualstudiogallery.msdn.microsoft.com/en-us/fbc7e5c1-a0d2-41bd-9d7b-e54c845394cd [6] http://developers.de/blogs/damir_dobric/default.aspx Peter Monadiemi


Das könnte Sie auch interessieren