Illik verteilte systeme

Verteilte Systeme
Architekturen und Software-Technologien

J. Anton Illik

Prof. J. Anton Illik 1
Prof. J. Anton Illik

Die Folien zum Buch
Das Buch vermittelt dem Leser Fach- und Methoden-Kompetenz in
folgenden Punkten: Kenntnis der gewünschten charakteristischen
Eigenschaften verteilter Systeme – Unterscheidung und Bewertung
verschiedener Systemmodelle (z.B. Client-Server-, Peer-to-Peer-
Architektur, serviceorientierte Architektur) – Beherrschung der Grundlagen
von Interprozess-Kommunikationsmechanismen und Middleware in
verteilten Systemen (Sockets, RPC, RMI, CORBA, Messaging
Services etc.) – Beurteilung der Ansätze für den Entwurf und die
Realisierung von verteilten Anwendungen (verteilte Objekte, Web-
Services, Java EE/JEE usw.) – Kenntnis der Lösungs- und
Einsatzmöglichkeiten für die verteilte Datenhaltung kennen (verteilte
Dateisysteme, Namensdienste Datenbanken usw.) – Einschätzung des
Potenzials neuer Computing Paradigmen, wie z.B. Cluster Computing,
und ihrer Bedeutung für den eigenen betrieblichen Einsatz.


Die Folien zum Buch
•  Inhalt: 1) Grundlagen verteilter Systeme:
2) Grundlagen verteilter Systeme - Verteilte Anwendungen und ihre
Eigenschaften – 3) Verteilet Anwendungen und ihre Eigenschaften –
4) Systemmodelle: Architektur verteilter Systeme –
5) Technologien in verteilten Systemen – 6) Cluster-Systeme
7) Entwicklung verteilter Systeme. 8) Objektorientierte
Programmierung und verteilte Systeme – 9) Technologien in verteilten
Systemen – 10) Technologieplattformen für verteilte Systeme – Die
Technologie von Microsoft: C# und .NET – 11) Verteilte Datenhaltung –
12) RAID Konzepte – 13) Organisationsformen für Speichersysteme –
14) Verteilte Datensysteme –
15) Cluster Dateisysteme 17) Verteilte Datenhaltung in verteilten
Applikationen: 18) Verteilte Datenhaltung in der Java-Technologie –
19) Namens- und Verzeichnisdienste
•  Die Interessenten: Zukünftige IT-System- und Software-Architekten
– Fortgeschrittene Studierende der Allgemeinen Informatik,
Wirtschaftsinformatik, Medieninformatik, Bioinformatik, Medizininformatik,
Geoinformatik. Das Buch ist ein idealer Begleiter für Lehrveranstaltungen zu
den Themen »Programmentwicklung verteilter Systeme« und
»Verteilte Computer-Systemarchitekturen«. Primär richtet sich das Buch
an zukünftige IT-System- und Software-Architekten.
•  Der Autor ist Professor für Software-Engineering und Programmiersprachen
an der Fakultät für Wirtschaftsinformatik an der Hochschule Furtwangen.
Er verfügt über eine umfassende Praxiserfahrung als Berater,
Account-Manager und Geschäftsführer eines Informatik-Hauses.
•  Blog: www.illik.de eMail: johann.illik@hs-furtwangen.de


Zielpublikum,
Au-au
und
Lernziele

Business Software Systems
Basic Engineering
Engineering Engineering Engineering
Einführung Programmieren
Allgemeine BWL Datenbanken 1
in die WI und Modellieren 1
Mathematik
& Statistik Rechnungswesen Algorithmen
Internetworking
und Controlling und Datenstrukturen
Makroökonomie

Präsentations- und
Moderationstechnik Programmieren
Geschäfts-Prozesse System-Architekturen
und Modellieren 1
WPV

Integrierte
Logistik Datenbanken 2
Standardsoftware
WPV und Software Engineering
SCM Computernetze

Organisations- Praxissemester
und Führungstechnik

Praxis-Seminar Vor- und Nachbearbeitungsblock
Studienarbeit

Soziale Interaktion Software-
Business-Projekt Netzdesign
Projekt
WPV

Bachelor-Seminar Mündliche Prüfung WI Thesis

Bild 1

Zielpublikum,
Au-au
und
Lernziele

Grundlagen
verteilter
Systeme

Applikations-Ebene/ Anwendungen

Systemsoftware-Ebene / Betriebssystem

Systemebene

Hardware-Ebene

Bild 2

Monolithische
Batch-‐Systeme
und
Closed-‐Shop-‐Betrieb

Der
Mainfraime,
eingesperrt
im
Rechenzentrum

Mainframe Drucker
Backbone Netz

Frontend

Mainframe
Karten-
Leser

Rechenzentrum

Bild 3

Der
Computer
streckt
seine
Fühler
aus
dem
RZ

