Informationsmanagement Vorlesung 7: Architekturen von ...iss.uni-saarland.de/workspace/documents/ifm-7_architekturen-von-in... · (Hammerfall, 2005, S. 19) Middleware (Hammerschall,

Informationsmanagement Vorlesung 7: Architekturen von Informationssystemen

Univ.-Prof. Dr.-Ing. Wolfgang Maass Lehrstuhl für Betriebswirtschaftslehre, insb. Wirtschaftsinformatik im Dienstleistungsbereich (Information and Service Systems ISS) Universität des Saarlandes, Saarbrücken SS 2012 Donnerstags, 10:00 – 12:00 Uhr (s.t.) Audimax, B4 1

Univ.-Prof. Dr.-Ing. Wolfgang Maass

14.06.12 Slide 2

1.  Einleitung Managementsicht des Informationsmanagement

2.  Grundlagen des Informationsmanagement 3.  Aufgaben des Informationsmanagement – Management der Informationswirtschaft (2-

stündig!) 4.  Aufgaben des Informationsmanagement – Management der Informationssysteme und

Führungsaufgaben (2-stündig!) 5.  Aufgaben des Informationsmanagement – IT-Controlling

Unternehmensarchitekturen 6.  Grundlagen der Unternehmensarchitekturen – Gastvortrag Dr. Steffen Roehn (2-stündig!)

Systemarchitekturen 7.  Architekturen von Informationssystemen 8.  Webarchitekturen (2-stündig!) 9.  Mobile & Cloud Computing

Datenmodellierung 10. Grundlagen der Datenmodellierung (2-stündig!) 11.  Semantische Datenrepräsentationen (2-stündig!)

Prozessmodellierung 12. Grundlagen der Prozessmodellierung

Vorlesungsagenda Übersicht


14.06.12 Slide 3

①  Verteilte Systeme und Anwendungen

②  Das Konzept der „Middleware“

③  Vorteile verteilter Systeme

④  (Verteilte) Architekturmodelle

⑤  n-Tier-Architekturen

⑥  „Thin“- und „Fat“-Clients

⑦  Kommunikationsmodelle, Transparenz, Transaktionen und Sicherheit

Agenda Vorlesung 7


14.06.12 Slide 4

Was versteht man unter Softwarearchitekturen? Komplexe Softwaresysteme bestehen nicht mehr nur aus einem einzelnen, isolierten Programm, sondern aus einer strukturierten Anordnung verschiedener Softwarekomponenten, die standardisiert Informationen austauschen. Architekturen beschreiben Varianten dieser Anordnungen.

Architekturen von Informationssystemen

Was versteht man unter Informationssystemen? (Wiederholung, VL 1) „Bei Informationssystemen (IS) handelt es sich um soziotechnische (“Mensch-Maschine-”) Systeme, die menschliche und maschinelle Komponenten (Teilsysteme) umfassen und zum Ziel der optimalen Bereitstellung von Information und Kommunikation nach wirtschaftlichen Kriterien eingesetzt werden.“ (WKWI, 1994, S. 80) è Fragestellung:

Wie können Informationssysteme strukturiert werden, dass sie die genannten Anforderungen ideal unterstützten?


14.06.12 Slide 5

„Ein verteiltes System setzt sich aus mehreren Einzelkomponenten auf unterschiedlichen Rechnern zusammen, die in der Regel nicht über gemeinsamen Speicher verfügen und somit mittels Nachrichtenaustausch kommunizieren, um in Kooperation eine gemeinsame Zielsetzung – etwa die Realisierung eines Geschäftsablaufs – zu erreichen.“ (Schill & Springer, 2012, S. 4)

Verteilte Systeme und Anwendungen

(Hammerschall, 2005)


14.06.12 Slide 6

Beispiel eines verteilten Systems

(Schill & Springer, 2012)


14.06.12 Slide 7

Informationssysteme zeichnen sich durch folgende Eigenschaften aus, welche durch die Architekturen erfüllt werden müssen: 1.  IS sind software-intensiv:

Umfangreiche Software mit mit vielen Mio. LoC (Lines of Code)

2.  IS sind datenzentriert: Unterstützung des Anwenders beim Bearbeiten von Daten und Informationen; die Datenverwaltung steht im Mittelpunkt

3.  IS sind interaktiv: Der Anwender hat über ein meist grafische Benutzeroberfläche (GUI) die Möglichkeit Einfluss auf die Datenbearbeitung zu nehmen

4.  IS sind hochgradig nebenläufig: Die Systeme können von vielen Anwendern parallel genutzt werden

Eigenschaften verteilter IS

(nach Hammerschall, 2005)


14.06.12 Slide 8

„Middleware ist eine intelligente Programmierschnittstelle, die auf dem verteilten System aufsetzt. Ihre Aufgabe ist es, alle Aspekte der Netzwerkprogrammierung so weit möglich und sinnvoll von der verteilten Anwendung zu verbergen sowie die Anwendung selbst geeignet in ihren Abläufen zu unterstützen.“ (Hammerfall, 2005, S. 19)

Middleware


Beispiel:

E-Mail-Programm

E-Mail-Dienst

Internet-Infrastruktur


14.06.12 Slide 9

•  Wird von der verteilten Anwendung als Zugriffsschnittstelle zum verteilten System genutzt

•  Grad der Komplexität einer Middleware kann variieren

ð  Ziel: Verbergen der Verteilungsaspekte vor der Anwendung

Middleware

•  2 Arten von Middleware: a)  Kommunikationsorientierte Middleware à Technischer Kern; Abstraktion der

