Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering Software Architektur I Einführung Innere/Äussere Architektur.

Ähnliche Präsentationen


Präsentation zum Thema: "Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering Software Architektur I Einführung Innere/Äussere Architektur."—  Präsentation transkript:

1 Mitglied der Fachhochschule Ostschweiz FHO 1 © FHS St.Gallen Software Engineering Software Architektur I Einführung Innere/Äussere Architektur Single-/Multi-Tier Middleware MOM

2 Mitglied der Fachhochschule Ostschweiz FHO 2 © FHS St.Gallen Software Engineering Lernziele Sie können... –den Sinn und Zweck der Architektur erläutern –zwischen innerer und äusserer Architektur unterscheiden –Single-/Multitier-Architekturen situationsabhängig vorschlagen –verschiedene Arten von Middleware benennen –die Prinzipien von Message Oriented Middleware (MOM) erläutern

3 Mitglied der Fachhochschule Ostschweiz FHO 3 © FHS St.Gallen Software Engineering Zweck der Architektur

4 Mitglied der Fachhochschule Ostschweiz FHO 4 © FHS St.Gallen Software Engineering Architektur …the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE Standard Recommended Practice for Architectural Description for Software-Intensive Systems)

5 Mitglied der Fachhochschule Ostschweiz FHO 5 © FHS St.Gallen Software Engineering Komponenten Komponenten sind Strukturelemente einer Softwarearchitektur. –Verschiedene Granularitätsstufen –Hauptzielsetzungen von Komponenten: Abhängigkeiten zu beherrschen –Eigenschaften von Komponenten (im engeren Sinne): Kapselung von Daten und Methoden (Information Hiding) Zugriff nur über definierte Schnittstellen Können einfach oder mehrfach instanziiert werden

6 Mitglied der Fachhochschule Ostschweiz FHO 6 © FHS St.Gallen Software Engineering IT-Architektur - Zusammenhänge Markt IT-Markt

7 Mitglied der Fachhochschule Ostschweiz FHO 7 © FHS St.Gallen Software Engineering Architektur im Entwicklungsprozess Äussere Architektur wird als Architekturprojekt festgelegt. Innere Architektur ist Teil des Design-Prozesses.

8 Mitglied der Fachhochschule Ostschweiz FHO 8 © FHS St.Gallen Software Engineering Innere Architektur I Teil des Entwicklungsprojektes Konkrete Subsystembildung System Subsysteme Applikationscluster Applikation (System) Modul (Subsystem) Komponente Implementierte Klassen

9 Mitglied der Fachhochschule Ostschweiz FHO 9 © FHS St.Gallen Software Engineering Innere Architektur II

10 Mitglied der Fachhochschule Ostschweiz FHO 10 © FHS St.Gallen Software Engineering Abstraktionsstufen im Architekturentwurf

11 Mitglied der Fachhochschule Ostschweiz FHO 11 © FHS St.Gallen Software Engineering Musterarchitektur Quasar I Quasar – Qualitäts-Software-Architektur Technologieunabhängige Musterarchitektur für komplexe verteilte betriebliche Informationssysteme: –Entwurfskonzepte und –richtlinien –Einheitliche Begriffswelt –Standardisierte Schnittstellen zu Diensten –Wieder verwendbare Dienstkomponenten Beispiel 1:

12 Mitglied der Fachhochschule Ostschweiz FHO 12 © FHS St.Gallen Software Engineering Musterarchitektur Quasar II Beispiel 2:

13 Mitglied der Fachhochschule Ostschweiz FHO 13 © FHS St.Gallen Software Engineering POSA Pattern Oriented Software Architecture 3 Ebenen von Muster: –Architekturmuster Muster für verteilte Anwendungen Bsp.: MVC –Entwurfsmuster Weniger als GoF (Gang of Four) Konzentration auf verteilte Anwendungen –Idiome Programmierspezifische Konzepte

14 Mitglied der Fachhochschule Ostschweiz FHO 14 © FHS St.Gallen Software Engineering Architekturmodelle Single-Tier Client-Server-Architekturmodell –Basismodell: Client Consumer Server Provider Peer-to-Peer-Architekturmodell –Ausgebautes Service-Modell: Service-Provider Service Consumer –Modell des Internet!

15 Mitglied der Fachhochschule Ostschweiz FHO 15 © FHS St.Gallen Software Engineering Schichtenarchitekturen 3 Hauptaufgaben: –Präsentation – Interaktivität – Input/Output der Daten –Anwendungslogik – Verarbeitung der Daten –Datenhaltung – Speicherung der Daten Verteilung der Aufgaben auf einzelne Schichten (Tiers) 2-Tier-Architektur Thin Client Fat (Rich) Client Stored Precedures Anwendungslogik Präsentation

