Stichworte zur Vorlesung „Neue Softwaretechnologien“ · 2006. 3. 22. · Fachhochschule Kiel...

Fachhochschule Kiel Fachbereich Informatik und Elektrotechnik

Institut für Angewandte Informatik

Prof. Dr.-Ing. Ulrich Samberg

Stichworte zur Vorlesung

„Neue Softwaretechnologien“

Mitschrift von J. Ruhlaender, SS 2004

Das Skript enthält die wesentlichen Stichworte zur Vorlesung. Für die weitere Erarbeitung sind die angegebenen Literaturhinweise bzw.

Internetquellen heranzuziehen.

1 / 52

Prof. Dr.-Ing. Ulrich Samberg Stichworte zur Vorlesung „.Neue softwaretechnologien“

Mitschrift SS 2004

Inhaltsverzeichnis Inhaltsverzeichnis .......................................................................................................................2 1. Windows-Anwendung ....................................................................................................4 2. Windows-Anwendung mit Komponententechnologie....................................................7 3. .NET-Anwendung.........................................................................................................13 3.1 .Net – Architektur .........................................................................................................13 3.2 Geschichte des .NET Frameworks................................................................................13 3.3 Überblick über die öffentlichen Versionen des Frameworks .......................................14 3.4 Zukunft des .NET Frameworks ....................................................................................14 3.5 Zukunft von Visual Studio .NET..................................................................................14 3.6 Verfügbarkeit ................................................................................................................14 3.7 Assembly / MSIL Code – native code ..........................................................................15 3.8 Common Language Runtime (CLR).............................................................................15 3.9 Runtime Hosts...............................................................................................................16 3.10 Sprachintegration ..........................................................................................................16 3.11 Einheitliche Klassenbibliothek .....................................................................................16 3.12 Sicherheitssystem (CAS) ..............................................................................................17 3.13 Komponentenkonzept ...................................................................................................17 3.14 Meta Daten....................................................................................................................17 3.15 XCOPY-Deployment und Versionierung.....................................................................18 3.16 Zum Thema Plattformunabhängigkeit ..........................................................................18 3.18 Interoperabilität.............................................................................................................19 4. Architekturvergleich .....................................................................................................22 4.1 Modell 1: HTML ..........................................................................................................22 4.2 Modell 2: DHTML........................................................................................................22 4.3 Modell 3: ASPX............................................................................................................22 5. Einbindung in eine Anwendungsarchitektur................................................................23 6. Vertieftes Verständnis der Web-Anwendungsarchitektur ............................................25

2 / 52


Mitschrift SS 2004

7. Anbindung der Datenhaltungsschicht...........................................................................28 7.1 Grundlagen....................................................................................................................28 7.2 Ergänzende Hinweise zur Anwendungentwicklung .....................................................30

7.2.1 Web Anwendungen mit Web-Forms ................................................................30 7.2.2 Events bei Web-Formularen .............................................................................30 7.2.3 Postback-Events und Non-Postback-Events.....................................................31 7.2.4 Zustand einer Web-Anwendung .......................................................................31 7.2.5 Der Lebenszyklus eines Web-Formulars..........................................................31 7.2.6 Erläuterung der Events im Lebenszyklus einer Web-Form.............................33 7.2.7 Beispiel eines ersten Web-Formulars ...............................................................34 7.2.8 XML Web Services Konzept............................................................................39 7.2.9 XML Webservice..............................................................................................40 7.2.10 .asmx Dateien....................................................................................................40 7.2.11 Beispiel für eine .asmx Datei mit inline Code. .................................................41 7.2.12 Testen des Web-Services mit dem Internet Explorer. ......................................41 7.2.13 Einen XML Webservice nutzen........................................................................45 7.2.14 WSDL (Web Service Description Language) ..................................................47 7.2.15 Das Code-Behind Modell etwas besser verstehen............................................47 7.2.16 Test des Web-Services mit einer Windows-Anwendung .................................47

Literatur ....................................................................................................................................51 Internet ......................................................................................................................................52

3 / 52


Mitschrift SS 2004

1. Windows-Anwendung Ziel: Grundverständnis einer „Windows-Anwendung“ USE-CASE:

Vertiebs-mitarbeiter

Kunde Verwalten

Kunde anlegen ....

Kunden verwalten

Artikel verwalten

Aufträge verwaltenHier will ichVornameName anlegen

4 / 52


Mitschrift SS 2004

Für den Teil: „Kunde anlegen“

+Kunde_anlegen()

Kunde

+erzeugen()+:()+:()

Oberfläche des Systems (Vertriebsmitarbeiter)

Technische Klasse

Wird für die Anwendungerstellt

Fertige Strukturen

Anwendung Fenster

Oberfläche

Für ein Windows-Programm weiter verfeinern: Win-Programme Klassenhierarchie: CTheApp - Applikationsebene CObject ClmdTarget CWnd Kernaussage: Zu Beginn wird das fachliche Modell entworfen daraus hergeleitet wird das technische Modell. Das technische Modell ist in der Grundausprägung in drei Ebenen (Schichten) gegliedert, die in der UML über die Classifier Oberfläche, Verarbeitung, Datenhaltung symbolisiert werden. Die Oberfläche wird typischerweise mit Hilfe vorgefertigter Klassen zur Programmierung von Oberflächen (z. B. MFC = Microsoft Foundation Classes), die Datenhaltung mit Hilfe einer Datenbank realisiert.

5 / 52


Mitschrift SS 2004

Lernziel:

• Objektorientierte Windows Anwendung Beispiel „Kunde“ • Abgrenzung zur Prozeduralen Lösung • Aufteilung einer Applikation (Konzept/Struktur) • Technische Implentierung (Com, NET-Architektur)

Historie:

1) Bibliotheken und Datenaustauschverfahren wurden benötigt: DLL Dynamic Link Libraries, DDE – Dynamic Data Exchange

2) fertige, wieder verwendbare Komponenten sollten erstellt werden: 1993 COM-Modell für Komponenten (Component Object Modell)

3) Rechnergrenzen sollten überschritten werden: Verwendung von RPC (Remote Procedure Call) Aufruf von Komponenten auf anderen Rechnern DCOM (Distributed COM)

4) Verwaltung der „entfernten“ Klassen in einer eigenen Softwareschicht kapseln: Middle Ware Software, die für Ortstransparenz (Unabhängigkeit vom Ort) sorgt. Die Software sucht für den Client den Server und übermittelt die Daten. versenden der Parameter Begriff: marshaling Pkt. 3-4: Microsoft OLE Alternativ von Microsoft Konkurrenten CORBA (Common Object Request Broker Architecture) Konzept des Botschaftenaustausches in einer Windows Applikation. Programmieren einer Windows-Oberfläche mit Visual Studio. (siehe auch Anlage 1)

6 / 52


Mitschrift SS 2004

2. Windows-Anwendung mit Komponententechnologie Lernziel:

• Wdh. Softwarearchitektur • Erweiterung der Begriffsdefinitionen • Beispiel einer Architekturlösung („RPC“) • COM • .NET-Architektur

Architektur:

graphische Darstellung des Systemzusammenhangs, Schnittstellen und Komponenten

Komponente:

wiederverwendbare, eigenständig definierte und anschließbare Programme, die mit anderen zusammenarbeiten. Modularisierung Anwendungen werden durch Module (Komponenten) aufgebaut Kommunikation über Nachrichten unabhängig von Protokoll und Hardware

1993: Component Object Model (Microsoft) Middle Ware:

Softwareschicht für die Verwaltung der Zusammenarbeit von Komponenten Typen:

insbesondere „verteilte“ Kommunikation zwischen Komponenten über Anwedungsgrenzen/

Rechnergrenzen hinweg aufgebaut heterogene

verteilte Architektur über unterschiedliche Betriebssysteme/ Anwendungen hinweg

Erster Schritt: verteilte Applikation:

Anwendungs-oberfläche Verwaltung Anwendungs-

verarbeitung

Anwendungs-oberfläche Netzwerk Anwendungs-

verarbeitungVerw.Client

Verw.Client

1-Tier

2-Tier

