Sinn und Unsinn der Windows Communication Foundation
Microsoft hat das .NET Framework lange Zeit als "Webservice-Infrastruktur" beworben und damit vielen Entwickler nahegelegt, dass eine .NET-Anwendung immer ein verteiltes System sein sollte. Das ist natürlich Unsinn.
- Dr. Holger Schwichtenberg
In fast jeder .NET-Architekturdiskussion steht die strategische Entscheidung über den Einsatz der Windows Communication Foundation (WCF) auf der Agenda. Microsoft hat das .NET Framework lange Zeit als "Webservice-Infrastruktur" beworben und damit vielen Entwickler nahegelegt, dass eine .NET-Anwendung immer ein verteiltes System sein sollte. Das ist Unsinn.
10 wichtige Fragen zu .NET
In dieser zehnteiligen Serie liefert .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen, die .NET-Entwickler beschäftigen.
- .NET 2.0 oder .NET 3.5?
- VB oder C#?
- Express oder Professional?
- Windows Forms oder WPF?
- LINQ-to-SQL oder ADO.NET Entity Framework?
- Visual Studio auf Deutsch oder auf Englisch?
- ASP.NET, Ajax oder Silverlight?
- DataReader, DataSet oder ORM?
- Sinn und Unsinn der Windows Communication Foundation
In den ersten drei Versionen des .NET Framework (1.0, 1.1 und 2.0) gab es zwei konkurrierende Ansätze für verteilte Systeme mit .NET: .NET Remoting und die ASP.NET-Webservices, die man nach ihrer Dateinamenserweiterung kurz ASMX nannte. Beide verfolgten unterschiedliche Ziele. .NET Remoting war für die proprietäre Kommunikation zwischen zwei .NET-Anwendungen gedacht, während sich .NET mit den ASP.NET Webservices dem Rest der Welt über die beim W3C standardisierte Kommunikation mit HTTP/SOAP öffnete. Microsoft weichte die scharfe Trennung dadurch auf, dass .NET Remoting auch einige Spielarten von HTTP/SOAP verstand und Drittanbieter .NET Remoting um die Kommunikation in Richtung CORBA und Java über IIOP und RMI erweiterten, zum Beispiel durch IIOP.NET (eine Implementierung von IIOP für .NET), JIntegra for .NET (eine Implementierung von .NET Remoting für Java) und MiddCor (eine in .NET geschriebener CORBA-ORB).
Was ist WCF?
Seit .NET 3.0 gibt es mit der Windows Communication Foundation (WCF) einen Ansatz, der die plattformübergreifende Kommunikation und die zwischen .NET-Anwendungen unter einem Dach vereint. WCF hat nicht nur dafür gesorgt, dass es nicht mehr zwei grundverschiedene Herangehensweisen für die beiden Kommunikationsfälle gibt, sondern dass die Anwendung auch ohne Neukompilierung zwischen den beiden Fällen wechseln und sich parallel anbieten lässt.
WCF ist ein Supermarkt mit Angeboten in zahlreichen Kategorien, aus denen sich der Entwickler seinen individuellen Kommunikationskanal zusammenstellen kann (siehe Abbildung 1). Man wählt ein Übertragungsprotokoll (etwa HTTP, TCP, Named Pipes, UDP, SMTP, MSMQ und ein Serialisierungsformat (beispielsweise SOAP, MTOM, ATOM, JSON, RSS oder ein proprietäres Binärformat) sowie optional Standards zur Authentifizierung, Verschlüsselung, Autorisierung, Integrität und Zuverlässigkeit. Dazu gehören WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, WS-Addressing, WS-Federation, WS-ReliableMessaging und WS-AtomicTransactions.
Durch die breite Palette der Protokolle und Formate lässt sich WCF in vielen Szenarien einsetzen, angefangen bei der Kommunikation zwischen zwei lokalen Prozessen, über die Kommunikation zwischen unterschiedlichen Windows-Systemen bis hin zur Kommunikation auf Basis offener Standards (siehe Tabelle 1). Es fehlt lediglich an der Implementierung von IIOP und RMI – WCF erlaubt aber grundsätzlich durch seine Erweiterbarkeit, solche Implementierungen zu erzeugen.
| Kommunikation mit … | .NET Remoting | ASP.NET-Webservices (ASMX) | WCF 4.0 |
| einem anderen Prozess, der auch mit .NET läuft, auf dem gleichen System | ++ | o | ++ |
| einem anderen Prozess, der auch mit .NET läuft, auf einem anderen System | ++ | + | ++ |
| einer anderen Applikations-Domain in dem gleichen .NET-Prozess | ++ | -- | ++ |
| mit CORBA IIOP - oder Java-RMI-Endpunkten | + (mit Drittanbieterwerkzeugen) | -- | - (eigene Erweiterungen notwendig) |
| einem anderen Prozess, der "WSI BP 1.1"-Webservices unterstützt | -- | ++ | ++ |
| einem anderen Prozess, der WS-*-Webservices unterstützt | -- | + | ++ |
| "Web 2.0-Kommunikation" | -- | + (JSON) | ++ (JSON, RSS, ATOM) |
Tabelle 1: Eignung der Verteilungstechniken für unterschiedliche Einsatzgebiete
Die herausragende WCF-Eigenschaft ist, dass sich der Entwickler zur Entwicklungszeit nicht auf eine Kombination der oben genannten Optionen festlegen muss, sondern sich das durch Änderungen der Konfigurationsdatei zur Betriebszeit und sogar durch Einstellungen des Benutzers zur Laufzeit verändern lässt. Auch kann ein Endpunkt in WCF gleichzeitig auf unterschiedliche Weise (beispielsweise TCP/Binär und HTTP/SOAP) mit Clients kommunizieren. Ab WCF 4.0 sind zudem Intermediäre ("Router") einzusetzen, die Nachrichten nach bestimmten Kriterien an andere Dienste verteilen. WCF ist auch für Silverlight verfügbar, was bedeutet, dass Silverlight WCF-Dienste aufrufen kann.
WCF 4.0
Im Rahmen des .NET Framework 4.0 erscheint auch eine neue Version von WCF. WCF 4.0 bietet nun Standardkonfigurationen, die längliche Konfigurationsdateien zur Ausnahme machen. Die interessanteste neue Funktion ist sicherlich das Routing, womit sich der Aufruf des Clients von dem ausführenden Dienst entkoppeln lässt. Der Router in der Mitte kann in Abhängigkeit von zahlreichen Faktoren (z.B. Inhalt der Nachricht oder Auslastung der Server) entscheiden, wer den Aufruf bearbeitet. Durch die Unterstützung von WS-Discovery kann ein Client zudem entsprechende Dienste im Netzwerk finden. Damit wandern zwei zentrale Funktionen von ESB-Systemen (Enterprise Service Bus) in den Kern von .NET. Darüber hinaus bietet WCF 4.0 u.a. folgende Verbesserungen:
- Verbesserungen für REST-Dienste: Help Pages, ASP.NET Cache Profiles, WebOperationContext.Current.GetUriTemplate, WebFaultException<T>
- Mehr Formate (XML, JSON, ATOM, Text, Binary)
- Deklarative Dienstbereitstellung (XAML) mit Workflow Services Dateinamenserweiterung .xamlx
- Neue Standards: WS-I BP 1.2, WS-I RSP, WS-BusinessActivity
- Neue Transportprotokolle: UDP
- DataContractResolver für Typermittlung zur Laufzeit für Serialisierer
- ReceiveContext-Klasse für Genau-einmal-Zustellungen mit MSMQ ohne Transaktionen
- Blob-Übertragung ohne Verpackung mit ByteStreamMessageEncodingBindingElement
- Tracing mit Event Tracing for Windows (ETW)
