Präsentation zum Thema: ""—  Präsentation transkript:

63 Systemeigenschaften und Architektur Wiederverwendung Rolle von Architekten

64 Anforderungen an Anwendungen
Anwendungssystem Funktionale Anforderungen System Eigenschaften

65 Systemeigenschaften Performance, Antwortzeit Verfügbarkeit
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

66 Systemeigenschaften Architektur maßgeblich für das
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 das Ereichen von Systemeigenschaften Abwägung bei Konflikten

67 Anforderungs-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)

68 Wiederverwendung 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 Komponenten außer: Komplettpakete wie SAP Gründe: Wiederverwendung Zu spät im Entwicklungsprozess Nur auf Code-Niveau

69 Anwendungs-Entwicklungsprozess
Planen Entwickeln Betreiben Analyse Spezifikation Entwurf Codierung Integration Qualitäts- Sicherung

70 Wiederverwendung auf Code-Niveau
Analyse Spezifikation Entwurf Codierung Integration Qualitäts- Sicherung Chance, dass passender Modul gefunden wird, sehr gering Keine Frage der Klassifikation oder Suche Lösung: Wiederverwendung auf höherem Niveau oder Spezifikation und Entwurf so, dass vorhandene Module eingesetzt werden können Vorbild: Hardware-Geräteentwicklung Extrem-Beispiel: Standard Software wie SAP Klassifizieren Speichern Suchen Einbauen Modul Bibliothek

71 Frameworks Framework Spezialisierung Anwendung

72 Wiederverwendung mit Frameworks
Analyse Spezifikation Entwurf Codierung Integration Qualitäts- Sicherung Modell des Frameworks Architektur des Frameworks Komponenten Anpassen Einbauen Framework Repository (Modell & Komponenten) Framework Entwickler

73 Wiederverwendung von Architektur & Komponenten
Anwendung Individual- Entwicklung Komponenten Basierte Entwicklung Anpassung von Standard-SW Modell & Referenz-Architektur Standard-SW Paket Komponenten Vom Markt Komponenten Bibliothek

74 Rolle von Referenzarchitekturen und Frameworks
Anwendung 1 Anwendung 1 Anw.1 Anwendung 2 Anwendung 2 Anw.2 . . . Anwendung n Anwendung n Anw.n abgeleitet abgeleitet Jede Anwendung hat eigene isolierte Architektur Referenz-Architektur (Blueprint) Framework Anwendungsmodell Referenzarchitektur Komponenten

75 Konzepte für die Anwendungsentwicklung
Frameworktechnik Muster für Anwendung Vorgefertigte Komponenten / Design Patterns Komponententechnologie Produktivität durch Container und Laufzeitservices Design Patterns OO Modellierung OO Programmierung Gener. von Coderahmen

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

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

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

79 Architektur im Software Lebenszyklus
Anwender A n a - Marketing l y s e IT Spezifikation Funkt. Anford. Spezifikation Systemeigensch. Referenz Architektur Entwurf Architektur Framework Interner Standard Vorherg. Version Anpassung & Iterative Entwicklung Detail Spezifikation Komponenten (Teil-) Codierung Integr. Test Produkte vom Markt Untern.-eig. Kompon. Vorherg. Release QS Funkt. & Systeme. Freigabe Roll-out

80 Herausforderungen an Architekturen Beispiele aus der Praxis

81 Herausforderungen an Architektur
Existierende IT „Ererbte“ Architekturen & Technologien „ererbte Systeme“ versus neue Geschäftsprozesse proprietäre SW-Produkte „Ererbte“ IT Organisation Herausforderungen 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ß Datenfluß Benutzergruppe Anwendung Computer Netzwerk Anwendungsfunktion Schicht Komponente Objekt Sicherheit Systemmanagement Zugriffsrecht Rechtegruppe System Ressource Organisationseinheit Handout Teil Seite