Der
Computer
verlässt
das
Rechenzentrum

Backbone Netz

Mainframe Drucker

Frontend

Mainframe
Karten-
Leser
Terminal-
Multiplexer
Mainframe

Rechenzentrum

Terminal Terminal Terminal Terminal

Fachabteilung

Bild 4

Der
Computer
streckt
seine
Fühler
aus
dem
RZ

Die
MulHvendor
–
Umgebung
forciert
oﬀene
verteilte
Systeme

Backbone Netz

Mainframe Drucker

Frontend

Mainframe
Karten-
Leser
Terminal-
Multiplexer

Mainframe

Rechenzentrum

Abteilungs-
computer
Terminal Terminal Terminal Terminal

Local Area Network

Workstation PC Workstation PC
Fachabteilung

Bild 5

Netzwerk-‐OS
mit
integriertem
Netzwerk-‐Dateisystem

Das
NFS:
OrganisaHon
auf
physikalischer
und
logischer
Ebene

Physikalische Hierarchisches
Platte Datensystem

Partition 1 Filesystem 1



Filesystem 4
Partition 4

Bild 6

Echt
verteilte
oﬀene
Systeme
auf
Micro-‐Kanal-‐Basis

Das
Client-‐Server-‐Prinzip
auf

•• Terminal-
Client- Server
Prozess 2 File-
Server

Client- Memory-
Prozess 1 Server

Inter-Prozess-Kooperation Netz-
Server
Speichermanagement

Prozessmanagement
User Space
Hardwareinterface

Micro-Kernel
Kernel Space

Bild 7

Echt
verteilte
oﬀene
Systeme
auf

Das
Client-‐Server-‐Modell
in
einer
verteilten
Umgebung

Client Terminal- RAM
Server Client
Server

µ Kernel µ Kernel µ Kernel µ Kernel

Netzwerk

µ Kernel Client µ Kernel Client

File- Netz-
µ Kernel µ Kernel
Server Server

Nachricht vom Client an Server

Bild 8

Client-‐/Server-‐Architektur

Das
Client-‐Server-‐Prinzip

Client Server

Zeit Aufruf

Antwort

Bild 9

Client-‐Server-‐Struktur

Client-‐Server-‐Struktur

entfernter Aufruf Server 1 Server 2
entfernter Aufruf
Client Rückmeldung Hauptstelle Rückmeldung Datenbankserver

Filiale

Bild 10

Peer-‐to-‐Peer-‐Architektur

Peer-‐to-‐Peer-‐Struktur

entfernter Aufruf
Peer_1 Peer_2

Phone Client Phone Client
entfernter Aufruf

Bild 11

Service-‐orienHerte
Architektur

Web-‐Service-‐Struktur

Client 1. Services suchen

Verzeichnis-
dienst

3. Services nutzen

2. Services finden

Service_1 Service_2 Service_3

Bild 12

MVC
Architekturmuster

MVC-‐Struktur

View Controller
(=Präsentation) (= Programm-
steuerung) Modell
(= Datenmodell)

Bild 13

Pipes
und
Fifos

Das
Prinzip
der
Pipe

Pipe

Byte-Stream

Byte-Stream

Bild 14

Genereller
Ablauf
einer
RPC

Ablaufstruktur
eines
typischen
RPC-‐Systems

Klient Server
Anwendungs- Kommunikations- Kommunikations- Server-
Klientenstub Serverstub
Programm komponente komponente Programm
Aufruf- Aufruf- Aufruf-
Prozeduraufruf Aufrufkodierung übertragung dekodierung Prozeduraufruf
empfang

Serveradresse rechne

Übertragungsprotkoll
rechne 3
3 4
4

rechne
rechne 7
7

Ergebnis- Ergebnis- Ergebnis- Ergebnis- Ergebnis-
Ergebnisrückgabe
dekodierung empfang übertragung kodierung rückgabe

Bild 15

Remote
Method
InvocaHon
(RMI)

Das
RMI/RPC-‐Prinzip

Externer Computer_2
Methodenaufruf JVM_2
Klasse B
Computer_1
Methoden
JVM_1
Klasse A l
m
B.m() n

Ergebnis-
Rückgabe

Bild 16

XML
RPC

Das
Prinzip
von
XML-‐RPC

externer Aufruf

C C++
code
code

Java code HTTP PHP
XML XML code
code
code
Perl Perl

Ergebnisrückgabe

XML-RPC

Source: JYSterinos

Bild 17

Lose
Koppelung
und
NachrichtenorienHerung

Message-‐oreinted
Middleware
mit
naHver
API

A A
Client P MOM P Server
I I

Bild 18

Portabilität
durch
Standard-‐SchniZstelle

Message-‐oriented
Middleware
mit
naHver
API
und
JMS-‐API

