Stichworte zur Vorlesung 2004 - Prof. Dr.

Transcription

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
Stichworte zur Vorlesung „.Neue softwaretechnologien“
Mitschrift SS 2004
Inhaltsverzeichnis
Inhaltsverzeichnis .......................................................................................................................2
1.
Windows-Anwendung ....................................................................................................4
2.
Windows-Anwendung mit Komponententechnologie....................................................7
3.
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.18
.NET-Anwendung.........................................................................................................13
.Net – Architektur .........................................................................................................13
Geschichte des .NET Frameworks................................................................................13
Überblick über die öffentlichen Versionen des Frameworks .......................................14
Zukunft des .NET Frameworks ....................................................................................14
Zukunft von Visual Studio .NET..................................................................................14
Verfügbarkeit ................................................................................................................14
Assembly / MSIL Code – native code ..........................................................................15
Common Language Runtime (CLR).............................................................................15
Runtime Hosts...............................................................................................................16
Sprachintegration ..........................................................................................................16
Einheitliche Klassenbibliothek .....................................................................................16
Sicherheitssystem (CAS) ..............................................................................................17
Komponentenkonzept ...................................................................................................17
Meta Daten....................................................................................................................17
XCOPY-Deployment und Versionierung.....................................................................18
Zum Thema Plattformunabhängigkeit ..........................................................................18
Interoperabilität.............................................................................................................19
4.
4.1
4.2
4.3
Architekturvergleich .....................................................................................................22
Modell 1: HTML ..........................................................................................................22
Modell 2: DHTML........................................................................................................22
Modell 3: ASPX............................................................................................................22
5.
Einbindung in eine Anwendungsarchitektur................................................................23
6.
Vertieftes Verständnis der Web-Anwendungsarchitektur ............................................25
2 / 52
Mitschrift SS 2004
7.
7.1
7.2
Anbindung der Datenhaltungsschicht...........................................................................28
Grundlagen....................................................................................................................28
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:
Kunden verwalten
Kunde Verwalten
Artikel verwalten
Kunde anlegen
....
Vertiebsmitarbeiter
Aufträge verwalten
Hier will ich
Vorname
Name anlegen
4 / 52
Mitschrift SS 2004
Für den Teil: „Kunde anlegen“
Kunde
+Kunde_anlegen()
Oberfläche des Systems (Vertriebsmitarbeiter)
+erzeugen()
+:()
+:()
Technische Klasse
Wird für die Anwendung
erstellt
Fertige Strukturen
Oberfläche
Anwendung
Fenster
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:
1-Tier
Anwendungsoberfläche
2-Tier
Anwendungsoberfläche
3-TierArchitecture
{
- Oberfläche
- Verwaltung
- Datenhaltung
Anwendungsverarbeitung
Verwaltung
Verw.
Client
Verw.
Client
Netzwerk
Anwendungsverarbeitung
2-Tier-Architektur
Verarbeitung
Verarbeitung
Datenhaltung
7 / 52
Mitschrift SS 2004
Beispiel Kontoverwaltung:
Kontoverwaltung
Einzahlung
bearbeiten
Kunde
Kontoverwaltung
Oberfläche
Client
Middelware
Schnittstelle
Konto = new Instanz()
Server
Suche Server
Serveridentifikation
Serveridentifikation
Konto.einzahlen(5)
Server
Klasse
Methode
der Klasse
Ergebnis an
Client übermitteln
Aufruf eingepackt übertragen
(verteilt) bzw. Serveraufruf
Ergebnis
8 / 52
Mitschrift SS 2004
Kommunikation zwischen den Komponenten
Probleme:
Client
Server
Sprachschnittstelle
problematisch bei unterschiedlichen Umgebungen
Lösung:
Client
Server
verweist auf
Schnittstelle
Zwischensprache
übersetzen in
Serverumgebung
Interface
Definition
Language
Microsoft Interface Definition Language: MIDL
MSIDL
9 / 52
Mitschrift SS 2004
Marshaling:
Verpacken, Versenden und Entpacken von Parametern.
Fachklasse
Kontoverwaltung
Konto
kontostand
einzahlen
einzahlen
Kunde
Technische Klasse
Client
Kontodialog
Konto
Oberfläche
Werte eingeben
Server
lKonto
kontostand
Kontoverwaltung
einzahlen
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:
COM-Server
Kontodialog
lKonto
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”
(Microsoft Intermediate Language)
MSIL
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 AlphaVersion (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
1.0
1.0
1.0
1.0
1.0
1.1
1.1
1.1
2.0
Produktversion
Visual Studio .NET
7.0/2002
7.0/2002
7.0/2002
7.0/2002
7.0/2002
7.1/2003
7.1/2003
7.1 / 2003
8.0 / 2005
Produktstadium
Alpha
Beta1
Beta2
Release Candidate 1
Endfassung
Beta1
Beta2 „Final Beta“
Endfassung
Alpha / Technical
Preview / PDC Build
Versionsnummer
1.0.xxxx
1.0.2204
1.0.2914
1.0.3328
1.0.3705
1.1.4322
1.1.4322.510
1.1.4322.573
1.2.30730 (*)
Datum
11.07.2000
15.11.2000
19.06.2001
22.10.2001
14.01.2002
19.10.2002
18.11.2002
09.04.2003
27.10.2003
(*) 1.2.* ist leider richtig. Microsoft hatte die Versionsnummer noch nicht auf 2.0 angepasst
3.4
•
•
•
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 des .NET Frameworks
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 MetaDaten, 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 XCOPYDeployment nimmt Bezug darauf, dass zum Installieren einer .NET-Anwendung der DOSBefehl 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 /System32Verzeichnis (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 (FCLNamespace 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.
Dienste/Bausteine
Sprachen
C#, V-Basic...
Enterprise Servers
SQL-Server
Runtime Environment
BizTalk
Dienste
.NET COM
Framework
OS
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
ASP
VB Forms
MFC/ATL
Bibliotheken
Microsoft Foundation
Active Server
Oberfläche
Class / Active Remplate Pages
Listening (C++ für
COM)
Web Services
NET Enterprise
Services
20 / 52
Mitschrift SS 2004
Wie arbeiten die Klassen des Frameworks zusammen?
ASP .NET
Web Forms
Benutzeroberfläche
WIN Forms
Web Service
Anbindung
Dateien und XML
ADO .NET
(Active Data
Objects)
XML...
21 / 52
Mitschrift SS 2004
4.
Architekturvergleich
4.1
Modell 1: HTML
Client
Browser
4.2
Server
HTML
wird
interpretiert
Modell 2: DHTML
Browser
wird interpretiert
bis Aufruf
lokaler Komponente
DHTML
COM
Lokale Komponente
Allgemeine
Anwendung
Modell 3: ASPX
Virtueller Pfad
ung
rdn
Zuo IIS
zu
}
4.3
}
Anfrage
Physikalische
Adresse
//localhost
Server
IIS
HTML
In der Verwaltung IIS
-> „Informationsdienste“
muss das virtuelle
Verzeichnis phys.
Zugeordnet sein
22 / 52
Mitschrift SS 2004
5.
Einbindung in eine Anwendungsarchitektur
Quelle:
Erläuterungen zum Buisinessexample
„Duwamish-Online aus Microsoft-Quellen visual.NET
Business Facade
Client
Web
Anwendung
Browser
Business Rules
Abarbeitung
Oberfläche
Data Access
Datenzugriff
System Framework
Anwendungskonfiguration
Common
Spezielle Datenbereiche
Zusammenspiel Client (Browser) ↔ Server in einer Web-Applikation
Anfrage
.aspx
Browser
.asp
IIS
HTML
.aspx
CLR
aspx
beim
ersten
Zugriff
Assembly
Code
behind
Assembly Programm ist lesbar mit ILDSAM (Interface Language Disassembler)
23 / 52
Mitschrift SS 2004
Präsentationsschicht
IIS
Client
CLR
ASP.NET
Web-Forms
Kennung.aspx
Ablauflogik
Transport
Ablauf
Datenabstraktion
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-Anwendungsarchitektur
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
Presentation Layer
Workflow Layer
Business Layer
Data Access Layer
Data
Source
Presentation
Layer
Client
Browser
Server
Anwendung
?
IIS
.asp Verarbeitung
ISAPI
„Internet Server
Applikation
Programmer
Interface“
sucht richtige
.dll zur
Verabeitung von
.aspx
Business Facade
Workflow
Layer
26 / 52
Mitschrift SS 2004
IIS
[ Banner
Menü
default.aspx
Seitenstruktur
Web-Oberfläche
Seitenstruktur
.....
Bannermodul.aspx
Web Control
Anwendung
Shoppingcart.aspx
Banner
Verarbeitung
Modulbase.vb
Cart.vb
Menü
Shoppingcart
Oberfläche
27 / 52
Mitschrift SS 2004
7.
Anbindung der Datenhaltungsschicht
7.1
Grundlagen
Browser
WEB
Buisiness
Facade
Embedded
SQL
Data
Access
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
icr
M
te
of
s
o
en
ing
e
DB
.NET
Client
Verwalter
OLE DB
Provider
Verwalteter
SQL-Server
„COM-Interoperation“ - Schicht
OLE DB
Fremddb-Komponenten
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
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-BehindKlassendatei 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 ButtonClick.
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 Server
HTML request
Initialize
Load ViewState
Process Postback Data
Load
Send Postback Change Modifications
Browser
(Client)
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 CodeBehind 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#-CodeBehind-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 EditorFensters 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 CodeBehind 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 WebServices 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 HTTPPOST. .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 WebService-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# WindowsAnwendung.
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
[3]
[4]
lesbar, gute funktionsfähige Beispiele
Maslo, Andreas; Freiberger, Jörg M.:
.NET-Framework Developers Guide
Markt + Technik, 2002
ISBN 3-8272-6142-2
weiterführend
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
[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/
52 / 52

Stichworte zur Vorlesung 2004 - Prof. Dr.

Transcription

Similar documents

WMI - Pearson

Lazarus

Spionage via Webcam: Welchen Schutz bieten Personal Firewalls

McAfee ePolicy Orchestrator 5.3.0 – Software

Einführung - Michael Puff

Entwicklung einer generischen Instant Messenger Anwendung für

Zusätzliche Unterrichtsmaterialien für Eclipse

Kapitel 1 Einleitung

Grafische Programmierung mit dem Borland C++

TK700-Serie - Benutzerhandbuch

thesis - LMU München

Delphi 6 für Profis

Prüfung August 2015

Ihre ersten drei .NET-3.0- Anwendungen

Erzeugen eines externen Schlüssels außerhalb des Browsers

Webtechnologien Teil 16: JavaScript

presse-drc, Apr.07

Bedienungsanleitung Nokia N73 Music Edition - Handy

Verwertung der Innovationen von an Hochschulen tätigen

Combining Index Structures for application-specific String

XML Schemasprachen