Systemeigenschaften und Architektur Wiederverwendung Rolle von Architekten

Anforderungen an Anwendungen Anwendungssystem Funktionale Anforderungen System Eigenschaften

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

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

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)

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

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

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

Frameworks Framework Spezialisierung Anwendung

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

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

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

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

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

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

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

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

Herausforderungen an Architekturen Beispiele aus der Praxis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beispiel 2 : Die neue Infrastruktur Handout Teil 1 Seite

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

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

Kommunikation zwischen Anwendungskomponenten Handout Teil 1 Seite

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

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

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

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

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

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

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

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

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

Schichten und Stufen von Web Anwendungen

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

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

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

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

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

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

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

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)

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

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

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

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

Wissensakquisition Erfassen Analysieren Aufbereiten Wissensrepository

Publikation von Wissen Intranet / Extranet Suche Navigation Gezielt Informieren Wissensrepository

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

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

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

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

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)

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

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

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

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

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)

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

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

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

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

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

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

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

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