Seite 2: WCF für Webservices & für die Kopplung von .Net-Anwendungen

Inhaltsverzeichnis

Kritik an WCF

Jedoch ist Kritik an WCF angebracht: Microsoft propagiert WCF als Vereinigung und Nachfolgetechnik von ASMX und .NET Remoting. Auch wenn WCF einige Konzepte von .NET Remoting übernommen hat, ist es allenfalls ein echter Nachfolger für ASMX. Als problematisch anzusehen ist, dass WCF nicht kompatibel ist mit bestehenden .NET-Remoting-Endpunkten: Es existiert für WCF keine Implementierung der .NET-Remoting-Serialisierung. WCF mischt sich zwar nicht in die Kommunikation von .NET Remoting ein, sodass .NET-Remoting-Anwendungen weiterhin funktionieren, jedoch ist eine Kommunikation zwischen einem WCF- und einem .NET-Remoting-Endpunkt nicht ohne erhebliche Änderungen im Programmcode realisierbar.

Auch bedeutet WCF eine gewisse Bevormundung der Entwickler, denn Microsoft setzt bei der Technik auf die lose Kopplung im Sinne serviceorientierter Architekturen (SOA). Die von .NET Remoting (oder Vorgängern wie IIOP, RMI und DCOM) angebotene enge Bindung durch verteilte Objekte durch Objektreferenzen ist in WCF nicht mehr enthalten. Wenn sich auch lose Kopplung bewährt hat, gibt es dennoch Szenarien, in denen man Objektreferenzen transparent in einem Netz nutzen könnte. Einen Vergleich zwischen WCF, ASMX und .NET Remoting zeigt Tabelle 2.

	.NET Remoting	ASP.NET Webservices ASMX (mit Webservice Extensions - WSE)	WCF
Betriebssysteme	NT 4, 9x, 2000, XP, 2003, Vista, 2008, Windows 7	NT 4, 9x, 2000, XP, 2003, Vista, 2008, Windows 7	XP, 2003, Vista, 2008, Windows 7
.NET-Versionen für Server	1.0, 1.1, 2.0, 3.0, 3.5, 4.0	1.0, 1.1, 2.0, 3.0, 3.5, 4.0	3.0, 3.5, 4.0
.NET-Versionen für Client	1.0, 1.1, 2.0, 3.0, 3.5, 4.0	1.0, 1.1, 2.0, 3.0, 3.5, 4.0 (auch WCF-Clients möglich)	3.0, 3.5, 4.0 sowie Silverlight 1, 2, 3, 4 (unter bestimmten Bedingungen auch ASMX-Clients möglich)
Transportprotokolle	HTTP, TCP, Named Pipes, AppDomain	HTTP (TCP)	HTTP, TCP, Named Pipes, MSMQ, UDP, Exchange E-Mail, (SMTP)
Formate	Binär, SOAP D/E	SOAP (alle Typen) , (JSON)	SOAP (alle Typen), MTOM, Binäres SOAP, JSON, RSS, ATOM
Hosting	IIS, COM+, eigener Host (Konsole, Dienst)	IIS (eigener Host (Konsole, Dienst))	WAS, IIS, COM+, Eigener Host (Konsole, Dienste), Windows Application Server "AppFabric"
Sicherheit	Ja, aber .NET 2.0	Ja, durch IIS und WSE	Ja, WS-*-Standards, NTLM/Kerberos
Code-Konfiguration	Ja	Ja	Ja
XML-Konfiguration	Ja	Nein (Ja bei WSE)	Ja
Kompatibel zu	(CORBA und RMI durch Drittanbieter)	WSI BP 1.1, (WS-*), tlw. andere SOAP-Webservices	WSI BP 1.1, WSI BP 1.2, WS-*
Kopplungsart	Eng	Lose	Lose / "Enger"
Serviceorientierung (Nachrichtenaustausch)	Ja	Ja	Ja
Objektorientierung (Objektreferenzen)	Ja	Nein	Nein
Nutzbare Datentypen	Alle (im Zweifel ByRef)	Nur XML-serialisierbare	Alle serialisierbaren mit XML-Serializer oder DataContractSerializer
Zirkuläre Referenzen	Ja	Nein	Ja, optional
Bewahrung der Typidentität	Ja	Nein	Ja, optional
Zustandsbehaftung des Servers	Einfach	Optional	Optional
Codierungsaufwand	Hoch	Gering	Mittel
Infrastrukturvoraussetzungen	Gering (Konsole) bis Hoch (IIS)	Hoch (IIS)	Gering (Konsole) bis Hoch (IIS)
Skalierbarkeit	Mittel	Hoch	Hoch

Tabelle 2: Vergleich der Verteilungstechniken in .NET