3-Tier-Architecture { - Oberfläche

- Verwaltung- Datenhaltung

Verarbeitung

DatenhaltungVerarbeitung

2-Tier-Architektur

7 / 52


Mitschrift SS 2004

Beispiel Kontoverwaltung:

Kunde

Kontoverwaltung

Einzahlungbearbeiten

Oberfläche Kontoverwaltung

MiddelwareClient Server

SchnittstelleKonto = new Instanz() Suche Server

Serveridentifikation

Aufruf eingepackt übertragen(verteilt) bzw. Serveraufruf

Konto.einzahlen(5)

Serveridentifikation

ServerKlasse

Methodeder Klasse

ErgebnisErgebnis anClient übermitteln

8 / 52


Mitschrift SS 2004

Kommunikation zwischen den Komponenten Probleme:

ClientSprachschnittstelle

Server

problematisch bei unterschiedlichen Umgebungen

Lösung:

Client Server

Zwischenspracheverweist aufSchnittstelle

übersetzen inServerumgebung

InterfaceDefinitionLanguage

Microsoft Interface Definition Language: MIDLMSIDL

9 / 52


Mitschrift SS 2004

Marshaling: Verpacken, Versenden und Entpacken von Parametern.

Kunde

Kontoverwaltung

einzahlen

Konto

kontostand

einzahlen

Fachklasse

Kontodialog

Konto

Werte eingeben

Technische Klasse

Oberfläche

Client

lKonto

einzahlen

kontostand Konto-verwaltung

Server

nicht verteilt:

Kontodialog lKonto

Erzeuge lServer/ lKonto

Betrag einzahlen

neuer Kontostand

10 / 52


Mitschrift SS 2004

Code: lKontoDialog { double kontostand; lKonto konto = new lKonto( ); konto.einzahlen( 0.0 ); cout << konto.getKontostand( ); konto.einzahlen( 100.0 ); cout << konto.getKontostand( ); } lKonto { private double kontostand = 0.0; public void einzahlen( double betrag ){ this.kontostand += betrag; } public double getKontostand(){ return this.kontostand; } } Aufruf mit Middleware:

Kontodialog lKontoCOM-Server

Aufruf lKonto Starte Server

einzahlen einzahlen

}

.dll oder

.exe

11 / 52


Mitschrift SS 2004

Lernziel

• Wdh. Komponenten Komponenten

• Schwächen des COM-Modells • .NET-Architektur

(Beispiel einer modernen Architekturbasis) Eigenschaften des COM-Modells

• COM dient zur Modularisierung der Anwendung • Kommunikation Client-Server wird hergestellt • Laufzeit DLL • Client lädt DLL • Zugriff auf die DLL erfolgt über die GUID (global unique identifier) • Client/ Server sind nicht statisch aneinander gebunden (Komponente/n können

ausgetauscht werden) • Erweiterung über Rechnergrenzen (DCOM)

Schächen des COM-Modells:

1. Probleme mit Schnittstellenimplementierungen bei unterschiedlichen Sprachumgebungen in Client/Server

2. Speicherlecks 3. Applikationsstruktur

(Class Factories, Marshaling (Verpacken der Informationen vorher<-> nachher)) 4. abhängig von einer Plattform (Betriebssystemumgebung)

Lösung: Common Language Runtime == Zwischenschritt wird versorgt mit “vorkompiliert” MSIL (Microsoft Intermediate Language) Was sind Frameworks ?

• F. gelten allgemein als die höchste Form der Wiederverwendung • mit Hilfe von F. können nicht nur Programmcodes, sondern auch Entwurfslöungen

wiederwendet werden • Ein Framework besteht aus einer Menge kooperativer Klassen, die einen

wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es besteht aus konkreten und insbesondere abstrakten Klassen, die Schnittstellen definieren. Die abstrakten Klassen enthalten sowohl abstrakte als auch konkrete Operationen.

• Im allgemeinen wird vom Anwender (Programmierer) erwartet, daß er Unterklassen definiert, um ein Framework zu verwenden oder anzupassen.

• Selbstdefinierte Unterklassen empfangen Botschaften von den vordefinierten Framework-Klassen nach dem „Hollywood-Prinzip“ – Don’t call us, we’ll call you !

12 / 52


Mitschrift SS 2004

3. .NET-Anwendung 3.1 .Net – Architektur • Net Framework

- Laufzeitsytem (CLR) - .NET Klassenbibliotheken

• Web – Services - Präsentation - Ablauflogik - Datenhaltung

• NET Enterprise Services - Kommunikation übergreifender Anwendungen

3.2 Geschichte des .NET Frameworks • 1998 erwähnt Microsoft Mitarbeiterin Mary Kirtland erstmals die Konzepte (einheitliche

Laufzeitumgebung), die ursprünglich für COM+ geplant waren, aber erst im .NET Framework realisiert wurden.

• Die Entwicklung wurde in den nächsten Jahren zunächst als COM Version 3.0, später als Next Generation Windows Service (NGWS) weitergetrieben.

• 11.7. 2000 Microsoft veröffentlicht unter dem Namen .NET Framework eine Alpha-Version (Technical Preview) des .NET Framework auf der PDC 2000 in Orlando

• 15.11.2000: Beta 1 • 19.6.2001: Beta 2 • 22.10.2001: RC1 • 14.1.2002: Version 1.0 (englisch) • April 2002: Version 1.0 (deutsch) • 19.10.2002: Beta1 der Version 1.1 • 18.11.2002: Beta2 ("Final Beta") der Version 1.1 • 09.04.2003: Endfassung der Version 1.1 verfügbar (englisch+deutsch) • 27.10.2003: Erste Präsentation von .NET 2.0 in breiter Öffentlichkeit auf der PDC 2004 in

LA

13 / 52


Mitschrift SS 2004

3.3 Überblick über die öffentlichen Versionen des Frameworks Produktversion des Frameworks

Produktversion Visual Studio .NET

Produktstadium Versions-nummer

Datum

1.0 7.0/2002 Alpha 1.0.xxxx 11.07.2000 1.0 7.0/2002 Beta1 1.0.2204 15.11.2000 1.0 7.0/2002 Beta2 1.0.2914 19.06.2001 1.0 7.0/2002 Release Candidate 1 1.0.3328 22.10.2001 1.0 7.0/2002 Endfassung 1.0.3705 14.01.2002 1.1 7.1/2003 Beta1 1.1.4322 19.10.2002 1.1 7.1/2003 Beta2 „Final Beta“ 1.1.4322.510 18.11.2002 1.1 7.1 / 2003 Endfassung 1.1.4322.573 09.04.2003 2.0 8.0 / 2005 Alpha / Technical

Preview / PDC Build 1.2.30730 (*) 27.10.2003

(*) 1.2.* ist leider richtig. Microsoft hatte die Versionsnummer noch nicht auf 2.0 angepasst 3.4 Zukunft des .NET Frameworks • Beta 1 des .NET Frameworks 2.0 im Sommer 2004 • Final ca. im März 2005 • Tausende zusätzliche Klassen für das .NET Framework werden in Zusammenhang mit

Windows "Longhorn" im Managed API "WinFX" erscheinen. (Stand 21. April 2004)

3.5 Zukunft von Visual Studio .NET • Zusammen mit dem .NET Framework 2.0 erscheint Visual Studio .NET 8.0 (Codename

"Whidbey") . • Zusammen mit dem nächsten Windows ("Longhorn") erscheint ebenfalls ein neues

"Visual Studio .NET for Longhorn" (Codename "Orcas"), dass das in Longhorn enthaltene neue Managed API "WinFX" unterstützt.

(Stand 21. April 2004) 3.6 Verfügbarkeit Das.NET Framework ist ein kostenloses Add-on für folgende Betriebssysteme: Windows 98, Windows ME, Windows NT 4.0, Windows 2000 und Windows XP. Ab dem Windows.NET Server gehört das.NET Framework zum Standardinstallationsumfang. Für Windows CE.NET gibt es eine Light-Version, das sogenannte.NET Compact Framework.

14 / 52


Mitschrift SS 2004

