Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 63 Systemeigenschaften und Architektur Wiederverwendung Rolle von Architekten

Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 1

Systemeigenschaften und ArchitekturSystemeigenschaften und Architektur

WiederverwendungWiederverwendung

Rolle von ArchitektenRolle von Architekten


Anforderungen an AnwendungenAnforderungen an Anwendungen

Anwendungssystem

FunktionaleAnforderungen

SystemEigenschaften


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


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


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)


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


Anwendungs-EntwicklungsprozessAnwendungs-Entwicklungsprozess

Planen Entwickeln Betreiben

Analyse Spezifikation Entwurf CodierungIntegration

Qualitäts-Sicherung


Wiederverwendung auf Code-NiveauWiederverwendung auf Code-Niveau



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


FrameworksFrameworks

Framework

Anwendung

SpezialisierungSpezialisierung


Wiederverwendung mit FrameworksWiederverwendung mit Frameworks



Framework Repository(Modell & Komponenten)

KomponentenAnpassenEinbauen

Modell des Frameworks Architektur des

Frameworks

FrameworkEntwickler


Wiederverwendung von Architektur & KomponentenWiederverwendung von Architektur & Komponenten

Anwendung

Individual-Entwicklung

KomponentenBasierte Entwicklung

Anpassung vonStandard-SW

Standard-SWPaket

KomponentenVom Markt

Modell & Referenz-Architektur

KomponentenBibliothek


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


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


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


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


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 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


Herausforderungen an ArchitekturenHerausforderungen an ArchitekturenBeispiele aus der PraxisBeispiele aus der Praxis


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


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


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


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


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


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


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


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


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


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


UNIXUNIX

UNIXUNIX

WindowsWindows


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


File SystemFile System

Objekt-RDBMS-

Abbildung

KomponenteKunde


Abstrakte & Datenzugriffsschicht

Kompo-nente

Verk. & Zahlung

Kompo-nenteMIS

...

Komponente Geschäftsprozeß & Workflow


Client-Server + Host KoexistenzClient-Server + Host Koexistenz

Kom

pone

nte

Sich

erhe

it &

Date

nsch

utz

Win

dows

Win

dows


OracleOracle

Kom

pone

nte

Syst

emm

anag

emen

t

KomponenteKunde


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


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


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


Beispiel 2 : Die neue InfrastrukturBeispiel 2 : Die neue Infrastruktur

ErerbteMainserver

UNIXServer

Work-stations


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


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


Kommunikation zwischen Kommunikation zwischen AnwendungskomponentenAnwendungskomponenten


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


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


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 */


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


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


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


„„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


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


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


Schichten und Stufen von Web AnwendungenSchichten und Stufen von Web Anwendungen


Schichten einer AnwendungSchichten einer Anwendung

Anwendungs-Logik

Datenhaltung

User Interface User Interface

Datenbank

Anwendungs-Logik

DB Interface

TP M

onito

r

1970 1985

Ablaufsteuerung


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



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



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

...


Ü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


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


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


Publizieren von InformationenPublizieren von Informationen

HTML

JSP

HTTP

Web Browser

Web ServerDaten

AutorenArbeitsplatz

Windows / Web Browser

LAN

HTTPHTML

JSP File


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)


Publizieren von Informationen mit UpdatePublizieren von Informationen mit Update

HTML

JSP

Web Browser

Web ServerDaten

HTTP

HTML

JSP File

Applet


3-Stufen Architektur mit DB-Server3-Stufen Architektur mit DB-Server

Plugins


JSP Servlets Daten

HTTP

D B M S

DB-Server

LAN

Web Browser

Web Server

Java (Anw.-Funkt.)


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


Was ist WissenWas ist Wissen

Daten

VerknüpfungVerknüpfungKontextKontext

InterpretationInterpretation

Information

Wissen


WissensakquisitionWissensakquisition

Erfassen AnalysierenAufbereiten

Wissensrepository


Publikation von WissenPublikation von Wissen

Wissensrepository

GezieltInformieren

SucheNavigation

Intranet / Extranet


WissensmanagementWissensmanagement

HTML

JSP

Web Browser

Web Server

Daten

HTTP

Applet

Servlets

Wissensrepository

Java (Anw.-Funkt.)


3-Stufen Architektur mit Mainframe3-Stufen Architektur mit Mainframe

Plugins


JSP

ServletsDaten

HTTP

Mainframe

LAN, proprietäre Protokolle

Alt-Anwendung

Web Browser

Web Server

Java (Anw.-Funkt.)


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


4-Stufen Architekt. mit Application und DB-Server4-Stufen Architekt. mit Application und DB-Server

Plugins


JSP

ServletsDaten

DB-Server

Web Browser

Web Server

Application-Server

Enterprise JavaBeans

Java (Anw.-Funkt.)


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*


SecondaryServer für Webserver 1*SecondaryServer für Webserver 2*


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


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


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


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


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


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


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



Client

Server

Server

Server

Web-Server

Application-Server

DB-Server



Client

Server

Web-Server

Application-Server

DB-Server



Client

Server

ServerServerServer

Web-Server

Application-Server

DB-ServerServerServerServer

Siehe auch: ECOM Beispiel (Folien 55 & 56)



Client

ServerServerServer Web & Application Server

DB-ServerServerServerServer



• 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


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


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

Documents

Architektur von Web-Anwendungen, LMU, WS-01/02 Folie 63 Systemeigenschaften und Architektur Wiederverwendung Rolle von Architekten