A A
P P
I I
Client MOM Server
A A
P P
I I

Bild 19

Das
Produzenten-‐Konsumenten-‐Modell

Die
Point-‐to-‐Point-‐KommunikaHon

JMS-Provider
Konsument_1
Messsage Queue2
A A
Produzent P P
I I

Messsage Queue1
A A
P P Konsument_1
I I

Bild 20

Die
Paradigmen
Point-‐to-‐Point
und
Publish-‐Subscribe

Die
Publish-‐Subscribe-‐KommunikaHon

JMS Provider

Topic 1
Produzent_1 Subscriber_2
Topic 2

Topic 3

Produzent_2 Topic 4 Subscriber_2

Bild 21

Open
Group
DCE

Gesamtarchitektur
des
DCE
der
Open
Group

OSF DCE Architektur

Distibuted Client/Server Applications
EXTENDED SERVICES
Distributed File Service Global Directory Service

M CORE SERVICES M
I I
D Time Directory D
Security Management
D Service
Service Service
Service D
L L
E E
W Remote Procedure Call W
A A
R DCE Threads (Thread-Safe C Library –libc_r) R
E Transported Services and Network E
DCE Host (AIX HP-UX DG/UX ODF/1 Sinix Solaris VMS OD2 NT)

Bild 22

Der
Au-au
von
COM

COM
als
SpeziﬁkaHon
und
ImplemenHerung

COM
Library

COM
Spezifikationen

Bild 23

Architektur
und
Paradigma

Schichten-‐Architektur
von
.NET

Anwendungen
ASP.NET ADO.NET Web-Services …

Common Language Runtime (Laufzeitumgebung)

Garbage Collection Sicherheit Just-in-time Compilation …

Betriebssystem (Windwos,Linux)

Bild 24

Die
Object
Management
Architecture

Das
OMA
Referenzmodell

Application Objects Business Objects Common Facilities

Object request Broker
ORB

Object Services

Bild 25

Struktur
einer
J2EE-‐Anwendung

3-‐Schichten-‐Architektur
einer
einfachen,
verteilten
J2EE-‐ApplikaHon

Schicht 1 Schicht 2 Schicht 3

Java EE Server

EJB Container
Enterprise
Enterprise Bean
Bean
Datenbank Server
Client Enterprise
Bean

Web Container

JSP Servlet

Bild 26

Die
J2EE-‐Architektur

Die
J2EE-‐Architektur

Applet
Container

Applet

JSE
HTTP
SSL
Java
HTTP
WebStart
SSL Web Container
enabled EJB Container
Rich Client
JSP Servlet
J2SE Enterprise
HTTP
Bean
SSL

Connector

Connector
MIDP Java Database
Java
Mail

JDBC
JAAS
Clients JAXP Mail

JDBC
JMS

JAXP
JAAS

JMS
JTA

JTA
HTTP JAF JAF
SSL
J2ME J2SE J2SE
Application
Client
Container
Application
Client
JDBC
JAAS
JAXP
JMS

J2ME

Bild 27

Die
J2EE-‐Architektur

Zentrale
Begriﬀe
In
einer
J2EE-‐Architektur

Begriff Bedeutung

Komponente Ist eine in sich abgeschlossene funktionelle Software-Einheit mit modularem
Charakter. D.h. die Komponente ist austauschbar, solange die Ersatzkomponente die
gleichen Schnittstellen hat.

EJB-Spezifikation Beschreibt die Regeln, nach denen die Schnittstellen der einzelnen Komponenten
bezüglich der EJB-Technologie zu entwerfen sind, damit die Modularität des Systems
stets gewährleistet ist.

J2EE Server Er stellt die übergreifende und umfassende Komponente dar, die alle anderen
Komponenten der J2EE-Architektur integriert. Dabei stellt er sowohl für die (internen)
Komponenten wie auch für die externen Clients verschiedene Dienste zur Verfügung.

EJB Container Ist eine Komponente, die den Enterprise JavaBeans eine Laufzeitumgebung zur
Verfügung stellt. Der EJB-Container selbst ist ein Bestandteil des J2EE-Servers.

Bild 28

Die
J2EE-‐Architektur

Zentrale
Begriﬀe
In
einer
J2EE-‐Architektur

Begriff Bedeutung

Enterprise Java Bean Ist eine Komponente, die innerhalb des EJB-Containers ausgeführt wird, und
entweder die Business-Logik enthält oder die Daten einer Datenbank repräsentiert.

Businesslogik Die Business-Logik wird auch Anwendungslogik genannt. Sie bezeichnet den Teil des
Codes einer Anwendung oder einer Enterprise Bean, welcher die Funktionen
bereitstellt, für den die Anwendungen oder Enterprise Bean entwickelt wurden.