3.7 Assembly / MSIL Code – native code Ein C++ Compiler erzeugt native code (direkt ausführbare Programme). Diese Anwendungen stellen die schnellsten und effektivsten Programme einer Hochsprache dar. Einer der Hauptgründe dafür ist die optimale Anpassung an die vorhandene Hardware und das Betriebsystem. Ein .NET Compiler (C#, Visual Basic, J#, JScript,…) erzeugt kein direkt ausführbares Programm (native code), sondern einen Zwischencode, der MSIL genannt wird. Die Abkürzung MSIL steht für Microsoft Intermediate Language und bildet eine so genannte Assembly. Dieser MSIL Code/Assembly wird nicht wie bei Java 1.0 interpretiert, sondern immer von einem JIT (Just in time Compiler) zur Laufzeit in native code gewandelt und ausgeführt. Weil der JIT Compiler sehr schnell ist, ist der Geschwindigkeitsverlust einer .NET Anwendung im Vergleich zu einem Native Code Programm nur sehr gering. 3.8 Common Language Runtime (CLR) Um .NET Programme (MSIL-Code) ausführen zu können, benötigt man immer eine Laufzeitumgebung. Diese heißt im .NET Framework Common Language Runtime (CLR). Die CLR besteht aus mehreren Basis Diensten: o Just-in-Time Compiler

Der MSIL-Code wird durch den JIT in die systemeigene Maschinensprache (native Code) des jeweiligen Systems übersetzt, mit den Basisdiensten verbunden und ausgeführt. Dadurch sind .NET Programme performanter als interpretierte Sprachen.

o Speicherverwaltung Umfasst einen „Garbage Collector“, der Objekte, auf die nicht mehr verwiesen

wird, selbstständig löscht. Die Speicherverwaltung verhindert zudem eine Fragmentierung des Speichers.

Dies steigert die Performance von Anwendungen. o Sicherheitssystem

Programmen werden unterschiedliche Sicherheitsstufen zugewiesen. Dazu gehört auch der Ursprung (Internet, Intranet, lokaler Rechner).

Das Sicherheitssystem verwaltet die Codezugriffssicherheit. So kann eine in einer Webseite eingebettete ausführbare Datei (bei Java: ein Applet) zwar eine Animation wiedergeben oder einen Musiktitel abspielen, jedoch keinen Zugriff auf das Dateisystem oder das Netzwerk durchführen.

o Interoperabilität Die CLR stellt eine Abwärtskompatibilität zu älteren COM-Komponenten und

DLL´s her, so dass diese weiter benutzt werden können. o Threading

Verwaltet das Erstellen und Beenden von Threads (Kind-Prozessen). o Exception Handling

Verwaltung von nicht abgefangenen Ausnahmen.

15 / 52


Mitschrift SS 2004

Einheitliche Laufzeitumgebung. Die CLR kompiliert den MSIL-Code mit dem JIT Compiler in ausführbare Programmteile, verbindet diese mit den Basisdiensten und führt den so erzeugten native-code aus. Ein Programmcode, der im Rahmen der CLR ausgeführt wird, heißt „managed code“ (verwalteter Code). Der restliche Code wird entsprechend „unmanaged code“ (nicht verwalteter Code) genannt. 3.9 Runtime Hosts Wenn eine .NET-Anwendung gestartet wird, ruft Windows nicht die CLR selbst direkt auf, sondern zunächst einen so genannten Runtime Host. Dieser lädt die CLR und übergibt der CLR den Einsprungpunkt für die Anwendung. Es gibt derzeit drei Runtime Hosts: den Shell Runtime Host, den Internet Explorer Runtime Host und ASP.NET. In Zukunft werden auch andere Office- und Back-Office-Anwendungen als Host fungieren können. 3.10 Sprachintegration Das.NET Framework ermöglicht die Zusammenarbeit der unterschiedlichsten Sprachen. Zusammenarbeit bedeutet dabei nicht nur, dass ein Aufruf von einem Programmcode möglich ist, der in einer anderen Sprache geschrieben wurde, sondern auch das in objektorientierten Sprachen eine Vererbung von Klassen möglich ist, die in einer anderen objektorientierten Sprache entwickelt wurde. Basis für diese Sprachintegration ist einerseits die Zwischensprache MSIL und die CLR und andererseits die so genannte Common Language Specification (CLS). Die CLS ist ein Regelwerk für Compiler, das festlegt, wie die Umsetzung von sprachspezifischen Konzepten in die MSIL erfolgen muss. Kern der CLS ist das Common Type System (CTS), das ein einheitliches System von Datentypen definiert. Denn nur wenn die verschiedenen Sprachen die gleichen Datentypen verwenden, ist eine problemlose Integration möglich. 3.11 Einheitliche Klassenbibliothek Ein weiterer Aspekt, der die Programmierung in verschiedenen Programmiersprachen bislang höchst unterschiedlich gemacht hat, waren die verschiedenen Funktions- bzw. Klassenbibliotheken. Die .NET Framework Class Library (FCL) ist eine sehr umfangreiche Klassenbibliothek, die von allen .NET Sprachen aus genutzt werden kann. Selbst wenn es in verschiedenen .NET Sprachen noch alternative Möglichkeiten für die Ausführung verschiedener Systemfunktionen (z.B. den Dateisystemzugriff) gibt, sollten die Klassen der FCL genutzt werden. Dies vermindert den Lern- und Umstellungsaufwand beim Wechsel auf eine andere Sprache enorm. Die FCL ist implementiert als eine Reihe von DLLs (Managed Code). Die FCL enthält in der Version 1.0 genau 2246 öffentliche Klassen (Umfang des.NET Framework Redistributable, optionale Add-ons nicht eingerechnet). Um die Übersichtlichkeit

16 / 52


Mitschrift SS 2004

zu gewährleisten, sind die FCL-Klassen in Namensräume eingeteilt. Ein Beispiel für einen FCL-Klassennamen ist System.Web.UI.Control. 3.12 Sicherheitssystem (CAS) Der Schutz vor schädlichen Codes ist ein immer wichtigeres Thema. Die CLR bietet daher ein neues Sicherheitssystem, das nicht mehr nur die Rechte des Benutzerkontos, unter dem der Code ausgeführt wird, berücksichtigt, sondern auch die Herkunft des Programmcodes. Das Sicherheitskonzept wird Code Access Security (CAS) genannt und ist die Weiterentwicklung des Zonenkonzepts des Internet Explorers, des Microsoft Authenticode-Verfahrens zur digitalen Signierung von Programmcode und der Software Restriction Policy (SRP) unter Windows XP. Die CLR ermittelt zur Bestimmung der Ausführungsrechte von Managed Code zunächst die Beweislage (engl. evidence). Zur Beweislage gehören insbesondere der Autor des Codes (hinterlegt durch das Authenticode-Verfahren) und der Speicherort des Codes (Zonenkonzept). Auf dieser Basis werden die Rechte des Codes ggf. eingeschränkt. Selbstverständlich erhält der Code niemals mehr Rechte als der Benutzer, unter dem der Code läuft, denn das Windows-Sicherheitssystem wirkt nach wie vor zusätzlich. Die CAS kann durch die Definition von Code-Gruppen und Berechtigungssätzen sehr fein konfiguriert werden. 3.13 Komponentenkonzept Das .NET Framework ist nicht nur objektorientiert, sondern auch komponentenorientiert. Im Mittelpunkt des Komponentenkonzepts stehen die so genannten Assemblies. Es gibt Assemblies in Form einer EXE oder einer DLL. Eine DLL-Assembly ist immer eine wieder verwendbare Softwarekomponente, die von einer anderen Assembly genutzt werden kann. Nur eine EXE-Assembly lässt sich als eine unabhängige Anwendung starten. Auch eine EXE-Assembly kann aber Dienste für Andere bereitstellen. Dieses Konzept unterscheidet sich zunächst nicht von dem Komponentenkonzept unter dem Component Object Modell (COM). Eine Assembly ist ein Verbund aus einer oder mehreren MSIL-Dateien, wobei mindestens eine der Dateien eine DLL oder EXE ist. Optional können auch nicht-MSIL-Dateien, so genannte Ressource-Dateien (z.B. Datenbank-, Grafik- oder Sound-Dateien), Teil der Assembly sein. 3.14 Meta Daten Jede Assembly und damit auch jede .NET-Komponente ist komplett selbst beschreibend, d.h. es sind ausführliche Informationen über die in der Komponente enthaltenen Klassen und deren Mitglieder enthalten. Diese Meta-Daten sind Pflicht. Dies ist ein großer Fortschritt

17 / 52


Mitschrift SS 2004

gegenüber COM, wo die Selbstbeschreibung in Form von Typbibliotheken eine oft vernachlässigte Option war. Für jedes Objekt der .NET-Laufzeitumgebung werden in den Metadaten alle Objektinformationen aufgezeichnet, die zur Verwendung des Objekts erforderlich sind. Hierzu zählen: • Name des Objekts • Namen und Typen aller Felder des Objekts • Die Namen aller Mitgliedsfunktionen, einschließlich Parametertypen und -namen Das Auslesen der Meta-Daten einer .NET-Komponente nennt man Reflection. Reflection ist integraler Bestandteil des .NET Frameworks, auf dem vier wichtige Mechanismen beruhen: • Beim Bindungsmechanismus ermittelt die CLR mittels Reflection den aufzurufenden

Programmcode. • Die in .NET eingebauten Mechanismen zur Objektserialisierung benötigen die Meta-

Daten, die sie via Reflection ermitteln. Objektserialisierung ist wiederum die Basis für das Remoting in.NET.

• Der Garbage Collector verwendet Reflection um festzustellen, welche Objekte noch in Benutzung sind.

• Mittels des Reflection-Mechanismus kann man dynamisch Code zur Laufzeit erzeugen. 3.15 XCOPY-Deployment und Versionierung Die meisten .NET-Anwendungen müssen nicht mehr installiert werden, sondern können einfach an einen beliebigen Ort kopiert und von dort gestartet werden (der Begriff XCOPY-Deployment nimmt Bezug darauf, dass zum Installieren einer .NET-Anwendung der DOS-Befehl XCOPY ausreicht). Diese Rückbesinnung auf die Wurzeln von Windows ist möglich durch den Verzicht auf die Registry als Konfigurationsspeicher und der Speicherung von DLLs im /System32-Verzeichnis (oder anderen zentralen Verzeichnissen). Anwendungsspezifische Konfigurationsinformationen werden nun in Form von XML-Dateien im Anwendungsverzeichnis abgelegt. Auch alle benötigten DLLs sollten dort liegen. Nur für wenige Ausnahmen, in denen eine Mehrfachnutzung einer DLL sinnvoll ist (z.B. bei der Framework Class Library), gibt es weiterhin einen zentralen Speicherort, den so genannten Global Assembly Cache (GAC), der unter %Windows%/Assembly liegt. Der GAC ist aber kein einfaches flaches Verzeichnis, sondern eine komplexe Verzeichnishierarchie, die ermöglicht, gleichnamige DLLs in beliebig vielen verschiedenen Versionen zu speichern. Dies ist das Ende der DLL-Hölle (der gegenseitigen Störung von Anwendungen durch die Verwendung einer DLL in unterschiedlichen, inkompatiblen Versionen). 3.16 Zum Thema Plattformunabhängigkeit Das .NET Framework ist nicht nur durch die Verwendung der Zwischensprache MSIL plattformunabhängig. Microsoft hat weite Teile des .NET Framework bei der European Computer Manufacturers Association (ECMA) standardisieren lassen. Der Standard heißt Common Language Infrastructure (CLI), ECMA-Standard Nr. 335.

18 / 52


Mitschrift SS 2004

Zum Zeitpunkt der Erstellung dieses Skriptes gibt es eine Implementierung der CLI für FreeBSD. Weitere Implementierungen für LINUX und für verschiedene UNIX-Derivate sind in Arbeit. Zum Beispiel das Mono project von Novell. (http://www.go-mono.com/) Im Rahmen der Standardisierung hat Microsoft auch weite Teile des Quellcodes des .NET Frameworks und der Programmiersprache C# für jedermann zugänglich gemacht (Shared Source CLI). Von der Standardisierung ausgenommen sind allerdings die Datenbankschnittstelle ADO.NET (FCL-Namespace System.Data) und die Benutzeroberflächen-Bibliotheken Windows Forms (FCL-Namespace System.Windows.Forms) und ASP.NET (FCL-Namespace System.Web). 3.18 Interoperabilität Um die Akzeptanz des .NET Framework zu fördern, hat Microsoft sinnvoller Weise eine Interoperabilität mit klassischen Windows-Anwendungen und COM-Komponenten sichergestellt. Die CLR ermöglicht sowohl den Aufruf von klassischen C-Style-DLLs (z.B. dem WIN32-API) als auch COM-Komponenten. Andersherum kann eine .NET-Anwendung auch als COM-Komponente aufgerufen werden.

.NET Anwdg.

SprachenC#, V-Basic...

Runtime Environment

Dienste/Bausteine

Dienste.NET COM

Framework

OS

Enterprise Servers

SQL-Server BizTalk

19 / 52


Mitschrift SS 2004

.Net NET Framework .NET Framework

Laufzeitsystem: (Runtime Environment) - Verwaltung des Speichers (Garbage

Collection/Defragmentierung des Speichers längere freie Speicherbereiche)

- Start/ Stop von Prozessen - Sicherheit - Bezüge der Komponenten

Klassenbibliotheken Framework = Menge wiederverwertbarer Klasse

CLR-Aufbau

Unterstützung der Basisklassen Thread-Einbindung COM-Marshaler Typ-Überprüfung Ausnahmebehandlung Sicherheitsmaschinerie Debugger JIT-Compiler Code Manager Garbage Collector

Klassenlader Klassen : Framework Klassenbibliotheken organisiert in Namensräumen (name Space)

schaffen logische Gruppen Interfaces (Schnittstellen) definieren das Angebot der Klassen

.NET Framework Klassensystem VB Forms Bibliotheken Oberfläche

MFC/ATL Microsoft Foundation Class / Active Remplate Listening (C++ für COM)

ASP Active Server Pages

Web Services NET Enterprise

Services

20 / 52


Mitschrift SS 2004

Wie arbeiten die Klassen des Frameworks zusammen?

ASP .NET

Web Forms

Web Service Anbindung

Benutzeroberfläche

WIN Forms

Dateien und XML

ADO .NET (Active Data

Objects)

XML...

21 / 52


Mitschrift SS 2004

4. Architekturvergleich 4.1 Modell 1: HTML

Browser

wirdinterpretiert

HTMLServer

Client

4.2 Modell 2: DHTML

Browser

DHTMLwird interpretiertbis Aufruflokaler Komponente

COM

Lokale Komponente } AllgemeineAnwendung

4.3 Modell 3: ASPX

HTML

In der Verwaltung IIS-> „Informationsdienste“muss das virtuelleVerzeichnis phys.Zugeordnet sein

Zuordnung

zu IIS

Anfrage

PhysikalischeAdresse

Server

IIS

Virtueller Pfad

//localhost

}