Netzwerkprogrammierung b)   Anwendungsorientierte Middleware à basiert auf kommunikationsorientierter

Middleware; Unterstützung der Anwendung


14.06.12 Slide 10

•  Setzt direkt auf dem Protokoll des verteilten Systems auf •  Dient als Kommunikationsinfrastruktur •  Konzentriert sich auf reine Kommunikationsaspekte •  Beispiele: Sun RPC, Java RMI, MQSeries

A - Kommunikationsorientierte Middleware

(Wikipedia)

Verteiltes System

KommunikationsorientierteMiddlewareBetriebs

-system

Anwendung



14.06.12 Slide 11

•  Setzt auf kommunikationsorientierter Middleware auf •  Erweitert diese um... -  Laufzeitumgebung -  Dienste -  Komponentenmodell

•  Beispiele: CORBA, J2EE/Java EE, .Net

B - Anwendungsorientierte Middleware


Verteiltes System

KommunikationsinfrastrukturBetriebs-system

Laufzeitumgebung

Anwendungs-komponente



Komponentenmodell

Dienste Dienste


14.06.12 Slide 12

•  Zentrale, nicht verteilte Anwendungen sind im Allgemeinen sicherer und leistungsstärker

Warum dann Verteilung? •  Gemeinsame Nutzung von Ressourcen, d.h.

•  Hardware Ressourcen, z.B. Drucker, Plotter, Scanner à Kostenersparnis

•  Daten und Informationen, z.B. Fileserver, Datenbank, World Wide Web, Suchmaschinen à Informationsaustausch

•  Funktionalität, z.B. Benutzerverwaltung, Produktdatenmanagement à Fehlervermeidung, Wiederverwendung

Vorteile verteilter Systeme



14.06.12 Slide 13

•  Architekturmodell beschreibt –  Rollen einer Anwendungskomponente innerhalb der verteilten Anwendung –  Beziehungen zwischen den Anwendungskomponenten

•  Rolle wird durch den Prozesstyp definiert, in welchem die jeweilige

Anwendungskomponente läuft: a)  Client Prozess = kurzlebiger Prozess; lebt für die Dauer der Nutzung durch

einen Anwender und agiert als Initiator b)   Server Prozess = langlebiger Prozess; lebt 'unbegrenzt‘ und agiert als Dienst-

Erbringer c)  Peer Prozess = Kurzlebiger Prozess; lebt für Dauer der Nutzung durch einen

Anwender und agiert sowohl als Initiator als auch als Dienst-Erbringer (Mischform)

(Verteilte) Architekturmodelle



14.06.12 Slide 14

•  Kurzlebiger Client-Prozess stellt Anfragen an einen langlebigen Server-Prozess

•  Ca. 80% aller verteilten Anwendungen arbeiten nach diesem Modell

•  Beispiel: Webserver

(Verteilte) Architekturmodelle (1) Client-Server-Architekturmodell

(Schill & Springer, 2012; Hammerschall, 2005)


14.06.12 Slide 15

•  Erweiterung des Client-Server-Modells um Objekte als Kommunikationseinheiten, statt einfacher Prozeduren

•  Objekte = mehr oder weniger fein granulierten Abbildungen von Konzepten, welche zwischen Systemen ausgetauscht werden (z.B. Bestellung, Kundendatensatz) (vgl. objektorientierte Programmiersprachen)

Beispiel: Datenaustausch bei Web Services

(Verteilte) Architekturmodelle (2) Objektorientiertes Architekturmodell

(nach Schill & Springer, 2012)


14.06.12 Slide 16

•  Weiterentwicklung des objektorientierten Architekturmodells •  Anwendungsfunktionen werden von Eigenschaften der verteilten

Systeme getrennt •  Jede Komponente erfüllt einen bestimmten Zweck und wird erst beim Start

auf ihren jeweiligen aktuellen Einsatzzwecks hin konfiguriert, Änderungen im Quellcode sind nicht notwendig

•  Eine Laufzeitumgebung kümmert sich um die Verwaltung (z.B. Starten, Stoppen) der aktuell benötigten Komponenten