Enterprise Anwendung Eine Enterprise-Anwendung kann sowohl Enterprise Beans als auch Bestanteile einer
Web-Anwendung (HTML-Dokumente, Servlets, JSPs) enthalten. Sie kann übereinen
J2EE-Server verteilt werden.

Deployment Das Deployment ist der Prozess der Installation und Integration einer Komponente in
den J2EE-Server.

Bild 28

Cluster
versus
LAN

Strukturiertes
LAN:
Server
(im
Stockwerk)
der
Fachabteilung

Client Client Client

LAN
Server

Server
LAN

Client Client Client

Bild 29

High-‐Performance-‐Cluster

Konzept
eines
Scalability
Clusters

Terminalserver
Switch

Management
Load Node Node 2 … Node
Balancer 1
Service Prozessor Netzwerk

Bild 30

High-‐Availability-‐Cluster

Konzept
eines
High-‐Availability
Clusters

Offizielles TCP/IP Netz, redundant

Cluster
Internconnect
Node 1 Node 2

Shared StorageVerbindung,
z.B. Fibre Channel, redundant

Shared Plattenresourcen für das
gesamte Cluster, in der Regel
Hardware-RAID-Lösungen mit
Dual-Controller

Bild 31

OO
Programmierung
und
verteilte
Systeme

Struktur
einer
verteilten
objektorienHerten
Anwendung

01 04
03
02
05

Rechner 1 Rechner 2

07
06

08

Rechner 3

Bild 32

Der
lokale
Prozedur
Aufruf

Die
Stack-‐Inhalte

zu main b 4 1096 zu rechne y 4 1090
gehöriger gehöriger
Stack- a 3 1098 x 3 1092
Rückkehradresse Stackab- Rückkehradresse
abschnitt (Zum Betriebssystem) 1100 schnitt (zur main) 1094

(a) zu main b 4 1096
gehöriger 3 1098
Stackab- a Rückkeradresse
7 Stack nach dem
Zu printf gehöriger schnitt (zum Betriebssystem) 1100
Stackabschnitt
ergeb Rückkehradresse Aufruf von printf
1084
(zur ergebnis) (b)
zu ergebnis ergeb 7 1086 Stack nach
gehöriger Rückkehradresse der
(zur rechne) 1088 Ausführung
Stackabschnitt
zu rechne y 4 1090 der Funktion
gehöriger 3 1092 rechne,
Stackab- x ergebnis
Rückkeradresse
schnitt (zum main)
1094 und print
zu main 4 1096
b
gehöriger 3 1098
Stackab- a Rückkeradresse zu main 4 1096
b
schnitt (zum Betriebssystem) 1100 gehöriger 3
a 1098
Stackab- Rückkeradresse
(c) schnitt (zum Betriebssystem) 1100
(d)

Bild 37

Genereller
Ablauf
einer
RPC

Ablaufstruktur
eines
typischen
RPC-‐Systems

Client Server
Anwendungs- Kommunikations- Kommunikations- Server-
Klientenstub Serverstub
Programm komponente komponente Programm
Aufruf- Aufruf- Aufruf-
Prozeduraufruf Aufrufkodierung übertragung Prozeduraufruf
empfang dekodierung

Serveradresse rechne


rechne 3
3 4
4

rechne
rechne 7
7

Ergebnis- Ergebnis- Ergebnis- Ergebnis- Ergebnis-
Ergebnisrückgabe
dekodierung empfang übertragung kodierung rückgabe

Bild 38

IdenHﬁkaHon
und
binden
der
Aufrufpartner

Beispiel
für
einen
RPC-‐Bindevorgang

Server Directory-Dienst Klient

Export Namenstabelle Import
(a) (b)
DokumentDrucken DokumentDrucken
(Dokument, Format) (Dokument, Format)
DokumentDrucken 123.456.7.8
(Dokument, Format)
(c)
Serveradresse
123.456.7.8

Prozeduraufruf (d) RPC: 123.456.7.8
DokumentDrucken(d,f) DokumentDrucken(d, f)

Return(status)

Bild 39

Sicherheitsaspekte

Struktur
eines
RPC
mit
AuthenHsierung
und
Verschlüsselung

Client K (a) Schlüssel Authentisierungsdienst
anfo rderung (K, S
(mit Schlüssel S1) 1)
Generiert KS(S1, S2)
ng {KS(S 1), KS(S2)}
(b) Rückmeldu
entschlüsselt KS(S1)
Server S
(mit Schlüssel S2)
verschlüsselt RPC-Aufruf (c) Nachricht
{RP C(KS), KS(S2)
mit KS, sendet diesen zu- }
sammen mit KS(S2) entschlüsselt KS(S2)
entschlüsselt RPC-Aufruf

ng {Ergeb nis(KS)} verschlüsselt Ergebnis mit KS
(d) Rückmeldu
entschlüsselt Ergebnis
(e) Nachricht
{RP C(KS)}