16 Mitglied der Fachhochschule Ostschweiz FHO 16 © FHS St.Gallen Software Engineering 3-Tier-Architecture Client-Tier: –Präsentation –Front-End Middle-Tier –Anwendungslogig –Business-Logic Server-Tier –Datenhaltung –Back-End –Persistenz Datenbanksysteme –Manchmal sind dies auch EIS (Enterprise Information System) wie z.B. Legacy Systems («Erbstücke»)

17 Mitglied der Fachhochschule Ostschweiz FHO 17 © FHS St.Gallen Software Engineering n-Tier-Architecture DMZ = Demilitarisierte Zone

18 Mitglied der Fachhochschule Ostschweiz FHO 18 © FHS St.Gallen Software Engineering Verteilte Systeme Heute Millionen von Computersystemen, welche miteinander verbunden sind. –Netzwerke bilden Transportebene –LAN – WAN –Intranet – Extranet – Internet

19 Mitglied der Fachhochschule Ostschweiz FHO 19 © FHS St.Gallen Software Engineering Verteilte Anwendungen Anwendungskomponenten arbeiten über die verteilten Systeme hinweg miteinander –Einfache verteilte Anwendungen z.B. Internetanwendungen über WWW –Verteilte Informationssysteme (Mehrschichtige Anwendungen): z.B. Flugreservationssystem –Eingebettete verteilte Systeme (Embedded distributed Systems) z.B. Intelligentes Navigationssystem im Auto –Mobile verteilte Systeme z.B. -Anwendungen über PDAs bzw. Mobiltelefone

20 Mitglied der Fachhochschule Ostschweiz FHO 20 © FHS St.Gallen Software Engineering Middleware Standardisierte Software, welche verteilte Systeme bzw. Anwendungen ermöglicht. –Abstraktion von der Netzwerkprogrammierung –Kommunikationsorientierte Middleware z.B. RPC, RMI, Web-Service –Anwendungsorientierte Middleware z.B. CORBA, J2EE,.NET

21 Mitglied der Fachhochschule Ostschweiz FHO 21 © FHS St.Gallen Software Engineering Kommunikationsmodelle Interaktionsmuster zwischen einzelnen Komponenten (Kommunikationspartner) –Synchron – Gleichzeitigkeit –Asynchron – Message Oriented Middleware (MOM)

22 Mitglied der Fachhochschule Ostschweiz FHO 22 © FHS St.Gallen Software Engineering Transparenz Ziel der Middleware: Verbergen von Verteilungsaspekten vor der Anwendung –Zugriffstransparenz –Ortstransparenz –Nebenläufigkeitstransparenz –Fehlertransparenz –Replikationstransparenz

23 Mitglied der Fachhochschule Ostschweiz FHO 23 © FHS St.Gallen Software Engineering Vor-/Nachteile der Verteilung Vorteile –Gemeinsame Nutzung von Ressourcen: Hardware Software (Anwendungen, Funktionalität) Daten, Informationen –Enabler von neuen Geschäftsmodellen z.B. e-Commerce Nachteile –Komplexe Systemumgebung –Erhöhtes Sicherheitsrisiko z.B. Viren, Würmer, Datenspionage etc.

24 Mitglied der Fachhochschule Ostschweiz FHO 24 © FHS St.Gallen Software Engineering Klassifikationsschema von Middleware Anwendungsorientierte Middleware –Um Dienste und Laufzeitaspekte erweiterte Middleware zur Unterstützung der Anwendung. Kommunikationsorientierte Middleware –Abstraktionsschicht zwischen Anwendung und verteiltem System

25 Mitglied der Fachhochschule Ostschweiz FHO 25 © FHS St.Gallen Software Engineering Kommunikationsorientierte Middleware Einordnung des Middleware-Protokolles:

26 Mitglied der Fachhochschule Ostschweiz FHO 26 © FHS St.Gallen Software Engineering Kategorisierung Kommunikationsorientierter Middleware Entfernter Aufruf (synchrone Kommunikation): –Prozedural: Remote Procedure Call (RPC) –Objektorientiert: Remote Method Invocation (RMI) Web-Services (SOAP) Nachrichtenorientierte Middleware (asynchrone Kommunikation) –Java Message Service (JMS) –MQSeries von IBM