(Verteilte) Architekturmodelle (3) Komponentenbasiertes Architekturmodell



14.06.12 Slide 17

•  Prozessorientierter Ansatz mit Diensten als Basiskonzept •  Dienste werden im verteilten System angeboten, gesucht und genutzt •  Vergleichbar mit Komponenten kapseln Dienste Funktionalität und Daten jedoch auf

einer höheren konzeptionellen Ebene, z.B. komplette Geschäftsprozesse •  Jeder Dienst hat eine Schnittstelle über die er angefragt wird •  Ziel: Interoperabilität über Plattform- und Unternehmensgrenzen hinweg

Beispiel: Service Oriented Architectures (SOA) realisiert als SOAP Web Services

(Verteilte) Architekturmodelle (4) Dienstorientiertes Architekturmodell



14.06.12 Slide 18

•  Gleichberechtigte Prozesse interagieren miteinander •  Jeder Prozess kann sowohl als Client- als auch als Serverprozess auftreten •  Ziel: Unabhängigkeit von zentralem Server •  Einsatz z.B. bei Tauschbörsen

(Verteilte) Architekturmodelle (5) Peer-to-Peer-Architekturmodell



14.06.12 Slide 19

•  In verteilten Informationssystemen findet sich typischerweise folgende Aufgabenverteilung wieder: a)  Präsentation à Bereitstellung einer (interaktiven) Benutzerschnittstelle b)   Anwendungslogik à eigentliche Funktionalität der Anwendung c)  Datenhaltung à dauerhafte und konsistente Sicherung der Daten

•  Ziel von n-Tier-Architekturen: geeignete Verteilung dieser Aufgaben auf Anwendungskomponenten, welche auf einer bestimmten Anzahl verschiedener Schichten (sog. Tiers) angeordnet sind.

•  Jede Schicht = unabhängiger Prozessraum innerhalb der Anwendung •  Vorteile von Schichten für Informationssysteme:

1)  Verteilung der Software zur Reduktion der Komplexität 2)  Interaktive Mensch-Maschine Schnittstelle 3)  Datenzentriertes Vorgehen

n-Tier-Architekturen



14.06.12 Slide 20

Verteilte System ist in Client- und Server-Schicht getrennt:

•  In der Client-Schicht liegen die Anwendungskomponenten zur Präsentation •  In der Server-Schicht liegen die Anwendungskomponenten zur Datenhaltung •  Die Anwendungslogik wird individuell auf Client- und Server-Schicht verteilt

2-Tier-Architekturen



14.06.12 Slide 21

•  3-Tier-Architekturen erweitern den 2-Tier-Ansatz um eine weitere, mittlere Schicht à unabhängige Schicht für die Anwendungslogik

•  Vorteile gegenüber 2-Tier-Architekturen: 1)  Zentrale Administration der Anwendungslogik möglich 2)  Gut skalierbar, da jede Schicht für sich skaliert werden kann

Beispiel: Webserver mit eigenem Datenbankserver

3-Tier-Architekturen



14.06.12 Slide 22

•  n-Tier-Architekturen werden neben der Anzahl der Schichten auch durch die Komplexität der Anwendungskomponente auf der Client-Schicht charakterisiert

•  Unterscheidung zwischen Thin- und Fat-Client-Architekturen à je nach Umfang der Anwendungslogik auf der Client-Schicht: a)  Thin-Client: Auf der Client-Schicht werden

ausschließlich Präsentationsaufgaben ausgeführt, z.B. Browser

b)   Fat-Client: Auf der Client-Schicht werden auch Teile der Anwendungslogik ausgeführt, z.B. Microsoft Word mit SharePoint

•  2-Tier-Architekturen sind zumeist Fat-Client-Architekturen

„Thin“- und „Fat“-Clients



14.06.12 Slide 23

Die folgende Tabelle zeigt allgemeine Richtlinien zur Entscheidung für oder gegen den Einsatz eines bestimmten Architekturtyp:

Einsatz der verschiedenen Architekturtypen



14.06.12 Slide 24

•  Kommunikationsmodelle beschreiben das Protokoll der Kommunikation zwischen verschiedenen Knoten in verteilten Systemen, die sog. Interprozesskommunikation (IPC)

•  Es wird zwischen synchroner und asynchroner Kommunikation unterschieden

Kommunikationsmodelle


•  Direktes Ergebnis •  Leicht implementierbar •  Enge Kopplung •  Hohe Abhängigkeit

(besonders im Fehlerfall)

•  Effizient, da keine Blockierung

•  Geringe Fehlerabhängigkeit

•  Komplizierter umzusetzen

•  Ergebnis muss aktiv bezogen werden


14.06.12 Slide 25

•  Ziel einer Middleware ist das Verbergen der Verteilung è Transparenz •  Möglichkeiten der Transparenz:

