 |
Microsofts neue Initiative ".NET" wird mit viel Rummel beworben. Grund genug, einmal hinter die Kulissen zu blicken und zu hinterfragen, was .NET eigentlich ist und welche Vorteile es dem Entwickler bietet.
Grundsätzliches
.NET ist ein Konzept zum Objekt-Zugriff übers Internet. Ein Objekt, das im Internet verfügbar ist, heißt "Web Service".
Web Services können nahezu beliebige Daten bereitstellen. So gibt es z.B. Web Services, die die Temperatur in einem US-Bundesstaat liefern oder einen Text übersetzen. Aus der Sicht des Programmierers bedeutet das, auf entfernte Objekte ziemlich einfach zugreifen zu können. Theoretisch ermöglicht das eine Integration und Interaktion der verschiedensten Dienste: so kann z.B. der Routenplaner-Service auf den Verkehrs-Service und den Wetter-Service zurückgreifen, um eine Route zu planen. Der Wetter-Service wiederum spricht die Services der verschiedenen Wettersatelliten-Hoster an etc.
Um einen Web Service und Clients für diesen Service zu erstellen, sollte der Entwickler - das ist jedenfalls die Position von Microsoft - optimalerweise Visual Studio .NET und die Microsoft .NET-Server verwenden.
Zwingend ist das jedoch nicht: Web Services werden u.a. auch von IBM und Sun propagiert. Selbst Microsoft setzt dabei - genau wie die Konkurrenz - auf offene Technologien wie z.B. HTTP, XML und SOAP. Prinzipiell sind die verschiedenen Web Services also miteinander kompatibel.
Im Folgenden werden wir uns die Bestandteile des .NET-Konzepts etwas genauer ansehen.
Visual Studio .NET bzw. das .NET-Framework
Das .NET-Framework ist laut Microsoft "eine Umgebung für die Entwicklung, Bereitstellung und Ausführung von XML-Webdiensten und anderen Anwendungen", die sich aus der Common Language Runtime (CLR) und verschiedenen Klassenbibliotheken zusammensetzt.
Dahinter steckt folgende Idee: Visual Studio .NET, das neue Entwicklungs-Flagschiff, erzeugt künftig nur noch eine Art Bytecode, keine Maschinensprache. Das funktioniert mit jeder Programmiersprache, die vom Visual Studio unterstützt wird. Es ist damit zu rechnen, dass das ziemlich viele sein werden - ActiveState beispielsweise entwickelt gerade eine Perl-Version für den Einsatz im Rahmen von Visual Studio .NET.
Zurück zum Bytecode: die Common Language Runtime ist dafür zuständig, dass die Bytecode-Programme auch ausgeführt werden. Im Gegensatz zu Java handelt es sich hierbei jedoch um einen Compiler, nicht um einen Interpreter. Die verschiedenen Klassenbibliotheken gehören zur CLR: sie liefern die Komponenten, um letztendlich Anwendungen zu entwickeln. So enthält "WinForms" beispielsweise Komponenten für die Windows-Entwicklung. Andere Bibliotheken sind spezialisiert auf die Funktionen, die man für die Erstellung und Nutzung von Web Services benötigt.
Der Bytecode ist prinzipiell plattformunabhängig. Soll heißen: wenn jemand (Microsoft hat dahingehende Pläne) die CLR auf ein anderes Betriebssystem wie Linux portiert, laufen mit Visual Studio .NET erzeugte Anwendungen auch dort. Deshalb wird das gesamte .NET-Konzept gern als plattformunabhängig bezeichnet. Das stimmt aber nur bedingt. .NET hat allenfalls das Potenzial, irgendwann einmal plattformunabhängig zu werden. Nach unserer Einschätzung jedoch wird Microsoft in diesem Bereich langfristig keinesfalls die Stufe von Java erreichen - Java beginnt gerade, sich für Mobile Appliances wie Handys durchzusetzen.
Fazit: die Entwicklungsumgebung und das Framework sind interessante Ansätze mit Zukunftspotenzial. Auf die (angebliche) Plattform-Unabhängigkeit jedoch sollte man nicht allzu viel geben.
Web Services
Web Services werden als DIE Innovation schlechthin angepriesen. Ganz so ist es aber leider nicht: die Idee, Objekte und Funktionen übers Netzwerk aufzurufen, ist alles andere als neu. Remote Procedure Calls und Corba seien hier nur als Stichworte für an weiterer Recherche interessierte Leser genannt.
Das Besondere an den Web Services ist, dass sie auf offenen Standards basieren, namentlich XML, HTTP, SOAP und WSDL. All diese Technologien sind bereits vom W3C standardisiert worden bzw. durchlaufen gerade den dazu notwendigen Prozess. Im Gegensatz zum .NET-Framework dürfen die Web Services an sich also wirklich als plattformunabhängig durchgehen. Auch muss man sich, wie oben bereits angeschnitten, nicht auf Microsoft beschränken. Andere Hersteller sind hier höchst aktiv, so z.B. Sun mit dem "Sun ONE"-Konzept, bei dem es sich ebenfalls weitgehend um Web Services dreht. Auch ActiveState hat im Rahmen seiner Programmiersprachen-Interpreter (so z.B. ActivePerl) bereits erste Versuche gestartet, Web Services zu integrieren. Diesen Ansätzen werden wir uns in nächster Zeit noch einmal detailliert zuwenden, nicht zuletzt, weil ActiveState die entsprechenden Tools kostenfrei zur Verfügung stellt.
Wie funktioniert nun ein Web Service? Für die Übertragung zwischen Client und Server wird das HTTP-Protokoll genutzt. Vorteil: Firewalls und Proxys machen keine Probleme. Das Datenformat für die Codierung der ausgetauschten Informationen ist SOAP, das Simple Object Access Protocol. Der Name sagt, worum es geht - Objekte via Netzwerk möglichst schnell und einfach zugänglich zu machen. SOAP ist ein XML-Format.
Folgendes Beispiel (von http://www.w3schools.com/soap/soap_example.asp)zeigt einen SOAP-Datenaustausch zwischen Server und Client. Sie müssen nicht genau verstehen, worum es geht, schließlich ist das hier kein SOAP-Tutorial.
Die Anfrage:
<soap:Envelope>
<soap:Body>
<xmlns:m="http://www.stock.org/stock" />
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
Die Antwort:
<soap:Envelope>
<soap:Body>
<xmlns:m="http://www.stock.org/stock" />
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
Nur: woher soll man wissen, welche Web Services es gibt und welche Daten sie erwarten bzw. zurückgeben? Dafür gibt es WSDL (Web Services Description Language), die in maschinenlesbarer Form Informationen über Web Services liefert.
Das UDDI ist dagegen eine Art Branchenverzeichnis für Web Services. Dort finden Sie Informationen über Firmen, sowohl normale Daten wie Kontaktinformationen, als auch die angebotenen Web Services.
Fazit
Microsoft .NET ist eine interessante Technologie, um Web Services zu nutzen, die wahrscheinlich zum nächsten Renner im WWW werden. Nicht vergessen werden sollten Alternativen wie J2EE von Sun, über die wir demnächst berichten werden.
|
|
|
|
Sie wollen diese Seite ausdrucken? Dafür haben wir eine spezielle Druckversion ohne grafische Elemente entwickelt! |
|
|
Einführung in CSS bei HTMLWorld.
|
|