ng {Ergeb nis(KS)}
(f) Rückmeldu

Bild 40

ImplemenHerung
eines
RPC-‐Programms

Verarbeitung
der
IDL-‐SchniZstelleninformaHon

rechnen.idl

IDL-Compiler

rechnen_cstub.o rechnen.h rechnen_sstub.o
#include

rechnen_client.c rechnen_server.c

C compile

rechnen_client.o rechnen_server.o

link link
rechnen_client.exe rechnen_server.exe

Bild 41

Die
Bestandteile
einer
RMI-‐Anwendung

Die
Rolle
von
Stub
und
Skeleton

Weitergabe Datenstrom weiterleiten Aufruf der Methode

Client Stub Skeleton Remote-Objekt

Aufruf einer entfernten Marshalling der Unmarshalling der
Methode Parameter Parameter

Bild 46

Das
Ablaufschema
eines
encernten
Methodenaufrufs

Der
RMI-‐Server
registriert
ein
Objekt
in
der
RMI-‐Registry

RMI-Server-Host
RMI-Registry

JVM B
RMI-Server

Bild 47

Das
Ablaufschema
eines
encernten
Methodenaufrufs

Die
RMI-‐Registry
liefert
die
Objektreferenz
zurück

RMI-Client-Host RMI-Server-Host
RMI-Client RMI-Registry

Bild 48

Das
Ablaufschema
eines
encernten
Methodenaufrufs

RMI
Gesamtablauf

RMI-Client-Host RMI-Server-Host

RMI-Registry
RMI-Client
JVMA

Stub RMI-Server

JVM B
OS A
Skeleton

OS B

Bild 49

Der
Sicherheitsmanager
(SecurityManager)

Sicherheitseinstellungen
(Permissions)

Policy Permissions Bedeutung
AllPermission Anwendung oder Applet dürfen alles

FilePermission Zugriff auf Dateien und Verzeichnisse

NetPermission Zugriff auf Netzwerkressourcen

PropertyPermission Zugriff auf Systemeigenschaften

ReflectPermission Zugriff über Reflection auf andere Objekte

RuntimePermission Einschränkungen von Laufzeitsystemen

SecurityPermission allgemeines Sicherheitskonzept, etwa für den Zugriff auf Policies

SerializablePermission Beschränkung der Serialisierung

SocketPermission Spezielle Einschränkungen an Sockets

Bild 51

Die
Object
Management
Architecture

Das
OMA
Refenzmodell

Application Objects Business Objects Common Facilities

Object request Broker
ORB

Object Services

Bild 56

Au-aue
eines
CORBA
Objekts

Au-au
eines
CORBA
Objekts

Implementierung
Schnittstelle

Client

Objektzustand

Objektreferenz abstraktes
CORBA Objekt

Bild 57

Language
Mapping

IDL
Language
Mapping

Client Objektimplementierung

Java Java

C++ C++

Smalltalk IDL Smalltalk
Interface

Attribute
ADA ADA
Method
en
C C
COBOL
COBOL

Bild 59

ORB-‐Architektur
(CORBA)

CORBA
Architektur

Client Server

DII IDL ORB IDL DSI Object
Stub Interface Skeleton Adapter

ORB Core
(Object Request Broker Kernkomponente)

Interface Repository Implementation Repository
(Schnittstellenablage) (Implementierungsablage)

von der ORB-Implementierung abhängige Schnittstelle
es existieren verschiedene Objektadapter
genormte Schnittstellen – sind für alle ORB-Implementierungen identisch
benutzerdefinierte Schnittstelle

Bild 60

Proxy-‐KommunikaHon

Prinzip
der
Proxy-‐KommunikaHon

Client Server

Client Objektimpl.

Stub Skeleton

ORB ORB

Bild 61

Au-au
einer
Server-‐Anwendung

CORBA
Objektserver

CORBA-Objektserver

Schnittstelle

Objekt

• Initialisierung des OA
• Registrieren der
Objekte beim ORB

Bild 62

Au-au
eines
CORBA
Clients

CORBA
Client

Client Programm

Programmiersprac
hen-spezifische
Objektreferenz

DII Interface
Stub

ORB
Objektreferenz

Bild 63

Die
ORB
Interoperability
Architecture

Voll-‐
und
Halbbrücke

Protokoll A Protokoll B

ORB Voll- ORB
A Brücke B

Protokoll A Protokoll B

ORB Halb- z.B. Halb- ORB
A Brücke IIOP Brücke B

Bild 64

GIOP
und
IIOP

GIOP
Nachrichten

Nachricht Absender
Request Client

Reply Server

CancelRequest Client

LocateRequest Client

LocateReply Server

CloseConnection Server

MessageError Client und Server

Fragment Client und Server

Bild 65

Zusammenfassung

CORBA
Referenzmodell

