18entwicklung verteilter systeme
DESCRIPTION
18Entwicklung verteilter Systeme. 18.0 Einführung Lernziele Verteilte Systeme 18.1 Charakteristika verteilter Systeme Entwurfsfragen Kommunikationsmodelle Middleware 18.2 Client-Server-Systeme Prozesse in Client-Server-Systemen Schichtenarchitektur. 18Entwicklung verteilter Systeme. - PowerPoint PPT PresentationTRANSCRIPT
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.1
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18 Entwicklung verteilter Systeme
18.0 Einführung Lernziele Verteilte Systeme
18.1 Charakteristika verteilter Systeme Entwurfsfragen Kommunikationsmodelle Middleware
18.2 Client-Server-Systeme Prozesse in Client-Server-Systemen Schichtenarchitektur
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.2
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18 Entwicklung verteilter Systeme
18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur zweischichtige Client-Server Architektur mehrschichtige Client-Server Architektur verteilte Komponentenarchitektur Peer-to-Peer-Architektur
18.4 Software als Service
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.3
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.0 Lernziele
die Hauptprobleme bei Entwurf und Implementation verteilter Softwaresysteme kennen
das Client-Server-Modell und die Schichtenarchitektur von Client-Server-Systemen verstehen
häufig genutzte Muster für verteilte Systemarchitekturen kennen und ihre Eignung für bestimmte Anwendungs-systeme beurteilen können
das Konzept der Software als Service verstehen
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.4
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.0 Verteilte Systeme
mehrere voneinander unabhängige Computer, die dem Benutzer als ein einzelnes kohärentes System erscheinen
Ressourcenteilung gemeinsame Hardware-Nutzung: Massenspeicher, Drucker, etc. gemeinsame Software-Nutzung: Dateien, Compiler, etc.
Offenheit Standardprotokolle Hard- und Software verschiedener Hersteller
Nebenläufigkeit verschiedene Prozesse gleichzeitig auf verschiedenen Rechnern Kommunikation zwischen den Prozessen möglich
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.5
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.0 Verteilte Systeme
Skalierbarkeit Kapazitätserweiterung durch neue Ressourcen begrenzt durch das Netzwerk
Fehlertoleranz Möglichkeit der Replizierung von Information bei Ausfällen oft eingeschränkter Dienst weiter möglich
komplexer als zentrale Systeme Entwicklung, Implementierung und Testen schwieriger Verhalten schwerer vorhersagbar Leistung von vielen verschiedenen Faktoren abhängig keine zentrale Steuerung
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.6
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Entwurfsfragen
Transparenz Was soll der Benutzer über die Verteilung wissen?
Offenheit Sollen nur Standardprotokolle verwendet werden?
Skalierbarkeit Kann die Systemkapazität leicht erweitert werden?
Informationssicherheit Gibt es gemeinsame Sicherheitsrichtlinien?
Dienstgüte (QoS – Quality of Service) Wie wird eine akzeptabele Dienstgüte spezifiziert?
Fehlermanagement Wie werden Fehler entdeckt, eingedämmt und behoben?
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.7
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Transparenz
Verteilung bleibt für Benutzer verborgen System wird als Einheit wahrgenommen Verhalten ist unabhängig von der Verteilung
Voraussetzungen Abstraktionen der Ressourcen Abbildung von logischen Ressourcen auf physikalische
Realisierungen durch Middleware
Beeinträchtigung durch fehlende zentrale Steuerung unterschiedliches Verhalten der einzelnen Rechner Verzögerungen im Netz
Information der Benutzer über Verteilung bessere Einstellung auf Folgewirkungen der Verteilung
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.8
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Offenheit
Offene verteilte Systeme erstellt nach allgemeingültigen Standards Zusammenarbeit von Komponenten aller Anbieter
Offenheit auf verschiedenen Layern auf Netzwerkebene üblich (Internetprotokolle) auf Komponentenebene seltener
Offene Standards CORBA (Common Object Request Broker Architecture):
in der Praxis nicht durchgesetzt Webservicestandards:
wegen Performanzproblemen stattdessen oft REST-Protokolle(Representational State Transfer)
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.9
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Skalierbarkeit
hohe Dienstgüte auch bei steigenden Anforderungen vertikale Skalierung durch stärkere Ressourcen horizontale Skalierung durch zusätzliche Ressourcen
Skalierungsdimensionen Umfang
• bei zunehmender Zahl von Benutzern weitere Ressourcen hinzufügen
Verteilung• geografische Verteilung der Komponenten ohne Leistungsverlust
Verwaltbarkeit• auch bei wachsendem System mit Verteilung der Komponenten
in unabhängigen Institutionen
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.10
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Sicherheit
Verteilte System leichter angreifbar als zentrale schwächste Komponente als Hintertür (Back door)
in andere Teile des Systems
Angriffsarten mithören (interception) unterbrechen (interruption) modifizieren (modification) Informationen einspielen (fabrication)
Sicherheitsrichtlinien meist nicht für alle Teile des Systems gleich untereinander nicht immer kompatibel
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.11
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Dienstgüte
Fähigkeit zur Dienstleistung verlässlich mit akzeptabler Antwortzeit und akzeptablem Durchsatz
Spezifizierung der Dienstgüte im Voraus nicht kosteneffizient,
wenn hohe Güte bei Spitzenbelastung verlangt wird schwierig bei unvereinbaren Parametern
wie Zuverlässigkeit und Durchsatz
wichtig bei zeitkritischen Daten Audio und Video ggf. Verhandlung der Dienstgüte
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.12
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1 Fehlermanagement
Robustheit gegen Ausfälle einzelner Teile “You know that you have a distributed system
when the crash of a system that you’ve never heard of stops you getting any work done.”
Mechanismen für Fehlertoleranz nötig Entdeckung von Ausfällen weitere Bereitstellung der noch möglichen Dienste möglichst automatische Fehlerbehebung
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.13
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1.1Prozedurale KommunikationKellner Gast
Was darf es sein?
Als Vorspeise bitte eine Spargelcremesuppe.
Und als Hauptgang?
Ein großes Steak, bitte.
Wie möchten Sie Ihr Steak?
Medium, bitte.
Mit Folienkartoffel oder Pommes frites?
Ach, bringen Sie mir doch einfach Menü 1!etc.
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.14
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1.1Nachrichtenbasierte Kommunikation
<vorspeise><gericht = "Suppe" typ = "Spargelcreme" /> <gericht = "Suppe" typ = "Kürbis" /><gericht = "Krabbencocktail" />
</vorspeise><hauptgericht>
<gericht = "Steak" typ = "Lende" garstufe = "medium"/> <gericht = "Steak" typ = "Filet" garstufe = "durch"/><gericht = "Zander" />
</hauptgericht><beilage>
<gericht = "Folienkartoffel" portionen = "2" /> <gericht = "Salat" typ = "Feld" />
</beilage>
Kellner an Küche
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.15
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1.1Prozedurale Kommunikation
Remote Procedure Calls (RPCs) Aufruf zwischen Komponenten wie bei lokalen Methoden Middleware fängt Aufruf ab und leitet ihn weiter entfernte Komponente führt Methode aus liefert Ergebnis über Middleware zurück
Nachteile des RPC-Ansatzes beide Komponenten müssen gleichzeitig verfügbar sein beide Komponenten müssen sich gegenseitig referenzieren
können
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.16
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1.1Nachrichtenbasierte Kommunikation
Senden von Nachrichten Komponenten sendet Nachricht über benötigten Service Middleware leitet die Nachricht an den Empfänger weiter Empfänger parst die Nachricht, führt Berechnung aus
und sendet Nachricht mit dem Ergebnis Middleware leitet die Nachricht an den ersten Sender
Vorteile des nachrichtenbasierten Ansatzes Komponenten müssen sich nicht gegenseitig kennen Komponenten müssen nicht gleichzeitig verfügbar sein
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.17
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
System 2System 1
18.1.2Middleware
Anwendungskomponenten
Netzwerk
Betriebssystem
Middleware
Anwendungskomponenten
Middleware
Betriebssystem
Netzwerk
koordinierteOperation
Informationsaustausch undallgemeine Dienste
logischeInteraktion
physikalischeKonnektivität
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.18
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.1.2Aufgaben der Middleware
Unterstützung für Interaktionen verbirgt physikalischen Standort von Komponenten wandelt Parameter um
Bereitstellung allgemeiner Dienste wiederverwendbare Implementierung von Diensten erleichtert Zusammenarbeit bietet konsistente Benutzerdienste => Kapitel 17
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.19
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.2 Client-Server-Systeme
Verteilte Systeme im Internet meist Client-Server-Systeme
Benutzer arbeitet mit Programm auf lokalem Rechner Client, z.B. Webbrowser
Lokales Programm interagiert mit Programm auf entferntem Rechner Server, z.B. Webserver
Server bietet Dienste für viele Clients an Clients greifen auf Dienste zu Clients präsentieren die Ergebnisse dieser Dienste Clients müssen die Server kennen Clients brauchen andere Clients nicht zu kennen
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.20
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.2 Client-Server-Interaktion
s1
s2 s3
s4
c1c2
c3
c4
c5
c6
c7 c8
c9
c10
c12
c11
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.21
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
CC6CC5CC4
CC3CC2CC1
SC2
SC1
18.2 Clients und Server auf Computern
s1 s2
s3 s4
c3 c4c2c1
c5 c6 c7 c8 c9c10
c11
c12
Netzwerk
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.22
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
C
S1
S2
C
S
C
S
18.2 Schichtenarchitektur bei Client-Server-Anw.
Präsentationsschicht
Datenverwaltungsschicht
Anwendungsverarbeitungsschicht
Datenbankschicht
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.23
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur
garantierte Antwortzeiten in Echtzeitsystemen Zweischichtige Client-Server-Architektur
einfache Client-Server-Systeme Zentralisierung aus Sicherheitsgründen
Mehrschichtige Client-Server-Architektur bei großen Mengen von Transaktionen
Verteilte Komponentenarchitektur Kombination von Ressourcen aus verschiedenen Systemen Implementierungsmodell für mehrschichtige Client-Server-Syst.
Peer-to-Peer-Architektur (P2P) direkter Austausch lokaler Information Server nur zur Bekanntmachung der Clients untereinander
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.24
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.1Master-Slave-Architekturen
Echtzeitsysteme Prozesse zur Datenerfassung von Sensoren Prozesse zur Datenverarbeitung und Berechnung Prozesse zur Steuerung von Aktuatoren
Master-Prozess MCI (Darstellung und Interaktion) Berechnung Koordination und Kommunikation der Slave-Prozesse
Slave-Prozesse aufgabenspezifisch z.B. Messwerterfassung aus einer Sensoren-Gruppe z.B. Steuerung einer Aktuatoren-Gruppe
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.25
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.1Master-Slave-Architekturen
Slave
Sensordaten-prozessor
Sensor-steuerungs-
prozess
Slave
Ampelsteuerungs-prozessor
Ampel-steuerungs-
prozess
Master
Leitwarten-prozessor
Koordinations- und Anzeige-prozess
Sensoren und Kamerasder Verkehrsüberwachung
Ampeln (WLZA) undWechselzeichen
Operator-Terminals
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.26
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
Server
Client
18.3.2Zweischichtige Client-Server-Architekturen ein einziger logischer Server und beliebig viele Clients Thin Clients: nur Präsentationsschicht Fat Clients: auch weitere Schichten der Anwendung
-> Schichtenmodell 18.2 (inkonsistent zu 18.3.2)
Präsentationsschicht
Datenverwaltungsschicht
Anwendungsverarbeitungsschicht
Datenbankschicht
Thin Fat
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.27
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.2Zweischichtige Client-Server-Architekturen Thin Clients
einfache Verwaltung der Clients Nutzung von Standard-Clients (z.B. Webbrowser) oft als GUI für Altsysteme hohe Belastung von Netz und Server
Fat Clients mehr Verarbeitung auf dem Client-Prozessor senkt Belastung von Netz und Server kann Fähigkeiten der Clients optimal nutzen aufwendigere Verwaltung z.B. bei neuer Funktionalität Beispiel: Geldautomaten
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.28
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.3Mehrschichtige Client-Server-Architekturen Verteilung der Schichten auf verschiedene
Prozessoren oft dreischichtig:
Client, Webanwendungsserver, Datenbankserver
bessere Skalierbarkeit z.B. zusätzliche Webanwendungsserver
leichtere Verwaltung Anwendungslogik zentriert in einer Schicht
Beispiel: Kontoführung im Web
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.29
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.3Client-Server-ArchitekturenArchitektur Anwendungen
zweischichtigThin Clients
• Anwendungen mit Altsystemen (Clients rufen Services auf)• Rechenintensive Anwendungen mit geringer Datenverwaltung
(z.B. Compiler)• Datenintensive Anwendungen ohne aufwendige Logik
(z.B. Browser)
zweischichtigFat Clients
• Anwendungen mit Standardprogrammen auf dem Client (z.B. Tabellenkalkulation)
• Anwendungen mit hohem Rechenaufwand (z.B. Visualisierung)
• mobile Anwendungen ohne garantierte Konnektivität (lokale Verarbeitung zwischengespeicherter Daten)
mehrschichtig
• große Anwendungen mit vielen Hunderten Clients• Anwendungen mit häufigen Veränderungen
bei Daten und bei Prozessen• Anwendungen mit Daten aus mehreren Quellen
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.30
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.4Verteilte Komponentenarchitekturen
Keine Differenzierung nach Schichten / Clients / Servern Komponenten nutzen Dienste und stellen Dienste bereit Kommunikation erfolgt über Middleware
(remote procedure calls) komplexer als Client-Server-Architektur
Kommunikations-Middleware
Komp. 1
verfügbare
Dienste
Komp. 2
verfügbare
Dienste
Komp. 3
verfügbare
Dienste
Komp. 4
verfügbare
Dienste
Client
Client
Client
Client
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.31
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.4Verteilte Komponentenarchitekturen
Anwendungen mit starker Verteilung(z.B. Data Mining mit mehreren Datenbanken)
in der Praxis selten wegen zwei Hauptnachteilen: hohe Komplexität
=> Verständnis-, Darstellungs- und Designprobleme Middleware-Standards nicht durchgesetzt
=> unterschiedliche Middleware unterschiedlicher Anbieter
Ablösung durch serviceorientierte Architektur vgl. Kapitel 19
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.32
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.3.5Peer-to-Peer-Architekturen gleichberechtigte Teilnehmer
keine Unterscheidung zwischen Client und Server bessere Verteilung der Rechenlast
jeder Knoten im Netzwerk kann benutzt werden bessere Verteilung der Netzlast
keine Umwege erforderlich dezentralisiert
hoher Aufwand bei Suche über viele Peers halbzentralisiert
„Super-Peer“ als Vermittlung und zur Aufgabenverteilung Anwendung meist im PC-Bereich
Informationsaustausch: Filesharing, VoIP, ... Verteiltes Rechnen: SETI@home, ...
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.33
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.4 Software als Service (SaaS)
Software bereitgestellt auf Server(n) Zugriff über Web-Browser keine lokale Installation keine Bindung an bestimmte Rechner / Mobilgeräte
Software verwaltet durch Anbieter keine Kosten beim Anwender kein Einfluss des Anwenders mögliche Probleme mit Datenschutz und Datensicherheit
Verschiedene Finanzierungsmodelle Werbung Abonnement pay per use
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.34
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.4 SaaS und SOA
SaaS: Bereitstellung von Funktionalität auf Servern Zugriff über das Web Server verwaltet Benutzerdaten Server verwaltet Sitzungsdaten lange Transaktionen (z.B. Dokumentbearbeitung)
SOA: Struktur für Softwaresysteme Menge zustandsloser Dienste mehrere Anbieter möglich Verteilung möglich kurze Transaktionen (z.B. Aufruf und Rückgabe eines Dienstes)
SaaS kann mit SOA implementiert werden, muss aber nicht
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.35
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.4 Implementationsfaktoren für SaaS
Konfigurierbarkeit Berücksichtigung spezifischer Bedürfnisse der Anwender
Mandantenfähigkeit virtuelle eigene Software für Anwender saubere Trennung der Daten effiziente Nutzung der Ressourcen
Skalierbarkeit Anpassung an schwer vorhersagbare Anzahl von Nutzern
Änderbarkeit Annahmen über Benutzerbedürfnisse möglicherweise falsch agile Entwicklungsmethoden sinnvoll
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.36
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.4 Konfigurierung von Services
Corporate Design des Anwenders im UI und bei Dokumentausgabe (Branding)
Geschäftsregeln und Arbeitsabläufe bezüglich der Daten (z.B. Validierung) bezüglich der Nutzung (z.B. Reihenfolge der Bearbeitung)
Datenbanken Erweiterung des generischen Datenmodells des Service
um unternehmensspezifische Anteile
Berechtigungen individuelle Konten für Mitarbeiter / Mitarbeitergruppen des
Anwenders Regelungen für Zugriff auf Funktionen und Ressourcen
© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Wissen. Was praktisch zählt.
Stand: 14.05.13 Folie 18.37
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
18.4 Unterstützung der Skalierbarkeit bei SaaS
jede Komponente als einfacher zustandsloser Service kann auf jedem Server laufen Benutzer kann mit mehreren Instanzen arbeiten
asynchrone Kommunikation kein Warten auf Ergebnisse einer Interaktion Benutzer kann weiterarbeiten
Poolbildung für Ressourcen kein Ausfall von Servern wegen fehlender Ressourcen
detailliertes Sperren in der Datenbank unterhalb Datensatzebene