Architekturen von Web-Anwendungen Vorlesung an der LMU München Winter-Semester 2001/02 Dr. Günter Merbeth
Zur Vorlesung Konzepte und Anwendungsbeispiele Keine Programmbeispiele Zwei Hauptplattformen Java & J2EE Microsoft.NET In Vorlesung Bei Einführung von Konzepten: J2EE Microsoft zur Ergänzung / Vergleich
Voraussetzungen Programmieren (Java) Grundkenntnisse Internet Grundkenntnisse Software Entwicklung Grundkenntnisse Datenbanken
(Vorläufiger) Plan Einführung, Begriffe Klassische Architekturen Beispiel ECOM: Verkaufsanbahnung bei BMW E-Business, Architekturen & Architekten im Entwicklungsprozess Herausforderungen und Beispiele Schichten und Stufen von Web Anwendungen Referenzarchitektur für Web basierte unternehmenskr. Anwendungen Beispiel: Unternehmensportal bei Softlab Rolle von Java und XML HTML und Applets JSP und Servlets Application Server, J2EE, Beispiel Portal Server, Prozess Management Content Management Anwendungsintegration (EAI, JCA, Web Services) Microsoft.NET Vergleich J2EE und .NET
Begriffe: Anwendungen Architekturen von Web-Anwendungen Software-Systeme Unterstützen Menschen bei Tätigkeiten z.B. - Bearbeiten eines Schadens bei Versicherung Automatisiert Abläufe z.B. - Ausführung einer Überweisung - Steuert die Bremsen in einem Auto (ABS) - Führt ein Waschprogramm durch
Klassifizierung von Anwendungssystemen Informationssysteme Dienstleistung Beispiel: Finanzdienstleistungen sind i.W. Informationsverarbeitung Verwaltung Unternehmenssteuerung ... Eingebettete Systeme Kommunikationsgeräte Haushaltgeräte Fahrzeuge Auto: Computer mit 4 Rädern Eingebettete Systeme und Informationssysteme wachsen zusammen Fahrerinformation und Fahrzeugsteuerung Anschluss Alarmanlage ans Internet
Systembasis für Anwendungssysteme Software-Systeme benötigen zum operativen Betrieb Hardware-Basis System-Software-Basis Basis und Entwicklungswerkzeuge unterschiedlich bei Informationssystemen Eingebetteten Systemen Schwerpunkt in Vorlesung: Informationssysteme Informationssysteme längere Historie als eingebettete Systeme
Entwicklungs-Epochen bei Informationssystemen
Epochen bei IS: Mainframe Terminal-Anbindung SNA (IBM), TRANSDATA (Siemens) Mainframe „Dumme“ Terminals Bildschirm-Masken Anwendungslogik Daten
Mainframe Epoche Hardware, Betriebssysteme Entwicklung Datenmanagement Mainframes: IBM, Siemens, ICL, Fujitsu, ... Minicomputer: DEC, … Datenmanagement Dateisysteme Hierarchische DBMS Netzwerk-DBMS RDBMS Middleware TP Monitore Kommunikation Proprietär: SNA, ... Entwicklung Editoren Sprachen (Compiler) COBOL, PL/1, Assembler, (FORTRAN) Generatoren für Masken und Code Dictionaries Projektbibliotheken
Epochen bei IS: Client/Server SNA Mainframe DB Server TCP/IP Application Server Mainframe Dezentralisierung GUI (Anwendungslogik) Altsysteme Anwendungslogik Daten Daten
Client/Server Epoche Hardware,Betriebssysteme Datenmanagement PC mit DOS, Windows, (OS/2) Unix Server: Unix, NT, Novell (OS/2) Mainframes: IBM mit MVS Bedeutung anderer Hersteller nimmt ab Datenmanagement Filesysteme Relationale DBMS Middleware RPC DCE TP Monitore (CORBA) Kommunikation TCP/IP Entwicklung CASE (Computer Added Software Engineering) Repositories Projekt- und Konfigurations-management Sprachen (Compiler, Debugger) COBOL C, C++, (Smalltalk) VB 4GL
Epochen bei IS: Netzwerk (Internet / Web) SNA DB Server Mainframe TCP/IP Application Server Mainframe HTTP DB Server Internet/ Intranet/ Extranet TCP/IP Web Server Mainframe Application Server
Netzwerk Epoche Hardware,Betriebssysteme „The network is the computer“ PC: Windows NC (Thin Client) Server: Unix, NT Datenmanagement Filesysteme Relationale DBMS ODBMS (Wissens/Content) Repositories Middleware Distributed TP Monitore CORBA J2EE, (EJB, Servlets, RMI) COM/DCOM SOAP (Web Services) Entwicklung Repositories mit Projekt- und Konfigurationsmanagement Sprachen IDE: Integrated Development Environments z.B. Visual Studio, Visual Age C++ Java C# VB
Eigenschaft der drei Generationen Sehr gute Tools Komplexe Architektur (Viele logische Komponenten) Netzwerk Thin Clients Re-Zentralisierung Management auf weniger Instanzen beschränkt Browser basiert Gute Kombination der Stärken von C/S und Mainframe - GUI - blockorient. Verbind. Web Architektur schon komplexer EU gleich PU Fette Clients, Sicherh. Verteilung der Anw. auf Client und Server Probleme mit großer Anzahl Clients bei Install. und Update Komfortable graphische Oberfläche Benutung komplexer Direkte Verbindung zwischen Client und Server RPC) Client / Server Schwache Toolunterstützung Einfache Architektur (DB und TP Monitor) EU ungleich PU Zentral Einfache Kontrolle und Verwaltung Einfache Installation und Update Einfach, dumme Terminals Primitive Oberfläche Verbindung zwischen Terminal und Rechner blockorientiert Mainframe Entwicklung Management Benutzung
Begriffe: Web-Anwendungen Architekturen von Web-Anwendungen Basierend auf Internet-Techniken Nutzung der Techniken des World Wide Web - HTTP (Protokoll) - HTML (Datenformat) - URL (Adressierung) - ... (Behandlung im Laufe der Vorlesung) Anwendungsbereiche - Internetauftritte - Intranetanwendungen - E-Business Anwendungen - M-Business Anwendungen Abgrenzung: Nicht Embedded Systems
E-Business Web basierte Anwendungen Drei wichtige Klassen Business to Consumer (B2C), Internet Einkauf über das Web (z.B. Amazon, Computer Shops) Homebanking (z.B. T-Online) Elektronischer Kundendienst Business to Business (B2B), Extranet Anbindung von Lieferanten Integration externer Vertriebskanäle (Händler, VAR, OEM) Integration von Dienstleistern (Discount Broker mit Transaktionsbank) Business to Employee (B2E), Intranet Informationsplattform für Mitarbeiter (z.B. Telefonliste) Unterstützung für interne Prozesse (z.B. Reiskostenabrechnung) Qualitätsmanagement Skill Management Wissensmanagement (z.B. Methoden, Erfahrungen)
E-Business Beteiligte Endkunden Lieferanten Geschäftsprozesse von Unternehmen Unter- nehmen als Kunden Auftrag- nehmer Mitarbeiter
Unternehmen E-Business Themen Lieferanten Kunden B2B B2B & B2E Supply Chain Management Customer Relationship Management Lieferanten Kunden Unternehmen Kern Geschäfts Prozesse B2B B2B & B2E B2B & B2C E – B u s i n e s s
Inter-/Intranet-Anwendungen Customer Relationship Management (CRM) Abwicklung Kundenbeziehung über Internet (B2C, B2B) Marketing Verkaufsunterstützung E-Commerce Helpdesks Supply Chain Management Abwicklung der Beziehungen mit Lieferanten (B2B) Zulieferketten Einkaufssysteme (E-Procurement)
Begriffe: Architekturen Architekturen von Web-Anwendungen IT-Architekturen sind Baupläne (wie im Bauwesen) - Konzepte - Modelle - Richtlinien und Standards Definieren Umsetzung der Anforderungen in Komponenten, Teilsysteme, Beziehungen Reduzieren Komplexität Ermöglichen Wiederverwendung
Architekturaspekte: ein Ebenenansatz Sicherheit Business Architektur Reale Welt Systemmanagement Organisationseinheit Geschäftsprozeß Datenfluß Rechtegruppe Ressource Anwendungsarchitektur Was Benutzergruppe Anwendung Anwendungsfunktion System Systemarchitektur Wie Schicht Komponente Objekt Zugriffsrecht Es gibt folgende Ebenen der Architekturen Business Architektur - die Geschäftsprozesse der Wertschöpfungskette und deren Beziehungen untereinander Anwendungsarchitektur - die Anwendungen sowie die Anwendungen unterstützende Systeme - wie z.B. Systeme für Workflowmanagement, Dokumentenmanagement, Systeme zur Integration von Systemen- mit allen Beziehungen untereinander SW-Systemarchitektur - die Komponenten und Komponentensysteme, Pattern, Teilsysteme, Frameworks und deren Beziehungen untereinander - einschließlich solcher Teilsysteme und Komponenten wie Datenbankbetriebssysteme, Middleware Plattformarchitektur - die Computer, Netzwerke und deren Beziehungen untereinander Übergreifend über die Ebenen: Aspekte der Sicherheit und des Datenschutzes Aspekte des Management von Anwendungen, Systemen und Ressourcen. Plattformarchitektur Anwendung Womit Computer Netzwerk Entwicklungsarchitektur
Architektur Jedes System hat eine Architektur Implizit Entsteht während der Entwicklung Akzeptabel bei ganz kleinen Anwendungen Vergleich traditionelle Architektur Für Hundehütte braucht man keinen Architekturentwurf Explizit Separater bewusster Schritt im Entwicklungsprozess Größere Systeme benötigen explizite Architektur Vergleich: Für jedes größere Gebäude wird eine Architektur entworfen Explizite Architekturen bewirken viele Vorteile
Architektur ist Gliederung eines Systems in Hauptkomponenten Architektur für ein einzelnes System Reduktion der Komplexität Verteilung von Aufgaben Zuordnung zu Systemkomponenten Einsatz von Standards Einsatz von Produkten Architektur für eine ganze Reihe von Systemen Zusätzlich Wiederverwendung von Architekturkomponenten Produktlinienansatz Unternehmens-Architekturmodell
Anforderungen an Untern.-Architekturmodell Einheitliche Benutzer-Schnittstellen für alle Anwendungen Anmeldung beim Netzwerk, nicht bei den Anwendungen Einheitlicher Zugriff auf Daten und Anwendungen durch Benutzer im eigenen Unternehmen bei Partnern im Internet Wiederverwendung Nicht nur von Code Auch Modelle und Architekturkonzepte Interoperabilität Infrastrukturprodukte kommen von unterschiedlichen Herstellern Produkte müssen Standard-Schnittstellen, -Formate und -Protokolle unterstützen Architekturmodell muß das ausdrücken
Anforderungen an Untern.-Architekturmodell Portabilität zwischen Plattformen Produkte und Anwendungen sollten nicht plattformabhängig sein Plattformwechsel während der Lebenszeit einer Anwendung notwendig MVS (Mainframe) Unix verschiedener Hersteller NT Linux Effizientere Anwendungsentwicklung, Werkzeuge für Entwurf Entwicklung Test Wartung Konfigurationsmanagement Generierung Projektmanagement
Anforderungen an Untern.-Architekturmodell System Management Einheitliches Werkzeug zum Verwalten der PCs NCs Netzwerkelemente Server Mainframe Middleware DBMS Anwendungen Investitionsschutz Altsysteme und Existierende Infrastruktur müssen in das Lösungskonzept für ein Unternehmen einbezogen werden.
Don Tapscott in: The Digital Economy Zitat „In the past, an architecture was really the design of a system that had been created to meet specific application needs. In the new business environment, organizations have little idea what their application needs will be in two, let alone five or ten years. Consequently, we need architectures that can enable the exploitation of unforeseen opportunities and meet unpredictable needs. Don Tapscott in: The Digital Economy
Projekt ECOM ECOM: E-Commerce Projekt bei BMW Softlab ist Auftragnehmer ca. 20 Mitarbeiter von Softlab E-Business für Vertrieb und Marketing (CRM) Konkretes Thema: Verkaufsanbahnung Direkter Verkauf wegen Händlerverträgen gegenwärtig nicht möglich Ziele des Vorhabens Bessere Kundenbetreuung Stärkere Kanalisierung des Vertriebsprozesses und Aufbau einer zentralen Kundendatenbank Noch stärkere Verzahnung zwischen Vertrieb und Produktion weltweit Built to Order Anpassung der Beziehungen zu Händlern unter Gesichtspunkten der Wertschöpfungskette
ECOM: Projektziele Gleiches Look & Feel weltweit Unterstützung Unterschiedliche Marken (BMW PKW, BMW Motorräder, Mini) Alle Länder Mehrere Sprachen Neue Informationen weltweit zur gleichen Zeit Länderspezifische Lösungen werden abgelöst Optimieren sowohl des zentralen wie auch des dezentralen Zuganges Ergebnis soll Plattform sein für Verbesserungen und Erweiterungen
NSC Administration
NSC Händler Monitoring
Händler Aktivitätenliste
ECOM: Anwendungsarchitektur Interface Customer NSC Dealer Dealer Locations Configurator Vehicle Request for Offer Appointment Test Drive Price Indicator Used Car Request for Information Operation NSC Operation Dealer Reservation List Admin NSC Mail Server Dealer Locator E-COM BACKBONE CRM Data Base ECOM Data Base Dealer Data Base Car & Price Data Base Graphical Content Content Management System
Customer Interface (A) ECOM: Phase 1 6 Module Landesgesellschaften und Händlerportal - nicht voll integriert - Datenaustausch Customer Interface (A) Request for Offer Appointment Test Drive Price Indicator Used Car Request for Information Session User Ascertain Vehicle Selector Dealer Locator Customer Data Dealer Data Car Data eCOM Data Subsidiary Portal Dealer Portal
Customer Interface (B) ECOM: Phase 1.5 7 Module & Car Configurator Portale der Landesgesellschaften und Händler integriert Integration von Finanzdienstleistungen Integration von 4 existierenden Modulen Customer Interface (B) SF Integration SF Integr. Vehicle Con- figurator Appointment Service Appointment Test Drive Request for Information Price Indicator Used Car Session User Ascertain Request for Offer Interpreter Rule- Map- System Coloring System Report- Generator Vehicle Selector Dealer Locator PCASO eCOM Data Subsidiary Portal Dealer Portal Car Data Dealer Data Customer Data
ECOM: Phase 2 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 Management Used Car Appointment Service Request for Offer Appointment Test Drive Request for Information Price Indicator Used Car Session User Ascertain 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
ECOM: Phase 3 Vorbereitung für Strategie des direkten Vertragsabschlusses Integration mit Produktionsplanung und Produktions-/Lieferprozess Customer Interface - Delivery Date Request for Vehicle Locator Order change Ordering / Tracking / Status info figurator Support Support Modules Modules Vehicle Con Price Indicator Session User Support Support Support Support Support Modules Modules Modules Modules Modules t.b.defined Integration Management Appointment Request for Appointment Request for Information Used Car Ascertain Vehicle Selector Service Test Drive Dealer Locator Used Car Offer SF HST TopDrive (Clarify) PCASO IVS… eCOM Data Subsidiary Portal (Clarify) Dealer Portal (Clarify) Car Data Dealer Data Customer Data
Functional Building Block Matrix User Views/ Processes Testdrive appoint- ment Reser-vation List Request for Offer Request for Information Used Car Evaluator Dealer Locator Car Configu-rator Vehicle Selector Used Car Evaluator Dealer Locator Functional Building Blocks User Data Collector Information distributor Offer Requestor Reservation List Handler
Varianten: Marken und Länderspez. Ausprägungen Customer´s View market specific 20% Bikes WEB-Customer-Interface brand specific generic part market-specific extensions 80% Functional Building Block E-COM BACKBONE
Example: 2 brands, 3 NSCs (of which one NSC is bilingual) Variantenstruktur Example: 2 brands, 3 NSCs (of which one NSC is bilingual) Java/HTML pages Language specific Italian French French German Italian French French German NSC specific Brand Adaptation sequence: 1. Brand adaptation 2. Market adaptation (could be parallel for several NSCs)
Varianten- und Releasestruktur Länder- varianten 1.0 2.0 3.0 1.0 2.0 3.0 1.0 2.0 3.0 Releases Bikes Marken
ECOM Systemarchitektur Web Client Beliebiger Browser
ECOM Komponenten Java Server Pages JSP Beans Entity Beans Ecom User Interface JSP Beans EJB Client Business Logik Entity Beans Abbildung der DB-Tabellen (create, update, find) Container Managed Persistence (CMP) Transaction mode REQUIRED Session Beans Utilities (currency, date), Queries, Import/Export
Software Layers Java Server Pages Servlet Engine JSP Beans (Processes) Dealer Locator Request for Offer Vehicle Selector New Module Use DL Use VSE Use … Java Server Pages Servlet Engine JSP Beans (Processes) Content Management System Vehicle Customer Dealer Session Management EJB Server Background Functions (Mail send,..) Entity Beans External Interfaces Oracle Data Base
Logische IT-Architektur # ECOM WebLogic EJB Server EJB Container Mail Server smtp JavaMail Adapter JavaMail Customer Ultra Thin Client HTML+JavaScript Internet Internet Services Testdrive appointment Request for offer Request for information Used vehicle price indicator Dealer locator Vehicle selector smtp User Management ... Support Error Mgmt Logging ... Webserver + Servlet Engine http ECOM JSP‘s Internal Services Task fulfillment Data maintenance Event Tracking Statistics Dealer + NSC Ultra Thin Client HTML+JavaScript Internet http/https Support Error Mgmt Logging ... RMI/IIOP CMP, Oracle 8.05 Filesystem Session JNDI
IT-Infrastruktur (logisch) 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)
IT-Infrastruktur (physikalisch) Intranet (Corporate Network) dbserv X File- server eCOM BEA Weblogic- Server-Cluster eCOM Webserver + Dispatcher weltweit eCOM Webserver + Dispatcher V1 * eCOM Webserver + Dispatcher V3* File- server File- server http Firewall Firewall http DMZ Internet (Access LAN) DMZ Extranet (Access LAN) Internet Extranet http http eCOM UltraThinClient Kunde eCOM UltraThinClient Händler
Integrationsansatz - Beispiel: Assist-Car-Online Content Provider Generic Content Telematic Content BMW Marketing BMW Generic Content Communication to and from Car Profile update into CRM Database Content Aktualisation Billing Preparation Generic Personalized Content Customer Special BMW Personalized Content Dealer Locations Contract Selling Personalised Configuration Dealer Locator Planning Route Dealer Portal E-COM Backbone BACKBONE CRM- DATABASE
Entwicklungsumgebung Entwicklung auf NT Integration und Test auf Solaris Zentrale Entwicklungsdatenbank auf Solaris RunTime Application Server WebLogic Server JSP/Servlet Engine WebLogic Server WebServer WebLogic Server Netscape Enterprise (Integration); wird abgelöst durch WebLogic Server Entwicklung Java Jbuilder 3 (Borland) JSP/HTML Homesite 4.5 (Allaire)
Weitere Entwicklungstools Datenbank Design PowerDesigner (Sybase) Aufbau SQL Navigator (Quest) Test Modul-Tests Junit 2.1 (Public Domain) Performance-Tests LoadRunner (Mercury) GUI-Tests WinRunner (Mercury) Sonstiges Dokumentation Office, Visio OO-Modelling Together/J (oisoft) Versionsmanagement Visual SourceSafe
Zahlen und Fakten (Version 1.5) Basissystem Datenbank, EJB-Server, JSP Beans Wird für alle Länder, Marken oder Sprachen verwendet 43 DB-Tabellen 64 EJB’s 37 Entity Beans 17 Stateless Session Beans 11 Stateful Session Beans 79 JSP Beans (u.a. Business Logik) 68 Utility Klassen
Zahlen und Fakten BMW Portale Customer Portale Group Portal, NSC Portale nur in Englisch Dealer Portal pro Sprache 379 JSP’s pro Sprache 476 Bilder Customer Portale Unterscheiden sich pro Land und Marke (BMW, Motorcycle, Mini) Teilweise auch pro Sprache (z.B. CH) 339 JSP’s pro Land, Marke und Sprache 2079 Bilder (u.a. Fahrzeug, Händler)
Fazit Server-Entwicklung mit EJB sehr produktiv WebLogic Server ausgereiftes und stabiles Produkt Skalierbare Multi-Tier-Architektur (fast) gratis Web-UI-Entwicklung mit JSP noch verbesserungsfähig Aufwand höher im Vergleich zu „klassischem“ C/S (z.B. VB) Betriebskosten deutlich geringer (keine Client-Installation) Vermischung Darstellung und Code Zu wenige UI-Controls für komplexe GUI’s Compile once - run anyware Hardware-unabhängig (Unix, NT, Host) Hersteller-unabhängige Technologie (BEA, IBM, Borland, …)