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.
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? [1]
- VB oder C#? [2]
- Express oder Professional? [3]
- Windows Forms oder WPF? [4]
- LINQ-to-SQL oder ADO.NET Entity Framework? [5]
- Visual Studio auf Deutsch oder auf Englisch? [6]
- ASP.NET, Ajax oder Silverlight? [7]
- DataReader, DataSet oder ORM? [8]
- 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 [9] und die ASP.NET-Webservices [10], 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 [11] und RMI [12] erweiterten, zum Beispiel durch IIOP.NET [13] (eine Implementierung von IIOP für .NET), JIntegra for .NET [14] (eine Implementierung von .NET Remoting für Java) und MiddCor [15] (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 [16] 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)
WCF für Webservices & für die Kopplung von .Net-Anwendungen
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 [17] sei die noch im Aufbau befindliche Artikelserie "WCF & Java Interop [18]" 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 [19] im gleichen Prozess (AppDomainChannel). Hier musste man bis in WCF "Named Pipes" einsetzen, was weniger effizient ist.
Vor- und Nachteile eines Application Server
Vor- und Nachteile eines Application Server
In vielen den Einsatz von WCF diskutierenden Fällen geht es gar nicht um die Kopplung zweier unabhängigen Anwendungen. Vielmehr geht es um die Frage, ob man eine Anwendung aus zwei physikalischen Schichten (Client – Datenbank, alias "2-Tier") oder drei physikalischen Schichten (Client – Application Server – Datenbank, alias "3-Tier") aufbauen möchte. Nur im zweiten Fall braucht man WCF, denn bei zwei physikalischen Schichten kann der Client direkt über die datenbankeigenen Protokolle mit dem Datenbankserver reden, etwa über Tabular Data Stream (TDS [20]) mit Microsofts SQL Server. Die Kommunikation ist in den ADO.NET-Datenbank-Providern gekapselt.
Gerade im deutschen Sprachraum fällt es IT-Experten bei dem Themenkomplex oft schwer, eine gemeinsame Sprache zu finden, denn "Schicht" ist doppeldeutig. Die einen verstehen unter "Schicht" eine rein logische Trennung (im Englischen "Layer"), die anderen meinen damit eine physikalische Trennung ("Tier"), siehe Abbildung 2. Der Autor des Artikels war letztens wieder Zeuge (und Opfer) der Aussage eines "strategischen" IT-Beraters, der verkündete: "Heutzutage sind 3-Schicht-Anwendungen absolute Pflicht, die skalieren besser." Während der Autor die logische Schichtentrennung nicht in Frage stellen möchte, ist er skeptisch in Bezug auf eine so generelle Befürwortung der physikalischen Trennung, nur weil sie "modern" ist. Bevor man sich für das 3-Tier-Modell mit Application-Server-Modell als "Middle-Tier" entscheidet, sollte man die Vor- und Nachteile durchdenken.
Ein Application Server kann rechenintensive und lang andauernde Operationen auslagern, die sonst den Client blockieren würden. Ebenso dient er der Zwischenspeicherung (Caching) von Daten, um die Anzahl der Zugriffe auf die Datenbank zu reduzieren. Wenn die Leistung nicht mehr ausreicht, kann man einfach einen neuen Anwendungsserver dazustellen.
Unterschiedliche Meinungen gibt es dazu, wie viele "Tiers" eine klassische serverseitige Webanwendung mit Webbrowser, Webserver und Datenbank hat. Für die einen ist das schon 3-Tier, für andere wird es erst dazu, wenn den Webserver und die Datenbank noch ein Application Server trennt. Auch ohne ihn kann man in dem Szenario durch weitere Webserver skalieren. Mit einem Anwendungsserver ist die Flexibilität aber größer, denn es lässt sich in Abhängigkeit davon skalieren, ob der Engpass das Rendering der Webseiten oder die Verarbeitung im Hintergrund ist.
Application Server bilden zudem eine Sicherheitsgrenze zwischen Client und Datenbank. Das ist nicht nur in Internet-Szenarien relevant, in denen im Fall der Kompromittierung des Webservers ein Application Server eine zusätzliche Schutzmauer vor der Datenbank bildet. Auch in klassischen Desktop-Anwendungen kann man die Datenbank mit einem Application Server vor dem direkten Zugriff der Clients besser abschotten.
Messung der Leistungseinbußen
Auf der Negativseite steht neben einem viel höheren Entwicklungsaufwand vor allem der zusätzliche Kommunikations-Overhead, den der Einsatz des Anwendungsservers überhaupt erst auslöst. Ein erheblicher Overhead entsteht bei jedem verteilten System, egal welches Framework und welches Protokoll man einsetzt. Im konkreten Fall ist die Größenordnung des Overheads für WCF aufzuzeigen.
Für die Messungen kommt das von dem Autor entwickelte "WCF Barometer [21]" zum Einsatz. 100 Datenbankzugriffe, bei denen sich je 1000 Datensätze (je 12 Spalten, nur elementare Datentypen) aus einer Datenbanktabelle mit 10.000 Datensätzen abholen lassen, dauern rund eine Sekunde, wenn der Client direkt auf das Datenbanksystem zugreifen kann (Abbildung 3).
Schaltet man einen Application Server zwischen den Client und die Datenbank, dauert die gleiche Kommunikation das Elffache (!) länger (siehe Abbildung 4).
Das ist der Overhead für den zusätzlichen Netzverkehr. Der Faktor steigt abermals, wenn man nicht TCP, sondern HTTP als Transportprotokoll einsetzt (siehe Tabelle 3).
| Alle Prozesse auf einem System | Verteilungsmodell 1 | Verteilungsmodell 2 | Verteilungsmodell 3 | |
| Client | Computer 1 | Computer 1 | Computer 1 | Computer 1 |
| Server | Computer 1 | Computer 1 | Computer 2 | Computer 2 |
| Datenbank | Computer 1 | Computer 2 | Computer 2 | Computer 3 |
| 2-Tier (TDS) | 1033 | 1082 | 1082 | 1082 |
| WCF Named Pipes/binär | 9603 | 9732 | n/a (*) | n/a (*) |
| WCF TCP/binär | 9612 | 9715 | 11586 | 12476 |
| WCF HTTP/SOAP | 11080 | 11192 | 13981 | 14099 |
Tabelle 3: Ausführungsdauer für das Lesen von 100 mal 1000 Datensätzen in unterschiedlichen Szenarien.
(*) Mit Named Pipes kann man in WCF nur Prozesse auf dem gleichen System aufrufen.
Den Verzögerungsfaktor kann ein Application Server nicht mehr hereinholen. Abbildung 5 zeigt, dass die Dauer bei 9,5 Sekunden liegt, wenn der Anwendungsserver nur beim ersten Mal die Daten vom Datenbankserver holt und bei den 99 folgenden Aufrufen nur noch die Daten aus seinem Zwischenspeicher im RAM weiterreicht. Er kann allenfalls punkten, wenn eine rechenintensive Verarbeitung hinzukommt und sich viele Daten zwischenspeichern lassen, deren Abholung aus der Datenbank zeitaufwendig ist (etwa wegen vieler Joins). Zu erwägen ist auch eine hybride Architektur, die den Application Server nicht generell für den Zugriff auf Daten zwischenschaltet, sondern nur bei ausgewählten, lang dauernden Vorgänge zum Einsatz kommt.
Fazit
Fazit
WCF ist zweifelsfrei eine mächtige und flexible Infrastruktur, die die effiziente Kommunikation zwischen zwei .NET-Anwendungen und die plattformübergreifende Kommunikation auf Basis von Webservices und WS-*-Standard auf eine gemeinsame Basis stellt. Mit den Konfigurationsvereinfachungen ab WCF 4.0 gibt es keinen Grund mehr, ASMX einzusetzen. .NET Remoting käme noch in Frage, wenn die enge Kopplung über verteilungstransparente Objektreferenzen gewünscht ist. Bevor man aber überhaupt eine weitere physikalische Schicht in seine .NET-Anwendung einzieht, sollte man die Vor- und Nachteile am konkreten Fall abwägen. Der Einsatz jedes zusätzlichen Netzprotokolls bedeutet einen nicht zu unterschätzenden Overhead.
Dr. Holger Schwichtenberg
bietet mit seinem Unternehmen www.IT-Visions.de [22] Beratung und Schulungen im .NET-Umfeld. Er hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher.
(ane [23])
URL dieses Artikels:
https://www.heise.de/-934625
Links in diesem Artikel:
[1] http://www.heise.de/developer/artikel/Reicht-NET-2-0-oder-muss-man-NET-3-5-einsetzen-227230.html
[2] http://www.heise.de/developer/artikel/C-oder-Visual-Basic-Die-richtige-Programmiersprache-fuer-NET-Entwickler-227234.html
[3] http://www.heise.de/developer/artikel/Genuegt-das-kostenfreie-Visual-Studio-Express-oder-muss-man-eine-Professional-Variante-kaufen-227246.html
[4] http://www.heise.de/developer/artikel/NET-Oberflaechen-mit-Windows-Forms-oder-WPF-227252.html
[5] http://www.heise.de/developer/artikel/Verwirrung-um-objekt-relationale-Mapper-LINQ-to-SQL-oder-ADO-NET-Entity-Framework-227256.html
[6] http://www.heise.de/developer/artikel/Visual-Studio-auf-Deutsch-oder-auf-Englisch-403653.html
[7] http://www.heise.de/developer/artikel/Die-Wahl-fuer-das-Web-ASP-NET-Ajax-oder-Silverlight-787452.html
[8] http://www.heise.de/developer/artikel/Daten-im-Zu-Griff-mit-NET-DataReader-DataSet-oder-ORM-802896.html
[9] http://www.it-visions.de/glossar/alle/835/lexikon.aspx
[10] http://www.it-visions.de/l4807.aspx
[11] http://de.wikipedia.org/wiki/IIOP
[12] http://de.wikipedia.org/wiki/Remote_Method_Invocation
[13] http://iiop-net.sourceforge.net/
[14] http://www.intrinsyc.com/products/j-integra.aspx
[15] http://www.middsol.de/middcor.htm
[16] http://www.it-visions.de/glossar/alle/3449/lexikon.aspx
[17] http://java.sun.com/webservices/
[18] http://www.kevingao.net/wcf-java-interop
[19] http://www.it-visions.de/glossar/alle/277/Application%20Domain.aspx
[20] http://www.it-visions.de/glossar/alle/3411/Tabular%20DataStream.aspx
[21] http://www.it-visions.de/dotnet/tools/wcfbarometer.aspx
[22] http://www.it-visions.de/start.aspx
[23] mailto:ane@heise.de
Copyright © 2010 Heise Medien