Seminararbeit Netzwerkprogrammierung

Seminararbeit - Netzwerkprogrammierung
1
Netzwerkprogrammierung
Stefan Renner
Seminar LaVida
24.Januar 2011
Eine Übersicht über Techniken und Möglichkeiten der
Netzwerkprogrammierung.
I. EINLEITUNG
N
etzwerkprogrammierung ist ein relativ breiter Begriff.
Aus diesem Grund werde ich Grundlagen und
verschiedene Konzepte erläutern, um diesen Begriff zu
erklären. Also zuerst die Frage:
A. Was ist ein Netzwerk?
"Netzwerke sind Systeme, deren Struktur durch einen
Graphen modellierbar sind und welche über Mechanismen
zur Eigenorganisation verfügen". Soweit die Definition.
Früher beschrieb das Wort Netzwerk eine Reihe serieller
Leitungen, mit denen Terminals an Großrechenanlangen
angeschlossen wurden. Für einige impliziert der Begriff
Netzwerk das Telefonnetz, oder das für die Verbreitung von
Videosignalen genutzte Kabelnetz. Diese Netzwerke sind auf
eine spezielle Art von Daten und deren Übertragung
spezialisiert und verbinden ebenfalls spezialisierte Geräte
miteinander. Im Gegensatz zu diesen spezialisierten
Netzwerken, gibt es natürlich auch generelle, allgemeine
Netze. Generelle Netze werden vorwiegend aus universeller,
programmierbarer Hardware aufgebaut und sind nicht für
spezielle Anwendungen optimiert. Sie sind vielmehr in der
Lage viele verschiedene Typen von Daten zu transportieren
und unterstützen eine breite, ständig wachsende Palette von
Applikationen. Was nun zu betrachten wäre, ist wie die
verschiedenen Komponenten eines Netzwerkes miteinander
kommunizieren. Hierzu werden im Folgenden sog.
Referenzmodelle betrachtet.
B. Referenzmodelle
Es existieren zwei wichtige Referenzmodelle für
Rechnernetzwerke. Das etwas allgemeinere TCP/IP-Modell
und das etwas detailliertere OSI-Modell. Beide Modelle
basieren auf der Idee der sog. "Schichten" oder "Layers". Um
diese Schichten zu verstehen, betrachtet man am besten das
sog. "Philosoph-Übersetzer-Sekretärin-Problem". Hierbei
wird das Problem betrachtet, wie zwei Philosophen, welche
nicht
dieselben
Sprachen
sprechen,
miteinander
kommunizieren um ihre Ideen auszutauschen. In Abbildung 1
wird gezeigt, dass sich beide Philosophen auf Schicht Drei
befinden. Philosoph "A" reicht seine Nachricht an seinen
Übersetzer "A" weiter, der seine Nachricht in eine Sprache
übersetzt, welche auch der Übersetzer "B" in den Diensten
von Philosoph "B" versteht. Übersetzer "A" reicht nun seine
Übersetzung an die Sekretärin "A" weiter, welche die
Nachricht per Fax an die Sekretärin "B" übermittelt. Es ist
also deutlich zu sehen, dass die beiden Sekretärinnen
miteinander kommunizieren. Die Übersetzer kommunizieren
ebenfalls miteinander und somit sind auch die Philosophen in
der Lage miteinander zu kommunizieren. Die Sekretärinnen,
die Übersetzer und die Philosophen befinden sich jeweils auf
einer Schicht.
Abbildung 1 Philosoph-Übersetzer-Sekretärin
Zu beachten an dieser Stelle wäre noch die Tatsache, dass
Übersetzer "A" einen sog. "Header" hinzufügt, welcher
beschreibt, um welche Sprache es sich bei nachfolgendem
Text handelt. Dieses Paket, also Header und Nachricht, wird
von der Sekretärin wieder als Nachricht in das von ihr
erstellte Paket eingebunden. Anhand dieses Problems lassen
sich auch drei Begriffe einführen, welche für die weitere
Lektüre von essentieller Wichtigkeit sind.
1) Protokoll
Protokolle sind Regelwerke, die die Kommunikation
innerhalb einer Schicht regeln. So ist zum Beispiel die
genaue Formatierung des Headers festgeschrieben. Der
Header, den Übersetzer "A" hinzufügt, könnte natürlich
verschiedene Formen haben. Er muss lediglich Übersetzer
"B" darüber informieren, um welche Sprache es sich hierbei
handelt. "This is Dutch" und andere Variationen würde ein
Mensch auch verstehen, bereitet aber einem Computer
Schwierigkeiten. Es ist daher genau festgeschrieben, dass
nach dem Bezeichner "L:" der Name der Sprache steht in der
nachfolgender Text geschrieben ist.
Diese Protokolle sind die "Privatangelegenheit" einer
Schicht. Es wird weder von höheren noch von niederen
Schichten auf diese Einfluss genommen.
Seminararbeit - Netzwerkprogrammierung
2) Dienst
Ein Dienst ist die Semantik einer Schicht. Ein Dienst
beschreibt, was eine Schicht, auch unter Verwendung
weiterer niederer Schichten, der nächst höheren Schicht an
Leistung anbietet und ihr so als Werkzeug zur Verfügung
steht. Der Dienst den Schicht Eins in unserem Beispiel
anbietet ist die Übermittlung des Übersetzerpaketes an den
anderen Übersetzer. Dieser kann anhand der Pakete, die er
bekommt, nicht feststellen, wie die niederen Schichten diese
Übermittlung realisiert haben.
3) Schnittstelle
Die Schnittstelle bezeichnet den Kommunikationspunkt
mit der nächst höheren Schicht. Diese ist am ehesten anhand
unseres Beispiels zu erklären, indem man sich vorstellt, dass
Übersetzer "B" eine kleine Nachricht an seine Übersetzung
klammert in der er Philosoph "B" über mögliche
Übersetzungsvariationen/Fehler informiert.
C. Das TCP/IP Referenzmodell
Das TCP/IP-Modell basiert auf der Idee der Schichten wie
sie in dem Beispiel des Philosoph-Übersetzer-SekretärinProblems erläutert sind. Die "Defense Advanced Research
Projects
Agency"
des
US-Amerikanischen
Verteidigungsministeriums (DoD) entwickelte ca. 1970
Protokolle zur Datenübertragung und Kommunikation.
Hierbei entstand das sog. "DoD-Schichtenmodell". Dieses
Modell wurde entwickelt, um ein rein militärisches
dezentrales Netz aufzubauen, dass durch seine Struktur von
hoher Ausfallsicherheit gekennzeichnet ist. In Kombination
mit der Internetprotokollfamilie (IP) ergibt sich das TCP/IPReferenzmodell, was die frühe Grundlage des Internets
darstellt. Es basiert auf vier Schichten die nachfolgend in
Abbildung 2 dargestellt sind:
2
zusammenhält. Diese Schicht ermöglicht es jedem Host
Pakete in jedes beliebige Netz einzuspeisen und diese werden
unabhängig voneinander zum Ziel transportiert. Eine
eventuell nötige Neuordnung der Pakete ist hierbei Aufgabe
höher liegender Schichten.
Die Internetschicht definiert ein offizielles Paketformat
und Protokoll namens "IP"(Internet Protocol). Es ist
Aufgabe der Schicht, diese IP-Pakete korrekt zuzustellen.
Sog. "Paket-Routing" und das Vermeiden von Überlastungen
sind hier die wichtigsten Begriffe.
3) Transport Layer
Das "Transport Layer" oder auch "Transportschicht"
ermöglicht, natürlich unter Verwendung der niederer
gelegenen Schichten, gleichgestellten Einheiten auf zwei
Hosts die Kommunikation. Hierzu wurden zwei Endpunktzu-Endpunkt-Übertragungsprotokolle
definiert.
"TCP"
(Transmission Control Protocol), ein zuverlässiges,
verbindungsorientiertes Protokoll, über das ein Bytestrom
fehlerfrei einem anderen Rechner zugestellt wird. Das zweite
Protokoll "UDP" (User Datagram Protocol), ist ein
unzuverlässiges,
verbindungsloses
Protokoll.
Dieses
Protokoll ist für Anwendungen vorgesehen, die die
Sicherstellung der Reihenfolge, sowie die Flusskontrolle
lieber selbst bereitstellen.
4) Application Layer
Das "Application Layer" oder auch "Anwendungsschicht"
umfasst sämtliche Protokolle deren sich Anwendungen
bedienen. Angefangen bei "TELNET", ein frühes Protokoll
um sich an einem entfernten Rechner anzumelden, um auf
ihm zu arbeiten, über "FTP"(File Transfer Protocol) um
Dateien zu übertragen bis hin zu E-Mail-Protokollen, wie
"SMTP"(Simple Mail Transfer Protocol) um E-Mails zu
übertragen. Im Laufe der Zeit sind sehr viele weitere
Protokolle
hinzugekommen,
wie
zum
Beispiel:
"HTTP"(HyperText Transfer Protocol) zum Abruf von
Webseiten aus dem "World Wide Web" oder
"DNS"(Domain Name Service) zur Zuordnung von
Hostnamen an deren Netzwerkadressen.
Zu beachten ist hierbei die Aufteilung in die sog.
"Transportschichten"(Physical Layer, Internet Layer und
Transport Layer) und die "Anwendungsschicht"(Application
Layer). Die Netzwerkprogrammierung beschäftigt sich nicht
mit der Funktionsweise der Transportschichten, sondern
nutzt lediglich den durch diese Schichten bereitgestellten
Dienst.
Abbildung 2 TCP/IP-Modell
1) Physical Layer
Das "Physical Layer" oder auch "Netzzugangsschicht"
enthält keine Protokolle aus der Internetprotokollfamilie. Aus
Sicht der Netzwerkprogrammierung betrachtet man diese
Schicht eher als Platzhalter für Techniken der
Datenübertragung von Punkt zu Punkt.
2) Internet Layer
Das "Internet Layer" oder auch "Internetschicht" ist die
entscheidende Schicht und die Schnur die alles
D. Das OSI-Referenzmodell
Das OSI-Referenzmodell ist ein, im Vergleich zum
TCP/IP-Modell, verfeinertes Modell. Es wurde 1979 mit der
Entwicklung begonnen und 1983 hat die Internationale
Organisation für Normung (ISO) das Modell standardisiert.
Es basiert, ebenfalls wie das TCP/IP-Modell, auf der Idee der
Schichten und man unterscheidet ebenfalls zwischen den
"Transportschichten" (Schicht eins bis vier) und den
"Anwendungsschichten" (Schicht fünf bis sieben). Das OSIModell arbeitet wesentlich klarer mit Begriffen wie
Protokoll, Dienst und Schnittstelle, welche sogar die
grundlegenden Konzepte des OSI-Modells darstellen und ist
Seminararbeit - Netzwerkprogrammierung
wesentlich universeller einsetzbar, da hier, im Gegensatz zum
TCP/IP-Modell, das Konzept vor den entsprechenden
Protokollen entwickelt wurde. So ist es zum Beispiel nicht
möglich, Bluetooth mit dem TCP/IP-Modell zu beschreiben.
Es gibt allerdings durchaus starke Ähnlichkeiten zwischen
den beiden hier angeführten Modellen, was allein schon in
der Namensgebung der nachfolgend in Abbildung 3
gezeigten Schichten deutlich wird.
3
2) Presentation Layer
Das "Presentation Layer" oder auch "Darstellungsschicht"
beschäftigt sich im Unterschied zu den unteren Schichten,
welche vor allem mit der Bitübertragung beschäftigt sind, mit
der Syntax und der Semantik der zu übertragenden
Informationen. Damit Computer mit unterschiedlichen
Datendarstellungen kommunizieren können, werden die
ausgetauschten Datenstrukturen auf abstrakte Weise
definiert.
Die
Darstellungsschicht
verwaltet diese
Datenstrukturen und ermöglicht somit den Austausch von
Datenstrukturen auf höheren Ebenen.
3) Application Layer
Das "Application Layer" oder auch "Anwendungsschicht"
enthält wie die gleichnamige Schicht des TCP/IP-Modells
eine Vielzahl von Protokollen. So sind "HTTP", "SMTP"
und "FTP" auch im OSI-Modell in der Anwendungsschicht
beheimatet.
II. UMGANG MIT DEN TRANSPORTSCHICHTEN
Wie schon vorangegangen erläutert, ist aus Sicht der
Netzwerkprogrammierung die genaue Funktionsweise der
Transportschichten von sekundärer Wichtigkeit, da nur die
durch die Transportschichten angebotenen Dienste genutzt
werden. Um diese Dienste nutzen zu können, ist jedoch ein
grundlegendes Verständnis unabdingbar.
Hierzu werden nachfolgend die wichtigsten Punkte
vorgestellt.
Abbildung 3 OSI-Modell
Auch
hier
werden
die
Protokolle
der
Internetprotokollfamilie verwendet. So ist "IP" hier der
Schicht drei zuzuordnen. "TCP" und "UDP" finden sich in
Schicht vier. Für die Netzwerkprogrammierung interessant
sind hier die Schichten fünf bis sieben, welche in ihrer
Gesamtheit der Anwendungsschicht des TCP/IP-Modells
relativ ähnlich sind.
1) Session Layer
Das "Session Layer" oder auch "Sitzungsschicht"
ermöglicht
es Benutzern Sitzungen untereinander
aufzubauen. Sitzungen bieten verschiedene Dienste an, wie
zum Beispiel "Dialog Control", welcher verfolgt wer gerade
Daten senden darf, oder "Token Management" welcher
verhindert, dass zwei Parteien wichtige Operationen zur
gleichen Zeit durchführen. Interessant ist hier noch
"Synchronization" welcher bei langen Übertragungen sog.
"Checkpoints" setzt, ab denen die Übertragung nach einem
Absturz wieder aufgenommen werden kann.
A. Internet Protocol
Das "IP" ist, wie schon angeführt, der Netzwerkschicht
zugeordnet und ermöglicht die Zustellung von Datenpaketen
an den Zielhost. Diese Pakete können unterschiedliche Wege
durch das Netzwerk wählen, was aus ihrer völligen
Eigenständigkeit resultiert. Dies kann zur Folge haben, dass
Pakete verloren gehen oder/und Pakete in der falschen
Reihenfolge am Zielhost ankommen. Die Reorganisation ist
hierbei höheren Schichten überlassen.
Um die Paketzustellung zu ermöglichen, hat jeder Host
(anwählbarer Computer des Netzes) im Netzwerk eine sog.
"IP-Adresse", wie zum Beispiel:"192.168.2.45". Diese
Adressen bestehen aus vier, durch Punkte getrennte, sog.
"Oktetten". Der Name "Oktett" erklärt sich durch die
Tatsache, dass jedes Oktett eine achtstellige Binärzahl
repräsentiert.
Genau wie im Beispiel "Philosoph-Übersetzer-SekretärinProblem" haben auch diese "IP-Pakete" einen "Header".
Dieser enthält unter anderem die Absenderadresse und die
Zieladresse. Der, diesem Header nachfolgende, "Datenteil"
des Paketes, ist dann das wieder mit einem "Header
versehene TCP oder UDP-Paket.
B. Transportprotokolle
Zur Transportschicht werden nachfolgend die zwei
bekanntesten Protokolle, TCP und UDP. Beide sind sog.
"Endpunkt-zu-Endpunkt" Protokolle. Diese Endpunkte
werden durch sog. "Sockets" dargestellt. Jedem Socket ist
eine sog. "Portnummer" zugeordnet. Diese Portnummern
sind normale Integerwerte zwischen 0 und 65535. Jeder
Seminararbeit - Netzwerkprogrammierung
Socket, als möglicher Endpunkt einer Verbindung im
Netzwerk ist durch eine IP-Adresse und eine Portnummer
eindeutig identifiziert. Desweiteren kann ein Socket
Endpunkt mehrerer Verbindungen sein.
1) Transmission Control Protocol
TCP ist ein Protokoll zur Bereitstellung eines
zuverlässigen Bytestroms zwischen zwei Endpunkten. TCPVerbindungen sind Duplex-Verbindungen, was bedeutet,
dass der Verkehr gleichzeitig in beide Richtungen fliesen
kann.
Für die Netzwerkprogrammierung ist zu TCP zu sagen,
dass es eine Verbindung herstellt, welche garantiert, dass die
Pakete in der richtigen Reihenfolge ankommen. Eventuell
verlorene Pakete werden erkannt und erneut gesendet.
2) User Datagram Protocol
UDP ist im Gegensatz zu TCP ein verbindungsloses
Protokoll. Es ist an sich recht schlank, da es im Wesentlichen
aus den im Header der UDP-Pakete stehenden Portnummern
besteht.
UDP kann zum Beispiel für kurze Serveranfragen
verwendet werden. Sendet beispielsweise ein Client (der
anfragende Computer) eine kurze Anfrage an einen Server
(der antwortende Computer) und dieser sendet ebenfalls eine
kurze Antwort zurück, so ist der aufwändiger Aufbau einer
TCP-Verbindung zwar möglich, sprengt jedoch weit den
nötigen Rahmen. Sollte doch einmal ein UDP-Paket verloren
gehen, so kann beim Sender ein Timer ablaufen, der
definiert, nach welcher Zeit eine Antwort hätte erfolgen
müssen. In diesem Fall wird das Paket erneut versandt.
C. Umsetzung in C#
Zur Verdeutlichung des zuvor beschriebenen hier
nachfolgend ein kleines Beispiel in C#.
Hier die Funktionsweise eines TCP Clients unter der
Verwendung der .Net Socket Klasse:
1) Aufruf des Socket-Konstruktors
sock=new Socket(AdressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
Um das das "Internet Protocol" zu verwenden, wird als
Adressfamilie die "InterNetwork"-Familie gesetzt. Da TCP
einen Bytestream realisiert wird der als Socket-Typ "Stream"
gesetzt und natürlich der Protokolltyp "TCP" für einen TCPVerbindung.
2) Aufruf der Connect()-Methode
sock.Connect(serverEndpoint);
Der Methode wird eine Instanz von "IPEndPoint"
übergeben. Dieses Objekt stellt die Kontaktdaten des anderen
Endpunktes der Verbindung dar, wie IP-Adresse und
Portnummer.
4
3) Senden und mit Send()
sock.Send(byteBuffer, 0, byteBuffer.Length,
SocketFlags.None);
Hier stellt byteBuffer das Array dar, dass die zu sendenden
Daten beinhaltet. An zweiter Stelle steht der Index des ersten
Elementes im Array, das gesendet werden soll. An dritter
Stelle die Anzahl der Bytes die gesendet werden sollen und
an vierter Stelle können bei Bedarf Flags gesetzt werden, die
aber hier zu weit hinein gehen. Für das Beispiel werden aus
diesem Grund keine gesetzt.
4) Schliesen des Sockets
sock.Close();
Ein Socket wird durch den schlichten Aufruf der Methode
Close() geschlossen. Dieser Aufruf sollte in einem "finally"Block stehen.
III. NETZWERKPROGRAMMIERUNG AUF HÖHEREN EBENEN
Eine Implementierung einer größeren Anwendung direkt
am Puls der Transportschichten ist sehr arbeitsintensiv,
unübersichtlich und auch in den Möglichkeiten beschränkt.
Aus diesem Grund wird dies auch nicht wirklich praktiziert
und es werden stattdessen schon vorhandene Frameworks,
Interfaces oder ähnliches verwendet. Man spricht von sog.
"Middleware". Middleware läuft sozusagen über der
Anwendungsschicht
und
nutzt
Dienste
der
Anwendungsschicht. Es ist möglich diese Middleware in drei
grobe Bereiche zu unterteilen. Zum einen wäre hier die
"kommunikationsorientierte" Middleware, zum zweiten die
"anwendungsorientierte" Middleware und zuletzt die
"nachrichtenorientierte" Middleware.
A. Die drei Typen von Middleware
Zuerst eine kurze Beschreibung der Bereiche bevor
weiterführend einige Inhalte näher besprochen werden.
1) Kommunikationsorientierte Middleware
Bei kommunikationsorientierter Middleware liegt der
Schwerpunkt
auf
der
Abstraktion
der
transportschichtennahen
Netzwerkprogrammierung.
Beispiele sind hier "RPC" (Remote Procedure Call),
JavaRMI (Remote Method Invocation) oder auch
"Webservices".
a)
Remote Procedure Call
Ein Remote Procedure Call ist sinngemäß ein Aufruf einer
entfernten Prozedur. Diese Technik ermöglicht die
Interprozesskommunikation. Hierbei laufen die aufgerufenen
Funktionen in der Regel auf anderen Computern.
b)
Java Remote Method Invocation
JavaRMI ist der Aufruf einer Methode eines entfernten
Java-Objekts und realisiert die Java-eigene Art des Remote
Procedure Call. "Entfernt" bedeutet hierbei, dass sich das
Seminararbeit - Netzwerkprogrammierung
Objekt auf einer anderen Java Virtual Machine befinden
kann, die ihrerseits auf einem entfernten Rechner oder dem
lokalen Rechner laufen kann. Dabei sieht der Aufruf für das
aufrufende Objekt (bzw. dessen Programmierer) genauso aus
wie ein lokaler Aufruf. Es müssen jedoch besondere
Ausnahmen abgefangen werden, wie zum Beispiel ein
Verbindungsabbruch.
c)
Webservices
Webservices unterstützen die Zusammenarbeit zwischen
Anwendungsprogrammen,
die
auf
unterschiedlichen
Plattformen und/oder Frameworks betrieben werden. Ein
Webservice ist eine Software-Anwendung, die mit einem
Uniform Resource Indetifier (URI) eindeutig identifizierbar
ist und deren Schnittstelle als XML-Artefakt definiert,
beschrieben und gefunden werden kann. Er unterstützt die
direkte Interaktion mit anderen Software-Agenten unter
Verwendung XML-basierter Nachrichten durch den
Austausch über Protokolle der Internetprotokollfamilie.
2) Anwendungsorientierte Middleware
Anwendungsorientierte Middleware unterstützt neben der
Kommunikation vor allem verteilte Anwendungen, also
Programme, die auf mehreren Rechnern/Prozessoren
ablaufen. Solche Anwendungen entstehen zum Beispiel
durch
horizontale
Schnitte
durch
das
Softwareschichtenmodell. Die Aufgabe des Gesamtsystems
wird also auf einzelne Softwarekomponenten aufgeteilt, die
untereinander Informationen austauschen. Beispiele für
solche anwendungsorientierte Middleware sind allgemeine
Architekturen, wie "CORBA"(Common Object Request
Broker Architecture), "JEE"(Java Platform, Enterprise
Edition) oder die ".Net-Platform"
a)
Common Object Request Broker Architecture"
Die "Common Object Request Broker Architecture"
(CORBA) ist eine Spezifikation für eine objektorientierte
Middleware, deren Kern ein sog. Object Request Broker, der
ORB, bildet und die plattformübergreifende Protokolle und
Dienste definiert. CORBA-konforme Implementierungen
vereinfachen das Erstellen verteilter Anwendungen in
heterogenen Umgebungen, also Umgebungen in denen
mehrere
unterschiedliche
Softwaresysteme
zusammenarbeiten.
b)
Java Platform, Enterprise Edition
Die Java Plattform, Enterprise Edition ist eine
Spezifikation der Softwarearchitektur für die Ausführung
transaktionsbasierter, in Java programmierter Anwendungen.
Sie ist eine der großen Plattformen, die um den MiddlewareMarkt kämpft. Größter Konkurrent ist dabei die .NetPlatform von Microsoft.
Die Spezifikation dient dazu, einen allgemein akzeptierten
Rahmen zur Verfügung zu stellen, um auf dessen Basis aus
modularen
Komponenten
verteilte,
mehrschichtige
Anwendungen entwickeln zu können. Klar definierte
Schnittstellen zwischen Komponenten und Containern sollen
dafür sorgen, dass Softwarekomponenten unterschiedlicher
Hersteller vereinbar sind, wenn sie die Spezifikation
5
einhalten, und dass die verteilte Anwendung gut skalierbar
ist.
c)
.Net-Platform
Microsoft bietet mit der .Net-Plattform gleich vier
übergreifende Ansätze. Zum Einen eine moderne
Implementierung des neuen Industriestandards "XMLWebservices". Eine Struktur für verteile Programme, im
LAN, aber mit zunehmender Bedeutung auch für
nichtkommerzielle
Anwendungsgebiete
im
Internet.
Desweitern die "Windows Communication Foundation"
(WCF), die ".Net Remoting Services" und die ".Net
Enterprise Services". Letztere sollen eine Konkurrenztechnik
zur erfolgreichen Java Platform, Enterprise Edition sein.
Die Windows Communication Foundation fasst die
verschiedenen Kommunikationstechnologien "DCOM",
"Enterprise Services", "MSMQ", "WSE" und Webservices
unter
einer
einheitlichen
API
zusammen.
Das
Hauptanwendungsgebiet der WCF liegt in der Entwicklung
von "Service-orientierter Architekturen" (SOA).
3) Nachrichtenorientierte Middleware
Nachrichtenorientierte Middleware arbeitet nicht mit
Methoden- oder Funktionsaufrufen, sondern über den
Austausch
von
Nachrichten
(messages).
Das
Nachrichtenformat gibt hier die eingesetzte Middleware vor.
Eine nachrichtenorientierte Middleware kann sowohl
synchron als auch asynchron arbeiten. Bei einer asynchronen
Variante wird eine Warteschlange verwendet, in die der
message-Produzent seine Nachrichten stellt. Ein Konsument
kann die Nachrichten dann konsumieren. Vorteile sind unter
anderem
die
vollständige
Entkopplung
von
Nachrichtensender und -empfänger und dass Anwendungen
auch weiterarbeiten können, wenn Teilkomponenten
ausgefallen sind. Eine Beispiel-Architektur wäre der "Java
Message Service" (JMS).
a)
Java Message Service
Der Java Message Service ist eine durch die Java
Community Process genormte API für die Ansteuerung einer
nachrichtenorientierten Middleware zum Senden und
Empfangen von Nachrichten aus einem Client heraus, der in
der Programmiersprache Java geschrieben ist. JMS
ermöglicht verteilte Kommunikation, welche lose gekoppelt,
verlässlich und asynchron läuft. Für die Anwendung braucht
man einen Provider, der die API umsetzt und somit den
Dienst bereitstellt. Dafür gibt es sowohl kommerzielle
Produkte, als auch Open-Source-Projekte. Beispiele wären
hier der kommerzielle "Sun GlassFish Message Queue" von
Sun Microsystems, der kommerzielle "WebsphereMQ" von
IBM oder das Open-Source-Projekt "OpenJMS". Zu
unterscheiden ist hier zwischen zwei Betriebsmodi.
"Eigenständig" und "eingebettet". Wobei "eigenständig"
bedeutet, dass der Provider als eigenständiger Prozess läuft
und die Kommunikation beispielsweise über TCP/IP
stattfindet. "Eingebettet" bedeutet der Provider läuft in der
selben Java Virtual Machine. Ein Vorteil ist hier die
schnellere Datenübertragung.
Seminararbeit - Netzwerkprogrammierung
B. Detailliertere Vorstellung einiger Technologien
Abschließend zu dem Thema Middleware werden
nachfolgend
noch
zwei
vorangegangen
erwähnte
Technologien genauer erläutert um den Umgang aus Sicht
des Programmierers darzustellen.
1) Common Object Request Broker Architecture
Die CORBA-Spezifikation ist an keine bestimmte
Programmiersprache gebunden. Vielmehr sind die
Softwarehersteller oder Communities aufgerufen, auf der
Grundlage dieser Spezifikation eigene Object-RequestBroker-Implementierungen zu erstellen.
Ein Object-Request-Broker (ORB) ist ein Vermittler, der
die Kommunikation von Objekten innerhalb eines verteilten
Systems ermöglicht. Er ist sowohl betriebssystem- als auch
programmiersprachenunabhängig. Die Aufgaben des ORBs
bestehen unter anderem darin, Daten zu senden bzw. zu
empfangen. Da Datenobjekte auf Quell- und Zielsystem
unterschiedliche Darstellungen besitzen können, sorgt sog.
"Marshalling" für die Umwandlung in ein eindeutiges
Übertragungsformat.
Unter Marshalling versteht man das Umwandeln von
Daten in ein Format, das die Übermittlung an andere
Prozesse ermöglicht. Auf der Empfängerseite werden aus
diesem Format die Daten in ihrer ursprünglichen Struktur
wiederhergestellt, was als "Unmarshalling" bezeichnet wird.
Eine in der Praxis oft verwendete Form des Marshallings
ist die Technik Objekte in das XML-Format umzuwandeln
und auf Empfängerseite wieder als Objekt im Speicher
aufzubauen.
Wie entsteht nun eine CORBA-Anwendung? Der erste
Schritt besteht üblicherweise in der Festlegung der
Objektschnittstellen auf Basis einer "Interface Definition
Language"-Spezifikation.
Diese "Schnittstellendefinitionssprache" ermöglicht es,
Objekte und die auf sie anwendbaren Methoden mitsamt den
möglichen Parametern und Datentypen zu beschreiben, ohne
dabei
die
Eigenschaften
einer
bestimmten
Programmiersprache zu verwenden. Diese Sprache dient rein
der Beschreibung, nicht jedoch der Formulierung von
Algorithmen.
Ist die IDL-Spezifikation festgelegt, können Entwickler
unabhängig voneinander den Client und den Server in ihrer
bevorzugten Programmiersprache entwickeln. Liegen diese
Implementierungen vor, folgt deren Übersetzung zu einer
ausführbaren Datei.
In einem Zwischenschritt werden aus der IDLSpezifikation mit Hilfe eines sog. "IDL-Compilers" die sog.
"Stellvertreterobjekte" generiert.
Auf Clientseite existiert ein Stellvertreter des Servers.
Dieser Stellvertreter bietet das gleiche API wie der Server
selbst an. Seine Aufgabe besteht unter anderem darin, alle
aktuellen Parameter über einen Kommunikationskanal in den
entfernten Adressraum des Servers zu übertragen. Dort
nimmt ein Stellvertreter des Clients die Daten entgegen und
führt den eigentlichen Aufruf auf dem Server aus. Diese
Stellvertreterobjekte sind von außen nicht von ihren
"Originalen" unterscheidbar. Der Stellvertreter des Servers
im Adressraum des Clients wird "Stub" genannt und der
6
Stellvertreter des Clients im Adressraum des Servers wird
"Skeleton" genannt.
Für die Generierung der Stellvertreterobjekte muss der
IDL-Compiler des jeweiligen ORB verwendet werden. Der
CORBA-Standard
schreibt
nicht
vor,
dass
die
Stellvertreterobjekte portabel über verschiedene ORBImplementierungen sein müssen.
Die ausführbare Programmdatei einer CORBAAnwendung besteht somit aus drei Komponenten:
1. Der anwendungsspezifische Teil wird vom Entwickler
beigesteuert und implementiert die Anwendungslogik.
2. Die Stellvertreterobjekte werden mit Hilfe eines IDLCompilers automatisch aus einer IDL-Spezifikation
generiert.
3. Die generische Funktionalität des ORB-Kerns, die in Form
einer Programmbibliothek zur Anwendung gebunden wird.
2) Webservices
Client-Programme senden im Allgemeinen Anfragen an
einen Webservice, und dieser antwortet mit der gewünschten
Information. Es wird daher gelegentlich behauptet, dass
Webservices für Rechner das sind, was Webseiten für den
Menschen sind. Auch wenn das nur einen Teil der
Möglichkeiten des Webservices beschreibt, ist dieser
Vergleich durchaus zutreffend. Webservices sind nicht für
menschliche Benutzer gedacht, sondern für Softwaresysteme,
die automatisiert Daten austauschen und/oder Funktionen auf
entfernten Rechnern aufrufen.
Die grundlegenden Komponenten einer Serviceorientierten
Architektur
sind:
Kommunikation,
Dienstbeschreibung und Verzeichnisdienst.
In
einer
Webservice-Architektur
werden
diese
Komponenten mithilfe der folgenden Spezifikationen
beschrieben:
-SOAP beschreibt das XML-basierte Nachrichtenformat der
Kommunikation und dessen Einbettung in ein
Transportprotokoll.
-WSDL
ist
eine
ebenfalls
XML-basierte
Metasprache,
um
Webservices
(Dienste)
zu
beschreiben.
-UDDI beschreibt einen Verzeichnisdienst für Webservices.
UDDI spezifiziert eine standardisierte Verzeichnisstruktur
für die Verwaltung von Webservice-Metadaten. Zu den
Metadaten zählen allgemeine Anforderungen, WebserviceEigenschaften oder die benötigten Informationen zum
Auffinden von Webservices.
Abbildung 4 Webservice-Architektur
Seminararbeit - Netzwerkprogrammierung
In vorangegangener Abbildung vier ist der Zusammenhang
dieser Komponenten deutlich gemacht. Deutlich zu erkennen
ist, wie der Client oder Servicekonsument über WSDL den
Webservice in einer UDDI-Verzeichnisstruktur lokalisiert
und anschließend über SOAP mit ihm kommuniziert
Nachfolgend werden diese drei Komponenten erläutert.
a)
Simple Object Access Protocol
Das "Simple Object Access Protocol" (SOAP) ist ein
Protokoll zum Austausch XML-basierter Nachrichten über
ein Computernetzwerk. Es regelt, wie Daten in der Nachricht
abzubilden und zu interpretieren sind und gibt eine
Konvention für entfernte Prozeduraufrufe mittels SOAPNachrichten vor. SOAP macht keine Vorschriften zur
Semantik applikationsspezifischer Daten, die versendet
werden sollen. Es stellt lediglich ein Framework zur
Verfügung. Zum Senden der Nachrichten können beliebige
Transportprotokolle verwendet werden, wie FTP, SMTP,
HTTP oder auch JMS. In der Praxis wird jedoch meist auf
HTTP zurückgegriffen.
Der Aufbau einer SOAP-Nachricht sieht wie folgt aus:
Eine SOAP-Nachricht ist ein XML-Dokument, das aus drei
Teilen besteht. "SOAP Envelope", "SOAP Header" und
"SOAP Body".
(1)
SOAP Envelope
Der SOAP Envelope ist vergleichbar mit einem
Briefumschlag. Der Envelope bildet das Wurzelelement des
XML-Dokuments. In ihm sind die anderen beiden Teile der
SOAP-Nachricht gekapselt. Zu Veranschaulichung hier die
Struktur:
<env: Envelope
xmlns:env="http://www.w3.org/2003/05/soapenvelope">
<!- SOAP Header -->
<!- SOAP Body -->
</env:Envelope>
Mit der Wahl des URI http://www.w3.org/2003/05/soapenvelope wird festgelegt, welche Version der SOAPSpezifikation in der konkreten SOAP-Nachricht verwendet
wird.
(2)
7
<env:Header>
m:authentication xmlns:m="http://www.soabuch.de/Annahme
env:role="http://www.soa-buch.de/Admin"
env:mustUnderstand="true">
<m:security-token>
afmaafdjioq230923
</m:secutiy-token>
</authentication>
<n:authorization
xmlns:n="http://www.soa-buch.de/Annahme"
env:role="http://www.soa-buch.de/Admin"
env:mustUnderstand="true">
<n:rights>
110101101
</n:rights>
</authorization>
</env:Header>
In diesem Beispiel besteht der SOAP-Header aus
sicherheitsrelevanten Informationen. Im ersten Kindelement
"authentication" wird Code übertragen, der den Absender
identifiziert ("security token"). Das zweite Kindelement
"authorization" enthält kodierte Informationen über die
Rechte des Absenders.
Das Übertragen von Sicherheitsinformationen ist ein
typisches Anwendungsgebiet für den SOAP-Header.
(3)
SOAP Body
Das zweite Kindelement einer SOAP-Nachricht ist der
SOAP-Body. Dieser ist zwingend erforderlich und muss auch
immer genau mit "Body" bezeichnet werden. Wie alle XMLElemente unterscheiden auch die Elementbezeichner der
SOAP-Spezifikation
Großund
Kleinschreibung.
Nachfolgend ist der Aufbau des SOAP-Body einer SOAPNachricht dargestellt:
<env:Body>
<m:nutzlast xmlns:m="http://www.soa-buch.de/">
<m:msg> Hier steht die eigentliche
Information die transportiert werden
soll!!!
</m:msg>
</m:nutzlast>
</env:Body>
SOAP Header
Der erste Teil einer SOAP-Nachricht ist der SOAPHeader. Ein SOAP-Header kann genau einmal in einer
SOAP-Nachricht vorkommen, und zwar ausschließlich als
erstes Kindelement des SOAP-Envelopes. Der Inhalt des
SOAP-Headers ist nicht in der SOAP-Spezifikation definiert,
diese stellt lediglich die Möglichkeit zur Verfügung, den
Header durch weitere Informationen anzureichern. Mögliche
Inhalte des SOAP-Headers sind üblicherweise begleitende
Spezifikationen. Zur Veranschaulichung hier ein Beispiel zur
Struktur eines SOAP-Headers:
Der SOAP-Body enthält die zu übertragende Information,
das heißt die eigentlichen Nutzdaten der Nachricht. Wie in
den Beispielen zu sehen ist, wird in einer SOAP-Nachricht
intensiver Gebrauch von XML-Namensräumen gemacht. Für
den Inhalt dieses SOAP-Body ist dies jedoch nicht zwingend
notwendig. Für komplizierter aufgebaute Nachrichten ist dies
jedoch unabdingbar, da sich ansonsten die Struktur kaum
noch eindeutig formulieren ließe.
Der Inhalt des SOAP-Body selbst muss ein wohl
geformtes XML-Dokument darstellen - mit Ausnahme des
Prologs, der an dieser Stelle nicht vorhanden sein darf. Der
Seminararbeit - Netzwerkprogrammierung
eigentliche Inhalt wird hier nicht näher spezifiziert, da dieser
anwendungsbezogen variiert.
Mit SOAP lassen sich alle Informationen verschicken, die
sich als XML-Dokument darstellen lassen. Beispiele dafür
sind HTML-Seiten, PDF-Dokumente, Verträge und
Bestellformulare. Problematisch wird jedoch der Versand
binärer Daten, da diese nicht unmittelbar als XML dargestellt
werden können.
8
(1)
(2)
b)
WebService Description Language
Die WSDL ist eine XML-Metasprache zur Beschreibung
von Webservice-Schnittstellen. Es werden im wesentlichen
Operationen definiert, die von außen zugänglich sind, sowie
Parameter und Rückgabewerte dieser Operationen.
Webservices werden in der WSDL aus zwei Blickwinkeln
beschrieben: abstrakt auf der Ebene der Funktionalität und
konkret auf der Ebene der technischen Details. Hierzu wird
die Beschreibung der Funktionalität, die ein Webservice
anbietet, von den technischen Details über den Ort und die
Art und Weise, wie ein Dienst angeboten wird, getrennt. Die
Konstrukte der WSDL ermöglichen es hierbei, einzelne
Bestandteile der abstrakten oder konkreten Beschreibung im
anderen Kontext wiederzuverwenden.
Für die Beschreibung eines Dienstes stehen der WSDL
folgende Komponenten zur Verfügung: "Operation",
"Message Exchange Pattern" und "Interface" für die
abstrakte Beschreibung sowie "Binding", "Endpoint" und
"Service" für die konkrete Beschreibung.
Im Allgemeinen interessante Komponenten sind hierbei:
"Interface", welche die abstrakte Funktionalität selbst
beschreibt, "Binding", welche beschreibt, wie der Dienst
aufgerufen wird, und "Service", welche beschreibt, wo der
Dienst sich befindet.
Die Anordnung der Komponenten in der WSDL-Datei ist
an keine bestimmte Reihenfolge gebunden. Die einzige
Ausnahme ist das "Description"-Element, das als
Wurzelelement des XML-Dokuments an erster Stelle im
Dokument steht.
c)
Universal Description Discovery & Integration
Das "Universal Description Discovery & Integration"Prinzip ermöglicht, stark vereinfacht ausgedrückt, das
Veröffentlichen und Auffinden eines Webservices im Web.
Dazu stellt der Anbieter die WSDL-Beschreibung seines
Dienstes in das UDDI-Verzeichnis (eine Datenbank). Ein
potentieller Nutzer kann diesen Dienst im UDDI-Verzeichnis
finden und die Schnittstellenbeschreibung in Form eines
WSDL-Dokuments anfordern.
Einen vereinfachten Zugang zum Prinzip von UDDI erhält
man durch den Vergleich mit der Funktionsweise von
Telefonbüchern. Ein Telefonbuch entspricht dabei einer der
vier
Haupttabellen
der
UDDI-Datenbank.
Diese
Haupttabellen werden gemäß des Sprachgebrauchs in
Datenbanken als "Entitäten" bezeichnet".
"White Pages"
Mithilfe der White Pages können Unternehmen
Informationen über sich selbst bereitstellen. Über diese
Informationen kann ein potentieller Nutzer eine erste
Entscheidung fällen, ob der den Dienst dieses Unternehmens
nutzen möchte.
"Yellow Pages"
Sollte der Name des Unternehmens nicht bekannt sein, so
kann der Nutzer überprüfen, in welche Kategorie ein
potentieller Dienstanbieter gehört. Mit Hilfe dieser Entität
erhält der Nutzer die Dienste aller Anbieter nach Branchen
gruppiert.
(3)
"Green Pages"
Mit der Entität der Green Pages können Beschreibungen
zu jedem einzelnen Dienst hinterlegt werden. Sollte ein
Nutzer also wissen, welchen Dienst er benötigt, aber keinen
entsprechenden Anbieter kennen und/oder nicht weis zu
welcher Branche besagter Anbieter gehört, kann er jeden
Service von Hand durchsuchen.
(4)
"Service Type Registration"
Während die Green Pages primär für den menschlichen
Gebrauch bestimmt sind, finden sich in der Service Type
Registration die Informationen in maschinenlesbarer Form.
Beide Entitäten verweisen aufeinander.
LITERATUR
[1] Tanenbaum, Andrew S.: Computernetzwerke. Prentice
Hall, Pearson Studium, 2003, S. 1-605
[2] Peterson, Larry L.; Davie, Bruce S.: Computernetze.
dpunkt.verlag, 2003, S 232-382
[3] Kühnel, Andreas: Visual C# 2010 - Das umfassende
Handbuch. Galileo Computing, 2010, S. 29-44, 703-711
[4] Puder, Arno; Römer, Kay: Middleware für verteilte
Systeme - Konzepte und Implementierung anhand der
CORBA Plattform MICO. dpunkt.verlag, 2001, S-37-46
[5] Makofske, David B.; Donahoo, Michael J.; Calvert,
Kenneth L.: TCP/IP Sockets in C# - Practical Guide for
Programmers. ELSEVIER, 2004, S.6-56
[6] Melzer, Ingo: Service-orientierte Architekturen mit Web
Services. Spektrum, 2010, S.62-117
[8] Ullenboom, Christian: Java ist auch eine Insel´- Das
umfassende Handbuch. Galileo Computing, 2009,
S.1145-1230
[9] Weerawarana, Sanjiva; Curbera, Francisco; Leymann,
Frank; Storey, Tony; Ferguson, Donald F.: WebServices
Platform Architecture. Prentice Hall, 2008,S.1-171
[9] Bildquelle: http://holger.euhm.de/Uni/DplAr/img66.gif
[10] Bildquelle: http://www.heftrich.de/gloss/images
/tcpip_dod1.gif
[11] Bildquelle: http://upload.wikimedia.org/wikipedia/de/9/
95/Webservice.png
[12] Bildquelle: http://www.hsgkl.de/faecher/inf/netze
/schicht/tanenbaum36.gif