Systemeigenschaften und Architektur Wiederverwendung Rolle von Architekten

1. Systemeigenschaften und ArchitekturWiederverwendungRolle von Architekten

2. Anforderungen an Anwendungen Anwendungssystem Funktionale Anforderungen System Eigenschaften

3. Systemeigenschaften • 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

4. Systemeigenschaften • 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

5. Anforderungs-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)

6. 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 erfolgreichAusnahmen: • 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

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

8. Wiederverwendung auf Code-Niveau Analyse Spezifikation Entwurf Codierung Integration Qualitäts- Sicherung Klassifizieren Speichern • 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 Suchen Einbauen Modul Bibliothek

9. Frameworks Framework Spezialisierung Anwendung

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

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

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

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

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

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

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

17. Architektur im Software Lebenszyklus Anwender Marketing IT A n a - l y s e 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

18. Herausforderungen an ArchitekturenBeispiele aus der Praxis

19. Sicherheit Systemmanagement Business Architektur Organisationseinheit Datenfluß Geschäftsprozeß Ressource Rechtegruppe Anwendungsarchitektur Anwendungsfunktion Benutzergruppe Anwendung System Systemarchitektur Schicht Objekt Komponente Zugriffsrecht Plattformarchitektur Anwendung Computer Netzwerk • Existierende IT • „Ererbte“ Architekturen & Technologien • „ererbte Systeme“ versus neue Geschäftsprozesse • proprietäre SW-Produkte • „Ererbte“ IT Organisation Herausforderungen an Architektur • Innovationen • Neue Technologien, z.B. Internet, Objektorientie-rung, Client-Server, Kompo-nententechnologie • Neue SW und HW Produkte, z.B. Middleware, Browser, DBMS • 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

20. Sicherheit Systemmanagement Business Architektur Organisationseinheit Datenfluß Geschäftsprozeß Ressource Rechtegruppe Anwendungsarchitektur Anwendungsfunktion Benutzergruppe Anwendung System Systemarchitektur Schicht Objekt Komponente Zugriffsrecht Plattformarchitektur Anwendung Computer Netzwerk • Budget und Termin • Budget- und Ressour-cenverbrauch zu hoch • Terminüberschreitung Risiken für strategische Architekturprojekte • Technologie • geforderte Performance wird nicht erreicht • geforderte Mengengerüste werden nicht beherrscht - Datenmengen, Transaktions-lasten • Betriebskosten zu hoch • 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

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

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

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

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

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

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

27. 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 Beispiel 2 : Lösungsszenarien

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

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

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

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

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

33. Beispiel 2 : Die neue Infrastruktur

34. 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 1

35. 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 Herausforderungen: Zusammenfassung 2

36. Kommunikation zwischen Anwendungskomponenten

37. 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 Kommunikations-Dienste

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

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

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

41. 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 Generiert aus Interface beschrieben in IDL Nutzer (Client) Anbieter (Server) Interface Definition Language Client Stub Server Skeleton • Client und Server können • in beliebigen • auch unterschiedlichen • Sprachen geschrieben sein CORBA/IDL sorgt für Mapping der Interfaces

42. RMI, 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

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

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

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

46. Schichten und Stufen von Web Anwendungen

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

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

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

50. User Interface Ablaufsteuerung Anwendungs- Logik . . DB Interface . Datenbank Schichten und Stufen von Architekturen S t u f e n Anwendungs- Schichten W e b Browser Browser W e b Server Web Server Xxx Server