Application
Business Objects
Objects

Object Services Object Request Common
Broker ORB Facilities

Bild 66

Zusammenfassung

Die
Komponenten
des
ORBs

Client Object Implementation

Static IDL Dynamic
Skeleton Skeleton

DII IDL Stubs Object Adapter

Object Request Broker Core

ORB Services & Common Facilities
Naming Service – Interface Repository – Life Cycle Service – Concurrency Service – …
Internationalization and Time – Mobile Agents Facility - …

Bild 67

SO
Architekuren
und
Web-‐Services
mit
XML
und
SOAP

Die
drei
fundamentalen
Rollen
einer
SOA

UDDI

Service
Broker

Publish
WDSL Find

Interact WDSL

Service
Contract
Service … Service
Comsumer Provider

Service
Client

Bild 68

SO
Architekuren
und
Web-‐Services
mit
XML
und
SOAP

Das
W3C
Architektur-‐Metamodell

Policy Model
Policy

Service Oriented Model Ressource oriented Model
Action Ressource

Message oriented Model
Message
Partially layerd on

Bild 69

Web-‐Services

Benutzung
von
Web-‐Services
–
aber
keine
SOA

Transaction Transaction
Messaging Messaging Messaging
Security Security Security

Web Service Web Service Web Service

Custom Mainframe
Eis
App Logic

Bild 70

Web-‐Services

Benutzung
von
Web
Services
innerhalb
einer
SOA

Business Service Data Service Discovery
Management

Monitoring
Service- Broker / Dienstevermittler
Mediation
Transactions Messaging Security

Web Service Web Service
Web Service

Custom Mainframe
EIS
App Logic

Bild 71

Web-‐Services

Web
Services:
WSDL,
UDDI
und
SOAP
wirken
zusammen

UDDI

WSDL

Client Server
Proxy SOAP Web
Services

SOAP (Simple Object Access Protocol) als Protokoll dient der Kommunikation zwischen Service-Anbieter und Service-Konsument
WDSL (Web Service Description Language) als Schnittstellenbeschreibung. Dient der Beschreibung der unterstützenden Methoden
und deren Parametern.
UDDI(Universial Description, Discovery and Integration) als Verzeichnisdienst (Registry) zur Registrierung von Web Services.
XML (eXtended Markup Language) als Datenformat für alle oben erwähnten Bestandteile.

Bild 72

EJB-‐Rollen

Rollenmodell

EJB-Rollen Beschreibung
Enterprise-Bean-Provider Das ist der Entwickler einer Enterprise Bean. Er programmiert alle Bestandteile für
die Enterprise Bean und fasst sie in einem jar-Archiv zu einer Komponente
zusammen. Diese Komponente übergibt er dem Applicationassembler.

Server-Provider Das ist der Hersteller eines J2EE-Servers. Mit J2EE-Server ist hier ein Server
gemeint, der konform zur J2EE-Architektur ist. Sun Microsystems liefert neben der
Spezifikation einen kostenfreien Application Server als Referenzimplementierung.
Auch Entwickler können diesen Server für die Entwicklungs- und Testphase nutzen.
Für den kommerziellen Einsatz ist dieser Referenzserver allerdings nicht geeignet,
bzw. zugelassen. Kommerzielle Produkte sind beispielsweise der „Web Logic
Server“ von Bea Systems, der „Web Sphere Server“ von IBM, oder der JBOSS-
Server von JBoss. Darüber hinaus gibt es noch zahlreiche weitere Server, die sich
voneinander hinsichtlich Performance, Funktionsumfang (proprietäre Erweiter-
ungen), Unterstützung durch Entwicklungswerkzeuge, Installations- und
Administrationskomfort unterscheiden.
Container-Provider Der Hersteller einer größeren J2EE-Komponente ist der Container-Provider. Diese
Komponente stellt die Laufzeitumgebung für Enterprise Java Beans zur Verfügung
und ist in einem J2EE-Server integriert.
Zur Zeit sind Server-Provider gleichzeitig die Container-Provider für die im Server
integrierten Container. Daher lässt sich in der Praxis kaum zwischen Server und
Container unterscheiden. Die EJB-Spezifikation lässt allerdings die Möglichkeit
offen, dass in Zukunft der Container eines Herstellers in den Server eines anderen
Herstellers integriert werden kann (Konsequenz der Komponentenarchitektur).

Bild 73

EJB-‐Rollen

Rollenmodell

EJB-Rollen Beschreibung

Applicationassembler Diese Rolle fasst die Enterprise Java Beans zu größeren Komponenten, den
Enterprise-Anwendungen, zusammen. Im Unterschied zum Enterprise-Bean-
Provider ist dies in der Regel kein Software-Entwickler. Er erstellt sogenannte
Applikationsdeskriptoren. Alle Bestandteile einer Enterprise-Anwendung werden von
ihm in einem ear-Archiv zusammengefasst. Die von ihm erzeugte Komponente
übergibt er dem Deployer.

