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

Mitglied der Fachhochschule Ostschweiz FHO 1www.fhsg.ch © FHS St.Gallen

So

ftw

are

En

gin

eeri

ng

S

oft

war

e E

ng

inee

rin

g

Software Architektur I

Einführung

Innere/Äussere Architektur

Single-/Multi-Tier

Middleware

MOM

http://creativecommons.org/licenses/by-nc-sa/3.0/


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

Zweck der Architektur


So

ftw

are

En

gin

eeri

ng

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 1471-2000 Recommended Practice for Architectural Description for Software-Intensive Systems)


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

IT-Architektur - Zusammenhänge

Middleware, Transaktions-Monitore, Verteilte Applikationen,WEB-Technologie, Datenbanken

Applikationsarchitektur

Prozess ProzessProzess

Systemarchitektur

Netzwerkarchitektur

Technologie

Geschäftstreiber

Technologietreiber

funktionale und nichtfunktionaleAnforderungen

TCP/IP, HTML, XMLVPN, etc.

Java, Visual Studio,VisualAge,UML-

Modellierungstools, ...

Entwicklungsumgebung

Geschäfts-Strategie

IT-Strategie

Markt

IT-Markt


So

ftw

are

En

gin

eeri

ng

Architektur im Entwicklungsprozess

Äussere Architektur wird als Architekturprojekt festgelegt.

Innere Architektur ist Teil des Design-Prozesses.


So

ftw

are

En

gin

eeri

ng

Innere Architektur I

Teil des Entwicklungsprojektes• Konkrete Subsystembildung

System

Subsysteme

• Applikationscluster• Applikation (System)• Modul (Subsystem)• Komponente• Implementierte Klassen


So

ftw

are

En

gin

eeri

ng

Innere Architektur II


So

ftw

are

En

gin

eeri

ng

Abstraktionsstufen im Architekturentwurf


So

ftw

are

En

gin

eeri

ng

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:


So

ftw

are

En

gin

eeri

ng

Musterarchitektur Quasar II

Beispiel 2:

http://www.sdm.de/


So

ftw

are

En

gin

eeri

ng

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

http://www.posa3.org/

http://www.posa3.org/


So

ftw

are

En

gin

eeri

ng

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!


So

ftw

are

En

gin

eeri

ng

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-ArchitekturThin ClientFat (Rich)

Client

Stored PreceduresAnwendungslogikPräsentation


So

ftw

are

En

gin

eeri

ng

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»)


So

ftw

are

En

gin

eeri

ng

n-Tier-Architecture

DMZ = Demilitarisierte Zone


So

ftw

are

En

gin

eeri

ng

Verteilte Systeme

Heute Millionen von Computersystemen, welche miteinander verbunden sind.– Netzwerke bilden Transportebene– LAN – WAN– Intranet – Extranet – Internet


So

ftw

are

En

gin

eeri

ng

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. E-Mail-Anwendungen über PDA‘s bzw. Mobiltelefone


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

Kommunikationsmodelle

Interaktionsmuster zwischen einzelnen Komponenten (Kommunikationspartner)– Synchron – Gleichzeitigkeit– Asynchron – Message Oriented Middleware (MOM)


So

ftw

are

En

gin

eeri

ng

Transparenz

Ziel der Middleware:

Verbergen von Verteilungsaspekten vor der Anwendung– Zugriffstransparenz– Ortstransparenz– Nebenläufigkeitstransparenz– Fehlertransparenz– Replikationstransparenz


So

ftw

are

En

gin

eeri

ng

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.


So

ftw

are

En

gin

eeri

ng

Klassifikationsschema von Middleware

Anwendungsorientierte Middleware– Um Dienste und Laufzeitaspekte erweiterte Middleware

zur Unterstützung der Anwendung.

Kommunikationsorientierte Middleware– Abstraktionsschicht zwischen Anwendung und verteiltem System


So

ftw

are

En

gin

eeri

ng

Kommunikationsorientierte Middleware

Einordnung des Middleware-Protokolles:


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

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 10646

– Externe Datenformate (mit semantischer Ebene):• EDI EDIFACT (Electronic Data Interchange)• XML (Extended Markup Language)

Fehlerbehandlung/Fehlerbehebung


So

ftw

are

En

gin

eeri

ng

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• www.opengroup.org/dce

http://www.opengroup.org/dce

http://www.opengroup.org/dce/


So

ftw

are

En

gin

eeri

ng

RPC (Remote Procedure Call) II

Ablauf eines entfernten (synchronen) Prozeduraufrufes:

Stub: Stumpf, Programmhülle mit Schnittstelle jedoch ohne Implementierungscode


So

ftw

are

En

gin

eeri

ng

RMI (Remote Method Invocation) I

Ablauf eines entfernten (synchronen) Methodenaufrufes:

Proxy: Stellvertreter

Skeleton: Serverseitige Programmhülle


So

ftw

are

En

gin

eeri

ng

RMI (Remote Method Invocation) II

Java-Source-Code

javac Java-Compiler

rmic RMI-Compiler Erst bei AufrufLoad auf den Client


So

ftw

are

En

gin

eeri

ng

MOM (Message Oriented Middleware) I

Modell der asynchronen Nachrichtenübermittlung:

MOM (Message)

(Message-Queue)


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

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


So

ftw

are

En

gin

eeri

ng

Publish-Subscribe Model

Abonnentensystem


So

ftw

are

En

gin

eeri

ng

Message Services Produkte

Java– JMS - Java Message Service

Microsoft– MSMQ – Microsoft Message Queuing

IBM– WebSphere MQ (früher MQSeries)


So

ftw

are

En

gin

eeri

ng

JMS – Architektur

Java-Anwendung

MOM-Server

CF – Connection FactoryD - Destination

JNDI – Java Naming and Directoy Interface


So

ftw

are

En

gin

eeri

ng

JMS - Kommunikationsablauf

Aufbau der Verbindung eines JMS-Client zum JMS-Provider

SendingMessage

ReceivingMessage

asynchronsynchron


So

ftw

are

En

gin

eeri

ng

Point-to-Point Schnittstelle

Beispiel von Java-Code auf Seite 106


So

ftw

are

En

gin

eeri

ng

Publish-Subscribe Schnittstelle

Wichtigster Unterschied bildet die Topic-Warteschlange.

Documents

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