82 Risiken für strategische Architekturprojekte
Budget und Termin Budget- und Ressour-cenverbrauch zu hoch Terminüberschreitung 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ß Datenfluß Benutzergruppe Anwendung Computer Netzwerk Anwendungsfunktion Schicht Komponente Objekt Sicherheit Systemmanagement Zugriffsrecht Rechtegruppe System Ressource Organisationseinheit Handout Teil Seite

83 Beispiel 1: Inseln mit funktioneller und Datenredundanz
Auftrags- verwaltung I Rechnungen Erstellen II Rechnungen Erstellen I Rechnungen Erstellen III Finanzen Verwalten Tuxedo Interfaces Auftrags- verwaltungI I Kundendienst I Dokumentenverwaltung Basierend auf untersch. Produkten Kundendienst II Kunden Prüfen Kundendienst III Handout Teil Seite

84 Beispiel 1: Vision „Komponentenarchitektur“
View Layer Partner Vertrieb Web Marketing Auftrags- verwaltung Kunden- ... Systemsmanagement Sicherheit Prozesse (Workflow) Business Layer Geschäftslogik Vertriebs- komponente Auftrags- komponente Rechnungs- komponente Kunden- Komponente ... Zugriffsschicht Zugriffsschicht Zugriffsschicht Zugriffsschicht Zugriffsschicht Data Layer Handout Teil Seite

85 Beispiel 1: Realität - Mix aus Systemarchitekturen
View Layer Partner Vertrieb Auftrags- verwaltung Rechnungs- system ... Daten Integration & Transaktionsmanagement Kunde Auftrag Vertrag Rechnung Vertriebssystem Web Kunden- Client Server Handout Teil Seite

86 Beispiel 2: Geschäftsprozesse
Kundensystem Beratung Management Information- System Auftragssystem Unternehmens- Steuerung Buchung Ticket- Erstellung Buchhaltungs- system Verkauf und Zahlung Buchhaltung Verkauf und Zahlung Zahlungs- Abwicklung Verkaufs- Abwicklung Kunden- und Auftragssystem Handout Teil Seite

87 Beispiel 2 : Die Infrastruktur
Clients “Ererbte” Mainframes Windows Client MF A MF B MF C MF D >=9600 bit/sec WAN Gateway Hochgeschwindigkeits- Netzwerk Externe Dienstleister Handout Teil Seite

88 Beispiel 2 : „Ererbte“ Mainframe-Anwendungen
Funktionale Architektur Schichten Architektur “Windows Like” Benutzeroberfläche Basismodule Optionale Module Bildschirm- transaktionen Management Infosystem Carrier Integration Kundensystem Auftragssystem Zahlungssystem Verkaufs-und Kassenbericht Info- und Mailsystem Travel Assistant Quality Assurance Eigenveranstaltung Buchhaltungssytem Geschäfts- regeln Abstrakte Datenschicht Datenzu- griffsschicht Proprietäres File System Handout Teil Seite

89 Beispiel 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 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 Zugriff der Mainframe Komponenten auf den UNIX Datenserver Handout Teil Seite

90 Client-Server Neuentwicklung
Verwalten Kunden Verwalten Aufträge Verkauf und Zahlung MIS ... Windows Komponente Nachricht Komponente Geschäftsprozess & Workflow UNIX Komponente Kunde Komponente Auftrag Komponente Verkauf & Zahlung Komponente MIS ... Komponente Systemmanagement Komponente Sicherheit & Datenschutz Komponente Nachricht Komponente Objekt-RDBMS-Abbildung Oracle UNIX Kunde Rechnung Auftrag Vertrag Handout Teil Seite

91 Mainframe Evolution + Windows Oberfläche
... Verwalten Kunden Verwalten Aufträge Verkauf & Zahlung MIS ... Windows Komponente Geschäftsprozeß & Workflow API für „ererbte“ Verfahren Kompo- nente Auftrag Objekt- RDBMS- Abbildung Komponente Kunde Nachricht Abstrakte & Datenzugriffsschicht Kompo- nente Verk. & Zahlung MIS ... Komponente Systemmanagement Komponente Sicherheit & Datenschutz Mainframe Oracle File System Kunde Auftrag Rechnung Vertrag Kunde Rechnung Auftrag Vertrag Handout Teil Seite