Deployer Er installiert und integriert (deployt) die vom Applicationassembler übergebenen
Enterprise-Anwendungen im J2EE-Server.

Systemadministrator Der Systemadministrator administriert das Gesamtsystem (Betriebssystem, J2EE-
Server, Datenbank- und andere Server). Er setzt z.B. Umgebungsvariablen für den
Server und das Java Runtime Environment oder ermöglicht den Zugriff auf
Datenbanken.

Bild 73

Architektur
und
Pradigma

Architektur
von
.NET

Anwendungen

Base Class Library (Klassenbibliothek)

ASP.NET ADO.NET Web-Services …

Common Language Runtime (Laufzeitumgebung)

Garbage Collection Sicherheit Just-in-time …
Compilation

Betriebssystem (Windows, Linux, …)

Bild 74

Common
Language
RunHme

Abkürzung
aus
dem
Umfeld
der
Laufzeitumgebung
CLR

Abkürzung Bedeutung
CLR Common Language Runtime
CIL Common Intermediate Language
JIT Just in time Compilation
CTS Common Type System
CLS Common Language Specification

Bild 75

Common
Language
RunHme

.NET
Programmiersprachen
(Auszug)

.NET Programmiersprachen Hinweis
C# Primäre .NET Programmiersprache, objektorientiert. Federführend von dem Turbo-Pascal-
Erfinder Anders Hejlsberg entwickelt.

Visual Basic .NET (oder kurz: VB.NET) Primäre .NET Scriptsprachen

Managed C++ Variante von C++, die in Managed Code übersetzt wird, der unter Kontrolle der CLR läuft.

J# Microsofts veränderte Java-Implementierung.

JScript.NET Microsofts JavaScript-Implementierung.

Fortran Klassische nicht objektorientierte Sprache für naturwissenschaftliche/technische
Problemstellungen.

Eiffel Objektorientierte Programmiersprache von Bertrand Meyer (1985). Als Besonderheit
unterstützt Eiffel die Design-By-Contract-Methode.

Java Objektorientierte, plattformunabhängige Programmiersprache. Java wird in Byte-Code
übersetzt und benötigt zur Ausführung eine JVM (= Java Virtual Machine).

ML Meta Language. In den 1970er Jahren von Robin Milner an der Universtät Edinburg
entwickelt. Funktionale Programmiersprache mit statischer Typisierung, Polymorphie und
Garbage Collection. Wird im wissenschaftlichen Umfeld verwendet und an Universitäten
auch als Lehrsprache genutzt.

Bild 76

Common
Language
RunHme

.NET
Programmiersprachen
(Auszug)

.NET Programmiersprachen Hinweis

Oberon
Eine von Niklaus Wirt und Jörg Gutknecht entwickelte objektorientierte
Programmiersprache und Entwicklungsumgebung mit großer Verwandtschaft zu Pascal.
Wird gerne an Bildungseinrichtungen verwendet.

Prozedurale Programmiersprache. Ende der 1960er, Anfang der 1970er Jahre entwickelt von
Pascal
Niklaus Wirth als Weiterentwicklung von Algol 60. Typische Lehrsprache.

Skriptsprache, entwickelt von Larry Wall Anfang der 1990er Jahre. Perl wird von
Perl
Systemverwaltern als plattformübergreifende Skriptsprache benutzt, um Verwaltungs-
aufgaben zu automatisieren. Web-Entwickler nutzen Perl als CGI-Sprache.

Python Ursprünglich für das verteilte Betriebssystem Amoeba an der Universität Amsterdam von
Guido van Rossum entwickelte objektorientierte Skriptsprache. Unterstützt auch den
funktionalen Programmieransatz.

SmallTalk Dynamisch typisierte objektorientierte Programmiersprache und Entwicklungsumgebung, die
der Objektorientierung in den 1980er Jahren den Durchbruch verschaffte. Entwickelt von
Alan Kay, Adele Goldberg und Dan Ingals in den 1970er Jahren am XEROX PARC For-
schungszentrum in Paolo Alto, Californien.

…

Bild 76

Die
Base
Class
Library

Komponenten
der
Base
Class
Library

Namespace Description
System Enthält die essentiellen Basisklassen (String, Int32, DateTime,
Boolean, etc.), die Mathe-Funktionen, die Environment-
Schnittstelle u.v.a.m.
System.CodeDom Klassen für die Code-Generierung und –Ausführung “on the fly”.
System.Collections Klassen zur Verwaltung von Objektsammlungen (“Container”):
Listen, Mengen, Bäume, Hashtabellen, usw.
System.Diagnostics Klassen für die Diagnose, das Event-Logging,
Performancemessungen, Tracing und Prozess-Management.
System.Globalization Klassen für Globalisierung / Internationalisierung von
Applikationen.
System.IO Klassen für die Ein-/Ausgabe von und auf Streams, Dateien,
Verzeichnissen, Serielle Ports, usw.
System.Net Klassen für die Netzwerkprogrammierung mit Unterstützung von
Sockets und Protokolllen, wie z.B. HTTP, usw.

