Gleich beim Aufstarten von Visual Basic.Net wird deutlich, dass eine grössere Auswahl an Projekttypen als in VB 6.0 offeriert wird. Verschwunden sind zwar ActiveX-Dll- und ActiveX-Exe-Projekte, da COM in der .Net-Welt nur noch als Kompatibilitätsbrücke nötig ist, dafür sind interessante neue Projekte hinzugekommen.
Auch wenn sich die meisten Visual Basic-Programmierer zunächst mit den Windows-Anwendungen beschäftigen werden, da diese dem vertrauten Standard-Exe-Projekttyp entsprechen, und die neuen Windows-Forms-Formulare mit ihren erheblich erweiterten Eigenschaften alleine schon Anreiz genug für einen Umstieg nach .Net sein dürften, haben natürlich auch die übrigen Projekttypen ihre speziellen Reize.
Da wäre vor allem die Konsolenanwendung zu nennen, die zwar über keine grafische Oberfläche verfügt, doch gerade durch diese Schlichtheit für viele Anwendungen sehr attraktiv ist. Eine Konsolenanwendung läuft in der Eingabeaufforderung (bzw. dem MS-DOS-Fenster von Windows 9x) und führt Ein- und Ausgaben ausschliesslich über die Tastatur durch. Dadurch kommt dieser Anwendungstypus immer dann in Frage, wenn ein Programm lediglich seinen Dienst verrichten soll und daher keine ausgefallene Oberfläche benötigt. Dieser Projekttyp ist gerade zum Lernen und Unterrichten sehr praktisch, denn das ABC der Klassenprogrammierung lässt sich in einer simplen Konsolenanwendung wunderbar einfach veranschaulichen.
Apropros Dienst: Ein Projekttyp, der rein gar nichts mit dem Thema Webdienste & Co. zu tun hat, ist der Windows-Dienst. Ein solcher Dienst ist ein Systemprogramm für Windows NT/2000/XP, das im allgemeinen mit dem Start des Betriebssystems aktiv wird, über keine Oberfläche verfügt (auch wenn es möglich wäre) und sich unauffällig im Hintergrund hält. Windows-Dienste überwachen zum Beispiel die Aktivitäten des Benutzers oder stellen wichtige Funktionen des Betriebssystems wie einen Webserver zur Verfügung. War die Programmierung unter Visual Basic 6.0 eine regelrechte Herausforderung, wenn man nicht auf Tools von Drittanbietern ausweichen konnte, so ist sie unter Visual Basic.Net ein Kinderspiel, da sich der Programmierer um keine Formalitäten mehr kümmern muss.
Auch wenn sich Microsoft grosse Mühe gegeben hat, auch jenen Programmierern, die ihre Zukunft noch nicht als Webprogrammierer sehen, einen Anreiz zu geben - der grosse Schwerpunkt von Visual Basic.Net liegt selbstverständlich auf den Webanwendungen und den brandneuen Web-Services, die eine vollkommen neue Art der Zusammenarbeit im Internet versprechen.
Auch unter Visual Basic 6.0 liessen sich Webanwendungen im Rahmen des IIS-Projekttyps umsetzen. Die Programmierer mussten jedoch stets gewisse Limitierungen in Kauf nehmen. Eine IIS-Anwendung basierte zwar auf dem Modell der Active Server Pages (ASP) und damit auf dem Microsoft-Standard für Webanwendungen, war relativ einfach zu programmieren und bot zudem auch eine zufriedenstellende Performance - richtig glücklich werden konnte man mit dieser Variante jedoch nicht.
Viele Visual-Basic-Programmierer taten sich grundsätzlich schwer damit, sich in das verbindungs- und zustandslose Modell einer Webanwendung hineinzudenken. Das Erstellen der Benutzeroberfläche musste entweder mit einem separaten HTML-Editor oder per "Visual Notepad" geschehen, was für die meisten VB-Programmierer nicht in Frage kam und ein wenig der Aufforderung gleichkam, in C oder gar Maschinencode programmieren zu müssen.
Erschwerend kam hinzu, dass der IIS-Projekttyp eine Eigenentwicklung des Visual-Basic-Teams bei Microsoft war und zu einem Zeitpunkt konzipiert wurde, als der Nachfolger von ASP bereits in Konturen sichtbar war. Es hätte von Anfang an klar sein müssen, dass der IIS-Projekttyp keine Zukunft haben würde.
Das alles wird spätestens mit der Auslieferung von Visual Basic.Net Vergangenheit sein. Die nächste Version verspricht nicht nur, dass sich Webanwendungen künftig so einfach programmieren lassen werden wie heute Windows-Anwendungen, sehr viel schwerer wird der Umstand wiegen, dass Visual-Basic-Programmierer sich in Zukunft nicht mehr als "Webprogrammierer 2. Klasse" fühlen müssen. Im Gegenteil: Visual Basic dürfte sogar zu der Programmiersprache fürs Web und Visual Basic.Net zu dem wichtigsten Entwicklungswerkzeug dieses Anwendungstyps werden. Ein Visual InterDev wird es übrigens nicht mehr geben, die Funktionalität wurde in Visual Studio.Net integriert.
Das Zauberwort für das alles heisst ASP.Net. Die nächste Generation der immer populärer werdenden Active Server Pages hat mit ihrem Vorgänger im wesentlichen den Namen und einige gemeinsame Konzepte gemeinsam. Ansonsten hat Microsoft die inzwischen etwas betagten ASPs generalüberholt.
Die wohl wichtigste Neuerung besteht darin, dass es keine Script-Programmierung mehr gibt. ASP.Net-Anwendungen werden wahlweise in Visual Basic.Net, C# oder jeder anderen .Net-Sprache (COBOL.Net von Fujitsu Software scheint sich wohl einer gewissen Beliebtheit zu erfreuen) programmiert, wobei es überhaupt kein Problem ist, die einzelnen Sprachen nahezu beliebig zu kombinieren. Das bedeutet, dass eine ASP.Net-Anwendung aus kompiliertem Maschinencode besteht, der in einer komfortablen Entwicklungsumgebung nicht nur entwickelt, sondern auch ausführlich getestet wurde.
Die Zeiten, in denen Visual-Basic-Programmierer ihre VBScripts mit Notepad eintippen und per FTP auf den Webserver kopieren mussten, in der Hoffnung, dass alles irgendwie gut gehen würde, sind damit vorbei. Der einzige kleine Schatten am ansonsten strahlend blauen Himmel ist der Umstand, dass das Angebot von Internet-Dienstanbietern am Anfang gerade in der Schweiz und in Deutschland noch relativ gering sein dürfte und VB-Entwickler auf die zahlreichen Provider in den USA angewiesen sind, was aber grundsätzlich kein Nachteil sein dürfte. Im Rahmen einer Kooperation mit Microsoft bietet der US-Provider www.brinkster.com sogar ein kostenloses Hosting für ASP.Net-Anwendungen an - es spricht also einiges dafür, nicht länger zu warten und die erste ASP.Net-Applikation mit Visual Basic.Net am Wochenende nicht nur umzusetzen, sondern gleich auch online zu bringen.
Die Grundlage für eine Webanwendung mit Visual Basic.Net ist der Projekttyp ASP.Net-Anwendung. Nach dem Anlegen eines neuen Projekts wird auf dem lokalen Webserver ein virtuelles Verzeichnis mit dem Namen des Projekts angelegt. Hier werden später alle Projektdateien gespeichert.
Die wichtigste Datei im neuen Projekt ist das WebForm-Formular. Dabei steht hinter jedem WebForm eine Aspx-Seite, die später über den Webbrowser aufgerufen wird. Die Idee der WebForms ist simpel: Sie sollen Visual-Basic-Programmierern den gleichen Komfort bieten, den sie von Windows-Formularen seit jeher gewöhnt sind. Da eine HTML-Seite allerdings keine normalen Steuerelemente beinhalten kann (ActiveX ist in diesem Zusammenhang zum Glück kein Thema mehr), gibt es spezielle Steuerelemente für WebForms, die ihren Windows-Pendants weitestgehend entsprechen. Diese unterteilen sich in zwei Gruppen: HTML-Steuerelemente und WebForms-Steuerelemente. Erstere entsprechen 1:1 den durch den HTML-Standard definierten Elementen. Sie bieten zwangsläufig weniger Möglichkeiten, stellen aber sicher, dass ein Formular browserunabhängig angezeigt werden kann.
Die WebForms-Steuerelemente als zweite Variante sind dagegen deutlich vielversprechender. Ihr unscheinbares Attribut "runat=server" sorgt dafür, dass sie bereits vor dem Abruf der Aspx-Seite auf dem Server ausgeführt werden. Dabei werden ihre zahlreichen Eigenschaften und Attribute ausgewertet und in HTML-Code umgewandelt, der an den Browser geschickt wird.
Übrigens lässt sich jedes HTML-Steuerelement nachträglich durch Hinzufügen von "runat=server" (was sich am einfachsten durch Anklicken mit der rechten Maustaste und Auswahl von "Als Server-Steuerelement ausführen" realisieren lässt) in ein WebForms-Steuerelement umwandeln. WebForms-Steuerelemente ähneln nicht nur optisch ihren Windows-Kollegen, sie verhalten sich auch so. Ein Doppelklick auf ein Steuerelement schaltet wie gewohnt auf das Programmcodefenster um, wo nun wie üblich eine Reihe von Ereignisprozeduren zur Verfügung steht. Nach dem Start der Anwendung wird die Aspx-Seite kompiliert und vom Internet Explorer angezeigt. Es ist wichtig, festzuhalten, dass Aspx-Seiten, wie ihre ASP-Vorgänger, grundsätzlich browserneutral sind (von den üblichen Feinheiten einmal abgesehen).
Eines der absoluten Lieblingsthemen der Microsoft-Strategen sind derzeit natürlich die Web-Services. Man lässt kaum eine Gelegenheit aus, um auf die Wichtigkeit und das enorme Potential dieser kleinen "Wundertierchen" hinzuweisen. Selbst das kommende Windows XP kann im Rahmen seiner Benutzeroberfläche (etwa, wenn es um das Bestellen von Abzügen von digitalisierten Bildern geht) auf Web-Services zugreifen und avanciert dadurch bereits zum ".Net-Betriebssystem".
Doch was steckt dahinter? Ein Webservice ist zunächst nichts anderes als ein x-beliebiges Programm, das auf einem Webserver ausgeführt wird, über keine eigene Benutzeroberfläche verfügt und Ein- und Ausgaben über das HTTP-Protokoll erledigt. Ein Web-Service besteht im allgemeinen aus mehreren Funktionen, die unabhängig voneinander aufgerufen werden können. Um möglichst universell einsetzbar zu sein, erfolgt sowohl der Funktionsaufruf als auch die Rückgabe der Ergebnisse im XML-Format.
Bei Microsoft basieren auch Web-Services auf ASP.Net. Es handelt sich um eine spezielle Sorte von Webanwendungen, sowohl was die Umsetzung als auch die Einbeziehung durch einen potentiellen Client angeht. Wie auch bei den ASP.Net-Anwendungen gilt, dass ihre Umsetzung mit Visual Basic.Net spielend einfach möglich ist. Das folgende kleine Beispielprojekt soll es unter Beweis stellen:
Legen Sie dazu als erstes ein neues VB.Net-Projekt vom Typ ASP.Net Webdienst an. Dadurch wird ein Projekt angelegt, das wie bei einer Webanwendung aus mehreren Dateien besteht. Die wichtigste Datei ist das File mit der Erweiterung .asmx, welches den Webdienst beinhaltet. Erwird mit der Designoberfläche angezeigt, auf die man für die Realisierung anspruchsvollerer Dienste einzelne Server-Komponenten ziehen könnte.
Schalten Sie dann mit F7 auf das Programmcodefenster um. Der Webdienst soll "zu Fuss" programmiert werden. Fügen Sie im oberen Teil des Klassenmoduls zwei Imports-Befehle ein:
Dies ist ein reiner Formalismus, der später eine unnötige Warnung vermeiden soll. Die angegebene URL wurde rein willkürlich gewählt. Achten Sie darauf, dass der Klassenname bei dieser Gelegenheit in DevisenService umgetauft wurde. Fügen Sie die einzige Funktion des Webdienstes ein. Sie heisst DevisenKurs, nimmt ein ISO-Kürzel entgegen, führt eine Abfrage in der Access-Datenbank Devisen.mdb durch (diese Datenbank besitzt lediglich eine Tabelle Devisen mit den drei Feldern ISO, Kurs und Devise) und gibt den Kurs als String zurück. Das Attribut Webmethod sorgt dafür, dass Visual Basic.Net erkennt, dass die Funktion für einen Webdienst implementiert wird, die später über das Web aufgerufen werden kann.
Das war's. Jetzt kann der Webdienst auch schon getestet werden. Visual Studio.Net schafft hier einen enormen Komfort, indem man keine Testumgebung aufsetzen muss. Drücken Sie einfach einmal die Taste und lassen Sie sich angenehm überraschen.
Nach dem Start erscheint der Internet Explorer, der alle Funktionen des Webdienstes DevisenService auflistet. In diesem Fall ist es lediglich die Funktion DevisenKurs. Selektieren Sie den Funktionsnamen. Es erscheint eine neue Seite, die eine Art "Testumgebung" für die Funktion enthält, die aus einem Eingabefeld für den Funktionsparameter und einer Schaltfläche für den Funktionsaufruf besteht. Die übrigen Details müssen Sie im Moment nicht interessieren. Es handelt sich um die komplette Beschreibung der Anfrage, die an den Webserver geschickt wird, und die Rückantwort des Webservers im SOAP-Format, wie obiger Screenshot zeigt.
Geben Sie einfach ein ISO-Kürzel (z.B. USD) in das Eingabefeld ein und klicken Sie auf die Schaltfläche. Durch das Anklicken der Schaltfläche wird die Funktion auf dem Webserver aufgerufen, und die Antwort des Webdienstes wird in einem weiteren Browserfenster angezeigt. Wundern Sie sich nicht über das zunächst etwas eigentümlich erscheinende Format. Das ist XML, wobei der eigentliche Rückgabewert zu erkennen sein sollte. Diese Antwort erhält jeder Client, der den Webdienst aufruft. Es liegt nun an dem Client, die Rückgabe auszuwerten. Wie das mit einem VB.Net-Client funktioniert, der einen Webdienst "konsumiert", wird im folgenden gezeigt.
Fügen Sie ein weiteres Projekt hinzu. Es soll sich um eine VB.Net-Konsolenanwendung handeln (es könnte auch ein x-beliebiger Projekttyp sein). Machen Sie dieses Projekt zum Startprojekt, indem Sie das Projekt im Projektmappen-Explorer-Fenster mit der rechten Maustaste anklicken und Als Startprojekt festlegen wählen. Damit die Konsolenanwendung einen Webdienst konsumieren kann, muss eine entsprechende Referenz in das Projekt eingefügt werden. Führen Sie den Menübefehl Projekt - Webreferenz hinzufügen aus. Es erscheint eine HTML-Seite, auf der mehrere Möglichkeiten angeboten werden. Klicken Sie auf die etwas unscheinbare Verknüpfung am unteren Rand mit dem Titel Webreferenzen auf dem lokalen Server.
Auf der nächsten Seite werden in der rechten Fensterhälfte alle auf dem lokalen Webserver vorhandenen Webdienste aufgelistet. Selektieren Sie unseren Webdienst und klicken Sie auf Referenz hinzufügen. Die Informationen stammen übrigens aus einer sogenannten DISCO-Datei. Der Name weckt unter Umständen zwar gewisse Assoziationen an eine unbeschwerte Jugendzeit, steht aber lediglich für "Discovery" und stellt eine rein textliche Beschreibung der auf einem Webserver angebotenen Webdienste dar.
Damit ist der Webdienst in der Konsolenanwendung bekannt und kann auf die gleiche Weise genutzt werden, als wäre es eine lokale Funktion. Geben Sie in das Modul die Befehle aus Listing 2 ein.
Bei localhost handelt es sich um einen Stellvertreternamen für den lokalen Webserver, der über das Einfügen der Webreferenz im Projekt ansprechbar ist. Nach Eingabe des Punktes werden alle Webdienste auf diesem Server aufgelistet. Die Funktion DevisenKurs steht über die Variable oD zur Verfügung, die für den Webdienst in seiner Gesamtheit steht. Starten Sie das Projekt. Kurz darauf sollte der umgerechnete Betrag im Konsolenfenster erscheinen, wie nebenstehende Abbildung zeigt.
Auch wenn sich der Webdienst in diesem absichtlich einfach gehaltenen Beispiel nicht sehr spektakulär präsentiert, darf eines nicht vergessen werden: Zwischen der Konsolenanwendung, die die Funktion des Webdienstes aufruft, und der Funktion selber liegt in der Realität das grosse, weite Internet. Webdienste stellen eine Möglichkeit dar, beliebige Funktionen zur Verfügung zu stellen, die von beliebigen Clients über das Internet aufgerufen werden können. Die Funktion DevisenKurs kann über das allgemeine SOAP-Protokoll auch von einem Unix-Server aus aufgerufen werden. In diesem Fall muss es allerdings eine Infrastruktur geben, die den Aufruf in den vom SOAP-Protokoll erwarteten Rahmen packt und die XML-Rückgabe des Servers auswertet.
Das sind alles Dinge, die Visual Studio.Net dem Programmierer abnimmt und indirekt den Eindruck erweckt, es handle sich um einen ganz normalen Funktionsaufruf.
Mit Visual Basic.Net wird die Rolle von Visual Basic als universelles Entwicklungswerkzeug neu definiert. Webanwendungen und vor allem die neuen Webservices stellen ein enormes Potential dar. Auch wenn zum jetzigen Zeitpunkt noch nicht abzusehen ist, mit welcher Geschwindigkeit sich die ASP.Net-Anwendungen im Web ausbreiten werden, Visual-Basic-Programmierer können diese Entwicklung mit dem sehr angenehmen Gefühl verfolgen, dass es zu ihrem "Lieblingswerkzeug" in den meisten Fällen wohl keine Alternativen geben wird.
