Date post: | 06-Apr-2016 |
Category: |
Documents |
Upload: | carl-waltz |
View: | 213 times |
Download: | 1 times |
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 1
Systemeigenschaften und ArchitekturSystemeigenschaften und Architektur
WiederverwendungWiederverwendung
Rolle von ArchitektenRolle von Architekten
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 2
Anforderungen an AnwendungenAnforderungen an Anwendungen
Anwendungssystem
FunktionaleAnforderungen
SystemEigenschaften
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 3
SystemeigenschaftenSystemeigenschaften
• Performance, Antwortzeit– Anzahl Transaktionen pro Zeiteinheit– Reaktionszeit wichtig für Akzeptanz einer Anwendung– Bei „embedded systems“: häufig harte Bedingung
• Verfügbarkeit– Stillstandszeiten akzeptabel?– Benutzung bei Web Anwendungen häufig rund um den Globus
• Internet• Global operierende Unternehmen
– 24 * 7
• Skalierbarkeit– Last kann sich schnell ändern– Anzahl der Nutzer im Netz nicht vorher bestimmt
• Zuverlässigkeit– Reine Internet-Auftritte nicht so kritisch– Wichtig z.B.
• Support für Kunden weltweit• Die Anwendung ist Teil eines kritischen Geschäftsprozesses
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 4
SystemeigenschaftenSystemeigenschaften
• Sicherheit– Zugriff unberechtigter Personen muss verhindert werden
• Verteilung– Das Netz ist der Computer
• Integrität von Transaktionen– Geschäftsvorfall besteht aus mehreren Einzelaktionen, die zusammen gehören; alle
oder keine; z.B. Reisebuchung
• Anpassbarkeit, Erweiterbarkeit– Nutzeranforderungen, Geschäftsprozesse ändern sich
• Potierbarkeit– System- / Plattformarchitektur ändert sich
Architektur maßgeblich für dasEreichen von Systemeigenschaften
Abwägung bei Konflikten
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 5
Anforderungs-KonflikteAnforderungs-Konflikte
• Konflikte– Zwischen funktionalen Anforderungen und Systemeigenschaften– Zwischen Systemeigenschaften
• Beispiele– Performance Anpassbarkeit– Performance Portierbarkeit– Make Buy
• Make– Spezifische Anforderungen erfüllen– Performance
• Buy oder Wiederverwendung– Entwicklungs-Geschwindigkeit (Time to Market)– Häufig kostengünstiger– Qualität (Testaufwand, Anzahl Betriebsstunden)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 6
WiederverwendungWiederverwendung
Größte Steigerung der Produktivität erzielt man durch Software, die nicht geschrieben werden muss
• Wiederverwendung: Thema seit 30 Jahren• Von Ausnahmen abgesehen nicht wirklich erfolgreich
Ausnahmen:– Bibliotheken (MFC, Swing, ...)– Datenbanken– Kommunikationsprotokolle– Transaktionsmonitore– Komponenten-Middleware (CORBA, COM, J2EE)Keine domänenspezifische Komponentenaußer: Komplettpakete wie SAP
• Gründe: Wiederverwendung– Zu spät im Entwicklungsprozess– Nur auf Code-Niveau
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 7
Anwendungs-EntwicklungsprozessAnwendungs-Entwicklungsprozess
Planen Entwickeln Betreiben
Analyse Spezifikation Entwurf CodierungIntegration
Qualitäts-Sicherung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 8
Wiederverwendung auf Code-NiveauWiederverwendung auf Code-Niveau
Analyse Spezifikation Entwurf CodierungIntegration
Qualitäts-Sicherung
ModulBibliothek
KlassifizierenSpeichernSuchen
Einbauen• Chance, dass passender Modul gefunden
wird, sehr gering• Keine Frage der Klassifikation oder Suche• Lösung: Wiederverwendung auf höherem
Niveauoder
• Spezifikation und Entwurf so, dass vorhandene Module eingesetzt werden können
• Vorbild: Hardware-Geräteentwicklung• Extrem-Beispiel: Standard Software wie SAP
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 9
FrameworksFrameworks
Framework
Anwendung
SpezialisierungSpezialisierung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 10
Wiederverwendung mit FrameworksWiederverwendung mit Frameworks
Analyse Spezifikation Entwurf CodierungIntegration
Qualitäts-Sicherung
Framework Repository(Modell & Komponenten)
KomponentenAnpassenEinbauen
Modell des Frameworks Architektur des
Frameworks
FrameworkEntwickler
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 11
Wiederverwendung von Architektur & KomponentenWiederverwendung von Architektur & Komponenten
Anwendung
Individual-Entwicklung
KomponentenBasierte Entwicklung
Anpassung vonStandard-SW
Standard-SWPaket
KomponentenVom Markt
Modell & Referenz-Architektur
KomponentenBibliothek
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 12
Rolle von Referenzarchitekturen und FrameworksRolle von Referenzarchitekturen und Frameworks
Anwendung 1
Anwendung 2
Anwendung n
...
Jede Anwendunghat eigene isolierteArchitektur
Referenz-Architektur(Blueprint)
Anwendung 1
Anwendung 2
Anwendung n
...
abgeleitet
Framework
• Anwendungsmodell• Referenzarchitektur• Komponenten
...
abgeleitet
Anw.n
Anw.1
Anw.2
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 13
Konzepte für die AnwendungsentwicklungKonzepte für die Anwendungsentwicklung
• OO Modellierung• OO Programmierung• Gener. von Coderahmen
• Komponententechnologie• Produktivität durch Container
und Laufzeitservices• Design Patterns
• Frameworktechnik• Muster für Anwendung• Vorgefertigte Komponenten /
Design Patterns
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 14
Software-ArchitektenSoftware-Architekten
• Architektur-Entwurf ist Aufgabe bei Entwicklung• Software-Architekt ist spezielle Rolle im Entwicklungsteam• Hauptaufgabe in der Phase, wenn Architektur entworfen wird• Ist aber während des ganzen Projektes nötig
– Einfluss der Architektur auf andere Tätigkeiten– Iterative Entwicklung erfordert Anpassung
• Abhängig von Projektgröße– Einzelperson– Architekturteam
• Software-Architekten sind sehr gefragt
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 15
Rolle von Software Architekten - 1Rolle von Software Architekten - 1
• Definiert eine Vision– Vertraut mit neuen Technologien– Versteht die globalen (auch Business) Anforderungen und
Zusammenhänge– Kommuniziert Zusammenhänge effektiv
• Schlüsselperson für technische Beratung– Review von Spezifikationen– Beurteilt Machbarkeit– Empfiehlt Technologien und Werkzeuge– Verfolgt Qualität von Entwurfs-Entscheidungen– Sichert Integrität des Entwurfs
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 16
Rolle von Software Architekten - 2Rolle von Software Architekten - 2
• Trifft Entscheidungen– Globale Entwurfs-Entscheidungen– Führt Technologieteam in größeren Projekten– Trifft „Make or Buy“ Entscheidungen– Identifiziert Risiken
• Coach für Entwickler und Koordinator– Sorgt für Dialog mit Projekt-Mitarbeitern– Erklärt Entwurf und Entscheidungen– Delegiert Verantwortung für Detail-Entwürfe
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 17
Architektur im Software LebenszyklusArchitektur im Software Lebenszyklus
Anwender Marketing IT
SpezifikationFunkt. Anford.
SpezifikationSystemeigensch.
EntwurfArchitektur
DetailSpezifikation
(Teil-) CodierungIntegr. Test
QSFunkt. & Systeme.
FreigabeRoll-out
ReferenzArchitektur
Komponenten
FrameworkInterner StandardVorherg. Version
Produkte vom MarktUntern.-eig. Kompon.Vorherg. Release
Anpassung&
Iterative Entwicklung
A n a - l y s e
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 18
Herausforderungen an ArchitekturenHerausforderungen an ArchitekturenBeispiele aus der PraxisBeispiele aus der Praxis
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 19
Herausforderungen an ArchitekturHerausforderungen an Architektur
Anforderungen Evolution der
Geschäftsstrategie Kundenorientie-
rung der Geschäfts-prozesse
Wettbewerb über Schnelligkeit - z.B. neue und geänderte Produkte
Fusionierungen, Erweiterung
Neue Geschäftsformen, z.B. E-Commerce
Innovationen Neue
Technologien, z.B. Internet, Objektorientie-rung, Client-Server, Kompo-nententechnologie
Neue SW und HW Produkte, z.B. Middleware, Browser, DBMS
Business Architektur
Anwendungsarchitektur
Systemarchitektur
Plattformarchitektur
GeschäftsprozeßGeschäftsprozeß DatenflußDatenfluß
BenutzergruppeBenutzergruppe AnwenduAnwendungng
CompuComputerter NetzwerkNetzwerk
AnwenduAnwendungsfunktingsfunkti
onon
SchicSchichtht KomponenteKomponente ObjektObjekt
Sic
herh
eit
Sys
tem
man
agem
ent
Zugr
iffsr
echt
Zugr
iffsr
echt
Rec
hteg
rupp
eR
echt
egru
ppe
Anw
endu
ngA
nwen
dung
Syst
emSy
stem
Res
sour
ceR
esso
urceOrganisatiOrganisati
onseinheitonseinheit
Existierende IT
„Ererbte“ Architekturen & Technologien
„ererbte Systeme“ versus neue Geschäftsprozesse
proprietäre SW-Produkte
„Ererbte“ IT Organisation
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 20
Risiken für strategische Architekturprojekte Risiken für strategische Architekturprojekte
Kunde versprochener
Nutzen wird nicht erzielt - z.B. Reduktion der Geschäftstransak-tionskosten, höhere Flexibilität und Geschwindigkeit bei Änderungen und Neuentwicklung
System kommt zu spät aus Sicht des geplanten Geschäftszieles
Technologie geforderte
Performance wird nicht erreicht
geforderte Mengengerüste werden nicht beherrscht - Datenmengen, Transaktions-lasten
Betriebskosten zu hoch
Business Architektur
Anwendungsarchitektur
Systemarchitektur
Plattformarchitektur
GeschäftsprozeßGeschäftsprozeß DatenflußDatenfluß
BenutzergruppeBenutzergruppe AnwenduAnwendungng
CompuComputerter NetzwerkNetzwerk
AnwenduAnwendungsfunktingsfunkti
onon
SchicSchichtht KomponenteKomponente ObjektObjekt
Sic
herh
eit
Sys
tem
man
agem
ent
Zugr
iffsr
echt
Zugr
iffsr
echt
Rec
hteg
rupp
eR
echt
egru
ppe
Anw
endu
ngA
nwen
dung
Syst
emSy
stem
Res
sour
ceR
esso
urceOrganisatiOrganisati
onseinheitonseinheit
Budget und Termin
Budget- und Ressour-cenverbrauch zu hoch
Terminüberschreitung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 21
TuxedoInterfaces
Beispiel 1: Inseln mit funktioneller und Beispiel 1: Inseln mit funktioneller und DatenredundanzDatenredundanz
Kunden Prüfen
Dokumentenverwaltung
FinanzenVerwalten
Auftrags-verwaltung I Rechnungen
Erstellen III
RechnungenErstellen II
RechnungenErstellen I
Kundendienst I
Kundendienst II
Auftrags-verwaltungI I
Kundendienst III
Basierendauf untersch.
Produkten
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 22
Beispiel 1: Vision „Komponentenarchitektur“ Beispiel 1: Vision „Komponentenarchitektur“
View LayerPartner Vertrieb
WebVertrieb Marketing Auftrags-
verwaltungKunden-
verwaltung...
Business Layer Prozesse (Workflow)
Geschäftslogik
Vertriebs-komponente
Auftrags-komponente
Rechnungs-komponente
Kunden-Komponente
...
Data Layer ProspectsDatabase
M ediationDevice
AccountsDatabase
Custom erDatabase ...
Zugriffsschicht Zugriffsschicht ZugriffsschichtZugriffsschicht Zugriffsschicht Syst
emsm
anag
emen
tSi
cher
heit
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 23
Beispiel 1: Realität - Mix aus SystemarchitekturenBeispiel 1: Realität - Mix aus Systemarchitekturen
View LayerPartner Vertrieb
Auftrags-verwaltung
Rechnungs-system
...
Daten Integration & Transaktionsmanagement
SalCusDatabase
Kunde AuftragVertrag Kunde Auftrag
Rechnung
Vertriebssystem Auftrags-system
Rechnungs-system
WebVertrieb
Kunden-verwaltung
Client
Server
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 24
Beispiel 2: GeschäftsprozesseBeispiel 2: Geschäftsprozesse
Kundensystem
Buchung
Ticket-Erstellung
Verkaufs-Abwicklung
Zahlungs-Abwicklung
Buchhaltung
Unternehmens-
Steuerung
Beratung
Auftragssystem
Verkauf und Zahlung
Kunden- und Auftragssystem
Buchhaltungs-system
Management Information-
System
Verkauf und Zahlung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 25
Beispiel 2 : Die InfrastrukturBeispiel 2 : Die Infrastruktur
“Ererbte” Mainframes
WAN
Gateway
MF A MF B MF C MF D
ExterneDienstleister
Hochgeschwindigkeits-Netzwerk
WindowsClient
>=9600 bit/sec
35.000 Clients
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 26
Beispiel 2 : „Ererbte“ Mainframe-AnwendungenBeispiel 2 : „Ererbte“ Mainframe-AnwendungenC
arrie
r Int
egra
tion
Kun
dens
yste
m
Auf
trag
ssys
tem
Verk
aufs
-und
Za
hlun
gssy
stem
Kas
senb
eric
ht
Info
- und
Mai
lsys
tem
Trav
el A
ssis
tant
Qua
lity
Ass
uran
ce
Eige
nver
anst
altu
ng
Buc
hhal
tung
ssyt
em
Man
agem
ent I
nfos
yste
m
Basismodule Optionale Module
Funktionale ArchitekturFunktionale Architektur Schichten Schichten ArchitekturArchitektur
Datenzu-griffsschicht
Abstrakte Datenschicht
Geschäfts-regeln
Bildschirm-transaktionen
ProprietäresFile System
“Windows Like”Benutzeroberfläche
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 27
Beispiel 2 : LösungsszenarienBeispiel 2 : Lösungsszenarien
• Alternative 1: Client-Server Neuentwicklung Anspruch: Neue skalierbare, zukunftssichere Lösung– UNIX Server + Windows Clients– Objektorientierte 3-Stufen-Architektur mit „dünnem“ Client– Nachrichtenorientierte Kommunikation + Online Transaktionsmonitor
• Alternative 2: „Host Evolution + Windows Oberfläche“ Anspruch: Modernisieren statt neu– Schrittweises Ersetzen der proprietären Datenhaltung durch Oracle auf
Mainframe– Klare Schichtenarchitektur– Entwicklung eines „fetten“ Windows Client mit GUI Rahmen + Integration
mit „ererbten“ zeichenorientierten Oberflächenteilen– Nachrichtenorientierte Kommunikation + Online Transaktionsmonitor
• Alternative 3: „Client-Server + Mainframe Koexistenz“ Anspruch: Modernisieren bei mehrjähriger Koexistenz– Ersetzen der proprietären Datenhaltung durch Oracle auf UNIX Server– Objektorientierte 3- Stufen-Architektur mit „dünnem“ Client– Nachrichtenorientierte Kommunikation + Online Transaktionsmonitor– Zugriff der Mainframe Komponenten auf den UNIX Datenserver
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 28
Client-Server NeuentwicklungClient-Server Neuentwicklung
Kom
pone
nte
Sich
erhe
it &
Dat
ensc
hutz Verwalten
KundenVerwaltenAufträge
Verkauf und Zahlung MIS ...
Komponente Geschäftsprozess & Workflow
KomponenteKunde
...
Komponente Objekt-RDBMS-Abbildung
KundeKunde AuftragAuftrag RechnungRechnungVertragVertrag
OracleOracle
Kom
pone
nte
Syst
emm
anag
emen
t
KomponenteAuftrag
KomponenteVerkauf & Zahlung
KomponenteMIS ...
Komponente Nachricht
Komponente Nachricht
UNIXUNIX
UNIXUNIX
WindowsWindows
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 29
Mainframe Evolution + Windows OberflächeMainframe Evolution + Windows Oberfläche
VerwaltenKunden
...KundeKundeAuftragAuftrag RechnungRechnungVertragVertrag
OracleOracle
Kom
pone
nte
Syst
emm
anag
emen
t
...
Kom
pone
nte
Sich
erhe
it &
Date
nsch
utz
MainframeMainframe
WindowsWindowsMISVerkauf &
ZahlungVerwaltenAufträge
...
API für „ererbte“ Verfahren
Kompo-nente
Auftrag
...KundeKundeAuftragAuftrag RechnungRechnungVertragVertrag
File SystemFile System
Objekt-RDBMS-
Abbildung
KomponenteKunde
Komponente Nachricht
Abstrakte & Datenzugriffsschicht
Kompo-nente
Verk. & Zahlung
Kompo-nenteMIS
...
Komponente Geschäftsprozeß & Workflow
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 30
Client-Server + Host KoexistenzClient-Server + Host Koexistenz
Kom
pone
nte
Sich
erhe
it &
Date
nsch
utz
Win
dows
Win
dows
...KundeKundeAuftragAuftrag RechnungRechnungVertragVertrag
OracleOracle
Kom
pone
nte
Syst
emm
anag
emen
t
KomponenteKunde
Komponente Nachricht
VerwaltenKunden MISVerkauf und
ZahlungVerwaltenAufträge
...
...
Kom
pone
nte
Nach
richt
UN
IXU
NIX
Kom
pone
nte
Sich
erhe
it &
Date
nsch
utz
API für „ererbte“ Verfahren
Kompo-nente
Auftrag
Abstrakte & Datenzugriffsschicht
Kompo-nente
Verk. & Zahl.
Kompo-nenteMIS
...
Objekt-RDBMS-Abbildung
MainframeMainframe...KundeKundeAuftragAuftrag RechnungRechnungVertragVertrag
File SystemFile System
Komponente Geschäftsprozeß & Workflow
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 31
Bewertung der LösungsszenarienBewertung der Lösungsszenarien
• Gute SkalierbarkeitGute Skalierbarkeit• Zukunftssichere Zukunftssichere
TechnologieTechnologie
• Zuverlässige und Zuverlässige und vertraute Technologievertraute Technologie
• Zuverlässiger BetriebZuverlässiger Betrieb• Stabiler Stabiler
MigrationswegMigrationsweg
• Extrem hohe KostenExtrem hohe Kosten• Extrem lange Extrem lange
LieferzeitLieferzeit• „„Neue Lösung neue Neue Lösung neue
Fehler“Fehler“• Totale Änderung des Totale Änderung des
BetriebesBetriebes
• „„Konservieren“ des Konservieren“ des Mainframe „für Mainframe „für immer“immer“
• Hohe Hardware-Hohe Hardware-kosten und kosten und langfristige langfristige AbhängigkeitAbhängigkeit
Pro
Pro
Kon
tra
Kon
tra
Client-Server Neuentwicklung
„Host Evolution + Windows Oberfläche“
„Client-Server + Mainframe Koexistenz“
• Zukunftssicherheit Zukunftssicherheit bei geringem Risiko bei geringem Risiko durch Strategie der durch Strategie der „kleinen Migrations-„kleinen Migrations-schritte“schritte“
• Hohe Hohe Entwicklungskosten Entwicklungskosten für Koexistenzfür Koexistenz
• Hohe Hardwarekosten Hohe Hardwarekosten durch Koexistenz durch Koexistenz
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 32
Beispiel 2 : Die neue InfrastrukturBeispiel 2 : Die neue Infrastruktur
UNIX Server
“Ererbte” Mainframes
WAN
Gateway
Host A Host B Host C Host D
Server1
Server2
Server3
ServernExterne
Dienstleister
Hochgeschwindigkeits-Netzwerk
WindowsClient
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 33
Beispiel 2 : Die neue InfrastrukturBeispiel 2 : Die neue Infrastruktur
ErerbteMainserver
UNIXServer
Work-stations
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 34
Herausforderungen: Zusammenfassung 1Herausforderungen: Zusammenfassung 1
• Kooperation von Systemen mit inhomogenen Plattformen– “Legacy”, z.B. IBM oder BS 2000 (Siemens) Mainframes– Client-Server-Architekturen
• UNIX• Windows
• State of the Art Technology unterstützen– Objekttechnologie, z.B. OO Analyse & Design, OO Sprachen wie C++, Java– Komponententechnologie, z.B. EJB, COM oder CORBA basierte
Komponentensysteme– Internet, Intranet bzw. Web Technologien
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 35
Herausforderungen: Zusammenfassung 2Herausforderungen: Zusammenfassung 2
• Verbindende Standards - für Interoperabilität trotz Heterogenität – Bei unterschiedlicher Formen verteilter Datenorganisation
• VSAM und IMS • relationale DBMS, z.B. DB2, Oracle, Informix, Sybase• Object DBMS, z.B. Objectivity, Objectstore• Content / Wissens-Repositories
– Bei unterschiedlichen Programmierschnittstellen für das Bereitstellen von Services
• Application Programming Interfaces, z.B. in C• Objektorientierte Schnittstellen, z.B. in C++, Java• Komponenten Architekturen: EJB, .NET
– Bei unterschiedlicher Form der Ressourcenverteilung im Netzwerk– Bei unterschiedlicher Form der Zugriffskontrolle durch die Systeme– Bei unterschiedlichem “Look and Feel” der Benutzeroberflächen
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 36
Kommunikation zwischen Kommunikation zwischen AnwendungskomponentenAnwendungskomponenten
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 37
Kommunikations-DiensteKommunikations-Dienste
Dienste für die Kommunikation zwischen verteilten Anwendungen und Komponenten Kommunikationsparadigmen
– Conversational Modell - nach dem CPI-C Standard– Remote Procedure Call Modell - RPC nach OSF/DCE– CORBA – Common Object Request Broker Architecture (OSF)– RMI, IIOP, SOAP– Nachrichtenorientiertes Paradigma - Messaging and Queuing Model– Web-Protokoll HTTP
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 38
Conversational Modell – CPI-CConversational Modell – CPI-C
Synchrone 1:1 Kommunikation nach dem CPI-C StandardCPI-C: Common Programming Interface for Communications
Computer “II”Computer “I”
ProzessA
ProzessB
Nachricht
Nachricht
A
B
A sendet Nachrichtan B
Zeit
ProcessStatus
B sendet Nachrichtan A
B führt Auftrag von A aus
A wartet auf B
Message = (Tag, Length, Value)
... CPI-C Stub
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 39
Conversational Modell – CPI-CConversational Modell – CPI-C
• Plattformunabhängiger Standard für APPC• APPC: Advanced Program to Program Communication• CPI-C Funktionen:
Aufruf: CALL routine_name (parameter*, return_code)Wichtigste Routinen:
CMINIT Initialize ConversationCMACCP Accept ConversationCMALLC AllocateCMSEND Send DataCMRCV Receive DataCMDEAL Deallocate
BeispielCMSEND (conversation_id, /* Input */
buffer /* Input */send_length /* Input */ &Request_to_send_received, /* Output */&return_code); /* Output */
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 40
Remote Procedure CallRemote Procedure Call
Synchrone n:1 Kommunikation nach dem RPC Standard
Reply Resultat
Call Argumente
Computer “X”Client AProzess
Computer “Z”Server
Prozess
Client Stub
Computer “Y”Client BProzess
Client A
Server
Client A ruft Server auf
Zeit
ProcessStatus Server führt Auftrag
von A aus
A wartet auf Antwort
Client B
Server führt Auftrag von B aus
Client B ruft Server auf
B wartet auf Antwort
Call Reply
Call Reply
Server Skeleton
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 41
CORBACORBA
CORBA: Common Object Request Broker Architecture
Aufgabe Nutzer(Client)
Anbieter(Server)
InterfaceClient und Server sollen verteilt sein
Lösung Nutzer(Client)
Anbieter(Server)
Client Stub Server Skeleton
Object Request Broker(ORB; Software Bus)
Generiert aus Interface
beschrieben in IDL
Interface Definition Language
Client und Server können• in beliebigen• auch unterschiedlichenSprachen geschrieben sein
CORBA/IDL sorgt für Mapping der Interfaces
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 42
RMI, IIOP, SOAPRMI, IIOP, SOAP
• Remote Method Invocation (RMI)RPC Variante für Java
• IIOPInternet Inter ORB ProtocolHeute auch benutzt als Basis für RMI im Web
• SOAPSimple Object Access ProtocolXML basiertes Protokoll– RPC– Messages zwischen unterschiedlichen Plattformen– Java basiert– Microsoft.NET
Themen werden später noch behandelt
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 43
„„Messaging and Queuing“ ModellMessaging and Queuing“ Modell
Asynchrone n:m Nachrichtenkommunikation über Warteschlangen
Computer “A”Client AProzess
Computer “B”Client BProzess
Computer “X”Server XProzess
... Nachrichten Stub
... persistente Warteschlange
Nachricht
Client A
Server X
Zeit
Client B
Server Y
AX
BX
X(A)Y X(B)Y Y(A)X Y(B)X
X(A)A
X(B)B
Message = (Tag, Length, Value)
Queue Computer
Computer “Y”Server YProzess
Queue 1
Queue 2
Queue 3
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 44
HTTP – Internet ProtokollHTTP – Internet Protokoll
• HTTP: HyperText Transfer Protocol • Generisches (für beliebige Daten), zustandsfreies Protokoll
HTTP response
HTTP requestComputer “Z”
In-Pipe
... HTTP stub
Computer “X”Web
Client A
Computer “Y”Web
Client B
Out-Pipe
Pipe .. HTTP pipe
Web Server HTML Pages
Web
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 45
HTTP – Internet ProtokollHTTP – Internet Protokoll
• 1990 in Verbindung mit WWW am CERN (Genf) definiert• Gegenwärtige Version 1.1; Performanceverb. gegenüber 1.0• HTTP request: request_method request_URL header body
– Request Methods HTTP 1.1):• GET retrieves the resource identified by the request URL• HEAD returns the header identified by the request URL• POST sends data to the Web server• PUT stores a resource under the request URL• DELETE removes the resource identified by the request URL• OPTIONS returns the HTTP methods the server supports• TRACE returns the header fields sent with the TRACE request
• HTTP response: result_code header body
HTTP 1.0
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 46
Schichten und Stufen von Web AnwendungenSchichten und Stufen von Web Anwendungen
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 47
Schichten einer AnwendungSchichten einer Anwendung
Anwendungs-Logik
Datenhaltung
User Interface User Interface
Datenbank
Anwendungs-Logik
DB Interface
TP M
onito
r
1970 1985
Ablaufsteuerung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 48
Schichten und Stufen von ArchitekturenSchichten und Stufen von Architekturen
• Schichten (Layer)– Logische Einheiten, die bestimmte Aufgaben für eine Anwendung erfüllen– Ursprüngliche Sicht: Schichten liegen übereinander– Realistische Sicht: Teilsysteme, die miteinander kommunizieren
• Stufen (Tiers)– Instanzen einer Anwendung– Zuordnung Schichten zu Stufen nicht 1:1– Im Web Umfeld typisch: n-tier Architekturen
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 49
Schichten und Stufen von ArchitekturenSchichten und Stufen von Architekturen
User Interface
Datenbank
Anwendungs-Logik
DB Interface
Ablaufsteuerung
Mainframe
T e r m i n a l
Anwendungs-Schichten
S t u f e n
Mainframe Client / Server
Client
( PC )
Server
Client
( PC )
Server
„Fette“ Clients
Client
( PC )
Server
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 50
Schichten und Stufen von ArchitekturenSchichten und Stufen von Architekturen
User Interface
Datenbank
Anwendungs-Logik
DB Interface
Ablaufsteuerung
Anwendungs-Schichten
S t u f e n
W e b
Browser
W e b
Server
Browser
Web Server
Xxx Server
...
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 51
Übergang von C/S zu WEBÜbergang von C/S zu WEB
• Clients (thin)– Keine Anwendungslogik auf dem Client– Verarbeitung nur für Benuter-Schnittstelle– Laden des Codes über das Netz– Vorteile:
• Keine Installation und Updates auf den (vielen) Clients• Einfachere Verwaltung• Sicherheit (Keine Wechsel-Laufwerke auf Clients)
• Java als plattform-unabhängige Sprache– Interpreter-Konzept– Vorteil: Portabilität der Anwendungen
• Industrie Standards als Plattformtechnologien– Internet, Web– J2EE, .NET– XML– Web Services
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 52
2-Stufen Architektur2-Stufen Architektur
Plugins
HTML Applet Andere Datenformate
JSP Servlets
Daten
HTTP
Web Browser
Web Server
Clienseitig:• User Interface• Ablaufsteuerung über Applets
Serverseitig:• User Interface• Ablaufsteuerung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 53
Beispiel: Publizieren von InformationenBeispiel: Publizieren von Informationen
• Unterscheidung– Informationsbereitstellung: Autoren– Publizierung
• Autoren– Arbeiten traditionell in typischen C/S Umgebungen– Neuere Anforderungen: Arbeit auch über das Web– Benutzen
• Office Werkzeuge• Spezielle Anwendungen (Web Editoren, z.B. FrontPage von MS)
• Publizierung– Statische Web-Seiten
• HTML– Dynamisches Publizieren
• Dynamischer Aufbau von Web-Seiten aus Daten von unterschiedlichen Quellen (auch DMBS)
• JSP (Java), ASP (VB)
• Anwendungen: Internet Auftritte, Intranet
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 54
Publizieren von InformationenPublizieren von Informationen
HTML
JSP
HTTP
Web Browser
Web ServerDaten
AutorenArbeitsplatz
Windows / Web Browser
LAN
HTTPHTML
JSP File
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 55
Publizierung von Informationen mit UpdatePublizierung von Informationen mit Update
• Autorenarbeitsplatz wie bei Variante ohne Update• Update
– HTML mit JavaScript– Applet
• Typische Anwendungen– Intranet mit Korrekturmöglichkeiten (z.B. Telefon-Nr.)– Einfache Business-Anwendungen (z.B. Kreditkalkulation)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 56
Publizieren von Informationen mit UpdatePublizieren von Informationen mit Update
HTML
JSP
Web Browser
Web ServerDaten
HTTP
HTML
JSP File
Applet
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 57
3-Stufen Architektur mit DB-Server3-Stufen Architektur mit DB-Server
Plugins
HTML Applet Andere Datenformate
JSP Servlets Daten
HTTP
D B M S
DB-Server
LAN
Web Browser
Web Server
Java (Anw.-Funkt.)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 58
Beispiel: WissensmanagementBeispiel: Wissensmanagement
• Wissensmanagement– Kein klar umrissene Anwendung– Vielfältige Ansätze
• Wissensmanagement hier:– Wissensakquisition– Wissensadministration– Wissenspublikation
• Verteilen• Abholen
• Wissensmanagement ist Management von Beziehungen– Wissensrepository
• Beispiel: Skillmanagement
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 59
Was ist WissenWas ist Wissen
Daten
VerknüpfungVerknüpfungKontextKontext
InterpretationInterpretation
Information
Wissen
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 60
WissensakquisitionWissensakquisition
Erfassen AnalysierenAufbereiten
Wissensrepository
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 61
Publikation von WissenPublikation von Wissen
Wissensrepository
GezieltInformieren
SucheNavigation
Intranet / Extranet
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 62
WissensmanagementWissensmanagement
HTML
JSP
Web Browser
Web Server
Daten
HTTP
Applet
Servlets
Wissensrepository
Java (Anw.-Funkt.)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 63
3-Stufen Architektur mit Mainframe3-Stufen Architektur mit Mainframe
Plugins
HTML Applet Andere Datenformate
JSP
ServletsDaten
HTTP
Mainframe
LAN, proprietäre Protokolle
Alt-Anwendung
Web Browser
Web Server
Java (Anw.-Funkt.)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 64
BeispielBeispiel
• Web-ifizierung von Mainframeanwendungen• Häufige Situation bei Mainframeanwendungen
– Große Anwendungs-Systeme– Hoher Entwicklungsaufwand– Mission-critical Anwendungen– User Interface altbacken und unkomfortabel– Verteilung über proprietäres Netzwerk
• Vorteile einer Web-ifizierung– Modernes User Interface– Benutzung Standard Netzwerk (TCP/IP, HTTP)– Keine Neuentwicklung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 65
4-Stufen Architekt. mit Application und DB-Server4-Stufen Architekt. mit Application und DB-Server
Plugins
HTML Applet Andere Datenformate
JSP
ServletsDaten
DB-Server
Web Browser
Web Server
Application-Server
Enterprise JavaBeans
Java (Anw.-Funkt.)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 66
Beispiel ECOM (ohne Anbindung Fremdsyst.)Beispiel ECOM (ohne Anbindung Fremdsyst.)
Webserver 2NetscapeEnterpriseServer
mit BEA WLS Plugin
UltraThin
Client
dbserv X
eCOM Infrastruktur 1BEA WebLogicServer
PrimaryServer für Webserver 1*
eCOM Infrastruktur 2BEA WebLogicServer
SecondaryServer für Webserver 1*SecondaryServer für Webserver 2*
eCOM Infrastruktur 3BEA WebLogicServer
PrimaryServer für Webserver 2*
Logisches WLS-Cluster
http-Dispatcher 1 http-Dispatcher 2
hot-stand-by Dispatcher-Cluster
Webserver 1NetscapeEnterpriseServer
mit BEA WLS Plugin
http
http
http
Internet /Extranet
Intranet(Corporate Network)
DMZ(Access LAN)
*wird dynamisch pro User zugeordnet
File-server
http
File-server
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 67
5-Stufen Architektur mit Alt-Anwendungen5-Stufen Architektur mit Alt-Anwendungen
DB-Server
Application-Server
Web Server
Web Client
Alt-
Anw
endu
ngE
RP
SD
B
Mai
nfra
me
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 68
Supp
ort
Mod
ules
Supp
ort
Mod
ules
Supp
ort
Mod
ules
DealerPortal(Clarify)
Vehi
cle
Sele
ctor
Dea
ler
Loca
tor
Req
uest
for
Offe
r
Test
Driv
eA
ppoi
ntm
ent
Use
d C
arPr
ice
Indi
cato
r
Req
uest
for
Info
rmat
ion
Asc
erta
inSe
ssio
n U
ser
SubsidiaryPortal(Clarify)
Supp
ort
Mod
ules
Serv
ice
App
oint
men
t
• 8 Module + Car Configurator• Portale der Landesgesellschaften und Händler integriert (TopDrive mit Clarify)• Integration von Finanzdienstleistungen• Automatische Integration von Anwendungen zur Datenbeschaff. (PCASO, HST, …)
PCASO
Vehi
cle
Con
-fig
urat
or
Use
d C
arM
anag
emen
t
TopDrive(Clarify)HST
CustomerData
Dealer Data
Car Data
eCOM Data
SF Inte
grat
ion
Customer Interface
t.b.d
efin
edBeispiel ECOMBeispiel ECOM
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 69
Client mit LAN Zugriff auf ServerClient mit LAN Zugriff auf Server
DB-Server
Application-Server
Web Server
Web Client
Alt-
Anw
endu
ngE
RP
SD
B
Mai
nfra
me
HTTPLAN
Firewall
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 70
Web & Application ServerWeb & Application Server
DB-Server
Web &Application Server
Produkte vom Markt (BEA, IBM, …)kombinieren in der Regel beides
Web Client
Alt-
Anw
endu
ngE
RP
SD
B
Mai
nfra
me
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 71
Physische Stufen-ArchitekturPhysische Stufen-Architektur
Client
Server
Server
Mainframe
. . .
Web-Client mit Web-Browser
Web-ServerApplication ServerDB-Server
Alt-Anwendungen (Legacy Systems)
HTTP
LAN
LAN oder proprietäre Protokolle
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 72
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
• Logische und physische Stufenarchitektur nicht unbedingt identisch• Gegebene Zuordnung
– Web Client ClientClient
• Traditionell: PC• Web PC, Network Computer• PDA• Mobiles Telefon• Spezialgeräte
– Altanwendung häufig Mainframe
• Abbildung im Serverbereich vielfältig
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 73
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
Client
Server
Server
Server
Web-Server
Application-Server
DB-Server
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 74
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
Client
Server
Web-Server
Application-Server
DB-Server
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 75
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
Client
Server
ServerServerServer
Web-Server
Application-Server
DB-ServerServerServerServer
Siehe auch: ECOM Beispiel (Folien 55 & 56)
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 76
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
Client
ServerServerServer Web & Application Server
DB-ServerServerServerServer
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 77
Abbildung logische/physische StufenarchitekturAbbildung logische/physische Stufenarchitektur
• Kombination der gezeigten Abbildungen möglich• Kriterien für Kombination unterschiedlicher Funktionen auf einem
Server oder Verwendung mehrerer Instanzen für eine Funktion– Komplexität der Anwendung– Anzahl Benutzer– Antwortzeitverhalten– Klarheit der Anwendungsstruktur– Kombination mit anderen Anwendungen– Lastverteilung
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 78
Entwicklungsstadien (Nutzungsarten) des WebEntwicklungsstadien (Nutzungsarten) des Web
Informationsmedium• Statische Webseiten
Informationsmedium mitUpdatemöglichkeit• Dynamische Webseiten• Client-seitige Komponenten• Datenbankzugriff
Plattform für• E-Business• Unternehmens-kritische Anwendungen
• Alle Anwendungskonzepte
Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 79
ReferenzarchitekturReferenzarchitektur
Con
tent
Man
agem
ent
Pro
zess
-Man
agem
ent
FirewallHTTPLAN
Tran
sakt
ions
-Man
agem
ent
Mes
sagi
ng S
ervi
ces
Portal Server
Benutzer-SchnittstellenKomponenten
BusinessKomponenten
Datenbank-Zugriffe
DatenbankenIn
tegr
atio
nsS
ervi
ces
Ver
zeic
hnis
Sch
nitts
telle
n
VerzeichnisServices
GeschäftsPartner
ERP Systeme
Alt-Anwend.
Datenbanken
Sic
herh
eit