Denn die WCF – und das ist ja nichts neues – ist extrem flexibel und erweiterbar. Interessant wird es allerdings erst, wenn diese Flexibilität und Erweiterbarkeit in der Praxis effektiv eingesetzt werden kann.

Mit Hilfe von WCF Custom Behavior Extensions kann man elegant eigene Behaviors dem WCF Kommunikationsstrom hinzufügen und somit effizient vertikale Funktionalität wie z.B. Validierung oder Restriktion implementieren.

Zum Artikel habe ich auch noch ein paar Code Samples zum Download bereitgestellt.

Der Abstrakt:

Mit der neuen Windows Communication Foundation (WCF) ist es für .NET-Entwickler einfacher als je zuvor, Web-Service-Technologien zu verwenden. Statt der technologischen Hürde sieht man nun vermehrt konzeptionelle Herausforderungen vor sich. Der Vortrag zeigt die wichtigsten Design Patterns in der Service-Orientierung und Web-Services-Architektur und auf deren Anwendungsbereich, praktischen Nutzen und Implementierung ein. Mit Kenntnis dieser grundlegenden SOA Patterns können stabile, performante und flexible Web Services mit der WCF umgesetzt werden.

Ich freue mich auf viele bekannte Gesichter auf der VSOne und natürlich auf euer Feedback!

Link: VSOne: SOA Patterns mit WCF

Dies deckt sich zum großen Teil auch mit den Erfahrungen, die ich bis Dato machen konnte. Schade finde ich es, dass der Performance-Vergleich z.B. nicht auf die einzelnen Bindings der WCF eingeht – aber der Artikel will ja primär die neue Technologie mit der alten vergleichen. Ich für meinen Teil durfte feststellen, dass für HTTP das BasicHttpBinding das schnellste ist. Wen wundert’s, es ist auch das einfachste.

Das bringt vor Allem Vorteile bei der Interoperabilität, denn “einfache” SOAP-Clients wie bei PHP oder Flex sind im Allgemeinen nicht in der Lage, den <import>-Definitionen innerhalb eines WSDL-Dokumentes zu folgen.

Der von Weyer beschriebene Ansatz ist einfach umzusetzen und funktioniert blendend. Ich möchte dazu allerdings ein paar Kleinigkeiten ergänzen, die leider meiner Meinung nach nicht ganz deutlich hervorgehoben wurden:

• Das “flattening” der WSDL-Definitionen funktioniert nur bei einem konfigurierten Endpoint
  (Ein üblicher Metadata-Exchange-Endpoint entfällt, weil es sowieso programmatisch hinzugefügt wird)
• Der “bindingNamespace” des Endpoints muss demselben Namespace entsprechen wie der, der im ServiceBehaviorAttribute und ServiceContractAttribute angegeben ist.

Für mich persönlich kann ich einen sehr positiven Eindruck von der Veranstaltung feststellen, zumal ich denke dass doch einige Teilnehmer nach dem Vortrag ein paar neue Erkenntnisse für sich mitnehmen konnten. Die angenehme und wissensdurstige Atmosphäre hat sicherlich seinen Beitrag für dazu geleistet, das ich meine Aufgabe als Referent mit einem gewissen Spaßfaktor erfüllen konnte.

Für all diejenigen, die nicht an der Veranstaltung teilehmen konnten oder die Teilnehmer, die gerne dass ganze nochmal nachlesen möchten habe ich im Works-Bereich einen Artikel bereitgestellt, in der die Kernthemen des Vortrages festgehalten sind. Dort stehen übrigens auch die Präsentation selbst sowie die gezeigten Code-Samples zum Download bereit.

Ich bin wie immer gespannt auf Feedback & Kommentare. Viel Spaß mit den Web Services Grundlagen.

Völlig parteilos – ich kenne beide Entwickler :-) – möchte ich diese zwei Design-Konzepte ein wenig aus meiner eigenen Betrachtungsweise durchleuchten. Auf gut englisch – my 2c…