92 Client-Server + Host Koexistenz
Komponente Sicherheit & Datenschutz Windows Kunde Auftrag Rechnung Vertrag Oracle Komponente Systemmanagement Komponente Komponente Nachricht Verwalten Kunden MIS Verkauf und Zahlung Aufträge ... UNIX API für „ererbte“ Verfahren Kompo- nente Abstrakte & Datenzugriffsschicht Verk. & Zahl. Objekt-RDBMS- Abbildung Mainframe File System Komponente Geschäftsprozeß & Workflow Handout Teil Seite

93 Bewertung der Lösungsszenarien
Client-Server Neuentwicklung „Host Evolution + Windows Oberfläche“ „Client-Server + Mainframe Koexistenz“ Gute Skalierbarkeit Zukunftssichere Technologie Zuverlässige und vertraute Technologie Zuverlässiger Betrieb Stabiler Migrationsweg Zukunftssicherheit bei geringem Risiko durch Strategie der „kleinen Migrations-schritte“ Pro Extrem hohe Kosten Extrem lange Lieferzeit „Neue Lösung neue Fehler“ Totale Änderung des Betriebes „Konservieren“ des Mainframe „für immer“ Hohe Hardware-kosten und langfristige Abhängigkeit Hohe Entwicklungskosten für Koexistenz Hohe Hardwarekosten durch Koexistenz Kontra Handout Teil Seite

94 Beispiel 2 : Die neue Infrastruktur
“Ererbte” Mainframes Windows Client Host A Host B Host C Host D WAN Gateway Hochgeschwindigkeits- Netzwerk UNIX Server Server 1 Server 2 Server 3 Server n Externe Dienstleister Handout Teil Seite

95 Beispiel 2 : Die neue Infrastruktur
Handout Teil Seite

96 Herausforderungen: 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 Handout Teil Seite

97 Herausforderungen: 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 Handout Teil Seite

98 Kommunikation zwischen Anwendungskomponenten
Handout Teil Seite

99 Kommunikations-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 Handout Teil Seite

100 Conversational Modell – CPI-C
Synchrone 1:1 Kommunikation nach dem CPI-C Standard CPI-C: Common Programming Interface for Communications Computer “II” Computer “I” Prozess A B Nachricht ... CPI-C Stub Process Status Message = (Tag, Length, Value) B führt Auftrag von A aus B A A wartet auf B A sendet Nachricht an B B sendet Nachricht an A Zeit Handout Teil Seite

101 Conversational 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 Conversation CMACCP Accept Conversation CMALLC Allocate CMSEND Send Data CMRCV Receive Data CMDEAL Deallocate Beispiel CMSEND (conversation_id, /* Input */ buffer /* Input */ send_length /* Input */ &Request_to_send_received, /* Output */ &return_code); /* Output */

102 Remote Procedure Call Synchrone n:1 Kommunikation nach dem RPC Standard Client Stub Server Skeleton Computer “X” Call Argumente Computer “Z” Client A Prozess Server Prozess Computer “Y” Client B Prozess Reply Resultat Process Status Server führt Auftrag von A aus Server führt Auftrag von B aus Server Call Reply Client B Call Reply Client A Zeit Client A ruft Server auf A wartet auf Antwort Client B ruft Server auf B wartet auf Antwort Handout Teil Seite

103 Object Request Broker(ORB; Software Bus)
CORBA CORBA: Common Object Request Broker Architecture Aufgabe Nutzer (Client) Anbieter (Server) Client und Server sollen verteilt sein Interface Lösung Nutzer (Client) Generiert aus Interface beschrieben in IDL Anbieter (Server) Interface Definition Language Client Stub Server Skeleton Object Request Broker(ORB; Software Bus) Client und Server können in beliebigen auch unterschiedlichen Sprachen geschrieben sein CORBA/IDL sorgt für Mapping der Interfaces