22 / 52


Mitschrift SS 2004

5. Einbindung in eine Anwendungsarchitektur Quelle: Erläuterungen zum Buisinessexample „Duwamish-Online aus Microsoft-Quellen visual.NET

Client Web

Browser

Anwendung Abarbeitung

Data Access

System Framework

Common

Spezielle Datenbereiche

Anwendungskonfiguration

Datenzugriff

Obe

rfläc

he

Business Facade Business Rules

Zusammenspiel Client (Browser) ↔ Server in einer Web-Applikation

Browser IIS

Anfrage

HTML

.aspx .asp

.aspx

CLR

beimerstenZugriff

Codebehind

aspx

Assembly

Assembly Programm ist lesbar mit ILDSAM (Interface Language Disassembler)

23 / 52


Mitschrift SS 2004

IISCLR ASP.NET Web-Forms

Präsentationsschicht

Client

Kennung.aspx

Datenabstraktion

Ablauf

Transport

Ablauflogik

Datenhaltung

Verarbeitung : CLR Common Language Runtime • Programme verwenden Standardbibliotheken

#using <mscorlib.dll> (microsoft core library) → damit die Verwaltung möglich ist, wurden neue Schlüsselworte eingeführt: • delegate deklariert Referenzauf eine/Mehrere Methoden • property deklariert eine Eigenschaft für eine „managed-Class“ • gc deklariert eine Klasse, die von der Garbage-Collection verwalted wird Garbage Collection: • alle Klassen angelegt auf einen zentral angelegten HEAP • Sonderformen: Wertklassen angelegt auf einem Stack • managed Schnitstellenklassen

24 / 52


Mitschrift SS 2004

6. Vertieftes Verständnis der Web-Anwendungs- architektur Ziel: -Wdh. – Zusammenarbeit Browser (Client) ↔ Server

- Informationsgewinnung über den Client - Verständnis der Webanbindung in einer komplexeren Anwendung (Microsoft Enterprise example „Duwamish“)

Beispiel Nutzung .NET-Framework Klassen in einer WEB-Anwendung

.NET-Klassen werden zur Unterstützung der Web-Programmierung eingesetzt Beschreibung der Klassenbibliothek Microsoft Developer Network – Information (hier auch im Help zu Visual Studio)

Attribute der Klassen

Methoden der Klassen entspr. Aufruf/Anwenungsinfo Klassenübersicht = Foundation Class

Beispiel: HttpRequest User-Host Address liefert IP-Adresse des Client

Aufruf: xx Request UserHostAddress locale Instanz / / Member- Variable der Klasse

25 / 52


Mitschrift SS 2004

Beispiel Duwamish

N-tier-Architektur

DataSource

Presentation Layer

Data Access Layer

Business Layer

Workflow Layer

Browser IIS

Business Facade

Anwendung

ServerClient

.asp Verarbeitung

ISAPIsucht richtige.dll zurVerabeitung von.aspx

„Internet ServerApplikationProgrammerInterface“

PresentationLayer

WorkflowLayer

?

26 / 52


Mitschrift SS 2004

IIS

default.aspx

Banner

Menü

