Post on 05-Apr-2015
Block 2 Interoperabilität für Geoinformationen
SeminarInteroperabilität für Geoinformationen
Grundlegendes zu Software-Architekturen 24.10.2003
Lars Bernard
Block 2 Interoperabilität für Geoinformationen
Grundlegendes zu Software-Architekturen
Struktur
1. Motivation
2. Ursprung und Begriffsdefinition
3. Design und Architekturen
4. Überblick Mehrschicht- und Servicearchitekturen
Patterns und Frameworks
5. Aktuelle DCP
Eng und lose gekoppelte Services
CORBA/COM/RMI und Web Services
Fazit
Block 2 Interoperabilität für Geoinformationen
1. Motivation – Wozu Architekturen ?
hierzu, nicht unbedingt....
Block 2 Interoperabilität für Geoinformationen
1. Motivation – Wozu Architekturen ?
hierzu bestimmt !
Block 2 Interoperabilität für Geoinformationen
1. Motivation – Wozu Architekturen ?
Überblick:
– Strukturierung komplexer Systeme ( Baupläne)– Kommunikation komplexer Systeme– Koordination– Kostenschätzung...
Kostenreduzierung, z.B. durch
– Wiederverwendung ( Standard-Fenster)– Gute Entwürfe recyclen ( Grundrisse)...
Der Architekt weiß, wie es geht !
....
Block 2 Interoperabilität für Geoinformationen
2. Software-Architektur – Ursprung:
In programming, the term architecture was first used to mean a description of a computer system that applied equally to more than one actual system. In 1969, Fred Brooks and Ken Iverson called architecture the "conceptual structure of a computer...as seen by the programmer"...."Where architecture tells what happens, implementation tells how it is made to happen."
(Paul Clements, Software Engineering Institute;http://www.sei.cmu.edu/architecture/essays.html)
Block 2 Interoperabilität für Geoinformationen
2. Software-Architektur – Definitionen:
There is no standard, universally-accepted definition of the term, for software architecture is a field in its infancy, although its roots run deep in software engineering.
(Software Engineering Institute / Carnegie Mellon University; http://www.sei.cmu.edu/architecture/definitions.html)
Block 2 Interoperabilität für Geoinformationen
2. Software-Architektur – Definitionen:
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization - these elements and their interfaces, their collaborations, and their composition.
(Booch, Rumbaugh, Jacobson (1999): The UML Modeling Language User Guide, Addison-Wesley).
Block 2 Interoperabilität für Geoinformationen
2. Software-Architektur – Definitionen:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them
(Bass, Clements, Kazman (1997): Software Architecture in Practice, Addison-Wesley).
Block 2 Interoperabilität für Geoinformationen
3. Design und Architekturen:
Der Schritt der Systemanalyse (z.B. domain analysis,...Literatur: z.B. Booch et al. (1999); Östereich (97-01)) mit dem elementaren Ziel: Systemanforderungen ermitteln und dazu passende Systemform finden
Ein grundlegendes Ziel des Software-Engineer ist die Wiederverwendung bestehender Konzepte/Komponenten bzw. Wiederverwendbarkeit der zu entwickelnden Komponenten
Block 2 Interoperabilität für Geoinformationen
3. Design und Architekturen:
Techniken zur Wiederverwendung bzw. zum Teilen (sharing) eines Ansatzes über mehrere Projekte (nach Szyperski 1999):
– Konsistenz teilen: Programmiersprachen– Lösungsfragmente teilen: Programm-Bibliotheken– Absprachen teilen: Schnittstellen– Interaktions-Architekturen teilen: Pattern– Teilarchitekturen teilen: Frameworks– Gesamtstruktur teilen: Systemarchitektur
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen - Schichtenmodelle
Beispiel Java:
JavaPlatform}
Java Program
Java API
Java V irtual Machine
SolarisW indows
NTO S n ...
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen - Schichtenmodelle
Beispiel 2-tier; client/server (seit den 80‘ern):
Client:User Interface + Prozessmanagement
Server: DBMS + Prozessmanagement
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen - Schichtenmodelle
Beispiel 3-tier; client/application-server/data-server(seit den 90‘ern):
Client:User Interface
Data Server: DBMS
Application Server: Prozessmanagement(Prozesslogik)
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen - Schichtenmodelle
Beispiel ISO/OSI Referenzmodell für Netzwerkanwendungen:
Block 2 Interoperabilität für Geoinformationen
4. Schichtenmodelle – Eigenschaften:
Ziel Abstraktion einzelner Schichten um diese austauschbar zu machen ( Interoperabilät):
Beschreibung von Schnittstellen
stricly layered versus non-strictly layered
Grundlegendes Prinzip der heute verwendeten Middleware-Ansätze
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen – Service based architecture
Dynamische Systemintegration
– program to program communictaion– Zusammenfügen von Anwendungskomponenten
zur Laufzeit (z.B. freie Wahl bei der Inanspruchnahme kostpflichtiger Angebote im WWW)
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen – Service based architecture Service
– Implementierung eines (standardisierten) Interfaces, das eine Menge von Operationen über ein Netzwerk verfügbar macht.
– Das Interface „versteckt“ Implementierungsdetails, so dass es unabhängig von der verwendeten Hard- und Softwareplattform genutzt werden kann (cross technology implementation).
– Wird durch eine service description beschrieben, welche alle Informationen enthält, die zur Interaktion mit dem Service erforderlich sind.
Block 2 Interoperabilität für Geoinformationen
4. Systemarchitekturen – Service based architecture
Find-bind-publish; Basiert auf den Interaktionen dreier Rollen:
1.Service provider
2.Service registry
3.Service requestor
Block 2 Interoperabilität für Geoinformationen
4. Patterns für Mehrschicht- & Servicearchitekturen Mehrschichtige Systeme sind aus einer Vielzahl von
Komponenten aufgebaut.
Daraus ergeben sich unterschiedliche, immer wiederkehrende Anforderungen:
– Transparenz, plattformneutrale Kommunikation
– Auffinden und Aktivierung von Komponenten
– Performance, Skalierbarkeit
Für viele dieser Probleme gibt es daher Lösungsmuster (patterns) die sich in vielen Systemen/Middlewares wiederfinden.
Block 2 Interoperabilität für Geoinformationen
4. Patterns – Kommunikationsmuster
Sowohl die einzelnen Schichten als auch Komponenten innerhalb einer Schicht müssen durch Kommunikationsmechanismen verbunden werden
Arten der Kommunikation:
1. Lokaler Server (native procedure call)
2. Synchroner RPC (Remote Procedure Call)
3. Asynchroner RPC
4. Message-basiert (Publish-Subscribe)
Block 2 Interoperabilität für Geoinformationen
4. Patterns Beispiele: Synchrone Kommunikation (S-RPC) Alle Komponenten sollten gleich angesprochen
werden können, egal ob sie lokal oder verteilt sind
Proxy-Pattern
+service()
AbstractService
+service()
Service
+service()-marshal()-unmarshal()
Proxy
Client
1 1
Block 2 Interoperabilität für Geoinformationen
4. Patterns Beispiele: Ablauf S-RPC
c : Client p1 : Proxy s : Service
service()
marshal()
service()
unmarshal()
Block 2 Interoperabilität für Geoinformationen
4. Patterns Beispiele: Broker
Wie lokalisiert man Komponenten?
Wie initiiert man die Kommunikation?
Client
+locate_service()+register_service()
Broker
+service()-marshal()-unmarshal()
Proxy
*
1
calls
* 1
message exchange
+service()-marshal()-unmarshal()
Proxy*1message exchange
+service()
Service
*
1
calls
Block 2 Interoperabilität für Geoinformationen
4. Patterns Beispiele: Ablauf Brokerc : Client client : Proxy b : Broker server : Proxy s : Service
service()
service()
marshal()
locate_service()
register_service()
unmarshal()
service()
marshal()
unmarshal()
Block 2 Interoperabilität für Geoinformationen
4. Frameworks - Eigenschaften
Frameworks:
– fassen Patterns zu logischen Einheiten zusammen– sind nicht nur abstrakte Konzepte sondern sind
durch Implementierungen realisiert – zielen meist auf einen speziellen
Anwendungsbereich– Bspe: Klassenbibliotheken, GUI-Toolkits, ...– Systemarchitekturen bedienen sich eines oder
mehrere frameworks
Block 2 Interoperabilität für Geoinformationen
4. Frameworks - Eigenschaften
white box framework
– Strukturierte Sammlung von Quelltexten– Interoperabilität zur Kompilierzeit– Implementierung transparent
black box framework
– Strukturierte Sammlung von binären Entitäten (components)
– plug-and-play zur Laufzeit– Implementierung unbekannt
vgl.Szyperski, C. (1999): Component Software - Beyond Object-Oriented Programming. Addison-Wesley.
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP
Distributed Computing Platform (DCP) bzw. Plattfomen für Distributed Object Computing (DOC)
Nachfolger der plattformspezifischen und implemetierungsaufwändigen Socket-Techniken bzw. der Remote Procedure Calls (RPC) die die direkte Implementierung auf Basis des Transmission Control Protocol (TCP) ablösten
Es wird heute (nicht wirklich trennscharf) unterschieden in:
– Eng gekoppelte Dienste– Lose gekoppelte Dienste
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP
Eng gekoppelte Dienste:
– Die eingebunden Ressourcen sind weitgehend bekannt
– Struktur der übertragenen Informationen ist weitgehend bekannt
– Kopplung erfolg in der Regel im Intranet (bzw. hinter einer gemeinsamen firewall)
Architekturen für eng gekoppelte Dienste:
– CORBA– DCOM– Java RMI, …
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP - CORBA
Die Common Request Broker Architecture (CORBA) wurde Anfang der 90er Jahre durch die Object Management Group (OMG) erstmalig vorgestellt
Generelle Idee:
– Interfaces eines Objektes werden durch die Interface Definition Language beschrieben
– Der Objekt Request Broker realisiert die Kommunikation zwischen Client- und Serveranwendungen
– Client müssen Stubs implementiern– Server müssen Skeletons implementieren– Dafür gibt es sprachspezifische IDL-Übersetzer
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP - CORBA
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP - CORBA
CORBA lieferte damit zunächst auch nur rudimentäre Lösung Weiterhin bleibt eine Menge von Absprachen notwendig um wirklich plattformunabhängige Lösungen zu realisieren
Die OMG versucht zu reagieren, mit der
– Erweiterung zur Object Management Architecture (OMA)
– Spezifikation grundlegender Dienste in CORBA 2.0 (pesistent object services, security services, etc.)
Implementierungen gibt es erst Ende der 90er Jahre
Da kommen die Web-Services auf….
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP
Lose gekoppelte Dienste:
– Die eingebunden Ressourcen sind weitgehend unbekannt
– Struktur der übertragenen Informationen ist selbstbeschreibend
– Kopplung erfolgt in der Regel im Internet
Architekturen und Protokolle für lose gekoppelte Dienste:
– WEB/HTTP; HTTPS– XML, SOAP, WSDL– UDDI
Block 2 Interoperabilität für Geoinformationen
5. Aktuelle DCP - Web Service
Block 2 Interoperabilität für Geoinformationen
Fazit
Architekturen dienen:
– der Strukturierung, – der Kommunikation von Designentscheidungen, – des Systementwurfes, – der Beschreibung der Interaktionen und
Schnittstellen.
Auf unterschiedlichen Granularitätsebenen finden sich mit höher werdender Granularität: Systemarchitekturen, Frameworks und Patterns
Block 2 Interoperabilität für Geoinformationen
Fazit
In Architekturen finden sich wiederkehrende Muster (patterns)
Frameworks erlauben die dynamische Konfiguration eines aus patterns aufgebauten Anwendungsgerüsts (toolbox)
Systemearchitekturen beschreiben das Gesamtsystem, dies sind in der Regel multi-tier Architekturen Abstraktion durch Schichten Interoperabilität durch definierte Schnittstellen
und Protokolle
Block 2 Interoperabilität für Geoinformationen
Fazit
Dienstearchitekturen sind Mehrschichtarchitekturen die speziell auf eine ad-hoc Zusammenstellung ausgerichtet sind
Es kann zwischen Dienstearchitekturen für eng und lose gekoppelte services unterschieden werden
Der aktuelle Hype konzentriert sich auf die lose gekoppelten Web Services ….