WCF für Webservices

Die Kommunikation zwischen zwei heterogenen Plattformen über W3C- und WS-*-Standards sind der klassische Webservice-Fall, wobei .NET entweder als Client oder als Server zum Einsatz kommen kann. Beschränkt sich die Kommunikation auf die in WSI Basic Profile 1.1 festgelegten Standards, braucht man kein WCF, denn die ASP.NET-Webservices erfüllen die Anforderung genauso. Viele Entwickler finden sogar ASMX in der Handhabung einfacher als WCF. Das liegt aber nur daran, dass Letzteres mehr Optionen bietet und daher die Konfiguration schon im Grundzustand aufwendiger ist. WCF 4.0 bietet daher erstmals Basiskonfigurationen, die in Standardfällen die Notwendigkeit zu Konfigurationseinstellungen auf eine Adressenangabe mit Protokollschema (zum Beispiel http:// oder net.tcp://) beschränken.

In den vielfältigeren Optionen liegt der Vorteil von WCF, wenn man später doch andere Kommunikationsformen benötigt. Wer dennoch mit ASMX beginnt oder begonnen hat, dem fällt der Umstieg auf WCF später nicht schwer. WCF deckt ASMX vollständig in Form des BasicHttpBinding ab. Ein ASMX-Server oder -Client ist kompatibel zu WCF, sodass man bei der Migration von ASMX zu WCF den Server und die Clients unabhängig voneinander umstellen kann. Zwar gibt es keinen Assistenten, der ASMX nach WCF überführt, aber durch Suchen/Ersetzen kann man das Meiste erledigen, zum Beispiel die Annotation [Webservice] durch [ServiceContract] austauschen. Nicht einfach umsteigen lässt sich allerdings, wenn die Webservice Extensions (WSE) für ASMX zum Einsatz kommen. WSE war ein Zusatzprodukt zu ASMX, mit dem schon vor WCF ein Teil der WS-*-Sicherheits- und Zuverlässigkeitsstandards in .NET nutzbar war.

Daran dass auch bei der Verwendung von Standards (SOAP, WSI Basic Profile, WS-*) die Interoperabilität zwischen WCF und anderen Plattformen nicht immer reibunglos funktioniert, ist nicht generell Microsoft schuld. Bei der unterschiedlichen Interpretation der Standards lässt sich meist kein Alleinchuldiger ausmachen. Für die Interoperabilität zwischen .NET-WCF und Java-Metro sei die noch im Aufbau befindliche Artikelserie "WCF & Java Interop" empfohlen.

WCF für die Kopplung der .NET-Anwendungen

Bei der Kopplung zweier .NET-Anwendungen kann man heute zwischen .NET Remoting und WCF wählen, denn .NET Remoting ist auch in den aktuellen .NET-Versionen noch enthalten. Es steht aber auf einem Abstellgleis, denn Microsoft entwickelt die Technik nicht mehr weiter. Die traurige Nachricht für seine bisherigen Nutzer ist, dass es für .NET Remoting und WCF weder eine einfache Migration noch eine Kompatibilität zur Laufzeit gibt. Die Umstellung ist insbesondere eine Qual, wenn man Kommunikationsspielarten von .NET Remoting verwendet, die es in WCF nicht mehr gibt. .NET Remoting erlaubt eine enge Kopplung auf objektorientierte Weise im Stil von CORBA: Clients können Netzwerkobjektreferenzen auf Serverobjekte erhalten, die jede Aktion des Clients auf dem Proxy-Objekt in Wirklichkeit auf dem Server ausführen. Clients können Ereignisse von Serverobjekten konsumieren und auch Parameter in Methodenaufrufen als Referenz übergeben.

WCF ist hingegen eine rein serviceorientierte Kommunikationsarchitektur, bei der Client und Server Nachrichten austauschen. Auch hier gibt es Proxy-Objekte, aber Methodenaufrufe lassen sich auf ihnen in Nachrichten umsetzen. Der Client erhält seine Antwort als Rückgabewert des Methodenaufrufs. Daten über Attribute kann man nicht vom Server abrufen und auch keine Ereignisse im Sinn von .NET konsumieren. WCF enthält andere Konzepte wie Callbacks, die sich aber in der Programmierweise deutlich von der transparenten Vorgehensweise in WCF unterscheiden.

In einem Kommunikationsfall hat .NET Remoting noch eine Optimierung zu bieten, die WCF (noch) nicht kennt. .NET Remoting enthält einen eigenen effizienten Kommunikationskanal zwischen zwei Application Domains im gleichen Prozess (AppDomainChannel). Hier musste man bis in WCF "Named Pipes" einsetzen, was weniger effizient ist.