Zunächst sollte man sich meiner Meinung nach der Natur des Web Services im Klaren sein. Konkret ist ein Web Service eine öffentliche Schnittstelle zum Aufruf einer entfernten Operation. Nun ist soetwas ja nicht das 8. Weltwunder – will heissen dass es viele weitere, zum Teil deutlich ältere Technologien gibt, die das gleiche bezwecken wollen – es seien hier nur RPC und CGI als prominente Beispiele erwähnt. Das Problem “stateful” vs. “stateless” stellt sich also nicht erst seit dem es Web Services gibt.

Einen entfernten Aufruf – den berüchtigten “Remote Call” durchzuführen ist mit der Web Services-Technologie mittlerweile kinderleicht. Remote operations zur Verfügung zu stellen ist mit dem .NET Framework zum Beispiel fast genauso kinderleicht. Umso mehr sind Entwickler dazu geneigt, diese Leichtigkeit der Verwendung mit “Leichtsinnigkeit” zu verwechseln. Denn die Tragweite der Entscheidungen über ein Web Service Design kann manchmal ungeahnte Züge annehmen.

Doch zurück zum Thema: Grundsätzlich wurden Web Services für den automatisierten (also maschinellen) Informationsaustausch geschaffen. Per Definition des W3C ist ein Web Service nämlich folgendes:

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

So. Eine klare Ansage. Aber beim zweiten durchlesen wird auch schon deutlich, wo der eigentliche Knackpunkt liegt. Es geht um das Teilstück “…interoperable machine-to-machine interaction…”. De facto lässt sich daraus ableiten, dass in der Idealform jeder Rechner innerhalb eines Netzwerkes jeden Dienst und dessen Operationen ansprechen und verarbeiten kann. Das kann auch komplexere Szenarien unterstützen; z.B dass Rechner, die Dienste zur Verfügung stellen, ihrerseits zur Erfüllung ihres eigenen Dienstes einen oder mehrere andere Dienste in Anspruch nehmen. Weiterhin ist per Definition auch die Multiplizität eines Dienstes freigestellt – d.h. es kann einen oder mehrere gleichartige, oder sogar equivalent operierende Dienste geben, die auf einer oder mehreren Rechnern zur Verfügung gestellt werden.

Bevor es nun zu theoretisch wird, kann man die Gedankenspiele abkürzend auf einen Nenner bringen: Bei Web Services geht es um flexible Kommunikation. Die Operation wird demjenigen zur Verfügung gestellt, der Sie braucht und ist idealerweise jederzeit ersetzbar. Des Weiteren ist die Operation idealerweise kontextunabhängig – lässt sich also ohne weiteres im Verbund mit anderen Operationen aufrufen, um daraus eine neue, sog. “orchestrierte” Operation zu formen.

Ich laufe hier natürlich sehr in Gefahr, in das SOA-Thema auszuschweifen – also gleich weiter mit der Ableitung der Definition des Web Services zu Entscheidungshilfen beim Design von Web Services.

Jetzt, da man die “Natur” eines Web Services sich genauer vor Augen hält, lässt sich eindeutig sagen, dass Web Services per se kontextunabhängig sind – im Resultat also “stateless”. Der Begriff “stateless” ist hier sehr leicht mit “statisch” ersetzbar – soll es aber nicht sein. Ein Web Service ist nicht zwingend statisch, weil es keinen Zustand hat. Der Gedanke der Kontextunabhängigkeit manifestiert sich bei Web Services nahezu überall: Die SOAP-Spezifikation enthält z.B. zahlreiche Möglichkeiten, Meta-Daten mit den Daten zu einer Operation zu übertragen. Im .NET Framework wird standardmäßig bei jedem Web-Service-Methoden-Aufruf die Web-Service-Klasse selbst instanziiert – eindeutige Zeichen dafür, dass Web Services für kontextunabhängige Verwendung ausgelegt worden sind.

