Web Services 1

Bauinformatik
Vertiefte Grundlagen
g
Graphentheorie
6. Semester
Web Services 1
Einführung
Verteilte Softwarearchitekturen
Prof. Dr.-Ing.
R J.
R.
J S
Scherer
h
TU Dresden - Institut für Bauinformatik
Nürnberger Str. 31a
2 OG
2.
OG, Raum
R
204
1
IT-Infrastruktur früher
•
•
•
•
1 Programm für jede Aufgabe
1 Sprache (2 Sprachen)
1 Rechner
1 Anwender, der die Programme ausführt und den Datenaustausch steuert
IT-Infrastruktur in Zukunft
•
•
1 llogisches
i h Programm
P
für
fü jede
j d Aufgabe,
A f b aber
b
viele generische, flexibel kombinierbare, wiederverwendbare
Programmkomponenten
g
p
• viele Sprachen
• viele Rechner (Cloud-, Grid-computing)
• Steuerung der Prozesslogik durch ausführbare Geschäftsprozesse
• Mehrere Anwender, die koordiniert miteinander arbeiten
⇒ das Computernetzwerk wird zu einem Virtuelles Unternehmen
⇒ Ein Unternehmen braucht eine Unternehmenssteuerung
TU Dresden - Institut für Bauinformatik
22
Entwicklung der Programmierparadigmen
Objektorientierung
• Ausgerichtet auf feingranulare Geschäftsfunktionen
• Wiederverwendung von Quellcode auf Methodenebene
• gute Wartung und Modifizierung des Programm-Codes durch Kapselung (wenn gut gekapselt wurde!)
Komponentenorientierung
• Ausgerichtet auf Geschäftsfunktionen mittlerer Granularität
• Wiederverwendung von vorgefertigtem, ausführbarem Code
• Verbesserte
V b
t Wartung
W t
undd Modifizierbarkeit
M difi i b k it einer
i Anwendung
A
d
d h Komposition
durch
K
iti
Serviceorientierung
• Ausgerichtet auf Geschäftsprozesse mit grober Granularität
• Flexibilität und Erweiterbarkeit durch die Komposition und Orchestrierung von Services
• Erhöhung der Interoperabilität und Skalierbarkeit durch lose Kopplung
System-Komponenten
• Bestehen i.d.R. aus mehreren Services
TU Dresden - Institut für Bauinformatik
33
Softwarearchitektur
•
•
Eine Softwarearchitektur beschreibt die grundlegenden Komponenten und
deren Zusammenspiel innerhalb eines Softwaresystems.
Die Softwarearchitektur ist die Basis für die Entwicklung von
Computersoftware. Ähnlich, wie ein Architekt im Bauwesen die Prinzipien und
Ziele eines Bauprojektes als Basis für die Fachplaner festlegt, legt ein
S
Systemarchitekt
hi k die
di S
Softwarearchitektur
f
hi k sowie
i di
die E
Entwicklungsspezifikation
i kl
ifik i
fest und stellt damit die Basis zur Verfügung, die zur Erfüllung der
Anforderungen der Anwender notwendig ist.
Software Architektur Beispiele
•
Es gibt viele Möglichkeiten zum Entwurf von Softwaremodulen und deren
K
Kommunikation:
ik i
• Client-Server
• Peer-to-peer (P2P)
• Serviceorientierte Architektur
• Grid-Computing, Cloud-Computing (weniger Sicherheit)
darstellbar als
• Schichtenmodelle
TU Dresden - Institut für Bauinformatik
44
Client-Server-Architektur
•
•
•
Client/Server ist eine skalierbare Architektur, bei der jeder Computer oder
Prozess im Netzwerk entweder ein Client oder ein Server sein kann.
Server Software läuft grundsätzlich (aber nicht immer) auf leistungsfähigen
Rechnern, die ausschließlich zur Ausführung der Geschäftsapplikation
bestimmt sind
sind.
Client Software läuft üblicherweise auf üblichen PC-Arbeitsplätzen. Clients
übermitteln Eingabedaten an den Applikationsserver, der häufig die
rechenintensiven Aufgaben übernimmt und das Ergebnis an den Client
zurückgibt.
TU Dresden - Institut für Bauinformatik
55
Client-Server-Architektur
(Zwei-Schichten-Architektur)
•Eigenschaften von Servern:
–Passiv
–Wartet
Wartet auf Anfrage (request)
–Bearbeitet die Anfrage und gibt
Antwort zurück (reply)
•Eigenschaften eines Clients:
–Aktiv
–Sendet
S d A
Anfrage
f
((request))
–Wartet auf das Antwort (reply)
Präsentations- und
Anwendungsschicht
Datenschicht
TU Dresden - Institut für Bauinformatik
66
Client-Server-Architektur
Viele Clients greifen auf 1 Server zu
Client
Client
Client
Client
Server
Client
Client
TU Dresden - Institut für Bauinformatik
Client
77
Verteilte Anwendung
Der Client bedient sich bei
mehreren Servern
Verzeichnisdienste
Server
Web
Server
Datenbank
Server
Anwendungsserver
Drucker
Server
File
Server
TU Dresden - Institut für Bauinformatik
Mail
Server
88
Drei-Schichten-Architektur
•
Die Drei-Schichten-Architektur ist eine Client-Server-Architektur, bei der
– Präsentationsschicht (Anwenderschnittstelle, Datenein
Datenein- und ausgabe)
– Logikschicht (funktionale Prozesslogik, Anwendungen) und
– Datenhaltungsschicht (Datenspeicherung- und zugriff)
als unabhängige Module entwickelt und gewartet werden, meist auf
unterschiedlichen Plattformen
Präsentationsschicht
Logikschicht
(Anwendungsschicht)
Datenhaltungsschicht
Mehrschichtige Systemarchitekturen wie die dreischichtige Architektur sind gut
skalierbar da die einzelnen Schichten logisch voneinander getrennt sind.
skalierbar,
sind
(s. EU-Projekt ToCEE 5-Schichten-Architektur)
TU Dresden - Institut für Bauinformatik
99
Peer-to-Peer
•
•
Ein peer-to-peer (P2P) Rechnernetz ist ein Netzwerk, das (bis auf wenige
Server)) eher die Rechenleistungg und Bandweite aller Teilnehmer nutzt.
Grundgedanke eines reinen P2P Datennetzes ist nicht die Einführung von
Clients und Servern, sonder von gleichberechtigten Knoten, die den anderen
Knoten im Netzwerk gegenüber sowohl die Funktion eines Client oder Server
erfüllen können.
TU Dresden - Institut für Bauinformatik
10
10
Nutzung verteilter Ressourcen
Prozess
werden verwendet
erstellen
Webservices
Nutzer
suchen
Suche
Berechnungsmodelle
Dokumente
TU Dresden - Institut für Bauinformatik
11
11
Beispiel: ISTforCE-Plattform
(EU Projekt 2000
2000-2003)
2003)
Austauschbare Analyse-
Service 2
Service 1
Services (ASP)
PMS
IT-Plattform
USER
DAS
MAS
PMNS
SNMS
SMS
Austauschbare InfrastrukturServices
Sensors
Servers
Zugriff
g auf Server & Sensoren
GRID
Basis-Infrastruktur-Services
PMS: Platform Management Service
PNMS: Platform Net Management Service
SNMS: Sensor Net Management Service
DAS: Data Access Service
MAS: Model Access Service
TU Dresden - Institut für Bauinformatik
12
12
Voraussetzung für die Nutzung verteilter Ressourcen
RECHNERNETZ
ANALOGIE FIRMA
Vernetzung der Rechner
Mitarbeiter lernen sich kennen
(
Veröffentlichungg der Ressourcen (z.B.
Verzeichnisdienst)
Kompetenzen
p
der Mitarbeiter werden in
eine Liste eingetragen
Telefonnummer
Adressierbarkeit der verteilten Ressourcen:
eindeutig identifizierbar durch URI (Uniform
Ressource Identifier)
Beschreibung der Schnittstellen (anwendbare Beschreibung der Kompetenzen des
Methoden und Parameter) der Ressourcen
Mitarbeiters und des erforderlichen
Inputs bei Inanspruchnahme der
beschriebenen Leistung
Üb t
Übertragungsprotokoll
t k ll
Vorgegebenes
V
b
S
Schema
h
zur Üb
Übertragung
t
von Daten (z.B. Formblätter)
Aufgabe aufteilen auf die Rechner
Aufgabe aufteilen auf die Mitarbeiter
Aufgabenabarbeitung managen,
Orchestrierung
Aufgabeabarbeitung managen Workflow
Aufgabenbenarbeitung kontrollieren
Aufgabenbearbeitung kontrollieren
TU Dresden - Institut für Bauinformatik
13
13
Technische Voraussetzungen
Î Architektur des Internet
ISP = Internet Service Provider
Post Office Protocol (POP) ist
ein Übertragungsprotokoll,
über welches ein Client E
EMails von einem E-MailServer abholen kann
Client = Nutzer (Mensch oder
Computerprogramm) eines
Dienstes;
Local Area Network (LAN)
=Rechnernetzwerk, das i. d. R. mehrere
Räume oder Gebäude umfasst, jedoch
selten mehr als ein Grundstück
TU Dresden - Institut für Bauinformatik
Backbone = verbindender Kernbereich eines
Telekommunikationsnetzes mit sehr hohen
Datenübertragungsraten
NAP (Network Access Point oder
IX=Internet Exchange) sind die
Internet-Knoten, die als
Austauschpunkte für den
Datenverkehr des Internets dienen.
Serverfarm = Gruppe von
gleichartigen, vernetzten ServerHosts, die zu einem logischen
System verbunden sind Î
Verteilung der Auslastung zwischen
den Servern
Router koppelt oder trennt
Rechnernetze und leitet
Datenpakete
p
weiter
14
14
Adressierung von Rechnern
IPv4-Adressen
•
Länge der IP-Adresse: 32 Bit
(theoretisch 4.294.967.296 Adressen Î heute zu wenig)
•
Schema der Adressierung:
xxx.xxx.xxx.xxx
xxx= jeweils 0 bis 255
IPv6-Adressen
IPv6
Adressen
•
•
•
seit 1994
auch IP Next Generation – IPNG genannt
Länge der IP-Adresse: 128 Bit = 16 Byte
((theoretisch 3,4 x 1038 Adressen))
•
Schema der Adressierung:
aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh
jeder Buchstabe steht für eine hexadezimale Zahl
TU Dresden - Institut für Bauinformatik
15
15
DNS (Domain Name System)
•
•
•
•
IP-Adressen sind für Menschen schlecht lesbar
DNS bildet Namen auf Adressen ab
– Eigentlich: Namen auf Ressourcen-Einträge
Namen sind hierarchisch strukturiert in einen Namensraum
– Max. 63 Zeichen pro Komponente, insgesamt 255 Zeichen
– In jeder Domain, kontrolliert der Domain-Besitzer den Namensraum
darunter
64.233.187.99 = google.de
TU Dresden - Institut für Bauinformatik
16
16
URL (Uniform Ressource Locator)
eine Unterart von Uniform Resource Identifiern (URIs). URLs identifizieren und lokalisieren eine Ressource
über das verwendete Netzwerkprotokoll (beispielsweise HTTP oder FTP) und den Ort (engl. location) der
Ressource in Computernetzwerken
<Protokoll> :// <Dienst> . <2.Subdomäne> . <1.Subdomäne> . <Domäne>/ Pfad / Datei
auch Toplevel
Toplevel-Domain
Domain genannt
http://
https://
auch Second-Level-Domain genannt
ftp://
mailto:
auch Third-Level-Domain genannt
www (World-Wide-Web):
(W ld Wid W b) der
d b
bekannteste
k
t t Internet-Dienst
I t
t Di
t
Pfad: Ort der Datei auf dem Server. Pfadangaben werden mit '/' voneinander getrennt.
Datei: Name der Datei, die über den Browser aufgerufen werden soll. Der Dateiname
kann entfallen
entfallen, wenn eine der Dateien des Verzeichnisses automatisch vom Webserver
bereitgestellt wird (z.B. index.html, local.html,...).
TU Dresden - Institut für Bauinformatik
17
17
Datenübertragung
TCP/IP – die „Sprache“ des Internet
Daten werden in Pakete (IP-Pakete) zerlegt
– TCP sorgt für vollständigen und fehlerfreien Transport der IP-Pakete
– IP sorgt für die Adressierung (genaueres später bei IP-Adressen)
Rechner im Internet = „Host“
hat eindeutige IP-Adresse
Anwendung Telnet, FTP, HTTP, SMTP (E-Mail), ...
TCP (Transmission Control Protocol)
Transport
UDP (User Datagram Protocol)
IP (Internet Protocol)
Vermittlung + ICMP (Internet Control Message Protocol)
+ IGMP (Internet Group Management Protoccol)
Verbindung LAN (z.B. Ethernet, Token Ring etc.)
TU Dresden - Institut für Bauinformatik
Anwendungsschicht
– zahlreiche Dienste wie TELNET, FTP, SMTP,
HTTP, NNTP (für DNS), ...
Transportschicht
– TCP (Transport Control Protocol)
• zuverlässiger bidirektionaler Byte-StromÜbertragungsdienst
• Fragmentierung,
F
ti
Flusskontrolle,
Fl k t ll
Multiplexing
– UDP (User Datagram Protocol)
• Paketübergabe an IP
• unzuverlässig,
g, keine Flusskontrolle
Vermittlungsschicht (IP - Internet Protokoll)
– Spezielles Paketformat und Protokoll
– Paketweiterleitung
– Routenermittlung
Verbindungsschicht
– nicht spezifiziert, hängt vom LAN ab, z.B.
Ethernet, WLAN 802.11b, PPP, DSL
18
18
Datentransfer – Routing
• Routing
es wird ein Weg für ein Datenpaket durch ein Netzwerk gesucht
• Router
"Durchleiter",
"D
hl it " vermittelt
itt lt Pakete
P k t anhand
h d der
d Adresse
Ad
im
i Header
H d
des Datenpaketes
• route-fähiges
route fähiges Protokoll
z.B. TCP/IP
meist liegen mehrere Router zwischen Sender und Empfänger
TU Dresden - Institut für Bauinformatik
19
19
HTTP (Hypertext Transfer Protocol)
• Protokoll zur Übertragung von Daten über ein Netzwerk.
• Gehört zur Anwendungsschicht etablierter Netzwerkmodelle an.
• Kommunikationsschema,
Kommunikationsschema um Webseiten oder jede beliebige Datei von
einem entfernten Computer auf den eigenen zu übertragen
• hauptsächlich eingesetzt, um Webseiten aus dem World Wide Web
(
(WWW)
) in einen Webbrowser zu laden
TU Dresden - Institut für Bauinformatik
20
20
HTTP Protokoll Browser/Web Server
HTTP Request
HTTP Response
Web
Browser
TU Dresden - Institut für Bauinformatik
Web
Server
21
21
Hier geht es weiter
TU Dresden - Institut für Bauinformatik
22
22
Servlets
Servlets sind...
• Auf Java basierende serverseitige Webkomponenten, die auf einem
Web- oder Anwendungsserver ausgeführt werden
• Nehmen über http Anfragen von Clients entgegen und geben Antwort
auf dem Browser (üblicherweise html) zurück
Client
(Applets)
•
•
•
•
•
•
Server
(Servlets)
Dynamische Generierung von Websites
Plattformunabhängig durch Java-Technologie
Flexibler Einsatz möglich
E it
Erweiterung
der
d Serverfunktionalität
S
f kti lität
Servlets verhalten sich ähnlich zu Applets
Applets sind Applikationen in Web
Web-Pages
Pages
TU Dresden - Institut für Bauinformatik
23
23
Aufgaben eines Servlets
Datenbank
Java-Anwendung
...
Request
Servlet
Response
1.
2.
3.
4..
5.
Client
S
Server
(Endanwender)
(z.B. Webserver mit
Servlet-Container))
Vom Client ggesendete, explizite
p
Daten lesen
Vom Browser implizit mit der HTTP-Anfrage gesendete Daten lesen
Ergebnisse generieren (mit Hilfe der in Java zur Verfügung stehenden Werkzeuge)
Konkrete
o ete Daten
ate an
a den
de Client
C e t zurücksenden
u üc se de
Implizite Antwortdaten an den Client senden
TU Dresden - Institut für Bauinformatik
24
24
Grundstruktur von Servlets
•
Servlets werden normalerweise von HttpServlet abgeleitet
•
Überschreiben die Methoden doGet()
() und doPost()
()
•
•
•
– doGet() und doPost() nehmen jeweils 2 Parameter entgegen:
• HttpServletRequest
– ermöglicht
g
Zugriff
g
auf alle eingehenden
g
Daten
• HttpServletResponse
– Ermöglicht die Spezifikation von ausgehenden Informationen
– Beinhaltet den PrintWriter,, mit dem Dokumentinhalt an den Client
zurückgesendet werden kann
– Lösen 2 Ausnahmen aus:
• ServletException
• IOException
PrintWriter erfordert den import von java.io
HttpServlet erfordert den import von javax.servlet
HttpServletRequest / HttpServletResponse erfordern den import von javax.servlet.http
TU Dresden - Institut für Bauinformatik
25
25
Lebenszyklus eines Servlets
Laden und instanziieren
• Entweder beim Start des Servlet-Containers oder bei der ersten Anfrage Initialisieren
• Die init-Methode des Servlets wird aufgerufen
• Hier kann das Servlet Initialisierungsaufgaben erledigen, z.B. eine Datenbankverbindung
herstellen oder Konfigurationsdaten aus einer Datei einlesen
Client-Anfragen bearbeiten
• Die service-Methode des Servlets wird aufgerufen
• Diese Methode überprüft den HTTP-Anfragetyp und leitet die Anfrage an die richtige
Methode weiter, z.B. doGet, doPost
Servlet-Klasse wieder entladen
• Der Servlet Container entscheidet, wann die Servlet-Instanz wieder aus dem Speicher
entfernt
tf t wird
id
• Vorher wird die Methode destroy aufgerufen
TU Dresden - Institut für Bauinformatik
26
26
Servlet-Container
•
•
•
•
•
•
•
•
Ein Servlet-Container (auch als Servlet-Engine) ist Vorraussetzung für die
Nutzung
g von Servlets.
Verantwortlich für Verwaltung von Servlets
Stellt Laufzeitumgebung für Komponenten zur Verfügung
Container leitet Anfragen an Servlets weiter
Verwaltet Lebenszyklus eines Servlets
Teil des WebWeb oder Applikationsservers
Beispiel: Apache Tomcat
– Offizielle Implementierung für Java Servlet und JavaServer Pages (JSP)
– „open source“
– Von Apache unter dem Projekt „Jakarta“ entwickelt
Apache Tomcat stellt eine Umgebung zur Ausführung von Java-Code auf
Webservern bereit. Mit enthalten ist ein kompletter
p
HTTP-Server.
TU Dresden - Institut für Bauinformatik
27
27
Apache TomCat – Screenshot des WebanwendungsManagers
TU Dresden - Institut für Bauinformatik
28
28
Verarbeitung von Servlets
HTTP-Anfrage
HTTP
Anfrage
Identifikation
Servlet
Servlet
Client
ServletContainer
(verwaltet alle
Servlets)
Webserver
Dynamische HTML-Seite
TU Dresden - Institut für Bauinformatik
29
29
Verarbeitung von Servlets
•
Am Client läuft ein Webbrowser als Präsentationsprogramm (Front-End)
– Requests
q
werden durch Eingabe
g
einer URL an den Webserver übergeben
g
– Der Webserver erkennt, dass es sich bei der empfangenen URL um einen ServletAufruf handelt
– Der Servlet-Aufruf wird an die Servlet-Engine (Servlet-Container) weitergegeben,
weitergegeben
die dann das Servlet ausführt
•
Die Parameter, die vom Client übergeben werden
– Müssen in die Sprache des Anwendungsprogramms konvertiert werden
– Dieser konvertierte Request muss dann an das Anwendungsprogramm
weitergesendet werden
•
Das Servlet im Servlet Container
– Verarbeitet den Request
– Produziert ein Ergebnis
– Konvertiert das Ergebnis in die Sprache des Webbrausers, d.h. html, und sendet es
zum Client zurück, der das Ergebnis schließlich in einem Ausgabefenster ausgibt
TU Dresden - Institut für Bauinformatik
30
30
Serviceorientierte Architekturen
•
Dynamische Zusammenstellung von Software-Komponenten
– Lose Kopplung: Dienste werden bei Bedarf dynamisch
• gesucht,
• gefunden und
• eingebunden.
Î Anwendungsintegration von verschiedenen, proprietären Anwendungen
(Services/Tools) d.h.
(Services/Tools),
d h Zusammenschluß zu logischen Einheiten
•
•
•
Nutzung heterogener Datenräume durch semantische Datenintegration
Wiederverwendung von Diensten durch Trennung von Schnittstelle und
Implementierung
A t
Automatisierung
ti i
der
d K
Kommunikation
ik ti durch
d hP
Prozessmodellierung:
d lli
– flexible Architektur und lose Kopplung ermöglichen die Implementierung
einmal modellierter Abläufe
TU Dresden - Institut für Bauinformatik
31
31
Verteiltes Rechnen – Grid-Computing
•
Das Ziel eines verteilten Rechensystems ist es, Nutzer und Ressourcen durch
eine transparente,
p
offene und skalierbare Architektur zu verbinden. Es ggibt viele
Möglichkeiten, eine derartige Architektur zu realisieren.
•
Möglich
Mö
li h sind
i d einfache
i f h Client-Server-Systeme
Cli t S
S t
bi
bis hin
hi zu Grid-ComputingG id C
ti
Systemen. Grid computing nutzt die Ressourcen von vielen
Arbeitsplatzrechnern, die in einem Netzwerk (üblicherweise im Internet)
miteinander verbunden sind, um Probleme zu lösen, die hohe Rechenkapazität
erfordern.
TU Dresden - Institut für Bauinformatik
32
32
Grid Computing = SOA + Rechenleistung + Sicherheit + Verwaltung
Simulationen
Daten
Messungen
Versuche
mechanische Bauwerksmod.
Modelle
geometrische Bauwerksmod.
Sensor-/ Messmodelle
Verwaltung
Dokumentation des Änderungsverlaufs
Simulation
Systemidentifikation
Grid
Rechenleistung
parallel computing
high throughput computing
Dienste
Überwachung / Alarm
SOA
SOA,
Modellvergleich
ASP
Workflows
- Informationslogistik
- Orchestrierung
Sicherheit
Nutzerautorisierung und
-authentifizierung
TU Dresden - Institut für Bauinformatik
33
33
Skalierbarkeit
•
•
Ein System ist skalierbar, wenn es einfach bezüglich der Anzahl von Nutzern und Ressourcen
modifiziert werden kann. Skalierbarkeit kann in drei Dimensionen gemessen werden:
– Lastskalierbarkeit
k li b k i — Ein
i verteiltes
il System
S
soll
ll auff größere
ß Datenmengen oder
d häufigere
h fi
Eingaben ohne zusätzliche Verzögerungen reagieren.
– Geographische Skalierbarkeit — Ein geographisch skalierbares System behält seinen Nutzen
und seine Performanz unabhängig von der räumlichen Entfernung der Nutzer bei.
bei
– Administrative Skalierbarkeit — bezeichnet die Fähigkeit, viele Nutzer in einem System zu
vereinigen ohne dieses dabei aufgrund der Komplexität unbedienbar zu machen.
Bei Skalierung in mehreren Dimensionen kann eine Reduktion der Performanz eintreten.
eintreten
TU Dresden - Institut für Bauinformatik
34
34