•  Ortstransparenz: Für die Anwendung bleibt verborgen, ob ein Aufruf lokal oder entfernt erfolgt

•  Zugriffstransparenz: Für die Anwendung bleibt weitgehend verborgen, wo sich eine Ressource, auf die sie zugreifen möchte, physikalisch befindet

•  Nebenläufigkeitstransparenz: Für den Aufrufer einer Anwendung bleibt verborgen, ob weitere, parallele Aufrufe in nebenläufigen Prozessen bearbeitet werden

•  Fehlertransparenz: Für die Anwendung bleiben typische Fehler, wie sie durch Verteilung auftreten können (z.B. Übertragungsfehler, eine Komponente fällt aus), weitgehend verborgen

•  Replikationstransparenz: Die Verwendung von Replikaten einzelner HW- oder SW- Komponenten bleibt für die Anwendung transparent

•  Vollständige Transparenz ist nicht immer sinnvoll

Transparenz



14.06.12 Slide 26

•  Neben der Kommunikation ist ein weiterer wichtiger Aspekt verteilter System die Zuverlässigkeit der Datenverwaltung

•  Sog. Transaktionen sind das Hauptkonzept zur Einhaltung der Datenkonsistenz und bestehen aus mehreren, zusammengefassten, atomaren Aktionen

Transaktionen


Eigenschaften von Transkationen (ACID): •  Atomarität: Es werden alle oder keine der

Aktionen innerhalb einer Transaktion ausgeführt

•  Konsistenz: Vor und nach einer Transaktion herrscht immer ein konsistenter Datenstand

•  Isolation: Transaktionen stören sich nicht gegenseitig

•  Dauerhaftigkeit: Der Zustand am Ende einer Transaktion wird dauerhaft festgeschrieben

Konsistenter Datenstand

Konsistenter Datenstand Zwischenstände und Aktionen

Abbruch bei Fehler


14.06.12 Slide 27

•  Durch den dezentralen und offenen Charakter stellen verteilte Systeme zahlreiche Angriffsziele dar

•  Aus diesem Grund ist bei der Konzeption und Entwicklung ein besonderes Augenmerk auf Sicherheit und Datenschutz zu legen

•  Kernbegriffe sind hierbei die Authentisierung und Autorisierung, sowie damit verbunden Kryptoverfahren •  Authentisierung bedeutet sicherzustellen, dass

die Kommunikationspartner auch die sind die sie vorzugeben scheinen (z.B. Zertifikate)

•  Autorisierung bedeutet einzelnen Kommuni- kationspartnern bestimmte Dinge zu erlauben oder zu verbieten (z.B. Zugangsdaten)

•  Kryptoverfahren stellen sicher, dass Informa- tionen nicht unbefugt gelesen oder geändert werden können

•  Zum Ermitteln der Sicherheitsanforderungen, werden verschiedene Formen von Angriffsszenarien aus den Kategorien Verhindern, Erlangen, Modifizieren und Fälschen evaluiert und daraus Schutzziele abgeleitet

Sicherheit



14.06.12 Slide 28

1.  Einleitung Managementsicht des Informationsmanagement

2.  Grundlagen des Informationsmanagement 3.  Aufgaben des Informationsmanagement – Management der Informationswirtschaft (2-

stündig!) 4.  Aufgaben des Informationsmanagement – Management der Informationssysteme und

Führungsaufgaben (2-stündig!) 5.  Aufgaben des Informationsmanagement – IT-Controlling

Unternehmensarchitekturen 6.  Grundlagen der Unternehmensarchitekturen – Gastvortrag Dr. Steffen Roehn (2-stündig!)

Systemarchitekturen 7.  Architekturen von Informationssystemen 8.  Webarchitekturen (2-stündig!) 9.  Mobile & Cloud Computing

Datenmodellierung 10. Grundlagen der Datenmodellierung (2-stündig!) 11.  Semantische Datenrepräsentationen (2-stündig!)

Prozessmodellierung 12. Grundlagen der Prozessmodellierung

Vorlesungsagenda Übersicht


14.06.12 Slide 29

Bücher: •  U. Hammerschall (2005), Verteilte Systeme und Anwendungen, Pearson. •  A. Schill & Th. Springer (2012), Verteilte Systeme, 2. Auflage, Springer.

Literatur


14.06.12 Slide 30

Univ.-Prof. Dr.-Ing. Wolfgang Maass Lehrstuhl für Betriebswirtschaftslehre, insb. Wirtschaftsinformatik im Dienstleistungsbereich (Information and Service Systems ISS) Universität des Saarlandes, Saarbrücken

Documents

Informationsmanagement Vorlesung 7: Architekturen von ...iss.uni-saarland.de/workspace/documents/ifm-7_architekturen-von-in... · (Hammerfall, 2005, S. 19) Middleware (Hammerschall,