104 RMI, IIOP, SOAP Remote Method Invocation (RMI) RPC Variante für Java
IIOP Internet Inter ORB Protocol Heute auch benutzt als Basis für RMI im Web SOAP Simple Object Access Protocol XML basiertes Protokoll RPC Messages zwischen unterschiedlichen Plattformen Java basiert Microsoft.NET Themen werden später noch behandelt

105 „Messaging and Queuing“ Modell
Asynchrone n:m Nachrichtenkommunikation über Warteschlangen Computer “A” Queue Computer Computer “X” ... Nachrichten Stub ... persistente Warteschlange Nachricht Server X Prozess Client A Prozess Queue 1 Queue 2 Computer “B” Computer “Y” Client B Prozess Server Y Prozess Queue 3 Message = (Tag, Length, Value) Server Y X(A)Y X(B)Y Y(A)X Y(B)X Server X BX X(B)B Client B AX X(A)A Client A Zeit Handout Teil Seite

106 HTTP – Internet Protokoll
HTTP: HyperText Transfer Protocol Generisches (für beliebige Daten), zustandsfreies Protokoll Computer “X” Computer “Z” Web Client A HTTP request Web Server In-Pipe HTTP response HTML Pages Out-Pipe Computer “Y” Web Client B Web ... HTTP stub .. HTTP pipe Pipe Handout Teil Seite

107 HTTP – 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

108 Schichten und Stufen von Web Anwendungen

109 Schichten einer Anwendung
1970 1985 Anwendungs- Logik Datenhaltung User Interface TP Monitor User Interface Ablaufsteuerung Anwendungs- Logik DB Interface Datenbank

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

111 Schichten und Stufen von Architekturen
Anwendungs- Schichten Mainframe Client / Server User Interface Datenbank Anwendungs- Logik DB Interface Ablaufsteuerung T e r m i n a l Client ( PC ) Server Client ( PC ) Server Client ( PC ) Server Mainframe „Fette“ Clients

112 Schichten und Stufen von Architekturen
Anwendungs- Schichten W e b User Interface Datenbank Anwendungs- Logik DB Interface Ablaufsteuerung Browser Browser W e b Server Web Server . Xxx Server

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

114 2-Stufen Architektur Plugins Web Browser Web Server Daten HTML Applet
Clienseitig: User Interface Ablaufsteuerung über Applets HTML Applet Andere Datenformate Web Browser Plugins HTTP Web Server Daten JSP Servlets Serverseitig: User Interface Ablaufsteuerung

115 Beispiel: 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) 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

116 Publizieren von Informationen
Web Browser HTML HTML HTTP Autoren Arbeitsplatz Windows / Web Browser LAN Daten JSP JSP File HTTP Web Server

117 Publizierung 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)

118 Publizieren von Informationen mit Update
Web Browser HTML Applet HTML HTTP Daten JSP JSP File Web Server

119 3-Stufen Architektur mit DB-Server
HTML Applet Andere Datenformate Web Browser Plugins HTTP Web Server Daten JSP Servlets Java (Anw.-Funkt.) LAN D B M S DB-Server

120 Beispiel: Wissensmanagement
Kein klar umrissene Anwendung Vielfältige Ansätze Wissensmanagement hier: Wissensakquisition Wissensadministration Wissenspublikation Verteilen Abholen Wissensmanagement ist Management von Beziehungen Wissensrepository Beispiel: Skillmanagement

121 Was ist Wissen Wissen Information Daten Verknüpfung Kontext
Interpretation Information Wissen

122 Wissensakquisition Erfassen Analysieren Aufbereiten Wissensrepository

123 Publikation von Wissen
Intranet / Extranet Suche Navigation Gezielt Informieren Wissensrepository

124 Wissensmanagement Web Browser Web Server Daten Wissensrepository HTML
Applet HTTP Web Server Daten JSP Servlets Java (Anw.-Funkt.) Wissensrepository

125 3-Stufen Architektur mit Mainframe
HTML Applet Andere Datenformate Web Browser Plugins HTTP JSP Web Server Daten Servlets Java (Anw.-Funkt.) LAN, proprietäre Protokolle Mainframe Alt-Anwendung

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