Bild 77

Die
Base
Class
Library

Komponenten
der
Base
Class
Library

Namespace Description

System.Resources Notwendig für die Herstellung von multilingualen Applikationen.

System.Reflections Klassen für den Zugriff auf Metadaten von z.B. Typen,
Methoden und Assemblies.

System.Text Supportklassen für die Codierung von Text/Strings.

System.Text.RegularExpressions Notwendig für die Handhabung von regulären Ausdrücken.

Klassen für die Implementierung paralleler Threads. Hilfsmittel
System.Threading für die Synchronisation paralleler Threads, z.B. Monitore und
Semaphore.

System.Windows.Forms Klassen für den Umgang mit grafischen Benutzeroberflächen.
Ersetzt die bisher unter Windows übliche Microsoft Foundation
Class (MFC).

System.Xml Klassen für den Umgang mit XML (Extensible Markup
Language). XML spielt nicht nur im Zusammenhang mit Web-
Services eine wichtigeRolle.

Bild 77

Zusammenfassung
und
Ausblick

Verteilungstechnologien:
Zeitliche
Entwicklung
und
Potenzial

Technologien in verteilten Systemen
Potenzial

geschäftsprozess-
orientiert
SOA
WebServices
J2EE
.NET

middleware-
orientiert
CORBA

DCE
RMI
systemorientiertPipes,Sockets,RPC

Zeit

Bild 78

RAID
0:
Beschleunigung
ohne
Fehlertoleranz

RAID
0
Disk
Striping

A B C D
E F G H
I J K L
M N O etc...

Bild 79

RAID
1:
Redundanz
ohne
Beschleunigung

RAID
1
Drive
Mirroring

/
Duplexing

A A E E I I M M
B B F F J J N N
= = = =
C C G G K K O O

D D H H L L P P

Mirroring Mirroring Mirroring Mirroring

Bild 80

RAID
2:
Beschleunigung
und
Redundanz

RAID
2
Hamming
Code
ECC

A0 A1 A2 A3 ECC / Ax ECC / Az
ECC / Ay
B0 B1 B2 B3 ECC / Bx ECC / By ECC / Bz

C0 C1 C2 C3 ECC / Cz
ECC / Cx ECC / Cy
D0 D1 D2 D3 ECC / Dx ECC / Dy ECC / Dz

A0 to A3 = Word A B0 to B3 = Word B ECC/Ax to Az = Word A ECC ECC/Bx to Bz = Word B ECC
C0 to C3 = Word C D0 to D3 = Word D ECC/Cx to Cz = Word C ECC ECC/Dx to Dz = Word D ECC

(7,4)-Hamming-Code

Bild 81

RAID
3:
mit
Parität
auf
separater
PlaZe
(Byte
Striping)

RAID
3
Data
Striping
mit
Priorität
auf
separater
PlaZe

Parity Generation

A0 A1 A2 A3 A PARITY

B0 B1 B2 B3 B PARITY

C0 C1 C2 C3 C PARITY

D0 D1 D2 D3 D PARITY

Stripe 0 Stripe 1 Stripe 2 Stripe 3 Stripe 0, 1, 2, 3 Parity

Bild 82

RAID
4:
Block
Striping

RAID
4:Independent
Data
Disks
with
Shared
Parity
disk

Parity
Generation
A0 A1 A2 A3 A PARITY
B0 B1 B2 B3 B PARITY
C0 C1 C2 C3 C PARITY

D0 D1 D2 D3 D PARITY

Block 0 Block 1 Block 2 Block 3 Blocks 0, 1, 2, 3 Parity

Bild 83

RAID
5:
Data
Striping
&
Parity
auf
alle
HDs

RAID
5
Independent
Data
Disks
with
Single
Distributed
Parity
Blocks

A0 B0 C0 D0 0 PARITY
A1 B1 C1 E1
1 PARITY
A2 B3 D2 E2
2 PARITY
Parity Generation A3 3 PARITY C3 D3 E3

4 PARITY B4 C4 D4 E4

A Blocks B Blocks C Blocks D Blocks E Blocks

Bild 84

Illik verteilte systeme

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (19)

Semelhante a Illik verteilte systeme

Semelhante a Illik verteilte systeme (20)

Mais de Prof. J. A. Illik, Hochschule Furtwangen University,

Mais de Prof. J. A. Illik, Hochschule Furtwangen University, (10)

Illik verteilte systeme