Ergo: Web Services sind erst mal von Haus aus “stateless”. Aber wieso spielen nun viele Entwickler mit dem Gedanken, einen Web Service “stateful” werden zu lassen? Das kann viele Unterschiedliche Gründe haben – in dem von mir geschilderten Fall war die Datenmenge der Vater des Gedanken. Es sei hier nur kurz in groben Zügen der Werdegang der Idee zum “stateful” Web Service beschrieben:

Zur Implementierung einer Suche frägt der Client mit variablen Parametern ein Satz von Daten an – die resultierende Datenmenge ist unglaublich groß (sagen wir mal mehrere tausend Datensätze mit einer großen Menge an Daten, sagen wir mal 1MB pro Datensatz). Die Abfrage und Beschaffung der Daten auf der Datenbank kostet sehr viel Zeit (sagen wir mal mehrere Minuten) und kostet unglaublich viel Ressourcen (sagen wir mal es ist eine alte, gebrechliche Datenbank mit wenig Skalierbarkeit). (Merkt man, dass ich nicht gut im Erfinden von Anforderungen bin?)

Um nun Ressourcen zu schonen und die Geschwindigkeit zu erhöhen, kann man eine Session einführen, die bei der initialen Such-Abfrage erstellt wird. Die Abfrage wird gegen die Datenbank ausgeführt, das Ergebnis in der Session gespeichert und nur ein Teil der Daten (sagen wir mal, die ersten hundert) an den Client zurückgeliefert. Sollte der Client in einem zweiten Aufruf mehr Datensätze verlangen, werden die in der Session gespeicherten Daten zurückgeliefert, anstelle eine neue Abfrage gegen die Datenbank abzusetzen.

Ich möchte an dieser Stelle den aufmerksamen Leser bitten, über die Sinnhaftigkeit dieser Idee – wie ich es getan habe – hinwegzusehen und sich nur auf die Thematik der Kontextbezogenheit zu konzentrieren – Danke.

Nun, in Konsequenz würde die Einführung einer Session folgende Auswirkungen haben:
Die Session müsste erstellt werden, ein Session-State-Service müsste die Sessions verwalten. Wie es mit Sessions so ist, wäre die Session nur begrenzt gültig – und damit auch der gewünschte Effekt in begrenztem Maße erreicht. Weiterhin müsste die Session-ID in jedem Aufruf mit übergeben werden – das Interface würde also mit noch mehr Meta-Daten beladen werden. Im Übrigen wäre der Aufruf der zweiten Operation (”gebe mir noch mehr Datensätze”) nur möglich, wenn zuvor die erste aufgerufen wurde.

All diese meiner Meinung nach unvorteilhafen Konsequenzen müsste man in Kauf nehmen, um das gewünschte Ziel zu erreichen. Ein ziemlich teurer Preis wie ich finde.

Mit zustandsbehafteten Web Services schafft man sich aus meiner Sicht den Flaschenhals “Session-Manager” an, erhöht u.U. die “Chattiness” der Kommunikation zwischen Client und Server und schreibt dem Client auch noch Regeln vor, wie er welche Operationen aufzurufen hat, damit er an das gewünschte Ergebnis kommt. Stellt man sich dieses Szenario auch noch in einer Umgebung vor, die für hohe Performance und Verfügbarkeit ausgelegt ist (z.B. im Cluster), kommen noch kleinere Hürden wie Persistierung der Sessions und Web Service Paralellität hinzu.

Alles in allem ist meiner Meinung nach – zumindest für das oben genannte Szenario – ein zustandsbehafteter Web Service
1. schwieriger zu implementieren
2. keine signifikante Alternative zur Steigerung des Datendurchsatzes
3. mit vielen Hürden bespickt (Session-Manager, Multi-Threading)
4. wesentlich schwerer skalierbar
5. für Clients um ein vielfaches komplexer in der Verwendung

Sofern es also nicht wirklich sehr gute Gründe für die Kontextbezogenheit bestimmter Web Service-Methoden gibt, gilt beim Design von Web Services für mein Dafürhalten die grundlegende Orientierung nach der eigentlichen technologischen Ausrichtung des Web Services – stateless.