27 Mitglied der Fachhochschule Ostschweiz FHO 27 © FHS St.Gallen Software Engineering Aufgaben kommunikationsorientierter Middleware Abstraktion des Transports Marshalling – Unmarshalling Datentransformation zwischen den Plattformen –Plattformabhängig (Hardware-/Betriebssystem-/Framework- /Programmiersprachabhängig): EBCDIC (IBM, Extended Binary Coded Decimal Interchange Code) ASCII (American Standard Code for Information Interchange) –Plattformunabhängig: CDR (CORBA, Common Data Representation) Unicode / ISO/IEC –Externe Datenformate (mit semantischer Ebene): EDI EDIFACT (Electronic Data Interchange) XML (Extended Markup Language) Fehlerbehandlung/Fehlerbehebung

28 Mitglied der Fachhochschule Ostschweiz FHO 28 © FHS St.Gallen Software Engineering RPC (Remote Procedure Call) I Entfernter Prozeduraufruf Idee: Aufruf einer entfernten Prozedur wie lokaler Prozeduraufruf (Verteilungs-/Ortstransparenz) Implementierung in unterschiedlichen Umgebungen: –Sun RPC –Microsoft Windows –Herstellerneutral: DCE RPC (Distributed Computing Environment) von Open Group

29 Mitglied der Fachhochschule Ostschweiz FHO 29 © FHS St.Gallen Software Engineering RPC (Remote Procedure Call) II Ablauf eines entfernten (synchronen) Prozeduraufrufes: Stub: Stumpf, Programmhülle mit Schnittstelle jedoch ohne Implementierungscode

30 Mitglied der Fachhochschule Ostschweiz FHO 30 © FHS St.Gallen Software Engineering RMI (Remote Method Invocation) I Ablauf eines entfernten (synchronen) Methodenaufrufes: Proxy: Stellvertreter Skeleton: Serverseitige Programmhülle

31 Mitglied der Fachhochschule Ostschweiz FHO 31 © FHS St.Gallen Software Engineering RMI (Remote Method Invocation) II Java-Source-Code javac Java-Compiler rmic RMI-Compiler Erst bei Aufruf Load auf den Client

32 Mitglied der Fachhochschule Ostschweiz FHO 32 © FHS St.Gallen Software Engineering MOM (Message Oriented Middleware) I Modell der asynchronen Nachrichtenübermittlung: MOM (Message) (Message-Queue)

33 Mitglied der Fachhochschule Ostschweiz FHO 33 © FHS St.Gallen Software Engineering MOM (Message Oriented Middleware) II Kein Session-Handling notwendig Grundsätzlich ein Store-and-Forward-Prinzip Zur Zusicherung der garantierten Zustellung: –Voraussetzung: persistente Warteschlangen –Rückmeldung bei erfolgter Zustellung

34 Mitglied der Fachhochschule Ostschweiz FHO 34 © FHS St.Gallen Software Engineering Request-Reply Model Simulation der synchronen Kommunikation Transaktion ist beim Sender erst abgeschlossen, wenn entsprechender Reply vorhanden ist. Vorteile gegenüber synchroner Kommunikation: –geringere Kommunikationsressourcen mehrere parallele Verbindungen möglich –Message-ID und Correlation-ID notwendig

35 Mitglied der Fachhochschule Ostschweiz FHO 35 © FHS St.Gallen Software Engineering Publish-Subscribe Model Abonnentensystem

36 Mitglied der Fachhochschule Ostschweiz FHO 36 © FHS St.Gallen Software Engineering Message Services Produkte Java –JMS - Java Message Service Microsoft –MSMQ – Microsoft Message Queuing IBM –WebSphere MQ (früher MQSeries)

37 Mitglied der Fachhochschule Ostschweiz FHO 37 © FHS St.Gallen Software Engineering JMS – Architektur Java-Anwendung MOM-Server CF – Connection Factory D - Destination JNDI – Java Naming and Directoy Interface

38 Mitglied der Fachhochschule Ostschweiz FHO 38 © FHS St.Gallen Software Engineering JMS - Kommunikationsablauf Aufbau der Verbindung eines JMS-Client zum JMS-Provider Sending Message Receiving Message asynchron synchron

39 Mitglied der Fachhochschule Ostschweiz FHO 39 © FHS St.Gallen Software Engineering Point-to-Point Schnittstelle Beispiel von Java-Code auf Seite 106

40 Mitglied der Fachhochschule Ostschweiz FHO 40 © FHS St.Gallen Software Engineering Publish-Subscribe Schnittstelle Wichtigster Unterschied bildet die Topic-Warteschlange.


Herunterladen ppt "Mitglied der Fachhochschule Ostschweiz FHO 1 www.fhsg.ch © FHS St.Gallen Software Engineering Software Architektur I Einführung Innere/Äussere Architektur."

Ähnliche Präsentationen


Google-Anzeigen