[

. . . . .Seiten-struktur

Bannermodul.aspx

Shoppingcart.aspx

Modulbase.vb

Cart.vb

Web ControlAnwendung

Banner

Menü

ShoppingcartOberfläche

Web-O

berfläche

Seitenstruktur

Verarbeitung

27 / 52


Mitschrift SS 2004

7. Anbindung der Datenhaltungsschicht 7.1 Grundlagen

Browser

Data Access

BuisinessFacade

WEB

EmbeddedSQL

Zugriffsschicht durch „Geschäftssystem“

Parametrierung/Aufrufe

Datenbankverbindung + SQL-Weiterleitung

DBMS

Datenzugriffsverfahren

ODBC DAO OLE DB ADO ⇓

ADO.NET

- open Database Connectivity - Data Access Object - OLE Database - Active-X Data Objects

- Active-X Data Objects im .NET Framework

28 / 52


Mitschrift SS 2004

Kernfunktionen von ADO.NET • Verbindung zur Datenbank • Daten verwalten (anlegen, ändern, löschen) • Datenstrukuren vewalten Verwaltungsschicht CLR

Datenzugriffsklassen sin Teil der Framework Klassenbibliothek

.NETClient

VerwalteterSQL-Server

DB

VerwalterOLE DBProvider

„COM-Interoperation“ - Schicht

OLE DBFremddb-Komponenten

Microso

ft eingene DB

Struktur Datenzugriff:

• Verbindungsobjekt • Befehlsobjekt

Beispiel:

siehe Visual C++ Schritt für Schritt S.524 ff. Datenaustausch/ Transfer

über Extensible Markup Language XML Spezifikation: W3C www.w3.org, www.xml.com beschrieben in EBNF (Extended Backus Naur Form)

Start- Tag [40] STag ::= ’<’ Name (S Attribute) *S? ’>’ hierzu gibt es WFC: Unique Att Spec WFC Well Formdness Constraint: Unique Att Spec No Attributename may appear more than once in the same start tag or empty element tag

exemplarisch: <termdef id=”dt_dog” term=”dog”>

29 / 52

http://www.w3.org/

http://www.xml.com/


Mitschrift SS 2004

7.2 Ergänzende Hinweise zur Anwendungentwicklung 7.2.1 Web Anwendungen mit Web-Forms Web Forms implementieren ein Programmiermodell, bei dem Webseiten auf einem Webserver dynamisch generiert und über das Internet auf einem Browser ausgegeben werden. Sie sind in gewisser Weise Nachfolger/Erweiterungen der klassischen ASP-Seiten. Bei Web Forms legt man HTML-Seiten für die statischen Inhalte an und schreibt C# oder anderen Code für die dynamischen Inhalte. Das Programm läuft auf dem Server, und die daraus resultierenden Daten werden in den statischen HTML-Code integriert, wodurch die Webseiten erzeugt werden. Was schließlich an den Browser gesendet wird, ist nichts weiter als normales HTML. Die Benutzeroberfläche wird in einer Datei mit der Erweiterung .aspx gespeichert. Die zu der Seite gehörende Logik (der Programmcode) kann in einer gesonderten Quelldatei, die „Code-Behind-Datei“ gespeichert werden. Dieser Programmcode nutzt die reichhaltigen Web Forms-Typen, die sich in den Namensräumen System.Web und System.Web.UI der Framework Class Library (FCL) befinden und Bestandteil von .NET sind. Wenn eine Anfrage von einem Browser an den Server gestellt wird, wird die Code-Behind-Klassendatei ausgeführt und erzeugt dynamisch die HTML-Seite, die an den Client-Browser gesendet wird. 7.2.2 Events bei Web-Formularen Web-Formulare sind Event-getrieben. Events (Ereignisse) kapseln die Vorstellung davon, dass »etwas geschehen« ist, in einem Objekt. Ein Event wird ausgelöst, wenn der Benutzer eine Schaltfläche anklickt, etwas aus einer Listbox auswählt oder sonstwie mit der Oberfläche interagiert. Eine Methode, die auf ein Event reagiert, nennt man Event-Handler. Event-Handler werden als Programm in die Code-Behind-Seite geschrieben und durch Kontrollattribute mit den Controls der HTML-Seite verknüpft. Bei den meisten Web-Anwendungen werden Events normalerweise auf dem Server behandelt und erfordern daher eine Hin- und Rückübertragung. ASP.NET unterstützt nur eine begrenzte Menge von Events, so etwa Button-Klicks und die Änderungen an Texten.

30 / 52


Mitschrift SS 2004

7.2.3 Postback-Events und Non-Postback-Events Postback-Events sind solche Events, die dazu führen, dass das Formular unmittelbar an den Server zurückgesandt wird. Dazu gehören Maus-Events wie zum Beispiel Button- Click. Im Gegensatz dazu werden viele Events, typischerweise bei Änderungen an Edit-Feldern u.s.w., als Non-Postback angesehen, die nicht sofort an den Server zurückgesandt werden. Solche Events werden stattdessen vom Control zwischengespeichert, bis das nächste Postback-Event auftritt. Man kann Controls mit Non-Postback-Events zwingen, sich wie Postbacks zu verhalten, indem man ihre Eigenschaft AutoPostBack auf true setzt. 7.2.4 Zustand einer Web-Anwendung Der Zustand einer Web-Anwendung ist der aktuelle Wert all ihrer Controls und Variablen in Hinblick auf den aktuellen Benutzer und die aktuelle Sitzung. Das Web selbst ist eine »zustandslose« Umgebung. Das heißt, was an den Server gesendet wird, hat keinen Zusammenhang mit vorangegangenen Sendungen, sofern nicht der Entwickler die notwendigen Anstrengungen unternimmt, um das Wissen über den Zustand festzuhalten. Allerdings bietet ASP.NET Unterstützung bei der Zustandsverwaltung von Benutzersitzungen. Nachdem eine Seite an den Server übergeben worden ist, erstellt der Server sie stets von Grund auf neu, bevor er sie an den Browser zurücksendet. ASP.NET bietet die notwendigen Mechanismen, um den Zustand der Server-Controls festzuhalten. Wenn Sie zum Beispiel eine Liste anbieten und der Benutzer eine Auswahl aus dieser Liste vorgenommen hat, bleibt daher diese Auswahl erhalten, nachdem die Seite an den Server zurückgesandt und anschließend vom Client neu aufgebaut wurde. 7.2.5 Der Lebenszyklus eines Web-Formulars Jede Anfrage nach einer Seite verursacht eine Kette von Events auf dem Server. Diese Events bilden, vom Anfang bis zum Ende, den Lebenszyklus der Seite und all ihrer Komponenten. Der Lebenszyklus beginnt mit einer Anfrage an den Server, die diesen zum Laden der Seite veranlasst. Nachdem die Anfrage abgeschlossen ist, wird die Seite freigegeben. Vom Anfang bis zum Ende des Lebenszyklus besteht das Ziel darin, geeigneten HTML-Code für den anfragenden Browser zu erzeugen. Der Lebenszyklus einer Seite wird durch die folgenden Ereignisse gekennzeichnet; jedes von ihnen kann entweder selbst behandelt oder der Standardbehandlung durch den ASP.NET-Server überlassen werden:

31 / 52


Mitschrift SS 2004

Lebenszyklus des Web-Formulars auf dem ServerHTML request

Browser (Client)

Initialize

Load ViewState

Process Postback Data

Load

Send Postback Change Modifications

PreRender

Save State

HTML reply Render

Dispose

32 / 52


Mitschrift SS 2004

7.2.6 Erläuterung der Events im Lebenszyklus einer Web-Form Initialize (Initialisieren) Die Initialisierung ist die erste Phase im Lebenszyklus jeder Seite und jedes Controls. An dieser Stelle werden alle Einstellungen initialisiert, die für die Dauer der eingehenden Anfrage benötigt werden. Load ViewState (ViewState laden) Die Eigenschaft ViewState des Controls wird gefüllt. Die ViewState-Information kommt aus einer verborgenen Variablen des Controls, die dazu dient, ihren Zustand über mehrere Anfragen an den Server hinweg zu bewahren. Der Eingabe-String dieser verborgenen Variablen wird durch das Seiten-Framework gelesen und die Eigenschaft ViewState wird dementsprechend gesetzt. Dieser Vorgang kann durch die Methode LoadViewState() modifiziert werden. Dadurch erhält ASP.NET die Möglichkeit, den Zustand des Controls über ein erneutes Laden der Seite hinweg zu verwalten, so dass das Control nicht auf seinen Ursprungszustand zurückgesetzt wird, wenn die Seite übersandt wird. Process Postback Data (Postback-Informationen verarbeiten) Während dieser Phase werden die Daten verarbeitet, die der Server beim Übersenden der Daten erhalten hat. Wenn diese Daten es erfordern, dass der ViewState aktualisiert wird, erfolgt der Update über die Methode LoadPostData( ). Load (Seite laden) Falls es erforderlich ist, wird die Methode CreateChildControls() aufgerufen, um die Controls in der Baumstruktur zu initialisieren. Der Zustand wird zurückgesetzt und die Controls zeigen die Client-seitigen Daten an. Die Ladephase kann modifiziert werden, indem das Event Load durch die Methode OnLoad modifiziert wird. Send Postback Change Modifications (Änderungen der Postback-Information senden) Wenn es Veränderungen zwischen dem aktuellen und dem vorherigen Zustand gibt, werden mit Hilfe der Methode RaisePostDataChangedEvent() Change-Events ausgelöst. Handle Postback Events (Postback-Events behandeln) Das Client-seitige Ereignis, in dessen Folge das Formular zurückgesendet wurde, wird behandelt. PreRender (Vor Seitenaufbau) Die Phase unmittelbar vor der Erzeugung der Ausgabe an den Browser. Im Wesentlichen besteht hier die letzte Chance, die Ausgabe zu modifizieren, indem die Methode OnPreRender() verwendet wird. Save State (Zustand sichern) Kurz nach dem Beginn des Lebenszyklus ist der View-State aus einer verborgenen Variablen ausgelesen worden. Nun wird er in die verborgene Variable zurück geschrieben, die als String-Objekt überdauert und die Rücksendung an den Client beendet. Dieses Verhalten kann mit Hilfe der Methode SaveViewState() überschrieben werden.

33 / 52


Mitschrift SS 2004

Render (Seite aufbauen) An dieser Stelle werden die Ausgaben generiert, die an den Clienten geschickt werden sollen. Dies kann mit Hilfe der Methode Render überschrieben werden. Falls erforderlich, wird hier CreateChildControls() aufgerufen, um die Server-Controls im Control-Baum zu initialisieren. Dispose (Seite freigeben) Dies ist die letzte Phase des Lebenszyklus. Sie bietet die Möglichkeit, abschließende Aufräumarbeiten durchzuführen und Referenzen auf irgendwelche anspruchsvollen Ressourcen freizugeben, zum Beispiel auf Datenbankverbindungen. Dies kann mit der Methode Dispose() geändert werden. 7.2.7 Beispiel eines ersten Web-Formulars Prinzipiell um ein Web Formular zu erstellen, benötigt man nicht mehr als einen beliebigen Texteditor um eine *.aspx Datei für die Oberfläche und eine *.aspx.cs Datei (Code-Behind) für die Verarbeitung, sowie das .NET Framework SDK. Wenn man eine andere Programmiersprache als C# nutzt, muss die Dateiendung der Code-Behind Datei entsprechend geändert werden. Bei Visual-Basic wäre es z.B. *.aspx.vb. Die erstellten Quelldateien können dann mit den Kommandozeilen Compiler des .NET SDK kompiliert werden. Viel komfortabler entwickelt man Web Formulare mit einer IDE wie Visual Studio. Dies wird in diesem Beispiel erläutert. Als erstes wird ein neues Projekt erstellt. Hier eine C# Web-Applikation.

Visual Studio legt fast alle Dateien, die es für das Projekt erzeugt, in einem Ordner unterhalb der Standard-Website des Rechners ab, in diesem Beispiel in WebApplication1. Visual Studio erstellt eine Anzahl von Standard Dateien für das Projekt. Das Web-Formular selbst wird in einer Datei namens WebForm1.aspx gespeichert. Diese Datei enthält ausschließlich HTML.

34 / 52


Mitschrift SS 2004

Eine zweite, gleich wichtige Datei, heißt WebForm1.aspx.cs und enthält den C#-Code, der mit dem Formular verbunden ist. Dies ist die Code-Behind-Datei.

Datei für die Benutzeroberfläche

Code-Behind Datei in C#

Um die Code-Behind-Datei (.cs) zu sehen, muss der Cursor innerhalb von Visual Studio .NET gesetzt werden. Das Formular mit der rechten Maustaste anklicken und im Pop-Up-Menü »Code anzeigen« anwählen. Nun kann zwischen dem Formular selbst, der Datei WebForm1.aspx und der C#-Code-Behind-Datei WebForm1.aspx.cs hin- und hergeschaltet werden. Wenn man sich das Formular in WebForm1.aspx ansieht, kann man zwischen dem Design- und dem HTML-Modus umschalten, indem man auf die Reiter unterhalb des Editor- Fensters klickt.

35 / 52


Mitschrift SS 2004

Kontext Menüpunkt Um die Code-Behind Datei anzuzeigen

Entwurf/Design Ansicht

HTML Ansicht

Die WebForm1.aspx Datei enthält typischen HTML-Vorlagentext. Eine Ausnahme davon ist die erste Zeile, die den folgenden ASP.NET-Code enthält: (etwas umformatiert um die Lesbarkeit zu erhöhen) <%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="WebApplication1.WebForm1" %> Das Attribut language zeigt an, dass die in der Code-Behind-Seite verwendete Sprache C# ist. Das Attribut Codebehind legt fest, dass der Dateiname dieser Seite WebForm1.aspx.cs ist, und dem Attribut Inherits ist zu entnehmen, dass diese Seite von WebForm1 abgeleitet ist. Wenn man in die WebForm1.aspx.cs Datei sieht, findet man schnell die Zeile

public class WebForm1 : System.Web.UI.Page Der C#-Code macht deutlich, dass WebForm1 von System.Web.UI.Page abstammt. In dieser Klasse sind Eigenschaften, Methoden und Events definiert, die allen serverseitigen Seiten

36 / 52


Mitschrift SS 2004

gemeinsam sind. In der HTML-Ansicht von WebApplication1.aspx sieht man, dass im Body der Seite mit Hilfe des Standard-HTML-Tags form ein Formular beschrieben wird:

<form id="Form1" method="post" runat="server"> </form>

Jedes Web-Formular benötigt mindestens ein solches tag, um mit dem Benutzer zu interagieren. Alle Controls werden zwischen diesen form tags gesetzt. Das Attribut runat="server" sagt aus, dass es sich um ein serverseitiges Control handelt und von ASP.NET auf dem Server ausgeführt wird. In die WebForm.aspx Datei kann Standard HTML und klassisches ASP eingefügt werden. Beispiel:

<body MS_POSITIONING="GridLayout">

Hallo Welt! Es ist jetzt <% = DateTime.Now.ToString() %> <form id="Form1" method="post" runat="server"> </form> </body>

Wenn die Seite mit Hilfe von Strg-F5 ausgeführt wird, erscheint im Browser:

Dies hat noch wenig mit ASP.NET zu tun. Also fügt man noch einen Button ins Formular ein. Dazu wechselt man in den Entwurfsmodus der WebApplication1.aspx Datei und zieht durch Drag&Drop einen Button ins Formular.

37 / 52


Mitschrift SS 2004

Dadurch werden die Projektdateien wie folgt geändert: 1. in der WebApplication1.aspx Datei diese Zeile hinzugefügt:

<asp:Button id="Button1" style="Z-INDEX: 101; LEFT: 23px; POSITION:

absolute; TOP: 46px" runat="server" Text="Button"></asp:Button> 2. in die WebApplication.aspx.cs Datei wird der Button bekannt gemacht:

protected System.Web.UI.WebControls.Button Button1; an diesen Zeilen kann man sehr schön erkennen, dass über die id in der *.aspx Datei eine Verbindung zur *.aspx.cs Datei (Code-Behind) hergestellt wird. Wenn man die Seite mit Strg-F5 ausführt und sich im Browser den Quellcode anzeigen lässt, sieht man, dass folgendes gesendet wurde.

. . .

<input type="submit" name="Button1" value="Button" id="Button1" style="Z-INDEX: 101; LEFT: 23px; POSITION: absolute; TOP: 46px" /> . . . Das bedeutet, dass ASP.NET die Zeile in der *.aspx Datei in Standard HTML gewandelt hat, bevor die Seite gesendet wird. Als nächstes wollen wir einen EventHandler hinzufügen, um in unserem C# Programm auf einen Klick auf den Button reagieren zu können. Dies geht am leichtesten, wenn im Entwurfsmodus ein Doppel-Klick auf dem Button durchgeführt wird.

38 / 52


Mitschrift SS 2004

Dadurch fügt die IDE automatisch einen EventHandler zu diesem Ereignis in der Code-Behind Datei hinzu. private void InitializeComponent() {

this.Button1.Click += new System.EventHandler(this.Button1_Click); this.Load += new System.EventHandler(this.Page_Load); } Zusätzlich wird eine Methode hinzugefügt, die immer wenn das Ereignis auftritt ausgeführt wird. private void Button1_Click(object sender, System.EventArgs e) { } Diese Methode „Button1_Click“ wird immer ausgeführt, wenn der Button vom Benutzer am Browser gedrückt wird. Das liegt daran, dass ein Button zu den Postback-Events gehört und beim Klick darauf ein sofortiges Senden zum Server ausgelöst wird. Wird in dem Rumpf der Methode die folgende triviale Programmzeile geschrieben, wird beim Klick auf den Button die Beschriftung des Buttons geändert.

Button1.Text = "button clicked";

7.2.8 XML Web Services Konzept Wenn ganze Geschäftsabläufe abgebildet werden, die einen automatischen Datenaustausch innerhalb eines Unternehmens voraussetzen und externe Partner einbeziehen, stellen Web-Services eine mögliche Lösung dar. Ein Beispiel für die Einbeziehung eines externen Partners ist ein Web-Shop mit Kreditkartenzahlung. Die Abwicklung einer Kreditkartenbuchung und die Freigabe der

39 / 52


Mitschrift SS 2004

Zahlung geschehen über einen Dienstleister wie einer Bank, einem Kreditkartenunternehmen oder einem unabhängigem Server-Provider. Dem Partner werden die notwendigen Informationen übergeben und dieser muss als Antwort ebenfalls Informationen liefern. In diesem Fall (Kreditkarten-Clearing) ist es typischerweise ein „Go“ oder „NoGo“. Die Anbindung eines externen Partners geschieht über eine Schnittstelle. Eine solche Schnittstelle sah in der Vergangenheit bei jedem Anbieter anders aus, sofern überhaupt eine vorhanden war. Besser wäre also eine einheitliche Schnittstelle. Diese sollte so allgemein gestaltet sein, dass sie grundsätzlich als Verbindung zwischen Geschäftspartnern genutzt werden kann. So sind Anwendungen wie beispielsweise diese folgende möglich: Eine Produktionsfirma X könnte automatisiert bei einem Großhändler Y einkaufen, wenn der Lagerbestand einen bestimmten Minimalwert erreicht hat. Genauso denkbar ist, mit der gleichen Technologie vor der automatisierten Bestellung ebenfalls automatisiert den günstigsten Händler zu suchen und diesem den Zuschlag zu geben. 7.2.9 XML Webservice Ein Konsortium bekannter Unternehmen wie IBM und Microsoft haben den Grundstein zu einer plattformübergreifenden Theorie geliefert, der die einheitliche Kommunikation von Komponenten über das Internet erlauben soll. XML Web Services basieren auf SOAP, also auf HTTP und XML, HTTP GET oder HTTP-POST. .NET versucht als Voreinstellung alle Protokolle zu unterstützen. (versucht, weil manche Web-Services zu komplex für HTTP-GET sind). HTTP dient als technische Basis für die Übertragung der Daten. Der Vorteil dieses Protokolls ist die starke Verbreitung. Jede gängige Firewall und jeder Proxy unterstützen dieses Protokoll. Für die Sicherheit der Daten ist dank SSL und HTTPS schon gesorgt. Die übertragenen Daten selbst liegen in der standardisierten Beschreibungssprache XML vor. Dies gilt sowohl für die Anfrage des Clients als auch für die Antwort des Servers. Ganz konkret kann man sich einen XML Webservice als eine Klasse vorstellen, die bestimmte öffentliche Methoden anbietet. Diese Methoden können ausgeführt werden. Derartige Mehoden werden Web-Methods genannt. 7.2.10 .asmx Dateien Ausgangspunkt für einen XML Web Service ist das Erstellen einer *.asmx Datei. Das asmx steht für active server method extended. Im einfachsten Fall wird nur diese Datei für einen Webservice benötigt. Die Datei beginnt mit einer Direktive die "@Webservice" lautet. Ähnlich wie in *.aspx Dateien können hier unter anderem die gewünschte Sprache angegeben werden sowie der Debug Modus ein- oder ausgeschaltet werden. Beispiel einer Direktive für einen Webservice: <% @Webservice Class="HalloWeltKlasse" Language="C#" Debug="true" %>

40 / 52


Mitschrift SS 2004

Anders als bei *.aspx Dateien kann hier direkt im Anschluss C# Programmcode folgen. Das Class Attribut nennt ASP.NET die als Web-Service offenzulegene Klasse. Diese Klasse dient als Einstiegspunkt für den Webservice und kann stark vereinfacht mit dem Deklarieren einer main()-Funktion in einem ISO C Programm verglichen werden, die den Einstiegspunkt für ein Konsolenprogramm angibt. Die angegebene Klasse muss von der Klasse Webservice abgeleitet sein und wird entweder direkt hinter der Web-Service Direktive durch inline Code definiert oder, wie der Assistent von Visual Studio .NET es macht, in einer Code-Behind Datei ausgelagert. 7.2.11 Beispiel für eine .asmx Datei mit inline Code. Zwar bietet Visual Studio .NET für .NET-Entwicklungen eine integrierte Entwicklungsumgebung mit großer Funktionsvielfalt, aber diese ist zum Anlegen von einem XML Web-Service nicht unbedingt erforderlich. Ich habe für dieses Beispiel den Notepad Editor von Windows benutzt und die kostenlos verfügbaren Kommandozeilenwerkzeuge vom .NET Framework SDK.

Hier kann man sehr schön sehen, dass die Methode sagHallo() wie gewohnt einfach als public deklariert wird, damit sie von außen aufrufbar ist. Diese kann natürlich auch über Parameter verfügen sowie über einen Rückgabewert. Einziger Unterschied ist, dass die Methode mit einem [WebMethod]-Attribut kenntlich gemacht werden muss. 7.2.12 Testen des Web-Services mit dem Internet Explorer. Anders als Active Server Pages (.aspx) sind XML-Web Services nicht zur Betrachtung mit einem Browser gedacht. Statt dessen werden sie von Client-Anwendungen über Protokolle HTTP GET/POST oder SOAP über HTTP genutzt. Wenn trotzdem ein Web-Service mit dem Browser aufgerufen wird, stellt das .NET Framework eine standardisierte Testseite für Web-Services zur Verfügung. Diese Seite wird jedes Mal von der .NET HTTP-Runtime generiert, wenn ein Browser auf eine *.asmx Datei

41 / 52


Mitschrift SS 2004

gerichtet wird. Diese Seite selbst ist eine *.aspx Seite mit dem Namen DefaultWsdlHelpGenerator.aspx und liegt im Verzeichnis \[Windir]\Microsoft.NET\Framework\[Version]\Config. Diese Seite funktioniert wie jede andere *.aspx Seite und kann verändert werden.

Die Runtime generiert auch automatisch eine Service-Beschreibung aus der *.asmx Datei. Dies ist ein XML-Dokument, das der Spezifikation namens "Web Service Description Language" oder kurz WSDL (ausgesprochen >>Wiz-Duhl<<) entspricht. Durch einen Klick auf den Link Dienstbeschreibung gelangt man zur WSDL-Seite.

42 / 52


Mitschrift SS 2004

Dieser Seite kann man Informationen über die Namensräume, die der Web-Service benutzt, entnehmen (die unterstützten Protokolle, die benutzten Datentypen sowie die offengelegten Web-Methoden). Die WDSL-Spezifikation ist eine Art Dreh- und Angelpunkt für die verschiedenen Web-Service-Entwicklungsplattformen. Wenn unterschiedliche Web-Services zusammenarbeiten wollen, müssen sich die Web-Service Entwickler an dieselbe Version von WSDL und an dieselbe Version von SOAP halten.

43 / 52


Mitschrift SS 2004

Zurück zur Testseite. Durch einen Klick auf den Methodennamen, gelangt man auf eine Seite mit der Beschreibung der Methode und einem Button um sie zu testen ("Aufrufen").

Durch einen Klick wird das Ergebnis der Methode angezeigt, verpackt in XML. Falls die Methode über Parameter verfügen würde, wären Eingabefelder für die zu übergebenen Parameter da. Das funktioniert auch, solange nur einfache Datentypen als Parameter übergeben werden. Sobald man versucht ein Objekt zu übergeben, muss man sich ein eigenes Testprogramm schreiben.

44 / 52


Mitschrift SS 2004

7.2.13 Einen XML Webservice nutzen Den prinzipiellen Aufbau von Anfrage und Antwort eines XML-Web-Services haben wir bereits gesehen. Die Anbindung wäre keine wirkliche Erleichterung, wenn man sie manuell vornehmen müsste. Dafür gibt es in ASP.NET ein Tool, das eine so genannte Proxy-Klasse automatisch erstellt. Diese Proxy-Klasse muss nun in dem eigenen Programm mit using bekannt gemacht werden. Dann braucht man nur noch ein Objekt aus dieser Klasse zu erstellen und kann die Methoden des Objektes (die offengelegten Methoden des Web-Services) benutzen. 1.Methode: Proxy Klasse manuell erstellen Das benötigte Tool um die Proxy-Klasse zu erstellen, heißt wsdl.exe und ist im Verzeichnis \[Windir]\Microsoft.NET\Framework\[Version]\ zu finden. um die Proxy-Klasse zu erstellen, muss wsdl.exe nur die gewünschte Programmiersprache und die URL zum Web-Service angegeben werden. Wichtig ist dabei, bei der URL den Parameter WSDL als GET-Parameter mit anzugeben. Beispiel: wsdl.exe /l:c# http://localhost/HalloWelt.asmx?WSDL Das Ergebnis ist eine C# Quellcode-Datei namens HalloWelt.cs. 2.Methode: Proxy Klasse mit Visual Studio erstellen Jeder, der eine Lizenz vom Visual Studio .NET besitzt, hat es etwas komfortabler. Um einen Web Service in einem Projekt nutzen zu können, muss man nur ein wenig klicken. Die notwendige Option findet man unter Projekt | Webverweis hinzufügen. Das stelle ich einfach als eine Sammlung von Screen-Shots vor. Bei dieser Methode kann man auch auf das manuelle Hinzufügen des WSDL Parameters verzichten.

45 / 52


Mitschrift SS 2004

46 / 52


Mitschrift SS 2004

7.2.14 WSDL (Web Service Description Language) Damit man über die Proxy-Klasse den Web-Service nutzen kann, müssen genaue Informationen über den Web Service eingeholt werden. Es wird ein so genannter Vertrag abgefragt, der die angebotenen Web-Methoden, deren Parameter und den Rückgabewert enthält. Wie im richtigen Leben ist der Vertrag ein bindendes Dokument, an das sich beide Seiten halten müssen. Dieser Vertrag ist ein XML-Stream. Dieser ist nach den Regeln der WSDL verfasst. Auf der Basis dieses Vertrages kann eine lokale Klasse erstellt werden. Diese stellt die Methoden des Web-Services zur Verfügung und leitet Aufrufe intern an diesen weiter. 7.2.15 Das Code-Behind Modell etwas besser verstehen Der Code-Behind-Ansatz bei der Programmierung von Web-Services sieht die Trennung von der Geschäftslogik vor, also von dem Web-Service Direktive und dem unterstützenden Code. In diesem Modell enthält die *.asmx Datei nur die Web-Service Direktive und der Quelltext steht in einer separaten Datei im Falle von C# mit der Dateiendung .asmx.cs. Diese Datei wird in eine Assembly kompiliert und in das bin Verzeichnis des Web-Services gelegt. Wird der Web-Service nun aufgerufen, liest ASP.NET die Direktive um den Namen der Klasse herauszufinden, die die unterstützende Logik enthält. ASP.NET sucht im bin Verzeichnis nach der passenden Assembly (MSIL-Code). Wenn im bin Verzeichnis mehrere Assemblies liegen, durchsucht ASP.NET alle, bis es die Richtige gefunden hat. Einer der Vorteile, die sich aus dem Speichern ihres Codes in kompilierter Form ergeben, ist, dass auf den Webservern kein Quelltext herumliegt. Ein böswilliger Benutzer, der Zugriff auf den Server mit ihren Anwendungen erlangt, wird den Code nicht einfach so stehlen können (>>einfach so<< wird verwendet, weil es Tools zu Dekompilieren von MSIL gibt). Nachteil des Code-Behind-Modells ist, dass die Verteilung einen weiteren Schritt erfordert - das Kompilieren des Quelltextes - was beim inline Code nicht nötig ist. 7.2.16 Test des Web-Services mit einer Windows-Anwendung Zum Testen des Hallo Welt Web-Services benutze ich eine einfache C# Windows-Anwendung. Diese erstellt man sich so mit dem Visual Studio: Datei | Neu | Projekt | Visual C# Projekt| Windows Anwendung Einen passenden Namen für das Projekt eingeben z.B. TestWebService und OK drücken. Als nächstes muss, wie unter Punkt 29 beschrieben, der Webverweis auf den Web-Service hinzugefügt werden. Danach sollte der Projektmappenexplorer so aussehen:

47 / 52


Mitschrift SS 2004

Mit Hilfe der Toolbox von Visual Studio .NET wurde eine Textbox und ein Button in die Anwendung gezogen. Diese wurden durch den Objektinspektor angepasst. Der Text der Textbox wurde gelöscht, damit die Textbox beim Start der Anwendung leer ist. Weiter wurde die Schriftgröße der Textbox auf 15,25 erhöht, sowie dem Button ein anderer Text zugewiesen. Nach dem hinzufügen der Steuerelemente soll die Windows-Anwendung im Entwurf diese Struktur haben:

48 / 52


Mitschrift SS 2004

Mit dieser Anwendung soll der XML-Web-Service getestet werden. Damit bei einem Klick auf den Button der Funktionswert der Web-Methode sagHallo() in der Textbox angezeigt wird, sind noch einige Schritte nötig. Der Namespace der WebMethode muss der Anwendung mitgeteilt werden, damit nicht bei jedem erstellen eines Objektes der Klasse HalloWeltKlasse zuvor TestWebService.localhost. vorangestellt werden muss.

Durch einen Doppelklick auf den Button >>Teste den WebService << wird ein EventHandler für den Button hinzugefügt. In diesem vom Assistenten erstellten Funktionsrumpf wird ein Objekt der Klasse HalloWeltKlasse erstellt. Über dieses Objekt können die Web-Methoden von dem Web-Service benutzt werden. Damit der Funktionswert in der Textbox angezeigt wird, wenn auf den Button geklickt wird muss eine Zuweisung an die Text Eigenschaft des Textbox Objektes. Siehe Abbildung:

Wenn dieses Programm mit STRG-F5 ausgeführt wird und auf den Button >> Teste WebService << gedrückt wird, sollte das Programm so aussehen:

49 / 52


Mitschrift SS 2004

50 / 52


Mitschrift SS 2004

Literatur [1] Hofmann, Johann; Jobst, Fritz; Schabenberger, Roland: Programmieren mit COM und CORBA Hanser, 2001 ISBN 3-446-21479-8 lesenswerte Einführung in COM/CORBA [2] Shepherd, George; Kruglinski, David J.: Inside Visual C++.NET Microsoft Press Deutschland, 2003 ISBN 3-86063-678-2 lesbar, gute funktionsfähige Beispiele [3] Maslo, Andreas; Freiberger, Jörg M.: .NET-Framework Developers Guide Markt + Technik, 2002 ISBN 3-8272-6142-2 weiterführend [4] Schwichtenberg, Holger; Eller,Frank Programmieren mit der .NET Klassenbibliothek Addison-Wesley, 2004 ISBN 3-8273-2128-X weiterführend [5] Schöning, Harald: XML und Datenbanken Hanser, 2003 ISBN 3-446-22008-9 [6] Bengel, Günther: Grundkurs Verteilte Systeme Vieweg, 2004 ISBN 3-528-25738-5 [7] Visual Studio.NET - Exemplarische Vorgehensweisen Begleitmaterial Visual Studio - Microsoft [8] Liberty, Jesse: Programmieren mit C# (Deutsche Übersetzung von Dorothea Reder & Jörg Staudemeyer) O´Reilly, 2002 ISBN 3-89721-331-1 [9] Ferrara, Alex; MacDonald, Matthew: Programmierung von .NET Web Services (Deutsche Übersetzung von Dieter Bremes) O´Reilly, 2003 ISBN 3-89721-348-6

51 / 52


Mitschrift SS 2004

52 / 52

[10] Lorenz, Patrick A.: ASP.NET Grundlagen und Profiwissen Hanser, 2003 ISBN 3-446-22552-8 [11] Lorenz, Patrick A.: ASP.NET Kochbuch Hanser, 2002 ISBN 3-446-22235-9

Internet .NET Framework Homepage von Microsoft URL: http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/netstart/html/sdk_netstart.asp Die deutsche Info-Site für Programmierung mit dem Microsoft .NET Framework URL: http://www.dotnetframework.de Galileo openbook - C# von Eric Gunnerson URL: http://www.galileocomputing.de/openbook/csharp/ Galileo openbook - Einstieg in ASP.NET von Matthias Lohrer URL: http://www.galileocomputing.de/openbook/asp/

Stichworte zur Vorlesung „Neue Softwaretechnologien“ · 2006. 3. 22. · Fachhochschule Kiel...

Documents

Transcript of Stichworte zur Vorlesung „Neue Softwaretechnologien“ · 2006. 3. 22. · Fachhochschule Kiel...