127 4-Stufen Architekt. mit Application und DB-Server
HTML Applet Andere Datenformate Web Browser Plugins JSP Web Server Daten Servlets Java (Anw.-Funkt.) Application-Server Enterprise JavaBeans DB-Server

128 Beispiel ECOM (ohne Anbindung Fremdsyst.)
DMZ (Access LAN) Ultra Thin Client http-Dispatcher 1 http-Dispatcher 2 hot-stand-by Dispatcher-Cluster http http Webserver 1 NetscapeEnterpriseServer mit BEA WLS Plugin Webserver 2 NetscapeEnterpriseServer mit BEA WLS Plugin File- server Internet / Extranet http http eCOM Infrastruktur 1 BEA WebLogicServer PrimaryServer für Webserver 1* eCOM Infrastruktur 2 SecondaryServer für Webserver 1* SecondaryServer für Webserver 2* eCOM Infrastruktur 3 PrimaryServer für Webserver 2* Logisches WLS-Cluster *wird dynamisch pro User zugeordnet File- server dbserv X Intranet (Corporate Network)

129 5-Stufen Architektur mit Alt-Anwendungen
Web Client DB Web Server ERPS Mainframe Application-Server Alt-Anwendung DB-Server

130 Beispiel ECOM 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, …) Customer Interface Support Modules Support Modules Vehicle Con- figurator Support Modules Appointment Service Appointment Test Drive Price Indicator Used Car Management Used Car Request for Information Session User Ascertain Request for Offer Integration SF Support Modules t.b.defined Vehicle Selector Dealer Locator HST TopDrive (Clarify) PCASO eCOM Data Subsidiary Portal (Clarify) Dealer Portal (Clarify) Car Data Dealer Data Customer Data Handout Teil Seite

131 Client mit LAN Zugriff auf Server
Web Client Firewall DB HTTP LAN Web Server ERPS Mainframe Application-Server Alt-Anwendung DB-Server

132 Web & Application Server
Web Client DB Web & Application Server Produkte vom Markt (BEA, IBM, …) kombinieren in der Regel beides ERPS Mainframe Alt-Anwendung DB-Server

133 Physische Stufen-Architektur
Client Web-Client mit Web-Browser HTTP Server Web-Server Application Server DB-Server . . . LAN Server LAN oder proprietäre Protokolle Mainframe Alt-Anwendungen (Legacy Systems)

134 Abbildung logische/physische Stufenarchitektur
Logische und physische Stufenarchitektur nicht unbedingt identisch Gegebene Zuordnung Web Client Client Client Traditionell: PC Web PC, Network Computer PDA Mobiles Telefon Spezialgeräte Altanwendung  häufig Mainframe Abbildung im Serverbereich vielfältig

135 Abbildung logische/physische Stufenarchitektur
Client Server Web-Server Server Application-Server Server DB-Server

136 Abbildung logische/physische Stufenarchitektur
Client Web-Server Server Application-Server DB-Server

137 Abbildung logische/physische Stufenarchitektur
Client Server Web-Server Server Application-Server Server DB-Server Siehe auch: ECOM Beispiel (Folien 55 & 56)

138 Abbildung logische/physische Stufenarchitektur
Client Server Web & Application Server Server DB-Server

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

140 Entwicklungsstadien (Nutzungsarten) des Web
Plattform für E-Business Unternehmens-kritische Anwendungen Alle Anwendungskonzepte Informationsmedium mit Updatemöglichkeit Dynamische Webseiten Client-seitige Komponenten Datenbankzugriff Informationsmedium Statische Webseiten

141 Referenzarchitektur Portal Server Benutzer-Schnittstellen Komponenten
LAN HTTP Firewall Portal Server Benutzer-Schnittstellen Komponenten Business Datenbank-Zugriffe Integrations Services Verzeichnis Schnittstellen Verzeichnis Services Geschäfts Partner Sicherheit Messaging Services Content Management Prozess-Management Transaktions-Management ERP Systeme Alt-Anwend. Datenbanken Datenbanken