Version vom 13. Jänner 2022, 07:32 Uhr

Grundlagen Verteilter Systeme

Ziele der Lektion

Erkennen, was über die ”bloße“ Verkabelung von Rechnern hinausgeht
Erfahren, welchen Schwerpunkt Middleware dabei besitzt
Verteilte Systeme aus Sicht der Systementwicklung beleuchten
Ermöglichen, ein verteiltes System zu entwickeln
Tieferes Verständnis für verteilte Systeme entwickeln
Schwierigkeiten bei der Replikation von Systemen erkennen

Einführung, Konzepte und Technologien

Nach Coulouris et. Al., sozusagen nach der Bibel der Verteilten Systeme kann ein solches definiert werden als:

„Ein Verteiltes System ist ein System in dem (Hardware oder Software) Komponenten in einem Computernetzwerk Ihre Aktionen kommunizieren und koordinieren, einfach durch den Austausch von Nachrichten.“

- Coulouris, Dollimore, Kindberg ^[1]

oder etwas weniger formell und eher pessimistisch ausgedrückt:

Eine verteiltes System ist eines in dem ich keinerlei Arbeit zustande bringe, weil irgendein mir unbekannter Rechner von dem ich nie gehört habe abgestürzt ist.“

- Leslie Lamport ^[2]

Verteilte Systeme ergeben sich aus der Notwendigkeit Rechner an unterschiedlichen Standorten miteinender zu verbinden; sie können eingeführt werden, um die Leistung (Performance) eines Server Systems zu erhöhen (siehe Cluster Computing) und sie erfüllen oftmals den Zweck, meist auch auf Server Systemen, Die Fehlertoleranz mit Hilfe von unterschiedlichen Backup Systemen zu gewährleisten.

Verteilte Systeme charakterisieren sich durch parallele Aktivitäten, indem autonome Komponenten gleichzeitig unterschiedliche Aufgaben abarbeiten. Die Kommunikation der einzelnen Komponenten findet statt, indem sie Nachrichten miteinander austauschen. Verteilte Systeme unterscheiden sich somit von Shared Memory Architekturen weil sie auf keinen gemeinsam benutzten Speicher zugreifen (können). Ein Einsatzgebiet von Verteilten Systemen ist auch die gemeinsame Nutzung von Ressourcen oder Geräten wie Drucker, Scanner, Telefonanlagen oder andere.

Dabei besitzt kein einziger Prozess in so einem System das Wissen über den globalen Status des Gesamtsystems. Es gibt auch keine gemeinsamen Zeitgeber, somit nur begrenzte Möglichkeiten die Taktgeber der einzelnen Prozesse zu synchronisieren.

Man unterscheidet bei verteilten Architekturen zwischen Multiprozessor und Multicomputer Systemen. Multiprozessor Systeme besitzen einen gemeinsamen Speicher, wie z.B. die z.Zt. aktuellen dual oder Quad Core Prozessor Architekturen. Multicomputer Systeme besitzen keinen gemeinsamen Adressraum (Speicher) und sind homogen in Hard- und Software aufeinander abgestimmt. Dies können „Massively Parallel Prozessoren (MPP)“ Systeme oder Workstation-Cluster sein. Solche Systeme führen dem allseits bekannten Szenario für Betriebssysteme die in verteilter Umgebung Einsatz finden.

Die größte Bedeutung ist allerdings den heterogenen Multicomputer Systemen zuzuordnen. Diese sollen auch im Rahmen dieses Studienheftes betrachtet werden. Dabei müssen in Bezug auf die Computerpraxis oft folgende Fragen beantwortet werden:

Was wenn komplett unterschiedliche Hardware verwendet wird, z.B. Intel CISC vs. PowerPC RISC Chips von IBM?

Wie kommunizieren Programme auf unterschiedlichen Betriebssystemen miteinander?
Was geschieht, wenn die Daten verschiedener Systeme unterschiedlich repräsentiert werden, z.B. EBCDIC vs. ASCII vs. UTF8 oder LATIN Zeichensätze?
Was geschieht oder muss geschehen, wenn Sie Ihr Büro in die Südsee verlegen?
Wie behalten sie die Übersicht über die vielen Aufgaben die auf einer Anzahl von Rechnern laufen?
Was, wenn zwei Ihrer Kunden gleichzeitig das selbe Produkt bestellen wollen (Concurrency oder Gleichzeitigkeit)?
Was, wenn die Datenbank mit den Informationen zu Ihrem Lagerbestand abstürzt?
Was, wenn jemand den Stecker zieht während sie im Internet eine Bestellung aufgeben?
Was tun, wen jemand in Ihre Server eindringen will?
Was, wenn der Kunde behauptet, er hätte gar keine Bestellung aufgegeben?
Was, wenn Ihr Laden so berühmt wird, dass Millionen von Kunden zur gleichen Zeit auf Ihre Webseite zugreifen?

All dies lässt sich zu den Herausforderungen der Heterogenität, transparenten Verteilung, Fehlertoleranz, Skalierbarkeit, Gleichläufigkeit, Offenheit und Sicherheit zusammenfassen. Diese müssen von verteilten Systemen im täglichen Gebrauch gemeistert werden.

Kommunikation in Verteilten Systemen

Gegeben sei das Beispiel eines Onlineshops entsprechend dem UML Usecase Diagramm in Abb. 1. Der Benutzer sich (1) das Inventar (alle Waren ansehen), (2) nach bestimmten Waren suchen und (3) Waren bestellen.

Abb. 1. Beispiel eines Use Cases: Kundenzugriff auf Server

Dabei gilt, dass der Online-Store Computer das „Shop-Programm“ und der Kunde das „Shopping-Programm“ einsetzt. Beide Computer sind über ein Netzwerk miteinander verbunden. Die unterschiedlichen Prozesse der Computer tauschen dabei folgende Nachrichten aus:

„Sende mir die Warenliste aller Waren“

„Hier ist die Liste der Waren: ...“
„Ich möchte diese bestimmte Ware bestellen“
„Die Bestellung der Ware wurde angenommen“

Abb. 2. Interconnected NETworks

Dabei müssen Sender und Empfänger der Nachrichten sich über bestimmte Dinge einig werden. Dies sind z.B.: Die Art und Weise wie die Nachrichten transportiert werden, Welcher Spannungswert für 1 oder 0 verwendet werden soll, welches das letzte Bit sein soll und was im Fall von Fehlern geschehen muss. Darüber hinaus muss klar sein, welche Bedeutung die Bits haben, also handelt es sich um Text oder Binärdaten, welcher Zeichensatz soll gelten oder gibt es andere speziell zugeschneiderte Formate. Viele andere Vereinbarungen müssen auch noch auf anderer Ebene getroffen werden. Die Summe dieser Vereinbarungen bezeichnet man als Protokoll.

Ein Protokoll ist eine bestimmte definierte Menge von Konventionen die es Computern erlauben Information auszutauschen. Dabei müssen sowohl Syntax und Semantik vereinbart werden. Gemeinsame Regeln müssen eingeführt werden, um die Interaktion zwischen den Computern zu Steuern und Administrieren und es müssen die Formate der auszutauschenden Daten bestimmt werden.

Dabei kann nicht davon ausgegangen werden, dass alle beteiligten Rechner am gleichen Netz angeschlossen sind, viel mehr kommunizieren diese über INTERconnected NETworks, also Computer sind an Netze angeschlossen die wiederum über ein übergeordnetes Netz miteinander verbunden werden. Dadurch entstehen komplexe Interaktionen zwischen und mit verschiedenen Kommunikationsprotokollen (siehe Abb. 2)

Zur Bewältigung dieser Komplexität gibt es mehrere Strategien. Eine Einteilung des Systems in Sub-Systeme (nach dem Motto „Devide et conquere“) kann vorgenommen werden. Dabei werden die zu entwickelnden Komponenten kleiner und können anderweitig wiederverwertet werden. Das System wird leichter wartbar und kann besser portiert werden.

Layered Architektur

Die Einteilung des Systems kann auch in Layern/Leveln und Partitionen vorgenommen werden. Dabei baut ein Layer auf den anderen auf und unterschiedliche Partitionierung eines Layers dient zur Behandlung unterschiedlicher Funktionalitäten.

Wie zu sehen in Abb. 3 werden Layer übereinander gestapelt und mit wohl definierten Schnittstellen (Interfaces) miteinander verbunden. Dabei bietet ein Layer n Services für den darüberliegenden Layer n+1 an indem er seinerseits Services des darunterliegenden Layers n-1 annimmt.

Die Schnittstellen (Interfaces) definieren dabei die Syntax des Service und beinhalten die Namen der zur Verfügung stehenden Funktionen die Namen und Typen von Parametern. Die Typen der Ergebniswerte und eine Definition der möglichen Ausnahmen, ähnlich dem Aufruf einer Funktion oder Methode in einem Programm. Ein wichtiger Aspekt, von dem häufig Gebrauch gemacht wird, ist dabei die Möglichkeit, dass ein bestimmtes Interface mehrmals und auf verschiedne Weise implementiert werden kann. So können logisch identische Funktionalitäten in verschieden ausgeprägtem Umfeld gleichermaßen bestimmt werden. So kann z.B. ein Layer 2 der Daten paketiert mit beliebigen Layer 1 Komponenten zusammenarbeiten, gleich ob diese die Pakete dann über Luft oder Kupfer übertragen.

Die wohl berühmteste Layer Architektur auf dem Gebiet der Computer-Kommunikation ist das sog. ISO/OSI Referenzenmodell. ISO = „International Standard Organization“ und OSI = „Open Systems Interconnect“ haben eine geschichtete Architektur für Netzwerk Protokolle verabschiedet, den sog. „Protokoll-Stack“ (Protokollstapel?). Beim Senden wird dabei der Stapel der einzelnen Layer (Schichten) von oben nach unten durchgegeben, wobei der obere Layer die Daten verändert und/oder erweitert und and den darunter liegenden Layer weitergibt.

ISO/OSI Layer

ATM hier in den 2. Layer zu geben ist eher spekulativ, ursprünglich ware es eher ein Paketnetzwerk auf Layer 1, da es sich wuasio als Draht dargestellt hat, aber wer kümmert sich heute noch um ATM?

Die unterste Schicht versendet dann die Nachricht als physische (elektromagnetische) Signale. Beim Empfang wird der Stapel in umgekehrter Reihenfolge durchlaufen. Die Signale werden vom untersten Layer aufgegriffen und dann Layer für Layer nach oben weitergegeben. Dabei kommunizieren zwei identische Layer auf unterschiedlichen Computern mit demselben Protokoll. Über alle Layer hinweg entsteht somit eine Verschachtelung von Layer- spezifischen Protokollen. Alle sieben Layer sind in Abb. 4 zu sehen.

Die Layer/Schichten im einzelnen:

Physical Layer: Zur physikalischen Übertragung der Bits und Bytes, elektronische Signale
Data Link Layer: Zum Transport zwischen zwei Punkten im Netzwerk, Media Access Control Prüfsummen Flow-Control etc.
Network Layer: End-to-End Datenübertragung zwischen Computern über alle verbundenen Netzwerke, Packet-Forwarding und Routing

Transport Layer: End-to-End Datenübertragung zwischen einzelnen Prozessen auf verschiedenen Computern, Ports, Flow-Control
Session Layer: Stellt eine virtuelle Verbindung zwischen Prozessen her, Z.B. Auf- und Abbau von Verbindungen
Presentation Layer: Definiert, wie die gesendeten oder empfangenen Daten interpretiert werden sollen, d.h. was die 1-en und 0-en bedeuten und in welcher Reihenfolge sie zu lesen sind
Application Layer: Die Verbindung zwischen zwei Applikationen, z.B. File Transfer nach OSI etc.

Im Internet hat sich allerdings ein vereinfachtes Modell durchgesetzt, eine vier-schichten Architektur die as ISO/OSI Model vereinfacht, siehe

Die Layer sind:

Hosts-to-Network oder PHY Layer: Physikalische Datenübertragung zwischen zwei Stationen
Internet oder IP Layer: End-to-End Datenübertragung zwischen Computern über alle Netzwerke hinweg
Transport Layer: End-to-End Übertragung zwischen einzelnen Prozessen auf den Computern, z.B. Vom Browser am Client zu Port 80 auf dem Server
Application Layer: Appliklationsspeziefische Protokolle wie HTTP oder FTP, SSH etc.

Das ISO/OSI Modell ist definiert und verabschiedet von einem anerkannten Standardgremium. In dem Standard hat das Modell an sich immer Vorrang vor den Protokollen, welche sich in der Regel auf einen bestimmten Layer beziehen und nicht Layer-überschreitend angewendet werden. Ein Layer kann mehrere Protokolle beheimaten. Das Modell ist universell einsetzbar und ist daher sehr Komplex in der Implementierung. Außerdem wurde es vielleicht zum falschen Zeitpunkt, also zu früh, verabschiedet.

Die dargestellten Layer, wie sie im Internet Verwendung finden, sind aus der Erfahrung und der aktuellen Nutzung der Protokolle heraus gewachsen. Vice versa zum ISO/OSI Modell stehen hier die Protokolle im Mittelpunkt und nicht die Kommunikationsschichten (Layer). Das Internet Layer-Modell ist einfach gehalten und daher robust; es existieren viele gut funktionierende Applikationen.

Auch wenn die meisten Applikationen basierend auf dem Internet Modell implementiert werden, so wird doch immer wieder das ISO(OSI Modell herangezogen, um Kommunikationsverfahren zu beschreiben. Man spricht und plant Kommunikation indem man die ISO/OSI Layer referenziert, wenn es dann zur Implementierung kommt werden dann diese Modelle auf das Internet-Kommunikationsmodell reduziert.

Dabei werden Layer 1 und 2 des ISO/OSI Modells, also Physical und Datalink Layer auf den Layer 1 des Internet Modells also auf den Host-to-Network Layer abgebildet. Der Layer 3 des ISO(OSI Modells, also der Network Layer, wird auf Layer 2 im Internet Modell abgebildet, den Internet Layer. Die beiden Transport Layer werden 1:1 zugeordnet, also Layer 4 im ISO/OSI Modell auf Layer 3 im Internet. Die restlichen Layer im ISO/OSI Modell werden im Internet zu dem Application Layer zusammengefasst.

Wie werden nun aber die Daten, auf dem Netzwerk Layer (Layer 3 im OSI Modell) übertragen? Hierbei gibt es zwei grundverschiedene Ansätze, das sog. „Circuit Switching“ (Leitungsvermittlung), also die Leitungsvermittlung und das „Packet Switching“ also die Paketvermittlung.

Die Leitungsvermittlung fand Ihre Anwendungsgebiete bisher immer in der Sprachkommunikation und wird vor allem in der Telekommunikation angewandt. Auch heute in den Zeiten von SIP und IMS wird z.B. die Sprache in einem modernen Mobilfunknetz bis zur Basisstation immer noch leitungsvermittelt (im RAN). Bei der Leitungsvermittlung gibt es eine fest zugeordnete Leitung (entweder einen physikalischen Draht, oder einen fest reservierten Zeitschlitz im Backbone Netzwerk) für eine Kommunikationsverbindung. Ein dedizierter Aufbau und Abbau der Verbindung ist notwendig. Die Leitungsvermittlung eignet sich besonders gut für Echtzeit-Datenverkehr wie Sprach oder Video Übertragung. Die Übertragung ist zuverlässig und von hoher Qualität, kann aber Ressourcen verschwenden, da z.B. Leitungen in beide Richtungen fix reserviert wurden, unabhängig davon, ob nun gerade gesprochen wird oder ob sich das Bild eines Videos nun verändert oder nicht.

Circuit Switching

Die Paketvermittlung ist eine Erfindung aus der Welt de Internets und geht auf das Amerikanische Verteidigungsministerium und dessen DARPA Net zurück. Ein sehr interessanter geschichtlicher Hintergrund, auf den hier aber nicht weiter eingegangen werden kann. Im Zentrum dieses Vermittlungsverfahrens steht die Datenübertragung bei der die Datenströme in diskrete Teilstücke eingeteilt und dann auf den Weg zum Empfänger geschickt werden. Dies sind die sog. Datenpakete nach denen dieses Verfahren Ihren Namen bekommen hat. Die Pakete werden dabei unabhängig voneinander, nach dem „store-and-forward“ Prinzip über mehrere Konten hinweg durch das Netzwerk transportiert (sie werden „geroutet“). Der ursprüngliche Datenstrom mit seiner Information in richtiger Reihenfolge wird dann beim Empfänger aufgrund von Zusatzdaten, die den einzelnen Paketen angefügt wurden, wieder rekonstruiert. Anders als in der Leitungsvermittlung kann hier die Nachricht Ihr Ziel über mehrere Wege erreichen. Und im Falle eine Übertragungspause werden auch keine Ressourcen benötigt.

Vorteile der Leitungsvermittlung sind eine fixe Bandbreite und somit garantierter Kapazität und niedrige Signalverzögerungen und Verzögerungsvariation. Als Nachteile können extra Overhead durch Verbindungsauf- und Abbau und die Verschwendung von Ressourcen bei geringer Nutzung genannt werden.

Vorteile der Paketvermittlung sind die effiziente Ausnützung von Ressourcen, die hohe Flexibilität bei Übertragungsweg und Übertragungsart und die Tatsache, dass auf Netzwerk-Layer Ebene kein Setup und Teardown der Verbindung notwendig ist. Ein wesentlicher Nachteil ist die fehlende Garantie über geringe Signalverzögerungen und effektiver Bandbreite, also die wichtigsten Quality of Service Parameter.

Verbindungsorientierte Übertragung

Auf dem Transport Layer unterscheidet man zwischen „Connection-oriented“ (Verbindungsorientiert), also verbindungsorientierter und „connectionless“, also verbindungsloser Kommunikation. Verbindungsorientierte Kommunikation gewährleistet eine (nahezu) fehlerfreie Kommunikation und garantiert die korrekte Reihenfolge der Daten für den der das jeweilige Transport Protokolle verwendet. Weiters wird Flusskontrolle durchgeführt und Datenverlust oder Duplizierung sind ausgeschlossen. Das TCP (Transmission Control Protocol) Ist dafür das wohl bekannteste Beispiel.

Verbindungslose Protokolle verschicken nach bestem Vermögen sogenannte Datagramme, das sind Datenpakete die für sich abgeschlossen und ohne Zusammenhang mit anderen Paketen losgeschickt werden. Dabei gilt die Prämisse von „Abgeschickt ist gleich Angekommen“. Pakete die verlorengegangen sind werden nicht erneut gesendet. Diese Datagramme kann man am besten mit Postkarten vergleichen. Das Berühmteste Beispiel dafür ist das UDP (User Datagram Protocol) Protokoll. Es wird immer dann eingesetzt wenn Daten schnell und mit geringer Verzögerung übertragen werden müssen, wobei die darüberliegenden Applikationen auf das ein oder andere verlorengegangene Datenpaket verzichten können. UDP stellt z.B. die Basis von RTP (Realtime Transmission Protocol) dar welches zur Übertragung in Echtzeit (z.B. VOIP oder Video Streaming) verwendet wird. Diese Übertragungprotokolle haben nichts mit den angewandten Kodierungsverfahren wie MPEG2 oder H.264 zu tun.

Verbindungslose Übertragung

Auf der Application-Layer Ebene ist das wohl bekannteste Protokoll HTTP, also Hypertext Transfer Protokoll, welches für World Wide Web implementiert wurde. Es wurde definiert unter IETF RFC 1945 und RFC 2616 (siehe www.ietf.org). Es ist ein „stateless“ Protokoll, also zwischen zwei gesendeten Nachrichten besteht kein Zusammenhang und basiert auf dem Request/Response, also dem Frage/Antwort Schema.

HTTP steht auf allen Plattformen zur Verfügung, wird oft auch schon von kleinen Geräten wie 4-Port Routern oder ähnliches zur Konfigurationsanbindung verwendet. Das Protokoll ist sehr einfach gehalten und die Nachrichten sind textbasiert. Entsprechende Nachrichten können also auch von Menschen gelesen und manuell eingetippt werden, meist zum Testen. Es kennt darüber hinaus einfache aber effektive Sicherheitsmechanismen und wird von Firewalls eher freundlich behandelt. Ein Grund dafür, warum SOAP meist über HTTP übertragen wird, was aber wiederum bedeutet, dass Firewalls eigentlich doch nicht so freundlich sein sollten was HTTP Verkehr anbelangt.

Eine HTTP Nachricht besteht aus einer Request oder Status Zeile (1. Zeile der Nachricht) gefolgt von mehreren Zeilen mit Name-Value-Pair (name=wert) einträgen die als Header bezeichnet werden. Darauf folgt eine Leerzeile mit der Zeichenkombination (<CR><LF>), also die art und weise, wie in Windows in der Regel Leerzeichen gespeichert werden. Darauf folgt der Sogenannte Body, welcher dann die Nutzdaten enthält.

Die erste Zeile einer HTTP Request Nachricht enthält die HTTP Methode (GET, HEAD, POST oder PUT, abhängig von der HTTP Version) und die angeforderte Ressource, also die URL der zu liefernden Daten (z.B. eine HTML Datei). Die Möglichen Header Werte kann man dem Standard entnehmen. Bei einer HTTP Response Nachricht enthält die erste Zeile den Status-Kode und eine kurze Beschreibung (z.B. „200 OK“, oder „404 Not Found“. Im Body der Nachricht sind dann die gewünschten Daten enthalten.

Nachrichtenkodierung

Daten, die über das Netzwerk übertragen werden sind einfach nur Bits und Bytes, Nullen und Einsen. Sie können verschiedenste Information und Formate repräsentieren. Z.B: Text wie ASCII, UTF8, UTF16, etc., oder einfache Datentypen wie byte, int , long, float etc. Sie können aber auch bedeuten, dass Objekte, Klassen, Bilder oder Dokumente über die Leitung geschickt werden.

Weiters, besteht ein Netzwerk aus einer Vielzahl verschiedenartiger, heterogener Systeme und Computer. Manche Computer interpretieren die Bytes in Bitreihenfolge von rechts nach links (Intel), andere von links nach rechts (PPC auf G5 Macs oder die CPU der XBOX360). Die Art der Zeichencodierung (UTF vs. LATIN) oder die Breite der Register, 8, 16, 32 oder 64 Bit, der verwendeten CPUs können sich unterscheiden. Einen Transformation der Daten oder ein „allgemein“ verständlicher Kode ist erforderlich, um nicht nur Bits sondern auch Information übertragen zu können. Dies ist theoretisch recht einfach, hat aber einen starken Einfluss auf die Performance und somit die Übertragungsrate.

Wenn man nun für jeden Code auf jeden beliebigen anderen Code ein Mapping definieren will, dann würde man bei n Codes n² Transformationen implementieren müssen; das berühmte n-Quadrat Problem. Viel besser wäre es also, vor der Übertragung, die vorliegenden Daten in ein kanonisches Format umzuschreiben, die Daten dann über das Netz zu schicken und auf der Empfangsseite dieses allgemein verständliche Format auf die Präsentation der Daten im lokalen System wieder zurück zu codieren. Dadurch wird eine Reduzierung der Komplexität auf 2*n statt n² erreicht.

Bei der Textcodierung werden dabei Character und Charactersets definiert wie früher ASCII oder EBSDIC Kodierung und in heutzutage im Sinne der globalen Familie des Internets Zeichenmengen und Kategorisierungen wie UTF oder LATIN.

Es braucht aber auch eine kanonisierte Form, um die Bits die in die Leitung fließen und am anderen Ende wieder ausgelesen werden zu interpretieren. Diese Form wird definiert in der Abstract Syntax Notation, ASN.1 der ISO (International Standard Organization). Der Standard besteht aus vier Hauptelementen:

Die Abstract Syntax beschreibt die Struktur von Daten unabhängig von anderen Programmiersprachen
Die Concrete Syntax beschreibt die Struktur der Daten bezogen auf eine bestimmte Programmiersprache.
Die Transfer Syntax beschreibt die Struktur der Daten auf dem Übertragungsweg
Die Encoding Rules (z.B. die Basic Encoding Rules BER) beschreiben die Transformation von der Concrete Syntax in die Transfer Syntax

ASN.1

Im Folgenden werden nun einige Beispiele für die Notierung in ASN.1 und die Kodierung in BER gegeben.

ASN.1 Deklaration eines Datentypen (hier “BookType”):

BookType ::= INTEGER {

paperback(0)

hardcover(1)

}

Beispiel Wertedefinition:

hardcover BookType ::= hardcover(1)

Die Standard Kodierungsregeln von ASN.1 besagen, dass:

Datentypen-Information wird via TAGs übertragen
Es werden keine Typennamen übertragen
TAGs werden annotiert, um Typen zu beschreiben.

Dabei gibt es vier verschiedene TAG Klassen:

UNIVERSAL, APPLICATION, CONTEXT-SPECIFIC, PRIVATE

Die Daten werden dann via TLV Kodierung (Tag, Length, Value) übertragen

BER TLV Prinzip

Beispiel Definition:

BookType ::= [APPLICATION 4] INTEGER {

paperback(0)

hardcover(1)

}

hardcover BookType ::= hardcover(1)

Die Daten hardcover werden nun in codiert wie in Abb. 11.

BER Beispiel

Die Kombination aus ASN.1 und BER ist sehr effektiv. Beliebige Datenstrukturen können kanonisiert übertragen werden. Der Preis für die Perfektion ist jedoch hoch. Die Kodierung ist aufwendig und ineffizient, z.B. beim Zugriff auf bestimmte Bits. Viele Applikationen kennen die Typen ihrer zu übertragenden Daten ohnehin, was diese Information überflüssig macht. ASN.1 ist ein Kind der Telekommunikationsstandardgremien und wird auch heute noch in diesem Bereich eingesetzt, z.B. bei UMTS oder Intelligent Networks. Mittlerweile hat sich allerdings XML als Standard bei der Übertragung von typisierten Daten etabliert.

XML, die Extended Markup Language ist eine textbasierte Meta Sprache mit einer selbstbeschreibenden Datenpräsentation: Daten und Typinformation zu den Daten erscheinen zusammen. XML ist plattformunabhängig und jede Menge Tools und APIs zum Generieren und Lesen von XML stehen zur Verfügung (SAX, DOM, etc.). Man könnte XMLD als die Sprache der Maschinen in Internet bezeichnen. Es gibt zur Zeit kaum datenorientierte Applikationen, die diesen Standard nicht unterstützen würden. XML ist adaptier- und erweiterbar, via sogenannter Extensible Stylesheets (XSLT). XML wurde standardisiert von der W3C.

Auf XML, XLINK, XPATH, XPOINTER und XSLT wird unter Kapitel 4.2.4 näher eingegangen.

XML ist eine Metasprache mit dem Zweck, konkrete Sprachen zu definieren, also im Falle der Datenübertragung das Vokabular zur Typenbeschreibung. Dabei werden die aktuellen Daten mit Tags versehen, die die Bedeutung der Daten bestimmen. Die Möglichkeiten, welche Daten wie getagged werden können, werden durch die XML Stylesheets bestimmt.

Ein durch XML beschriebenes Set an Daten in einer Datei wird als Dokument bezeichnet. Diese Dokumente sind hierarchisch geordnet, indem mit Anfangs- und Endtaggs versehene Datensegmente ineinander verschachtelt werden.

XML ist sehr erfolgreich aber man sollte sich nicht von dem Mythos blenden lassen, dass XML einfach zu handhaben und von Menschen lesbar sei (Beweis: Speichern Sie ein MS-Word Dokument als XML ab und öffnen sie diese mit einem einfachen Texteditor).

Es gibt noch andere Methoden zur Serialisierung von Daten, vor allem objektorientierte Laufzeitumgebungen wie .Net oder Java definieren eigene über die jeweilige Sprache hinaus nicht standardisierte Formate um , z.B. Objekte zu speichern oder zu übertragen.

Remote Procedure Calls, Middleware und verteilte Objekte

Bevor wir auf RPC eingehen sollten wir einen kurzen Ausflug in die Welt der Clients und Server machen. Gegeben sei dabei der schon unter 1.2 vorgestellte Usecase eines Online-Store.

Der Online Store stellt den Dienst, Waren über das Internet anzubieten und zu vertreiben bereit. Die notwendigen Prozesse die dabei ablaufen werden dabei unter dem Begriff „Server“ zusammengefasst. Oft wird damit auch der ganze Computer bezeichnet, auf dem diese Prozesse oder Aufgaben abgearbeitet werden.

Der Prozess der diesen Service benutzt, wird als Client bezeichnet. Dabei kann ein Server der Client eines anderen Servers sein, z.B. in einer Multi-Tier Architektur moderner Business-Anwendungen.

Den gesamten Service jetzt aber nur auf Basis von Requests und Responds die via TCP über das Netz geschickt werden, wäre sehr zeitaufwendig, fehleranfällig und kaum wieder verwertbar für viele verschiedene Online-Stores.

Datei:Media/image15.png
Datei:Media/image16.png

Client Server Schema

Es gibt dazu einen eleganteren Ansatz. Dabei tut man auf der Seite des Clients einfach so, als würde man eine Prozedur oder Funktion aufrufen, ohne dass dem Aufrufenden dabei klar ist, ob die Funktion nun auf dem eigenen lokalen Rechner oder auf einem anderen irgendwo im Internet abgearbeitet wird. In unserem Beispiel könnte man dann einfach zwei C-Funktionsprototypen definieren wie etwa:

public Receipt order(Books] books);

public Book[] suche(String keyword);

Totale Transparenz und absolute Ununterscheidbarkeit von lokalen und entfernten Aufrufen von Funktionen auf einem beliebigen Computer wird allerdings immer ein Ideal bleiben. Faktoren wie Laufzeitverzögerung, parallele Abarbeitung, Speicherzugriff oder teilweise Ausfälle von Geräten wird von Programmierern immer gesondert behandelt werden müssen. Man kann Ihnen das Leben dabei allerdings wesendlich vereinfachen, indem man notwendiges Expertenwissen über Sockets, Session-Management, Datenrepräsentation oder das Auffinden von Services (Funktionen) vereinfacht oder abstrahiert.

Der erste Versuch dies zu erreichen ist die Einführung von sogenannten Remote Procedure Calls. Diese Technologie setzt auf dem Transport Layer auf und entbindet damit den Applikationsprogrammierer von der Verantwortung Netzwerkprotokolle oder Sockets selbst ansteuern zu müssen.

Naming Services

„It’s all in a name.“

Diese im Englischen oft verwendete Redewendung deutet auf die Wichtigkeit der Namensvergabe für das was wir tun und geschaffen haben hin. Dies gilt um so mehr für verteilte Systeme, denn was man nicht benennen kann existiert letztlich nur für sich selbst und ist somit nutzlos in der Welt der anderen. Und verteilte Systeme sind vom Benutzer aus betrachtet nun mal nichts anderes als: „Die Welt der Anderen“. Damit Computer mit Namen gut umgehen können müssen diese systematisiert werden. Dadurch entstehen Namenssysteme und in verteilten Systemen Namensdienste zur Auffindung von Ressourcen im Netz.

Jede logische Einheit eines Naming-Service, jeder Eintrag den man dort ablegen kann, besteht aus drei Elementen:

NAME:

Dieser beschreibt das Objekt um das es geht (welches eingetragen oder gesucht wird)

ADRESSE:

Der Ort an dem sich das Objekt befindet

PFAD

Beschreibt, wie man am Ort des Objektes zu dem Objekt selbst findet.

Die oben genanten Elemente lassen sich z.B. auch in dem HTML Address-Tag wieder finden: <a ref=http://ffh.online-campus.at/Dokumente/AIT2/Studienheft.pdf> Skriptum zu GridComputing </a> mit NAME=“Skriptum zu GridComputing“, ADRESSE=ffh.online-campus.at und PFAD=Dokumente/AIT2/Studienheft.pdf.

Man braucht Naming Services, um Objekte (oder anders gesagt Ressourcen) im Netz zu identifizieren. Objekte können sein: Dateien, Benutzer, Datenbanken, Variablen, Kommunikationsverbindungen o.ä. Man nutzt Namenssysteme auch, um Daten und Information mit anderen zu teilen und um eine Indirektion zwischen Objekt und Zugriffsmethode zu schaffen. Die Bindung von Namen an Objekte ist dadurch dynamisch und kann jederzeit geändert werden Ein einziger Name kann eine gesamte Menge an Objekten bezeichnen und man kann einem Objekt gleich mehrere Namen geben. Außerdem ist die Namensvergabe eine Voraussetzung für die Transparenz eines Systems. So können WWW Server irgendwo auf der Welt aufgestellt werden, die Server können beliebig umgezogen werden und es kann mehrere replizierte Server geben, die auf der ganzen Welt verteilt laufen und den gleichen Namen haben, z.B.: um von einer Adresse www.millisoft.com, Antworten von europäischen oder amerikanischen Servern zu bekommen, je nach Konfiguration.

Naming Services stehen folgenden Problemen gegenüber: Dem Management von Kontextinformation, die ständige Verfügbarkeit der Namensauflösung - vom Namen zum wirklichen Objekt, dem riesigen Umfang an Namen und Objekten in einem (weltweiten) System und der Heterogenität unterschiedlicher Namensysteme welche miteinander verschränkt werden müssen.

Dabei ist Kontextmanagement der zentrale Aspekt, da die Bedeutung von Namen in der Regel abhängig vom Kontext ist in dem Sie gebraucht werden. SO kann z.B. das englische Wort „state“ einen Staat in den USA wie Kansas oder Kalifornien bezeichen und in einem anderen Kontext den momentanen Zustand eines laufenden Computerprogramms beschreiben.

Es gibt verschiedene Möglichkeiten, diese Probleme zu lösen:

Zentralisiertes Kontextmanagement hat den Vorteil, dass es einfach zu implementieren ist aber die Nachteile, dass es einen „Single Point of Failure“ und einen weiteren Performance Engpass darstellt
Verteiltes Kontextmanagement hat den Vorteil, dass es keinen „Single Point of Failure“ gibt und Loadsharing zwischen den Servern betrieben werden kann. Nachteile sind, dass es sehr komplex zu implementieren ist und der Ausfall eines Servers bedeutet, dass der Namensbereich für den dieser zuständig ist nicht mehr bedient werden kann.
Verteiltes Kontextmanagement mit Replikation bietet hohe Verfügbarkeit, effizienten Zugriff und Loadsharing zwischen den Servern. Nachteile sind, dass nun auch Replikationsmanagement betrieben werden muss und dass laufzeitbedingt Inkonsistenzen in der Namensverwaltung auftauchen können.

Die Namen selbst können flach oder strukturiert sein. Beispiele für flache Namen oder Identifier sind die Reisepassnummer oder die ISBN eines Buches. Beispiele von strukturierten Namen sind Pfadangaben in einem hierarchischen Dateisystem, die Namespaces in C# oder die Paketnamen in Java, sowie die Domain Namen für Internet Adressen.

Die Funktionen eines Naming Services, ganz gleich ob dieser nur einen einzigen Application Server oder das ganze Internet abdeckt, lassen sich, abgesehen von den administrativen Aufgaben, in zwei Gruppen zusammenfassen: Die Manipulation von Kontext- und Namensinformation, sowie das Beantworten von Nachfragen.

Die Schreibfunktionen des Services sind: ADD – zum Erstellen eines Bezugs zwischen Name und Objekt, DELETE – zum Löschen des selben und MODIFY zum Verändern einer zuvor erstellten Referenz. Die Lesefunktionen sind: READ – das Auflösen eines Namens auf das konkrete damit verknüpfte Objekt, SEARCH – das Finden von Namen oder Objekten bezogen auf bestimmte Attribute und LIST – das Auflisten aller Namen in einem bestimmten Namensraum.

Geschichte der P2P Netze

Beispiele für Naming Services sind, im Bereich der Programmierung von verteilten Systemen das JNDI „Java Naming Directory Interface“ zum Auffinden von lokalen oder entfernten Objekten und im Bereich großer Netzwerke das X.500 Directory oder der DNS „Domain Name Service“ des WWW.

Die Hauptaufgabe des DNS ist das Umwandeln (LOOKUP) von symbolischen Computernamen auf Internet Adressen (und vice versa REVERSE-LOOKUP). Der Namensraum des DNS ist hierarchisch gegliedert und ortsunabhängig organisiert. Die Aufteilung erfolgt in Domains die in einer Baumstruktur miteinander verbunden sind. Im Gegensatz zum wenig verwendeten X.500 Directory baut der Domain Name Service auf einem einfachen Datenmodell auf, arbeitet mit einfachen Filter-Abfragen und ist Weltweit anerkannt (ICANN).

Peer-to-Peer Netzwerke

Peer-to-Peer Netzwerke sind ein fester Bestandteil des Web2.0 in den Bereichen Messaging (ICQ, Jabber), Groupware (Groove, Wave?), Internettelefonie (Skype), Media-Streaming (Hulu, Zatoo), Hosting/Filesharing (Bittorrent, Avalanche) oder auch bei Suchmaschinen (YaCy) (vergleiche auch [I4]).

In den 90-er Jahren des letzten Jahrhunderts hat ein Paradigmenwechsel eingesetzt der Peer-to-Peer Systeme den traditionellen Client/Server Lösungen bevorzugte. P2P Systeme sind autonom, skalierbar, dynamisch, anonym, dezentral und selbst-organisierend. Peer-to-Peer Datenverkehr macht mittlerweile mehr als die Hälfte des Internet Verkehrsvolumens aus. Man unterscheidet heute mindestens drei Generationen von Peer-to-Peer Netzwerken: 1. Generation – zentralisierte P2P Netze, 2. Generation reine P2P und hybrid P2P Netzwerke und 3. Generation – 3. Generation DHT (Distributed Hash Tables) P2P Netzwerke a la Bittorrent.

Bei der ersten Generation von Peer-to-Peer Netzwerken, den zentralisierten P2Ps speichert ein Server den Index zum Auffinden der Daten im Netz. Der Datenaustausch findet dann Peer-to-Peer also direkt von Rechner zu Rechner statt. Wie bei allen zentralisierten Systemen ist auch hier der Schwachpunkt der zentrale Server dessen Ausfall zu einem Totalausfall des Dienstes führen würde. Außerdem skaliert ein System schlecht dessen Hauptlast auf einem einzigen Rechner liegt.

Bei reinen P2P Systemen der 2. Generation sind alle Peers (Rechner) gleich. Queries und Pings werden weitergeleitet und es existiert keinerlei „globales Wissen“. Solche Systeme sind sehr robust. Dadurch ergeben sich allerdings Performance Probleme verursacht durch Message-flooding (hohe Anzahl von Nachrichten) und Daten-Kollisionen. Es gibt z.B. bei Gnutella auch keine Garantie alle Daten aufzufinden. Bei der hybriden P2P Variante wie Fasttrack unterscheidet man zwischen „normalen“ Peers und „Super“ Peers. Dadurch entsteht eine gewisse Hierarchie im Netz. Super-peers nutzen Ihre lokale Information bei einer Query und leiten diese nur weiter, wenn auf dem Peer Rechner selbst nichts gefunden wird.

In der 3. Generation der Peer-to-Peer Netzwerke wird das Konzept der verteilten Hashtabellen angewendet (DHT). Auch hier sind alle Peers gleich und es gibt keinerlei hierarchische Struktur. Die Last wird gleich verteilt auf alle Peers und Knoten und Objekte im Netz werden alle auf im gleichen Schlüsselraum (Anzahl möglicher Schlüssel) abgebildet.

Eine detaillierte Diskussion des Themas Peer-to-Peer Netzwerke würde eine ganze Vorlesung ausfüllen. Auch die Behandlung anderer wichtiger Aspekte zum Thema verteilte Systeme wie Zeitsynchronisation von Netzwerken, die Integration von globalen Daten und Datenreplikation sowie Parallelität und Transaktionsmanagement, würden den Rahmen dieses Studienheftes sprengen und können daher hier nicht weiter ausgeführt werden. Dem interessierten Leser bleibt es überlassen, diese Themen in der im Anhang angegeben Literatur selbst nachzulesen.

Praxis Verteilter Systeme

„Was ist anders an verteilten Systemen?
Nun, sie sind eben nicht zentralisiert.“ ^[3]

Das Client Server Modell

In diesem Modell unterscheidet man zwei verschiedene Arten miteinander kooperierender Prozesse: die Server, die einen Dienst (Service) bereitstellen und die Clients, die Nutzer eines Dienstes. Ein Client sendet eine Anfragenachricht, in der er einen bestimmten Dienst nachfragt, an einen Server. Dieser erfüllt den Dienst, indem er die nachgefragten Daten oder eine Fehlermeldung zurückliefert, die den Grund des Versagens beinhaltet (siehe auch [I5]).

Es ist aber auch möglich, dass ein Prozess gleichzeitig sowohl Client als auch Server ist. Wenn ein Server für die Bereitstellung eines Dienstes den Dienst eines anderen Servers benötigt, wird er zum Client bezüglich des anderen Servers.

Interprozess-Kommunikation

Zwischen Threads: Alle Threads eines Prozesses befinden sich im selben Adressraum. Dadurch ist es möglich, Daten im Hauptspeicher abzulegen, auf die jeder von ihnen zugreifen kann. Die Kommunikation zwischen den Threads erfolgt also am effektivsten über globale Variablen. Allerdings bildet der Zugriff auf die gemeinsam genutzten Daten einen kritischen Abschnitt, der zu synchronisieren ist. Dies kann mit Hilfe von Semaphoren, Monitoren oder ähnlichen Mitteln erfolgen. Durch sie wird garantiert, dass ein Thread einen kritischen Abschnitt ohne Unterbrechung durch einen anderen ausführt.

Zwischen Prozessen: Mehrere Prozesse können nicht über globale Variablen miteinander kommunizieren, da jeder Prozess seinen eigenen Adressraum besitzt. Betriebssysteme bieten jedoch für Prozesse andere Mittel der Kommunikation an. Laufen zwei Prozesse im selben Rechner ab, so kann bei der Implementierung der Interprozesskommunikation (IPC) der physisch vorhandene gemeinsame Speicher genutzt werden. In UNIX System V werden dafür Bibliotheksroutinen zum expliziten Einblenden vom shared memory oder dem Austausch von Nachrichten angeboten. Besitzen zwei Prozesse Zugriff auf das selbe Filesystem, so kann die Kommunikation auch darüber erfolgen (named pipes in UNIX). Ein allgemein anwendbares Verfahren der IPC ist jedoch der Nachrichtenaustausch. Er funktioniert sowohl zwischen Prozessen, die sich auf dem lokalen Rechner befinden als auch zwischen Prozessen, die sich auf unterschiedlichen Rechnern befinden.

Synchrone Middleware

Geht man vom OSI-Schichtenmodell für Netzwerke aus, positioniert sich die Middleware in den obersten drei Schichten: „Applikation, Präsentation und Sitzung“. Sie definiert dabei auf Grundlage des darunter liegenden Netzwerkes die Kommunikationsmechanismen zwischen den einzelnen Applikationen.

Zum Einsatz einer Middleware-Lösung muss diese auf den zu integrierenden Systemen überhaupt zur Verfügung stehen, es muss die Funktionalität der entsprechenden Schnittstelle im Mittelpunkt der Spezifikation bzw. des Design stehen und sie sollte über ausreichende Mechanismen zur Transaktionssicherung verfügen bzw. Möglichkeiten zur Verschlüsselung und Authentifizierung anbieten.

Bei der synchronen Kommunikation ist der Sender (Client) von der Anforderung einer Verbindung zum Empfänger (Server) bis zum Erhalt der gewünschten Informationen oder Ergebnisse blockiert (blocking), was bedeutet, dass die Ausführung des entsprechenden Programms für die Dauer der Kommunikation und der Bearbeitung der Anfrage durch den Server ausgesetzt wird. Hat der Server den Wunsch eines Verbindungsaufbaues bestätigt, können keine weiteren Verbindungen zu ihm aufgebaut werden (siehe auch [P9] und [P10]).

Asynchrone Middleware

Das asynchrone Kommunikationsprinzip beinhaltet die Unabhängigkeit der internen Verarbeitung und Kommunikation beim Sender und Empfänger. Nach Übergabe des zu sendenden Datenstroms an das Kommunikationssystem fährt der Sender mit weiteren Prozeduren fort, ohne zu blockieren. Er wartet demzufolge nicht auf eine Quittierung oder ein Bearbeitungsresultat des Empfangssystems. Dieses Konzept bietet den Vorteil, dass der Server weder direkt mit dem Client verbunden noch überhaupt verfügbar sein muss, damit eine Kommunikationsanforderung im Netzwerk abgesetzt werden kann (non-blocking) und trotzdem erfolgreich bearbeitet wird (siehe auch [I5]).

Bei asynchroner Kommunikation, auch Message Passing genannt, arbeitet der Sender nach dem Abschicken einer Nachricht bereits weiter, ohne auf eine Antwort zu warten. Die Anfrage verbleibt dann unter Umständen längere Zeit in der Anfrageschlange beim Empfänger, ohne den Prozess komplett zu blockieren. Eine solche Entkopplung ermöglicht eine sehr flexible Arbeitsweise der Anwendungen. Neben dem Begriff Message Passing wird dies auch als „fire and forget“ bezeichnet. Die beiden hier in Frage kommenden Varianten sind die Broadcasting- und Publish/Subscribe-Kommunikation.

Beim Broadcasting schickt der Sender die Nachricht über einen öffentlichen Kanal ab. Jeder Empfänger, der Zugang zu diesem Nachrichtenmedium hat, kann die Nachrichten verwerten oder nicht. Die grundsätzliche Idee hinter der Publish/Subscribe-Kommunikation ähnelt der des Broadcastings mit dem Unterschied, dass die Nachricht nur an Empfänger zugestellt wird, die im Vorhinein diese Nachricht oder das Thema der Nachricht abonniert (siehe auch [P9]).

Nachrichtenorientierte Middleware

Die in den vorhergehenden Abschnitten beschriebenen Middleware-Ansätze gehen in ihrer praktischen Umsetzung weitgehend von einer synchronen Kommunikation zwischen zwei Applikationen oder zwischen einer Applikation und einer Datenbank aus. Solange kommuniziert wird, sind der Sender und der Empfänger in allen Fällen blockiert. Erst in jüngster Zeit existieren Bestrebungen, beispielsweise bei der OMG mit CORBA, asynchrone Kommunikationsmechanismen in die Standards zu implementieren. Ein weiterer Nachteil ist die strenge Peer-to-Peer Ausrichtung der Middleware-Ansätze. Dadurch wird eine Einbindung neuer Applikationen aufgrund der hohen Kopplung zwischen den Systemen wesentlich erschwert.

Message-orientierte Middleware (MOM) geht einen anderen Weg. Die Kommunikation zwischen zwei Applikationen erfolgt hier ausschließlich über den Austausch von Nachrichten, d.h. dass nach Übertragung einer Nachricht an die Middleware-Schicht die Applikation sofort weiterarbeiten kann. Der Transport und das Routing der Informationen werden von der MOM-Software übernommen. Somit kann über message-orientierte Middleware asynchron kommuniziert werden. Allerdings werden auch synchrone Mechanismen zum Datenaustausch angeboten (siehe auch [P9]).

Enterprise Applikationen und e-Business

Um Komponentenorientierte Middleware beschreiben zu können, muss zunächst einmal geklärt werden, was Komponenten überhaupt sind. Allgemein versteht man unter einer Komponente einen ausführbaren Programmkode, der eine bestimmte Funktionalität beinhaltet und diese in Form von Diensten über definierte Schnittstellen den Clientanwendungen oder anderen Komponenten bereitstellt. Im Unterschied zur objektorientierten Programmierung ist ein Zugriff auf Funktionalitäten und Daten nur über diese Schnittstellen möglich. Die strikte Kapselung ermöglicht es, die Implementation auszutauschen ohne das Gesamtsystem zu beeinflussen solange Funktionalität und Schnittstellen gleich bleiben. Der Zugriff auf Komponenten ist dabei nicht auf einzelne Prozesse oder auf einzelne Computer beschränkt. Verteilung und Kommunikation werden durch eine Middleware-Schicht realisiert, wodurch Modifikationen am Quellcode der Clientprogramme wegfallen können. Komponenten sind somit insbesondere für n-Tier Applikationen geeignet. Ziel der Entwicklung ist es, durch die lose Kopplung und das Black-Box-ähnliche Verhalten die Wiederverwendung zu fördern und den Prozess der Softwareentwicklung mit der Unterstützung von Drag-und-Drop basierter Zusammenstellung von Applikationen aus Softwarekomponenten zu beschleunigen.

Mit der 1997 vorgestellten Enterprise Java Beans (EJB) Technologie stellt die Firma Sun ein entsprechendes Komponentenmodell für die Entwicklung und das Deployment von serverseitigen Unternehmensanwendungen zur Verfügung (siehe auch [P8] und [P10]). Die Veröffentlichung der Modell-Spezifikation ermöglicht es Drittanbietern, die Implementation von Laufzeit- und Entwicklungsumgebungen selbst umzusetzen. Lösungen existieren beispielsweise von Bea Systems, Iona Technologies und IBM.

Der EJB-Container stellt die Laufzeitumgebung für die Enterprise Java Beans zur Verfügung. Dazu gehören eine Anzahl von Diensten, die durch die EJB-Spezifikation festgelegt oder vorgeschlagen werden (siehe Tabelle unten). Die Infrastruktur für den EJB-Container wird wiederum durch den EJB- Server bereitgestellt. Zu seinen Aufgaben gehören u.a. das Pooling von Datenverbindungen und die Thread-Verwaltung.

Tab. 1: Strukturbilanz EJB Dienste und Spezifikationen (Quelle [P10])

Ressourcenverwaltung	Verwaltung und Zuteilung von benötigten Ressourcen. Dazu gehören beispielsweise der Hauptspeicher und die Kommunikationsverbindungen
Life Cycle Management	Kreierung, Initiierung und Zerstörung von Bean-Instanzen
Transaktionsmanagement	Bereitstellung von Mechanismen für die Transaktionsverwaltung
Security	Dazu gehört u.a. Verschlüsselung von Kommunikation und Daten und die Authentifizierung von Nutzern und Nutzergruppen
Persistenz	Lokales Speichern von EJB-Komponenten und Wiederherstellung nach Ausfällen (beispielsweise des Server-Rechners)
Distribution	Verteilung der Enterprise Beans und Entkopplung von der zugrunde liegenden Netzwerkschicht.
Load balancing	Aufteilung von Anfragen durch Clients auf gleichartige Enterprise-Beans

Die Enterprise Beans enthalten die Implementation der Business-Prozess Logik und die zugehörigen Daten. Sie existieren in drei Ausprägungen:

Session Beans enthalten die Anwendungslogik. Sie sind nicht persistent. In der Applikationsintegration werden sie oft benutzt, um den Zugriff auf bestehende Unternehmensanwendungen zu realisieren.
Entity Beans dienen zur Modellierung von Unternehmensdaten und dem Zugriff auf diese. Sie repräsentieren eine objektorientierte Sicht auf die zugrunde liegenden persistenten Daten.
Message driven Beans enthalten, wie die Session Beans, die Anwendungslogik mit dem Unterschied, dass die Kommunikation hier über Nachrichten abgewickelt wird.

Komponentenorientierte Middleware bietet umfassende Lösungen für die Probleme der EAI. Durch sie wird eine Integration auf Geschäftsprozess Ebene (Business-Prozess Level EAI) wesentlich vereinfacht oder erst ermöglicht (siehe [P10]).

Praktische Übungen 1: Parallel-Quicksort

Implementieren Sie ein Quicksort Programm in einem verteilten System. Das Prinzip des Quicksort Algorithmus basiert darauf, dass eine lange Liste von Daten in mehrere Teillisten unterteilt wird und diese Teillisten dann sortiert und wieder zusammengeführt werden. Wenn diese Teillisten nun parallel zueinander sortiert werden können, dann kann der Sortiervorgang weiter beschleunigt werden.

Beim „gewöhnlichen“ seriellen Quicksort geschieht folgendes: Um eine Folge F = k1,...,kN von N Elementen anhand des Quicksort Algorithmus der Größe nach zu sortieren, wählt man als erstes ein beliebiges Element k = {k1,...,kN}, das als Pivotelement verwendet wird. Anhand dieses Elements wird die Folge F in zwei Teilfolgen geteilt, wobei die erste Teilfolge nur Elemente beinhaltet die kleiner oder gleich k sind, die zweite Teilfolge nur Elemente die größer oder gleich k sind. Nun wird dieses Verfahren für die beiden Teilfolgen rekursiv wiederholt. Zuletzt werden alle Teilfolgen zusammengesetzt.

Der erste Schritt des parallelen Quicksorts ist identisch mit dem des seriellen. Man wählt aus der Folge F = k1,...,kN ein beliebiges Element k = {k1,...,kN} das als Pivotelement dient. Jetzt werden die Teilfolgen Subset 1 und Subset 2 nicht vom gleichen Prozess weiterverarbeitet, sondern jede Teilfolge wird an einen anderen Prozess geschickt. Dort werden die Teilfolgen wieder in Teilfolgen unterteilt und an weitere Prozesse verschickt. Dies geschieht so lange bis jeder Prozess im System in dem man sich befindet eine Teilfolge zur weiteren Verarbeitung zur Verfügung hat. Diese CPUs führen dann den seriellen Quicksort durch bis ihre Teilfolge sortiert ist und schicken dieses Ergebnis an die erste CPU. Sobald alle Ergebnisse zur Verfügung stehen ergeben diese dann die geordnete Folge F.

Details und weitere Erklärungen zum Quicksort Algorithmus finden Sie unter:

http://de.wikipedia.org/wiki/Quicksort

Die folgenden Übungsvarianten sollen mit Hilfe der Programmiersprache Java gelöst werden. Beantworten Sie auch die Frage, unter welchen Bedingungen Ihre Implementation eines Parallelen Algorithmus dem eines seriellen überlegen ist, also: Unter welchen Bedingungen ist ein verteilter Quicksort schneller als ein lokal-serieller. Die zu sortierende Liste soll aus einer Reihe zufällig erzeugter Zahlen bestehen. Beschreiben Sie Ihre Implementierung auf 3-5 Seiten.

Parallel Quicksort Implementierung mit Threads

Implementieren Sie den oben beschriebenen parallelen Quicksort Algorithmus in einem Java Programm. Dabei soll jede Teilliste in einem eigenen Thread implementiert werden. Am Ende der Sortiervorgänge sollen die Teillisten wieder zusammengeführt werden.

Information zu Java Threading finden unter anderem unter:

http://www.boku.ac.at/javaeinf/jein2.html#thread

Parallel Quicksort Implementierung mit TCP/Sockets

Implementieren Sie den oben beschriebenen parallelen Quicksort Algorithmus in einem Java Programm. Dabei soll jede Teilliste in einem eigenen Java Programm sortiert werden. Die Java Programme sollen dabei die Teillisten mit Hilfe von einfachen TCP-Sockets verschicken. Am Ende der Sortiervorgänge sollen die Teillisten wieder zusammengeführt werden.

Information zur Java Socket Programmierung und Objekt-Serialisierung finden unter anderem unter:

Parallel Quicksort Implementierung via HTTP GET/POST

Implementieren Sie den oben beschriebenen parallelen Quicksort Algorithmus in einem Java Programm. Dabei soll jede Teilliste in einem eigenen Java Programm sortiert werden. Die Java Programme sollen dabei die Teillisten mit Hilfe von HTTP GET oder POST Requests verschicken. Am Ende der Sortiervorgänge sollen die Teillisten wieder zusammengeführt werden. Die fertig sortierten Teillisten können in der 200 OK Antwort-Nachricht zurückgegeben werden.

Bibliotheken und Dokumentation zur Verwendung von HTTP in Java finden unter anderem unter:

Parallel Quicksort Implementierung via XML-RPC

Implementieren Sie den oben beschriebenen parallelen Quicksort Algorithmus in einem Java Programm. Dabei soll jede Teilliste in einem eigenen Java Programm sortiert werden. Die Java Programme sollen dabei die Teillisten mit Hilfe des XML-RPC Protokolls austauschen. Am Ende der Sortiervorgänge sollen die Teillisten wieder zusammengeführt werden.

Bibliotheken und Dokumentation zur Verwendung von XML-RPC in Java finden unter anderem unter:

http://ws.apache.org/xmlrpc/

Parallel Quicksort Implementierung via Java RMI

Implementieren Sie den oben beschriebenen parallelen Quicksort Algorithmus in einem Java Programm. Dabei soll jede Teilliste in einem eigenen Java Programm sortiert werden. Die Java Programme sollen dabei die Teillisten mit Hilfe des XML-RPC Protokolls ausgetauscht werden. Am Ende der Sortiervorgänge sollen die Teillisten wieder zusammengeführt werden.

Informationen zur Verwendung von Java RMI finden unter anderem unter:

http://www.mm.informatik.tu-darmstadt.de/courses/helpdesk/rmi_tutorial.html

Praktische Übungen 2: Verteilte Datenspeicherung

Im Angesicht von populären Filesharing Diensten und P2P Netzwerken soll in dieser Übung eine sehr einfache Variante von verteilter Datenspeicherung implementiert werden. Dabei soll ein beliebiger Knoten in einem Netzwerk zwei verschiedene Befehle implementieren:

put_data(key, data)
data = get_data(key)

Dabei stellt der Parameter „key“ eine Zeichenkette (einen String) dar, welche Schlüssel benutzt, um die Daten, beschrieben durch die Variable „data“, ab zuspeichern und wiederzufinden. Der Schlüssel soll eindeutig sein. Der Einfachheit halber sollen auch die Daten durch eine Zeichenkette repräsentiert sein (für Fortgeschrittene könnte man dies erweitern, sodass ein beliebiges Objekt abgespeichert werden kann). Diese beiden Funktionen sollen in etwa so funktionieren wie die allseits bekannten Hashtables, assoziativen Arrays oder die sog. Dictionaries.

Nun sollen aber nicht alle Daten auf dem selben Rechner gespeichert werden. Dazu soll ein einfacher Verteilalgorithmus herangezogen werden, um die zu speichernden Daten auf verschiedene Rechner zu verteilen. Der einfachste Form eines sogenannten Hashalgorithmus könnte so aussehen:

Speichere alle Daten deren Schlüssel „key“ Zeichenkette beginnt mit

A,B,C, auf Rechner 1 abspeichern
D,E,F, auf Rechner 2
G,H,I auf Rechner 3 und so weiter bis Z

Sie können aber auch einen anderen Hash-Algorithmus verwenden, um die Daten zu verteilen.

Beim Implementieren müssen Sie nicht 8 Rechner einsetzen Es reicht, wenn alle Programm-Instanzen auf einem Rechner laufen, aber an verschiedenen Adressports lauschen. Dabei sollten 4 Instanzen ausreichend sein.

Sie müssen die zu Speichernden Daten dabei nicht persistieren, d.h. wenn Sie Ihr Programm beenden sind auch die Daten verloren (bei einem richtigen Produkt dürfte so was natürlich nicht passieren).

Verteilte Datenspeicherung via XML-RPC

Implementieren Sie die oben beschriebene verteilte Datenspeicherung in einem Java Programm. Die Java Programme sollen dabei die get_data() und put_data() Funktionen mit Hilfe des XML-RPC Protokolls realisieren.

Bibliotheken und Dokumentation zur Verwendung von XML-RPC in Java finden unter anderem unter:

http://ws.apache.org/xmlrpc/

Verteilte Datenspeicherung via Java RMI

Implementieren Sie die oben beschriebene verteilte Datenspeicherung in einem Java Programm. Die Java Programme sollen dabei die get_data() und put_data() Funktionen mit Hilfe von Java RMI realisieren.

Informationen zur Verwendung von Java RMI finden unter anderem unter:

http://www.mm.informatik.tu-darmstadt.de/courses/helpdesk/rmi_tutorial.html

Verteilte Datenspeicherung via SOAP

Implementieren Sie die oben beschriebene verteilte Datenspeicherung in einem Java Programm. Die Java Programme sollen dabei die get_data() und put_data() Funktionen mit Hilfe des SOAP Protokolls realisieren.

Bibliotheken und Dokumentation zur Verwendung von SOAP in Java finden unter anderem unter:

Grid Computing – Computer im Raster

In dieser Lektion werden die Grundbegriffe wie sie im Grid Computing verwendet werden erklärt und dargestellt. Dieser Teil / diese Lektion des Studienheftes gilt als Ergänzung zu den anderen Lektionen die auch die theoretischen Grundlagen der praktischen Übungen darstellen.

Das „Grid“ wurde Mitte der 90er Jahre erfunden und bezeichnet eine verteilte Rechner Infrastruktur die für wissenschaftliche und ingenieurtechnische Problemstellungen konzipiert ist. Was Grid Computing auszeichnet bzw. von anderen Technologien wie z.B. dem Internet, enterprise, verteiltem und Peer-to-Peer Computing unterscheidet ist das zugrundeliegende Konzept. Damit ist das koordinierte Teilen von Ressourcen und Lösen von Problemen in dynamischen, multi-institutionellen Virtuellen Organisationen (VO). Dieses Teilen ist nicht auf den Austausch von Files beschränkt sondern fokussiert vielmehr auf den direkten Zugriff auf Computer, Software, Daten und anderen Ressourcen. Zur Frage was geteilt werden darf, die entsprechenden Befugnisse und die Bedingungen unter denen dies geschehen darf werden von Ressourcen Providern und Verbrauchern gleichermaßen streng kontrolliert. Dazu notwendige Regeln werden durch eine Menge bestehend aus Individuen und/oder Institutionen definiert und als VO bezeichnet.

Was ist das Grid?

Die „Erfinder“ Ian Foster und Carl Kesselman beschreiben Grid Computing als

„A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.“

und weisen darauf hin, dass Grid die angesprochenen Themen wie z.B. on-demand access auf Rechenleistung, Daten und Dienste bereits in den späten 60ern des vorigen Jahrhunderts erörtert wurden.

So schreibt Len Kleinsrock 1969:

„We will probably see the spread of ‚computer utilities‘, which, like present electric and telephone utilities, will service individual homes and offices across the country.“

Im Jahr 2000 verfeinern Ian Foster und Steve Tuecke im Paper „The Anatomy of the Grid“ diese Definition, um soziale und Policy Aspekte einzubinden. Grid Computing behandelt demnach „coordinated resourse sharing and problem solving in dynamic, multi-institutional virtual organizations“. Der Schlüssel dazu ist das Verhandeln von Ressourcen-Sharing Maßnahmen zwischen einer Menge unterschiedlicher teilnehmender Partnern wie z.B. Providers und Customers. Dieser so entstehende Ressourcen-Pool kann dann für unterschiedliche Zwecke genutzt werden.

Folgende weitere Definition dazu von Foster und Tuecke:

„The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data and other resources, as is required by a range of collaborative problem-solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization.“

Auf die speziellen Aspekte der hier erwähnten virtuellen Organisation wird noch genauer eingegangen. Die nun folgende Checkliste fasst den Kern der obigen Definition in drei Punkten zusammen:

Koordinierte Ressourcen, jedoch nicht zentral kontrolliert
Verwendung von offenen Standard-, Mehrzweckprotokollen und Interfaces
Erfüllen von nichttrivialem Quality-of-Service Anforderungen. Dazu zählen allgemein Security, verteilte Workflow- und Ressourcen Management Performance, koordinierte Ausfallsicherung, Services zur Erkennung von Problemen.

Nun stellt sich die Frage, ob nicht auch das Internet selbst ein Grid ist? Schließlich ist es auch offen, verwendet entsprechende Protokolle und erlaubt den Zugriff auf verteilte Ressourcen. Einzig, die Koordination der Ressourcen, um QoS bereitstellen zu können fehlt, zumindest derzeit.

Was aber ist das Grid nun? Was zeichnet Grid Computing aus und wie ist es aufgebaut? Um diese Frage beantworten zu können, zunächst das Konzept der sog. Virtuellen Organisation.

Virtual Organizations (VOs)

Wie bereits eingangs erwähnt ist das Konzept der VO im Grid von zentraler Bedeutung. Um besser zu verstehen worum es sich hierbei handelt, wie sie sich bilden und welches Ziel VO haben, wird anhand der folgenden vier Beispiele exemplarisch dargestellt.

Eine neue Fabrik soll entstehen. Um eine Entscheidung treffen zu können, wird zunächst ein umfangreiches Finanzprognosemodell eines ASPs benötigt. Dieses Modell soll Zugriff auf einschlägige und proprietäre historische Daten einer gemeinsamen Datenbank haben die auf Speichersystemen eines SSP betrieben werden.

In einem Meeting das während der Definitionsphase stattfindet, werden kollaborativ und interaktiv what-if Szenarien durchgespielt. Die in dieser Phase involvierten Abteilungsleiter können dabei auch in unterschiedlichen Städten sein. Der ASP nimmt einen Cycle Provider (CP) ^[4] unter Vertrag, um für bestimmte Szenarien mehr „Schwung“ zur Verfügung zu haben. Jeder Zyklus muss natürlich den notwendigen Sicherheits- und Performanceansprüche genügen.

Ein Industriekonsortium wurde gegründet mit dem Ziel eine Durchführbarkeitsstudie für ein neues Überschallflugzeug zu erstellen. Es wird dazu eine hochpräzise multidisziplinäre Simulationen des gesamten Flugzeugs durchgeführt. Die Simulation integriert proprietäre Softwarekomponenten die von unterschiedlichen Partnern entwickelt wurden, auf deren Rechnern betrieben werden und Zugriff auf entsprechende Design Datenbanken und andere Daten die durch das Konsortium zur Verfügung gestellt wurden, haben.

Ein Krisenmanagementteam reagiert auf einen chemischen Unfall und benutzt dazu lokale Wetter- und Bodenmodelle, um die Verbreitung der chemischen Substanzen in der Umwelt abzuschätzen. Dabei werden auch die Auswirkungen auf die Bevölkerung sowie geographische Eckdaten wie z.B. Flüsse, Trinkwasserversorgung udgl. einbezogen. Das Ergebnis ist ein vorläufiger Plan zur Entschärfung akuter Gefahrensituationen und beinhaltet Aufgaben für Katastropheneinsätze, Evakuierungsmassnahmen sowie die Verständigung von Spitälern um einige der wichtigsten Maßnahmen zu nennen.

Tausende Physiker in hunderten Laboratorien und Universitäten weltweit kommen zusammen, um den LHC ^[5] am CERN zu entwerfen, zu bauen und zu betreiben sowie die Ergebnisse aus den kollidierenden Teilchen auszuwerten und unter anderem die Existenz des Higgs-Bosons zu beweisen was einen weiteren Durchbruch zum Verständnis des Standardmodells der Elementarteilchenphysik bewirkt.

Während der Analysephase werden Rechen-, Speicher- und Netzwerkressourcen konzentriert, um ein sog. „Data Grid“ zu erstellen mit dem es möglich ist Petabytes ^[6] an Daten zu analysieren.

Atlas Detector des CERN

Die vier hier dargestellten Beispiele unterscheiden sich in vielen Punkten. Die Anzahl der Mitwirkenden, die unterschiedlichen Aktivitäten, die Dauer und der Umfang der verschiedenen Aktivitäten und die verschiedenen Ressourcen die geteilt werden. Trotz dieser zum Teil sehr großen Unterschiede gibt es auch viele Gemeinsamkeiten. So kann eine Organisation in einer oder mehreren VO mitwirken indem sie alle oder nur einige ihrer Ressourcen teilt. Dabei entscheidet jeder Besitzer von Ressourcen wann, wo und welche Ressourcen benutzt werden können. So könnte z.B. eine VO Partnern erlauben ihre Simulationsdienste nur für sehr einfache Aufgaben zu nutzen. Ebenso können die Verbraucher von Ressourcen Bedingungen stellen. So könnte der Nutzer einer Ressource verlangen, dass nur solche Ressourcen bereitgestellt werden, die auch als sicher gelten.

Zur Umsetzung solcher Bedingungen werden entsprechende Mechanismen benötigt, die Policies ausdrücken, die Identität eines Nutzers oder einer Ressource herstellen (Authentisierung) und entscheiden, ob eine Operation für die eingesetzten Beziehungen konsistent ist (Authorisation).

Grid Architektur Allgemein

Die Einrichtung, das Management und die Nutzung von dynamischen, über mehrere Organisationen agierende VO und der somit entstehenden Beziehungen bedingt eine Reihe neuer Technologien. Als Ausgangsbasis wird angenommen, dass eine VO Beziehungen zu jeglichen potentiellen Nutzern aufbauen können muss, um bestmöglich zu funktionieren. Damit sind Fragen rund um die Interoperabilität und somit die Verwendung gemeinsamer Protokolle in einer vernetzten Umgebung von besonderer Wichtigkeit und einer der Kernpunkte. Eine Grid Architektur lässt sich deshalb auch als eine Protokollarchitektur verstehen. Diese definieren die Grundmechanismen mittels derer Benutzer von VO und Ressourcen Beziehungen untereinander ausverhandeln, managen und diese auch nutzen. Solche Standard Protokolle erlauben die Erstellung von (Application Programming Interface) APIs und Software Development Kits (SDK), um die notwendigen Abstraktionen zu schaffen, die eben für ein brauchbares Grid notwendig sind. Die Summe dieser Technologien wird auch als Middleware („the services needed to support a commmon set of applications in a distributed network“) ^[7] bezeichnet.

Interoperabilität

Interoperabilität ist deswegen so wichtig, um sicher zu stellen, dass Beziehungen zwischen den unterschiedlichsten Beteiligten hergestellt, neue Teilnehmer aufgenommen werden können werden, und dies über verschiedene Plattformen, Sprachen und Programmierumgebungen hinweg. Dementsprechend müssen diese Mechanismen so implementiert sein, dass sie über die organisatorischen Grenzen, operationalen Policies und Arten von Ressourcen hinweg agieren können. Andernfalls müssten Anwendungen und Nutzer von VOs bilaterale Beziehungen eingehen da sonst nicht sichergestellt werden kann, dass die genutzten Mechanismen auch auf andere anwendbar ist. Universell eingesetzte Protokolle wie HTTP und HTML sind Beispiele die zeigen, wie der Austausch von Informationen weltweit ermöglicht wurde. Ebensolche Protokolle und Syntax werden im Grid benötigt, um die Möglichkeit des Austausches von Informationen zwischen Ressourcen im Grid zu ermöglichen.

Protokolle

Interoperabilität hängt also stark von den verwendeten Protokollen ab die definieren, wie die unterschiedlichen Elemente in verteilten Systemen miteinander interagieren, um ein bestimmtes gewünschtes Verhalten zu erreichen. Der Fokus liegt damit auf den externen Interaktionen anstatt auf internen Aspekten wie z.B. Software und Charakteristika von Ressourcen was Vorteile mit sich bringt. VOs benötigen Mechanismen die neue Ressourcen finden, Identitäten erstellen, Autorisationen feststellen und neue Aufteilungen initiieren. Die dazu notwendigen Protokolle müssen flexibel und leichtgewichtig sein, um Ressourcenteilungen so schnell als möglich herzustellen und auch wieder abbauen zu können.

Da VOs sich eher ergänzen anstatt existierende Institutionen zu ersetzen dürfen solche Mechanismen zum Austausch von Ressourcen keine Änderungen der lokal verwendeten Policies erzwingen. Weiters muss gewährleistet sein, dass jede Institution weiterhin die Kontrolle über ihre Resourcen bewahren kann.

Services

sind ausschließlich durch das Protokoll definiert und das Verhalten das es implementiert. Die Definition von Standard Services für Zugriffe auf Berechnungen, Daten, dem Finden von Ressourcen, Co-scheduling, Replizieren von Daten usw. erlaubt Services die von VO angeboten werden zu erweitern, um so weiters ressourcenspezifische Details zu abstrahieren die sonst für die Entwicklung von VO Anwendungen hinderlich wären.

APIs

dienen dazu, die Entwicklung von anspruchsvollen Anwendungen in komplexen und dynamischen Umgebungen zu ermöglichen. Anwender wiederum müssen diese wiederum bedienen können. Robustheit, Richtigkeit, Entwicklungs- und Wartungskosten sind dabei wichtige Anliegen. Standard Abstraktionen, APIs und SDKs können die Entwicklung beschleunigen, verteilte Nutzung von Code ermöglichen und somit die portable Anwendungen ermöglichen. APIs und SDKs sind also ein Zusatz statt Alternative zu den Protokollen. Ohne Standard Protokolle kann Interoperabilität nur auf API Level erreicht werden und das nur durch eine einzige Implementierung die überall eingesetzt wird oder indem jede Implementierung die Details aller anderen Implementierungen kennt. Das ist jedoch für viele interessante VOs undurchführbar. So ist z.B. der Jini Ansatz wo Protokoll Code von remote sites geladen wird keine Lösung. ^[8]

Zusammenfassend ist es wichtig festzuhalten, dass für die Betrachtung einer Grid Architektur zunächst die Identifikation und Definition von Protokollen und Services im Vordergrund stehen, dann die der APIs und SDKs.

Überblick über internationale, europäische und nationale Forschungsprojekte im Grid Computing Bereich

Es existieren eine Vielzahl unterschiedlicher Grid Projekte auf internationaler, europäischer und nationaler Ebene. Im Folgenden wird auf einige dieser Pojekte kurz eingegangen.

Internationale Grid Projekte

Globus/Globus Alliance: Globus Toolkit

Das Globus Toolkit wurde von der Globus Alliance entwickelt. Es ist ein Open Source Software toolkit zur Erstellung von Grid Systemen und Anwendungen.

Die drei Hauptfunktionen sind Execution, Data und Information Services. Diese basieren auf einer Public Key Infrastrukture (PKI).

Die erste produktive und somit weit verbreitete und eingesetzte Version war die Version 2. Diese implementierte drei Funktionen durch drei unabhängige TCP/IP Server die via Sockets über selbst definierte Protokolle kommunizierten. Globus Ressource Allocation Manager (GRAM) stellt eine Laufzeitumgebung zur Verfügung. GridFTP ist ein hochperformantes, sicheres und verlässliches Datentransferprotokoll das für wide-ares Netzwerke mit hoher Bandbreite optimiert ist. Das Monitoring und Discovery Service (MDS) ist ein LDAP Verzeichnisdienst und stellt die Informationsservicekomponente des Globus Toolkit 2 (GT2) dar. Die von Foster vorgestellte Grid Protokoll Architektur, die die Wichtigkeit der Standardprotokolle herausstreicht, um VO zu realisieren, wird in dieser Implementierung der Protokolle umgesetzt. Viele andere Grid Projekte wenden diese Version des Toolkits an.

Die Open Grid Service Architecture (OGSA) beschreibt einen Service Bus, um die Grid Infrastruktur mit allgemeinem Verhalten und Semantik erstellen zu können, während die Open Grid Service Infrastructure (OGSI) Spezifikation die Schnittstellen eines Grid Services definiert. Da OGSI zu proprietär war, um in größerem Rahmen verwendet zu werden, wurde sie durch die Web Services Resource Framework (WSRF) neu spezifiziert. WSRF sind im Globus Toolkit Version 4 (GT4) verfügbar und sind als reine Web Services spezifiziert.

Gridbus

Dieses Projekt ist ein technisch orientiertes Entwicklungsprojekt für Next-Generation Cluster und Grid Technologien die echtes Utility-driven Service Oriented Computing unterstützen. Der Name leitet sich vom Forschungsthema ab, Next-Generation GRID Computing and BUsiness Technologien.

Das Gridbus Projekt bietet, ähnlich wie Globus, Komponenten, um ein Grid zu erstellen. Zusätzlich werden ausgeklügelte Services angeboten:

.NET basiertes Grid Framework (Alchemi)
Grid Market Directory (GMD)
Resource Usage Accounting (GridBank)
Grid Portals (G-monitor, Gridscape)

Legion

Hierbei handelt es sich um ein objektbasiertes Metasystem, entwickelt an der University of Virginia. Es wurde designed, um Millionen Hosts und Trillionen Objekte miteinander über Hochgeschwindigkeitsleitungen zu verbinden.

Im Gegensatz zu Globus, dessen Architektur als Summe von Services verstanden werden kann, stellt Legion eine integrierte Architektur dar, d.h. die Struktur der höheren Ebenen basiert auf einem einzigen vereinten Objektmodell.

Die Firma Avaki bietet Legion Software kommerziell an und integriert auch Enterprise Information Systems. Im Jahr 2005 wurde Avaki von Sybase gekauft.

UNICORE

Uniform Interface to Computing Resources ist eine Middleware, um transparenten und sicheren Zugriff auf High Performance Computing Resourcen zu erlauben. Die Entwicklung von UNICORE wurde bereits 1997 als deutsches Forschungsprojekt gemeinsam mit Siemens, IBM und Hitachi HP gestartet. Weitere Entwicklungen wurden in European Grid Project EUROGRID, GRIP und OpenMolGRID unternommen.

Die Software ist als Open Source Software via SourceForge verfügbar und wird vom UNICORE Form vorangetrieben.

Europäische Grid Projekte

Die europäische Forschung im Grid begann mit der Deklaration der Lissabon Strategie im Jahr 2000. Ziel war Europa bis 2010 in die am meisten kompetitive, wissensbasierte Ökonomie zu transformieren. Dazu wurden die sog. Framework Programs (FP) initiiert, um die Forschung und Entwicklung in den unterschiedlichen zu stärken. Diese Programme laufen üblicherweise einige Jahre lang.

Die ersten Grid Projekte die von der EU unterstützt wurden liefen unter FP5. Die folgenden drei Projekte stehen repräsentativ für FP5, stellen also zugleich einen kurzen historischen Abriss dieser Zeit dar.

GRIA

In diesem Projekt standen die Entwicklung von Geschäftsmodellen und Prozessen die eine kosteneffiziente und effektive Nutzung von Rechenzeit in einem offenen Grid Marktplatz zur Verfügung stehen, im Vordergrund. Dieser Grid Marktplatz und die dazu entwickelten Modelle sollten weiters helfen, die Nachfrage nach Ressourcen besser zu nutzen und zu verwalten. Da die Grid Middleware zu dieser Zeit noch nicht ausgereift genug war, um verlässliche Anwendungen anbieten zu können, wurden Web Services entwickelt, die diese Funktionalitäten anboten. Zu den weiteren Entwicklungen gehörten Performance Abschätzung, QoS, Workflows, Cluster Management, Security sowie die Semantik für Interoperabilität.

EU Data Grid

Hier standen die Entwicklung von Techniken zur Verarbeitung und Datenspeicherung wie sie für Next Generation Scientific Research benötigt werden im Vordergrund. Die dazu notwendige Infrastruktur sollte rechenintensive Analysen von groß angelegten shared Datenbanken ermöglichen. Die Dimensionen bewegten sich im Bereich von mehreren hundert TerraBytes bis PetaBytes, verteilt über unterschiedliche wissenschaftliche Communities.

Es mussten drei unterschiedliche Typen von Ressourcen verwaltet werden. Computing, Storage und Network wofür 12 WPs eingerichtet wurden.

GEMSS

Die Entwicklung von neuen sog. Grid-enabled Werkzeugen zur Verbesserung der Diagnose, der operativen Planung und chirurgischer Prozeduren.

Dazu wurde eine innovative Middleware entwickelt die benutzt werden kann, um Medizinern und Forschern bei Zugriff auf hochentwickelte Simulationen und Bildverarbeitungsdiensten, eine verbesserte vor-operative Planung und Unterstützung bei chirurgischen Eingriffen in nahezu Echtzeit zu ermöglichen.

Dazu wurde auf existierende Grid und Web Technologien gebaut die den notwendigen Standards entsprechen, somit künftige Erweiterungen und Interoperabilität ermöglichen bzw. gewährleisten. Dazu wurde auch eine Testumgebung entwickelt, die die Evaluierung und Validierung der GEMMS Umgebung ermöglichte und auch die Einbindung der Arbeitsumgebungen der damit arbeitenden Leute erlaubte. Des weiteren berücksichtigte GEMSS Fragen rund um Privacy, Sicherheit, Fehlererkennung und Wiederherstellung im Fehlerfall. Auch rechtliche Aspekte wurden berücksichtigt, also aktuelle gesetzliche Entwicklungen und EU Regulationen.

Nationale Grid Projekte

UK eScience

Unter der UK Regierung finanziert ist das UK eScience Schirmprojekt für verschiedene Grid Projekte für unterschiedlichen Anwendungen und Use Cases. Dazu zählen Projekte in den Bereichen Astronomie, Physik, Biologie, Chemie, dem Ingenieurswesen, Finanz und Gesundheit.

OGSA-DAI

Der Fokus richtet sich hier auf die Entwicklung entsprechender Middleware, um den Zugriff und die Integration von Daten aus unterschiedlichen Quellen für das Grid zu ermöglichen. Hierbei stehen im Vordergrund die Identifikation von Rahmenbedingungen, Designentscheidungen, und die Erstellung bzw. Bereitstellung von Software um dies zu erreichen.

TeraGrid

wurde bereits 2004 abgeschlossen und stellte 40 Teraflops Rechenleistung und knapp 2 Petabyte an Speicher dar. Es stellte spezielle Datenanalyen, Visualisierungsressourcen sowie 10-30 Gigabits/s Netzwerkverbindungen zur Verfügung. TeraGrid wurde durch die Grid Infrastructure Group (GIG) an der University of Chicago koordiniert.

Austrian Grid

Dieses Konsortium vereint führende Forscher in unterschiedlichen Bereichen wo fortgeschrittene Computertechnologien mit Partnern im Bereich Grid-abhängiger Anwendungen vereint werden.

Ziel ist die Forschung im Bereich Grid-Computing in Österreich ganz allgemein zu unterstützen und Entwicklungen sowie Kooperationen zwischen verschiedenen Forschungsinstitutionen zu koordinieren.

Das Austrian Grid Projekt wird vom Ministerium für Wissenschaft und Forschung gefördert.

Webservices – Anbieten, Verhandeln und Abarbeiten

In den letzten 10 Jahren hat das Web die Art und Weise verändert wie wir leben. Das war aber erst der Anfang. Das Web ist eine einfache, allgegenwärtige aber bis dahin wenig beachtete Plattform für verteilte Programmierung. Warum wenig beachtet? Nun, die meisten heutigen Webservices haben eigentlich nicht sehr viel mit dem Web zu tun. Im krassen Gegensatz zu seiner Einfachheit bringen diese eine schwergewichtige Architektur für einen verteilten Objektzugriff wie einst COM oder CORBA zu Tage. Viele Webservice Architekturen erfinden die Funktionalitäten des Web neu oder ignorieren diese die das Web so erfolgreich gemacht hat.

Aber das muss nicht so sein. Die nutzvollen Funktionen die Remote Services erfolgreich machen sind uns bekannt. Diese Services existieren bereits und wir benutzen sie jeden Tag. Und diese Services können riesig werden, z.B. die Google Suchmaschine. Was ist das anderes als ein Remote Service, um eine Datenbank abzufragen und eine schön formatierte Antwort zurückzubekommen? Wir denken über Webservices normalerweise nicht als „Services“, weil das Programmierer-vokabular ist und der letztendliche Client einer Web Seite ein Mensch ist, aber ein Service ist es immerhin.

Jede Web Applikation, jede Webseite, ist ein Service. Diese Macht kann man für programmierbare Applikationen nutzen, wenn man anstatt gegen das Web mit Web arbeitet und wenn man es nicht begräbt unter zahllosen Ebenen der Abstraktion. So sollte man dem Web die Webservices zurückgeben (siehe O’Reilly RESTful Services [B4]).

REST

Web Services werden meist mit SOAP oder XML-RPC in Verbindung gebracht. Aber auch mit dem sogenannten REpresentational State Transfer oder kurz REST, einem Architekturstil, können Web Services auf einfache und effektive Weise entwickelt werden.

„Der Begriff Representational State Transfer bzw. das Akronym REST bezeichnen einen Softwarearchitekturstil für verteilte Hypermedia-Informationssysteme wie das World Wide Web. Während dessen Architektur durch den URI-Standard und HTTP beschrieben werden kann, legt der REST-Architekturstil nahe, jede Ressource mit einer eigenen URI anzusprechen.

REST stammt aus der Dissertation von Roy Fielding aus dem Jahre 2000, in welcher der Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückgeführt wird. Fielding war zuvor auch an der Spezifikation des Hypertext-Transfer-Protokolls (HTTP) beteiligt.

Der Begriff wird auch im weiteren Sinne verwendet, um grundsätzlich einfache Schnittstellen zu kennzeichnen, die Daten über HTTP übertragen, ohne etwa eine zusätzliche Transportschicht wie SOAP oder Sitzungsverwaltung über Cookies einzusetzen.

REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die Implementierungen verteilter webbasierter Systeme vereinfachen soll.“ – Aus Wikipedia April 2010

REST meint: Das Web ist einfach

Internet Datenverkehr besteht noch immer hauptsächlich aus E-Mail (vielen Dank an alle Spammer) und Filesharing. Daten-Streaming ist gerade am Aufholen, siehe YouTube. Wenn es also das Internet morgen nicht mehr gäbe, würden die Menschen vor allem Ihre E-Mails vermissen. Wozu brauchen wir dann das Web im Allgemeinen? Warum ist HTTP so gut geeignet für Web Services wo es doch eigentlich dazu gedacht war Projekttexte in einem Physiklabor (CERN;-) hin und herzuschicken? Nun weil es einfach und efektiv ist. In frühen Zeiten wurden HTTP und HTML einfach nur als ein schlechter Witz der Datenübertragung gesehen. Und die allererste Version von HTTP sah wirklich ein wenig danach aus:

Client Request	Server Response
GET /hello.txt	Hello, world!

Das war alles. Man verbindet sich mit dem Server, gibt den Pfad zu einem Dokument an und der Server sendet den Inhalt des Dokumentes zurück. Viel mehr konnte man mit HTTP 0.9 nicht anfangen. Es war ein mehr oder weniger funktionsloser Abklatsch von Protokollen wie FTP. Aber genau dieses Fehlen von speziellen Funktionen prädestiniert es für verteilte Programmierung. Man sagt was man will und bekommt es. Die Einfachheit von HTTP ist seine Stärke.

Adressierbarkeit und „Statusfreiheit“ besser Statelessnes sind die beiden Designentscheidungen die HTTP so erfolgreich machten. Diese Eigenschaften machen es auch heute noch zu einem gut skalierenden Protokoll auf für „Mega-Sites“. Viele Funktionen die in HTTP 0.9 fehlen haben sich als unnötig erwiesen und würden das Web nur entstellen, wenn man sie hinzufügen würde. Die restlichen wichtigen Mechanismen wurden mit der Version 1.0 und 1.1 eingefügt. Die beiden verbleibenden Mechanismen die das Web so erfolgreich gemacht haben sind URIs und HTML; später auch noch XML. Auch diese Standards sind einfach in ihrem Kern und dabei effektiv und pragmatisch aufgebaut. Sie sind somit wichtig fürs Web. Offensichtlich sind diese einfachen Technologien mächtig genug das Web und dessen Applikationen am Laufen zu halten. Das World Wide Web ist eine einfache und flexible Umgebung für die Bedürfnisse von sowohl Menschen die konsumieren und produzieren als auch für Maschinen die miteinander kommunizieren.

Große Webservices sind nicht einfach

Es existieren eine Reihe von Protokollen und Standards die, meist auf HTTP aufbauend, dafür gemacht wurden, um Webservices zu bauen. Diese Standards werden zusammengefasst unter dem WS-* Stack. Dieser schließt WS-Notification, WS-Security, WSDL und SOAP mit ein. Etwas lachs könnte man diese als die großen oder fetten Webservices bezeichnen. Komplexe Webservices basieren meist auf diesen Protokollen. Für die meisten Szenarien kann man aber einfach nur die RESTful Architektur, also HTTP und sonst nichts anwenden und kommt zu einem guten Ergebnis.

Die REST Architektur und die Resource Oriented Architecture (ROA) sind kompatibel mit einigen WS-* Standards. Diese WS-* Standards werden dazu benutzt, um Remote Procedure Calls über HTTP abzusetzen. Manchmal ist so ein RPC Stil angemessen. Was aber Probleme aufwirft ist die damit verbundene Komplexität. Allzu oft werden die großen/fetten Webservices angeboten, wo doch das gute alte HTTP den Job genauso gut hätte erledigen können. Der Effekt der dabei eintritt ist, dass HTTP auf ein Transportprotokoll reduziert wird, welches eine riesige Masse an XML Information überträgt die dann beschreiben was „eigentlich“ an Stelle des HTTP Requests passieren soll. Der daraus resultierenden Service ist komplex, nur schwer zu debuggen und wird außerdem wohl nur dann richtig funktionieren wenn all Clients das gleiche Setup besitzen wie das der Entwickler.

Große Webservices haben den Vorteil, dass moderne Tools den zugehörigen Code mit einem Klick produzieren können, besonders wenn man in Java oder C# implementiert. Wenn man solche Tools verwendet scheint es nicht wichtig die einfacheren RESTful Methoden zu verwenden. Die Tools verstecken die Komplexität und Bandbreite und Rechenzeit ist billig.

Diese Einstellung funktioniert, wenn man in einer homogenen Umgebung arbeitet, hinter der eigenen Firewall oder der von „befreundeten“ Gruppen. Also z.B. im Intranet einer Produktionsstätte. Aber wenn die Services, und vor allem deren Benutzung, sich im gesamten Internet ausbreiten sollen, dann muss man Client Programme berücksichtigen von denen man vielleicht nie etwas gehört hat. Die Benutzer des eigenen Service wollen vielleicht, dass dieser mit anderen unbekannten Services interagiert. Man muss dann proprietäre Mapping Software erstellen, damit andere den Service in einer Weise verwenden können, über die die Entwickler selbst nicht nachgedacht haben. Nun, das ist das tägliche Brot in der Welt der Webprogrammierer.

Abstraktionen echter Funktionalität sind niemals perfekt. Jeder zusätzliche Layer erzeugt Fehlerquellen, Probleme bei der Zusammenarbeit, und Skalierbarkeitsprobleme. Neue Werkzeuge können Komplexität verstecken aber nicht rechtfertigen – und sie erzeugen immer noch mehr Komplexität. Um einen Service zum funktionieren zu bringen muss man das Web als ganzes im Sinn haben, das bedeutet man muss Adaptierbarkeit, Skalierbarkeit und Verwaltbarkeit berücksichtigen. Die Einfachheit und Qualität von HTTP 0.9 sind Grundvoraussetzungen für diese Anforderungen. Je komplexer ein System ist, desto schwieriger wird es dieses zu reparieren oder zu erweitern wenn etwas schief geht oder neue Anforderungen erfüllt werden müssen.

Wenn man nun RESTful Webservices anbietet, kann man die entstehende Komplexität dazu einsetzen, um zusätzliche Funktionalität anzubieten oder um mehrere Services miteinander reden zu lassen. So ist ein erfolgreicher Service ein Teil des Web aber setzt nicht darauf auf oder benutzt es. Die Information, der Dienst, sollte verfügbar gemacht werden, nach den Regeln die all die anderen Sites im WWW anwenden. Je näher man dabei an den Basis-Web-Protokollen ist desto einfacher wird es.

Grundlagen moderner Webservices

Web Services sind ein aussichtsreicher Versuch, Service Oriented Architecture Prinzipien praktisch umzusetzen, sie stellen die technische Realisierung der SOA dar.

Den Web Services ereilte allerdings ein ähnliches Schicksal wie den Web-Portalen als um die Jahrtausendwende die Dotcom Blase geplatzt ist. Sie wurden schnell berühmt, tauchten im Gartner Hype Cycle auf und jeder versteht darunter etwas anderes. Mit dem Auftauchen eines neuen Paradigmas, des Cloud Computing welches später in diesem Skriptum behandelt wird scheinen die Webservices allerdings Ihre Bestimmung endgültig gefunden zu haben.

Die vielen Definitionen darüber, was einen Webservice zu einem solchen macht gehen leicht auseinander, je nachdem wer diese anbietet.

Das SaaS Konzept

Software as a Service (SaaS) ist eine Form von Cloud Computing, bei der Nutzer eine Applikation über das Internet beziehen. Dabei werden Infrastruktur-Ressourcen und Applikationen zu einem Gesamtbündel kombiniert. Nach ihrem Wesen, Applikationen situativ zu nutzen und nutzungsabhängig zu bezahlen, wird SaaS häufig als „Mietsoftware“ bezeichnet.

Aufgrund der Art und Weise, wie die Dienstleistung erbracht wird, passt diese Bezeichnung jedoch nicht: Der Kunde mietet keine Software, vielmehr bezieht er einen Anwendungsservice mit allen Eigenschaften, die ein Service bietet: Abnahme nach Bedarf, leichte Erweiterbarkeit und Bezahlung nach Abnahmemenge. Dieser Service beinhaltet alle für die Nutzung notwendigen Komponenten: Hard- und Software (Lizenzen), Wartung und Betrieb. Die Anbindung an den Dienstleister sowie alle kundenseitigen Komponenten und Aufwände sind nicht enthalten.

Anders als beim Application Service Providing bietet der Dienstleister beim SaaS-Modell nicht für jeden Kunden eine eigene Installation an. Hier nutzen alle Kunden dieselbe Anwendung und Infrastruktur, die sich bei einem Dienstleister befindet. Ein Vorteil eines 1 zu n-Ansatzes ist, dass Änderungen und Erweiterungen, wie z.B. notwendige Updates und Upgrades, die alle Kunden betreffen, nur einmal vorgenommen werden müssen. Dieser hohe Grad an Standardisierung schränkt jedoch die individuelle Anpassbarkeit der Lösung an die jeweiligen Kundenbedürfnisse ein (Industrialisierung von IT).

Anwendungsbeispiele für SaaS:

Da es sich bei SaaS um Standardanwendungen handelt, die bereits für andere Benutzer betrieben werden, sind die Anwendungen „sofort“ verfügbar. Sie sind in Unternehmen einfach und schnell zu testen, zu implementieren und zu verwalten. Vor dem Einsatz sind nur grundlegende unternehmenseigene Einstellungen vorzunehmen. SaaS bildet exemplarisch zwei Aspekte von Cloud Computing ab, die dynamische Skalierbarkeit und den Servicegedanken.

Bereits verbreitete Anwendungsbeispiele für SaaS sind „Communication as a Service“ oder „Collaboration as a Service“. Hierbei bezieht der Nutzer Kommunikations- oder Zusammenarbeitsdienste aus dem Internet. In der Regel verbirgt sich hinter einem solchen Angebot die Palette von Unified Communications-Diensten, also insbesondere Voice over IP-Telefonie und Instant Messaging, aber auch Webkonferenzen und E-Mail.

Unternehmen lagern hierbei also ihre Kommunikations-Infrastruktur an einen Dienstleister aus, der diese als Dienst bereitstellt. Die Schwelle, solche branchenunabhängigen Anwendungsdienste auszulagern, ist gering und kann einen einfachen Start in Cloud Computing markieren. Die in der Regel IP-basierte Kommunikations-Infrastruktur erleichtert zudem die Integration in die Geschäftsprozesse und die Addition zusätzlicher Funktionalitäten.

„Communication as a Service“ markiert einen Zugangspunkt zum Cloud Computing von der Seite der Telekommunikation.

Collaboration as a Service (ColaaS) kann als Weiterentwicklung von Communication as a Service verstanden werden. Hier steht der gemeinsame Zugriff auf Dokumente im Vordergrund, so dass Arbeitsgruppen eine Basis für ihre gemeinsame Arbeit erhalten – über Grenzen und Zeitzonen hinweg. Solche kollaborativen Organisationsformen verbreiten sich immer mehr. Die Basiskommunikation in solchen Systemen liefert das E-Mail-System, das entweder Bestandteil des Angebots ist oder via Standardprotokoll von anderen Anbietern mitgenutzt werden kann. Bestandteile eines „Collaboration as a Service“-Angebots können darüber hinaus sein: Kalender, Adressverwaltung, Instant Messaging/Chat, Telefonie, Web- und Video-Conferencing, Team-Sites oder Blogs/Wikis/Foren.

Begriffsdefinition Webservice

Die Web Services Architecture Arbeitsgruppe der W3C deﬁniert Web Services als:

”Ein durch eine URI (nach RFC2396) identiﬁziertes Softwaresystem, dessen öffentliche Schnittstellen und Protokollbindungen durch XML deﬁniert und beschrieben sind.“

Eine etwas pragmatischere Definition aus der Industrie lautet:

”A Web Service is a piece of server-side software that provides a certain functionality (as a black box) and is accessible through Internet protocols using XML/SOAP messages with a described and published interface (typically by means of WSDL). Those interface descriptions should be registered in a (global) registry such as UDDI.“ -siehe [P11]

Und weitere Definitionen aus dem „Programmierervolksmund“ lauten:

Webservices sind nichts wirklich neues, aber stellen einen neuen Ansatz dar, um die Fehler der Vorgängertechnologien zu mindern. Sie basieren auf modernen und offenen Standards und eignen sich nur für eine Computer zu Computer Kommunikation. Dabei benötigen sie ein Transportprotokoll, und unabhängig von der Programmiersprache und dem Betriebssystem. Letzteres ist nur idealer Weise richtig und gilt für die Verwendung von Webservices, nicht aber unbedingt für deren Implementierung.

Der Ausgangspunkt der Entstehung von Webservices geht eigentlich zurück auf die Zeit in der Mensch zu Mensch Kommunikation, also das Verschicken von (unstrukturiertem) Text via E-Mail. Als nächster Schritt kam dann das WWW, die Mensch zu Computer Kommunikation, bei der der Mensch konsumiert, und im Web2.0 auch produziert, und der Computer passiv bleibt (abgesehen von der dynamischen Aufarbeitung der zu präsentierenden Information) . In der dritten Phase treten nun die Webservices auf, die Computer zu Computer Kommunikation bei der ein Computer eine Dienstleistung für einen anderen Computer erbringt. Darüber hinaus verfolgt das Semantic Web die Vision wobei die beteiligten Computer sich gegenseitig „verstehen“ und „wissen“ was ihnen von anderen Computern angeboten wird. Die Dienste bieten nicht nur eine Schnittstelle mit deren syntaktischer Beschreibung an, sondern darüber hinaus auch noch semantische Metadaten die vom Benutzer verstanden werden können.

Eigenschaften von Webservices

Web Services ermöglichen die Kommunikation zwischen verschiedenen heterogenen Systemen und erleichtern dabei die Integration von existierender Soft- und Hardware in neue Systeme. Webservices agieren als Fassade, Stellvertreter oder Proxy für eine Menge von sich hinter dem Service Interface verbergenden Anwendungen. Es gibt zwei Protokollvarianten für Webservices: Dokument und RPC, wobei letztere Variante eher veraltet ist und in der Praxis bei neuen Deployments nicht mehr eingesetzt wird. Zur Beschreibung der Service Schnittstellen und der zu übertragenden Daten kommen hauptsächlich, ja fast ausschließlich, XML Protokolle wie SOAP oder XML-RPC vor und als unterliegendes Übertragungsprotokoll kommt zur Zeit hauptsächlich HTTP und HTTPS zum Einsatz. Daraus geht hervor, dass Webservices eigentlich nur für die Computer zu Computer oder „Machine to Machine“ (M2M) Kommunikation gedacht sind. Dabei ermöglichen sie einen leichteren Zugriff auf sonst unerreichbare Systeme, unter anderem auch den Aufruf über Firewalls hinweg die nur den Port 80 für HTTP Verkehr offen halten. Letzteres hat den Effekt, dass strikte Schutzmechanismen sich nun auch noch den Inhalt der HTTP Nachrichten ansehen müssen, um einen unerlaubten Kontakt zu verhindern.

Service Interface und Implementation, XML als Basis für SOAP

Das implementieren eines Dienstes als Webservices ist verhältnismäßig einfach, unabhängig davon, ob es sich dabei um einen Client oder einen Server handeln soll.

Folgende bekannte Bibliotheken zur Erstellung von Webservices basieren auf dem SOAP Protokoll:

Apache AXIS
Perls SOAP::Lite
Pythons pywebsvcs
Rubys Webservice Framework für Ruby-on-Rails
.NET Framework
Systinet
IBM: ETTK
Sun: WSDP
Cape Clear

Wenn es jedoch dazu kommt, komplexe standardisierte Dienste zu implementieren die mit Hilfe eines WSDL Dokumentes definiert werden sollen, muss dann meist dieses WSDL Dokument per Hand erstellt werden, was ebenso komplex sein kann wie das Programmieren selbst. Für den Alltag allerdings gibt es genügend Tools welche alle notwendigen WSDL Dateien Client Stubs und Server Skeleton Klassen automatisch erstellen.

Typischer Webservice Aufruf

Um Webservices implementieren zu können sollte man die Prinzipien des SOAP Protokolls kennen und um dies wiederum leichter zu verstehen kommt man nicht umhin, sich mit speziellen XML Themen auseinanderzusetzen.

XML ist, die eXtensible Markup Language, ist ein Ableger von SGML, dem Vater aller Markup Sprachen (auch HTML). XML ist eine Metasprache die die Grundlage von Web Services, basierend auf SOAP oder einfach nur XML-RPC. Dabei bietet XML die Möglichkeit, strukturierte Dokumente zu erzeugen (SOAP request/response, WSDL oder UDDI Dokumente). Es wurde von der W3C standardisiert und die Verwendung ist frei. Es gibt viele Erweiterungen zum Basis XML Standard, einige davon sind essentiell für die Definition und Verwendung von Web Services. Für SOAP sind folgende Themengebiete wichtig: XML, Information Set (oft auch nur InfoSet), Namensräume, Schema, XPath, Signature und Encryption.

XML Information Set

Das XML Information Set ist eine mögliche Darstellung von XML Dokumenten bei dem jedes XML Dokument einem Information Set entspricht. Die vollständige Information des Dokuments wird dann als Baum dargestellt. Die Wurzel des Baums ist das „Document Information Item“. Dieses kommt daher auch nur genau einmal vor.

XML Namensräume

Es gibt für XML eine eigene Speziﬁkation (Recommendation), die: „Namespaces in XML“. Diese wurde ein Jahr nach der ersten XML Version veröffentlicht als eine Lösung zu dem Problem der identischen Bezeichner. Das Problem ist vergleichbar mit dem von identischen Variablennamen bei der Programmierung. Das Problem ist vor allem bei der Wiederverwendung von XML-Strukturen evident und wird durch die Verwendung einer URI als Präﬁx (URLs sind echte Teilmenge der URIs) gelöst (Beispiel: Das Präfix ffh: wird allen FernFh relevanten XML Tags vorausgestellt und das Präfix selbst dann über die komplette Angabe der URL www.fernfh.at definiert. Dadurch können XML Tags weltweit eindeutig bezeichnet werden).

XML Schema

Die XML Schema Description Language (XSD) ist vermutlich die wichtigste Sprache zur Formulierung von beliebigen aber „wohlgeformten“ XML Strukturen. XSD bildet zusammen mit XML 1.0 (2nd Edition) und den Namensräumen die Basis für zukünftige Entwicklungen um XML. Ein XML Schema ist ein XML Dokument, welches die Struktur von XML Dokumenten beschreibt. Ein XML Dokument bewertet man als gültig hinsichtlich eines bestimmten Schemas dem ein Dokument entspricht welches über ein solches Schema verfügt und einen zu diesem konformen Aufbau hat.

XML XPath

XPath erlaubt es, nicht nur den ”Ort“ eines XML Dokumentes, sondern auch ein Element innerhalb eines XML Dokumentes anzugeben Damit können Teile eines Dokumentes lokalisiert oder extrahiert werden XPath kann dadurch für lesende Anfragen und Suchen (via XQuery) genutzt werden. XPath wird auch in Verbindung mit XSLT, zum transformieren von XML Information verwendet.

XML Beispiel:

<name>

<first>Oliver</first>

<last>Jorns</last>

</name>

<country>Austria</country>

</person>

<name>

<first>Joachim</first>

<last>Zeiss</last>

</name>

<city>Sopron</city>

<country>Ungarn</country>

</person>

</addresses>

SOA

Ein zentrales Versprechen welches Web Services geben, besteht in der erhöhten Flexibilität und Agilität, die sich durch die verschiedenen Möglichkeiten ergibt, Dienstleistungen im Internet zu nutzen bzw. mit Hilfe aus dem Internet zu realisieren. Mit diesem Anspruch und dem Ziel, die IT-Welt zu revolutionieren, ist vor Jahren das Paradigma der service-orientierten Architektur (SOA) angetreten. Viele Anwender haben begonnen, SOA-Initiativen zu realisieren und denken darüber nach, wie SOA im Kontext von Cloud Computing einzuordnen ist.

Es ist notwendig, die Begriffe zu präzisieren und unter dem Gesichtspunkt der jeweiligen Architektur zu betrachten. Eine stringent implementierte service-orientierte Architektur schafft erst die Voraussetzung dafür, verteilte, lose gekoppelte Dienste von Cloud Anbietern zu nutzen und zu orchestrieren, insbesondere über Abteilungs- und Unternehmensgrenzen hinweg oder wenn Private Clouds mit Public Clouds oder klassische IT-Infrastruktur im Unternehmen kombiniert werden sollen (hybride Architekturen). Ohne die Modularisierung und Kapselung von Technologie, die durch eine SOA geschaffen wird, können höherwertige Cloud-Dienstleistungen nicht genutzt werden, sondern lediglich Infrastruktur-Dienstleistungen also Infrastructure as a Service (siehe Lektion über Cloud Services).

Wenn Cloud Computing über „Infrastructure as a Service“ hinausgehen will, dann ist das Architekturkonzept einer SOA als Grundlage unverzichtbar, denn SOA erlaubt es Unternehmen, Applikationen in einzelne Dienste (Services) zu zerlegen, die jeweils einen realen Geschäftsvorgang abbilden und auf Basis standardisierter Schnittstellen interoperabel eingesetzt werden können. Eine SOA ermöglicht es, diese Dienste auf einfache Weise zu kombinieren, so dass Veränderungen in Geschäftsprozessen softwareseitig schnell nachvollzogen werden können. Dies bedeutet, dass die IT-Strategie schneller an eine veränderte Geschäftsstrategie eines Unternehmens angepasst werden kann und somit zu mehr Flexibilität, Agilität und gesteigerter Wettbewerbsfähigkeit beitragen kann.

Insofern stehen SOA und das später in diesem Heft behandelte Cloud Computing nicht in Konkurrenz zueinander. Cloud Computing ist nicht die nächste Evolutionsstufe von SOA, sondern es handelt sich um zwei einander ergänzende, orthogonale Konzepte. Beide Konzepte zusammen werden in den nächsten Jahren die Business- und IT-Anforderungen, also den Austausch und die verteilte Verarbeitung von Unternehmensinformationen in globalen Wertschöpfungsnetzen, beeinflussen.

SOAP

SOAP bedeutet „Simple Object Access Protocoll“. Eine euphemistische Namensgebung, denn im Vergleich zu anderen Methoden wie RESTful Services oder XML RPC ist SOAP alles andere als einfach. Einfach zu verwenden ist es nur durch die Unmenge an Tools und IDEs die dieses Protokoll mittlerweile exzellent unterstützen.

SOAP 1.0 wurde im Herbst 1999 von DevelopMentor, IBM, Microsoft, Lotus und UserLand Software veröffentlicht. Version 1.1 wurde Anfang 2001 als W3C Note eingereicht. Die Idee, entfernte Funktionsaufrufe mit einem XML Vokabular zu ermöglichen, wurde dabei von XML-RPC übernommen. Wie bereits gesagt stand damals SOAP für ”Simple Object Access Protocol“ wobei es aber weder einfach ist noch erlaubt es einen echten Zugriff auf Objekte. Daher steht SOAP mittlerweile nur für SOAP als Kunstwort und nicht mehr als Akronym für Simple oder Objekt ...

Die aktuelle Version, SOAP 1.2 (seit April 2007), ist eine W3C Recommendation. SOAP unterstützt das Versenden von synchronen und asynchronen Nachrichten an Dienste. und ist dabei Transportprotokoll unabhängig. Meistens wird SOAP allerdings via HTTP oder HTTPS übertragen (vergleiche []).

Das SOAP Protokoll (incl. SOAP über HTTP)

Das XML-Vokabular SOAP stellt die Basis vieler Web Services dar. Es existieren auch Definitionen von Webservices welche nur SOAP Schnittstellen als solche akzeptieren. SOAP ist ein Protokoll; bestehend aus Nutzdaten und Verwaltungsinformationen (wie zum Beispiel Routing Daten). Es benötigt ein Transport-Protokoll, meist HTTP. Je nach Anwendung bieten sich aber auch SMTP (asynchron), FTP (für umfangreiche Nutzdaten) oder direkt TCP (für hohe Performanz) an. Die aktuelle Version, SOAP 1.2, ist eine W3C Recommendation (siehe http://www.w3.org/TR/soap12-part0/ .../part1 und .../part2 (vergleiche auch [P11]).

Die SOAP Nachricht

Einfaches Beispiel einer SOAP Nachricht, welches die wesentliche Struktur eines Requests zeigt, sieht wie folgt aus:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22>

<env:Header>

<n:hello xmlns:n="http://example.org/hello%22>

<n:expires>2003-10-28T18:00:00+01:00</n:expires>

<n:someint>1</n:someint>

</n:hello>

</env:Header>

<env:Body>

<my:message xmlns:my="http://www.mycompany.com/myns%22>

<my:text>Hello World!</my:text>

</my:message>

</env:Body>

</env:Envelope>

Jede SOAP Nachricht besitzt folgende Elemente (unabhängig davon, ob es sich um Request oder Response, synchronem oder asynchronem Aufruf handelt):

Einen Envelope mit dem Namensraum, bei SOAP 1.2 ist dies http://www.w3.org/2003/05/soap-envelope Dort gibt es auch das Schema.
Einen optionalen Header mit Verwaltungsinformationen und evtl. benutzerdeﬁnierten Feldern.
Einen Body mit mindestens einem Element. Der Body enthält die gesamten Nutzdaten.

Der SOAP Header

Der SOAP Header enthält Verwaltungsinformationen und Metadaten. Für die Header Elemente gilt, dass diese keine Nutzdaten enthalten, diese oft nicht nur für den (endgültigen) Empfänger angegeben werden und dass diese nicht von SOAP-Knoten verarbeitet werden (außer das Attribut mustUnderstand == true siehe unten). Typische Header Elemente sind Routinginformationen, Transaktionsdaten, Zugriffsdaten wie Name und Passwort (letztere sollten aber verschlüsselt sein, z.B. via WS-Security).

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22>

<env:Header>

<n:ext xmlns:n="http://example.org/ext%22 env:mustUnderstand="true">

<n:someint>1</n:someint>

</n:ext>

<m:ext2 xmlns:m="http://example.org/ext2%22 env:role="http://www.w3.org/2003/05/soap-envelope/role/next%22

env:mustUnderstand="true">

<m:someint>1</m:someint>

</m:ext2>

</env:Header>

<env:Body>

<my:message xmlns:my="http://www.mycompany.com/myns%22>

<my:text>Hello World!</my:text>

</my:message>

</env:Body>

</env:Envelope>

Beachtung und Verarbeitung von Header-Elementen ist optional, außer das Attribut mustUnderstand ist logisch wahr, also true oder 1. Kann ein SOAP-Knoten ein Header-Element in einem solchen Fall nicht bearbeiten, so muss dieser einen SOAP-Fault erzeugen und an den Sender zurückschicken. Ein SOAP-Knoten ist jeder Rechner zwischen Sender und Empfänger, der SOAP versteht.

Einschränkungen werden durch das Attribut role bestimmt. Im gegebenen Beispiel (oben) muss das Element ext2 nur vom Knoten http://example.org/ext2 verstanden werden. Dieser Knoten wird nach Bearbeitung das Element aus der Nachricht löschen. Andere mögliche Rollenattribute sind ultimateReceiver oder none.

Der SOAP Body

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope%22

xmlns:b="http://www.fernfh.at/AddService>

<env:Body>

<b:add env:encodingStyle="http://www.w3.org/2003/05/soap-encoding

<b:a>2</b:a>

<b:b>3</b:b>

</b:add>

</env:Body>

</env:Envelope>

Jede SOAP Nachricht muss einen Body mit mindestens einem Element haben welches aus einem anderen Namensraum als dem von SOAP stammen muss. Dies ist für eine eventuelle Überprüfung des Schemas notwendig. Wie man im Beispiel oben sehen kann beinhaltet der Body alle Nutzdaten, d.h. alle Parameter für einen Service Aufruf beziehungsweise alle Rückgabewerte einer Service Antwort (siehe auch [P11]).

Fehlerbehandlung in SOAP

Entsteht bei einem Web Services Aufruf ein Fehler, so muss ein sog. Soap-Fault an den Sender geschickt werden. Der Body eines Faults besteht nur aus einem fault Element. Dieses muss ein Code und ein Reason Element enthalten. Weitere Elemente wie Detail sind optional. HTTP Fehlermeldungen wie 403 oder gar ein HTTP redirect sind nicht zulässig.

Folgendes Beispiel zeigt einen SOAP Timeout Fehler (siehe [P11]):

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22

xmlns:m="http://www.example.org/timeouts%22

xmlns:xml="http://www.w3.org/XML/1998/namespace%22>

<env:Body>

<env:Fault>

<env:Code>

<env:Value>env:Sender</env:Value>

<env:Subcode>

<env:Value>m:MessageTimeout</env:Value>

</env:Subcode>

</env:Code>

<env:Reason>

<env:Text xml:lang="en">Sender Timeout</env:Text>

</env:Reason>

<env:Detail>

<m:MaxTime>P5M</m:MaxTime>

</env:Detail>

</env:Fault>

</env:Body>

</env:Envelope>

SOAP und WSDL

WSDL ist die Web Services Description Language. Es ist ein XML Vokabular zum Beschreiben von Schnittstellen. Bei Web Services ist eine maschinenlesbare Schnittstellenbeschreibung nicht erzwungen, aber unbedingt empfehlenswert, den unter anderem werden WSDL Definitionen von entsprechenden Tools zur Codeerzeugung verwendet. Andere Tools können aber auch aus einer lokalen Klassendefinition (in welcher Sprache auch immer) ein WSDL Generieren, damit andere Applikationen diese Klasse als Service ansprechen und verwenden können. Entsprechende Beschreibungen dienen auch als Dokumentation für den Dienst an sich.

Die wichtigsten Elemente eines WSDL Dokuments sind :

Interface aller exportierter Funktionen
Deﬁnition der Ein- und Ausgabedatentypen
Binding Information (wie rufe ich den Dienst auf )
Adressangaben (wie genau ﬁnde ich den Dienst)

Ein WSDL Dokument ist wie folgt aufgebaut:

Root-Element: <definitions>
Kind-Elemente bei WSDL 1.1 sind (WSDL 2.0):
<types> enthält die verwendeten Datentypen
<message> gibt an, welcher Nachrichteninhalt übertragen werden kann.
<portType> (interface) Signaturen der Methoden
<binding> liefert Details zur Implementierung inklusive der Protokolle zum Aufruf.
<port> (endpoint, Teil von service)
<service> enthält eine Sammlung von einem oder mehreren Ports: wo überall ﬁnde ich die Services (Server Adressen).

WSDL root element:

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions

targetNamespace="http://localhost/axis/Calc.jws%22

xmlns="http://schemas.xmlsoap.org/wsdl/%22

xmlns:apachesoap="http://xml.apache.org/xml-soap%22

xmlns:impl="http://localhost/axis/Calc.jws%22

xmlns:intf="http://localhost/axis/Calc.jws%22

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/%22

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/%22

xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/%22

xmlns:xsd="http://www.w3.org/2001/XMLSchema%22>

</wsdl:definitions>

WSDL Signatur der Methode:

<wsdl:portType name="Calc">

<wsdl:operation name="add" parameterOrder="a b">

<wsdl:input message="impl:addRequest" name="addRequest"/>

<wsdl:output message="impl:addResponse" name="addResponse"/>

</wsdl:operation>

</wsdl:portType>

WSDL Binding:

<wsdl:binding name="CalcSoapBinding" type="impl:Calc">

<wsdlsoap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http%22/>

<wsdl:operation name="add">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="addRequest">

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/%22

namespace="http://DefaultNamespace%22 use="encoded"/>

</wsdl:input>

<wsdl:output name="addResponse">

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/%22

namespace="http://localhost/axis/Calc.jws%22 use="encoded"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

Aus obigem ergibt sich, dass man den Dienst im RPC-Style über HTTP anspricht und dass es eine Methode add gibt. Ein- und Ausgabe sind auch referenziert.

WSDL Port definition:

<wsdl:service name="CalcService">

<wsdl:port binding="impl:CalcSoapBinding" name="Calc">

<wsdlsoap:address location="http://localhost/axis/Calc.jws%22/>

</wsdl:port>

</wsdl:service>

Der Service rennt auf: localhost Verzeichnis axis und hat den Namen Calc.java

SOAP und UDDI

UDDI bedeutet: Universal (Service) Description, Discovery and Integration. Während WSDL eine rein technische Beschreibung der Schnittstelle bietet ist UDDI ein SOAP basierter Dienst, der die WSDL Information erweitern und ergänzen soll. UDDI kann mit den gelben Seiten einer Telefongesellschaft (oder dem Herold) verglichen werden, also eine Art Branchenbuch für Webservices. Meta-Daten zu den Diensten (z. B. um was für einen Dienst es sich handelt) können erfasst werden. Außerdem werden Suchmöglichkeiten nach Diensten speziﬁziert.

UDDI wird seit Herbst 2000 von Ariba, IBM und Microsoft entwickelt. Es ist ein Register/Broker für Dienste inklusive Beschreibung und Suchmethoden. Wichtige Daten sind Kontaktinformationen, Infos über die Dienste, kategorisierte Listen und Protokoll-Informationen. UDDI besteht aus einem Netzwerk von (UDDI)-Knoten, die via SOAP Informationen austauschen. Dies erlaubt verteiltes veröffentlichen und (hoffentlich auch) ﬁnden von Webservices.

Ein UDDI Verzeichnis und dessen Daten sind intern als Baum strukturiert, wobei einmal mehr XML zur Anwendung kommt. In dieser Struktur gibt es vier wesentliche Elemente:

Firmen (Business-Entity)
Dienste (Business-Service)
Bindungen (Binding-Template)
Technisches Modelle (TModel)

Die ersten drei Elemente bilden die oberen Knoten im Baum und TModels bieten und erlauben Referenzen auf externe Informationen (siehe [P11]).

SOA im Detail

Erklärung und Definition

Die Grundidee von SOA ist Dienste verteilt in einem Computernetz anzubieten. Dienste können von anderen Diensten genutzt werden und so aus einzelnen bekannten Diensten einen neuen mehrwertigen Dienst zusammenstellen. Die Dienste werden veröffentlicht und in Verzeichnissen aufgenommen. Andere Dienste können diese dann ﬁnden und bekommen Informationen darüber, wie man den gefundenen Dienst nutzen kann.

SOA wird oft im Zusammenhang mit EAI (Enterprise Application Integration) unter dem Topic Interoperabilität genannt. Dabei geht es um Integration von alten in neue Systeme. Ein paar Beispiele dazu:

Beispiel 1: Buche einen Flug, reserviere einen Sitzplatz, bezahle den Flug.
Beispiel 2: Automatisches Lager, das automatisch nachbestellt und dabei den billigsten Anbieter sucht.
Beispiel 3: Kühlschrank mit Barcodeleser und automatischer „Lagerführung“ und Nachbestellung im Internet.

Ein möglicher Ansatz zur Umsetzung der SOA Paradigmen sind Web Services.

Es gab bereits einige Ansätze in diese Richtung, z.B. RPC, RMI, DCOM oder CORBA. Diese haben den Nachteil, dass sie abhängig von Betriebssystem oder Programmiersprache sind. Deren Verwendung war oft sehr komplex. Softwaresysteme bestehen mehr und mehr aus kleinen Komponenten, die über immer mehr Rechner verteilt sind, eine Anforderung die mit den oben genannten „alten“ Systemen nicht realisierbar war. Außerdem konnte kaum eine Integration von externen Systemen bei anderen Institutionen (Zuliefererintegration) erstellt werden. Moderne Webservices versprechen diese Probleme via SOAP, WSDL und UDDI diese Probleme zu lösen

Probleme die SOA Implementierungen lösen müssen sind:

Wie ﬁndet man die Funktionalität, die gerade braucht wird?
Wie benutzt man ein Modul, nachdem man es gefunden hat?
Braucht ich bestimmte Soft- oder Hardware, um den Dienst nutzen zu können?
Wie kann man sicherstellen, dass andere den bereitgestellten Dienst überhaupt ﬁnden können?

Rollenvergabe für und Ablauf von Services

Es gibt 3 wesendliche Rollen in einem SOA basierten System:

1. Dienstanbieter

Implementiert den Dienst und publiziert diesen auf einem meist über das Internet zugänglichen Server. Er dokumentiert die Aufrufschnittstelle (das Interface) in einer computerlesbaren Form und ist verantwortlich für die Bereitstellung (hosting).

2. Dienstverzeichnis

Hier werden die von den Anbietern veröffentlichten Schnittstellen in einer katalogisierten Form verwaltet und präsentiert. Ein solches Verzeichnis kann mit den gelben Seiten verglichen werden.

3. Dienstnutzer

Er nutzt den angebotenen Dienst, nachdem dieser meist über einen Verzeichnisdienst gefunden wurde.

In einem SOA Szenario laufen meist folgende Schritte ab:

Ein Anbieter (Service Provider) implementiert einen Dienst.
Der Dienst wird inklusive der Beschreibung veröffentlicht (deployment).
Der Dienst wird bei einem Verzeichnisdienst (Service Broker) registriert (siehe UDDI).
Ein Nutzer sucht im Verzeichnis nach einem Dienst und erhält eine Liste möglicher Kandidaten inkl. Schnittstellenbeschreibung (siehe WSDL).
Der Nutzer ruft einen Dienst mit Hilfe der erhaltenen Informationen auf.

Sämtliche Schritte laufen unter Zuhilfenahme standardisierter Protokolle und einem einheitlichen Datenformat ohne menschliche Interaktion ab.

Praktische Übung

In dieser Übung geht es um die Bereitstellung und Konzeptausarbeitung von Webservices welche dazu verendet werden können um in einem Cloud Computing Szenario eingestzt werden zu können.

Bearbeiten Sie dazu folgende Aufgabenstellung:

Installieren Sie einen EJB und SIP Servlet Server und deployen und testen Sie ein Beispielservice welches über Technologie- und Marktdomänen hinweg eine Gesamtdienstleistung bereitstellt.
Verfassen Sie, basierend auf den Erfahrungen zu Punkt 1, ein formloses Konzeptdokument von circa 10 Seiten in dem Sie eine mögliche Geschäftsidee ausformulieren. Dabei geht es um die Darstellung des Konzeptes und zu möglichen verwendeten Technologien und Designansätzen. Sollte Ihre Idee so fortschrittlich sein, dass sie aus Ihrer Sicht gegenwärtig nicht umgesetzt werden kann, dann diskutieren Sie bitte entsprechende Fragen und Probleme die es zu beantworten bzw. zu lösen gilt, um den Dienst in die Realität umzusetzen

Nähere Erläuterungen zu Punkt 1.:

Installieren Sie den frei erhältlichen Applikationsserver Sailfin. Laden Sie dazu zunächst das Installationspaket herunter unter https://sailfin.dev.java.net/downloads/download_windows.html für Windows, .../download_mac.html für Apple Rechner oder .../donwload_linux.html für Linux. Laden Sie das „Promoted Build“ JAR-File herunter.
Die Vorgehensweise zur Installation und Konfiguration entnehmen Sie bitte folgender Seite: https://sailfin.dev.java.net/downloads/instructions.html
Starten und Testen Sie nun das CallSetup Beispiel, welches zusammen meit dem Server beim Installieren auf Ihren Rechner kopiert wurde. Folgen Sie dabei den Anweisungen auf der Seite https://sailfin.dev.java.net/downloads/sampleinstructions.html
Beachten Sie, dass die Anweisungen zum Starten und Testen auch ausführlich beschreiben, wie die Client-Applikationen installiert und Konfiguriert werden müssen. Es handelt sich dabei um die X-Lite Software die Verwendet wird um SIP basierte Voice und Video Kommunikation durchzuführen.
Testen Sie den Dienst indem Sie die In der Anleitung beschriebene Webseite aufrufen, Zwei Client-Instanzen starten und dann via Klicks auf der Webseite einen Voice-Call initieren.

Cloud Computing: Services auf Wolken

Cloud Computing erlaubt die Bereitstellung und Nutzung von IT-Infrastruktur, von Plattformen und von Anwendungen aller Art als elektronisch verfügbare Dienste, die von verschiedenen Anbietern im Internet erbracht werden. Cloud-Ressourcen werden in der Regel virtualisiert: Der Cloud-Nutzer hat dadurch stets eine wunschgemäße, beliebige Sicht auf Ressourcen. Cloud-Angebote sind darüber hinaus dynamisch skalierbar: ein zusätzlicher oder geringerer Ressourcen-Bedarf kann schnell und ohne großen Aufwand automatisch geregelt werden. Cloud Computing folgt den Ideen des Utility Computing, d.h. es wird immer die aktuell verbrauchte Menge an Ressourcen zur Verfügung gestellt und abgerechnet. Dadurch ist eine wirtschaftliche Bedeutung entstanden; signifikante Kostenersparnisse sowie neue Geschäftsmodelle werden mit dem Cloud Computing verbunden (vergleiche [I3]).

Einführung und Definition: Vom Mainframe zur Cloud

Mit Cloud Computing erzielt ein Konzept seinen Durchbruch, das viele Trends und Technologien in sich aufnimmt und zu einer neuen Qualität verschmilzt. Die Geschichte der IT ist seit Anbeginn gekennzeichnet durch ein Wechselspiel von zentralen und dezentralen Kräften. Dabei wurde die räumliche Verteilung bzw. Anordnung von Rechenleistung durch technologische und ökonomische Rahmenbedingungen determiniert. Jeder Evolutionsschritt in der IT-Industrie erhielt durch ein vorherrschendes IT-Modell – auch „Computing Paradigma“ genannt – seine Prägung. Die Paradigmen erwachsen aus den technologischen und ökonomischen Rahmenbedingungen für die Rechen- und Netzleistung.

Die Entstehung des Phänomens Cloud Computing ist eng verknüpft mit:

der enormen Steigerung der Rechenleistung
der flächendeckenden Verfügbarkeit höherer Bandbreiten
den Virtualisierungstechnologien

Als eine Synthese von IT- und Telekommunikations-Leistungen führt Cloud Computing dazu, dass – vereinfacht dargestellt – jegliche Leistung als Service erhältlich wird. Cloud Computing repräsentiert somit den Gedanken von „Services aus dem Netz“.

Die Entwicklungsschritte des Phänomens Cloud Computing werden im Folgenden kurz skizziert:

Großrechner (Mainframes): Am Anfang stand der Großrechner. Durch ihn wurde Rechenleistung an zentraler Stelle bereitgestellt. Die transaktionsorientierten Anwendungssysteme boten im Wesentlichen nur punktuell stattfindende Benutzerinteraktionen. Stapel- (Batch)-Verarbeitung war ein weiteres Kennzeichen ebenso wie die räumliche Nähe zum Anwender.
Personal Computer und Client/Server Prinzip: In den 80er Jahren rückte der vergleichsweise kleine und bürotaugliche Personal Computer (Client) in den Fokus. In Verbindung mit zentralen Servern wurde so das IT-Modell der leistungsfähigeren und flexibleren Client/Server-Systeme möglich. Hier war die Rechenleistung verteilt, je nach Funktion beim zentralen Server oder auch lokal auf dem Client beim Anwender. Das PC-Paradigma ist durch eine extreme Nähe zum Anwender (Einzelplatz-Anwender) sowie durch eine starke Dezentralisierung gekennzeichnet. Die Dezentralisierung und die damit verbundene Individualisierung erklären den Erfolg dieses Konzeptes.
Internet Die nächste große Welle brach in den 90er Jahren mit der Einführung des Internets an. Es entstanden wieder stärker zentralisierte Webanwendungen. Dieses IT-Modell hat den Vorzug, dass die Aktualisierung der Software an zentraler Stelle erfolgt. Die eigentliche Anwendungslogik liegt auf den Web-Servern; die Rechnerleistung des Clients wird nur noch für die Benutzerschnittstelle benötigt. Das Internet-Paradigma ermöglicht die räumliche Trennung der Rechenleistung vom Anwender und vereint zentrale wie dezentrale Aspekte.
Web2.0 und SOA: Seit der Jahrtausendwende befindet sich die IT-Industrie in der Transformation in eine Serviceorientierte IT-Welt. Web 2.0 lässt sich im Prinzip ebenfalls unter dem Begriff Service fassen, geht es doch hier um kommunikative Aspekte des Webs mit starker Betonung von spontaner Interaktion. Die Konzepte der Web-Anwendungen wurden zunehmend auf Geschäftsanwendungen übertragen. Web 2.0-Technologien, die auf globale Zusammenarbeit von Anwendern bei der Informationsverarbeitung setzen, halten weiter Einzug in den Unternehmen. Das gilt auch für service-orientierte Architekturen (SOA). Im Zentrum stehen hier die Komposition von Services sowie deren systematische Verknüpfung mit Anwendungen und anderen Services. Die Bündelung von IT-Anforderungen zu Services im Sinne von Service-orientierten Architekturen (SOA) verleiht der Unternehmens-IT ein hohes Maß an Agilität: Sie erlaubt es, einzelne Services voneinander zu entkoppeln und in Abhängigkeit von den Erfordernisse der Anwender flexibel neu zu kombinieren. Die lose Koppelung von Services erlaubt es, den Ort der Ausführung zu ändern, solange die Regeln für einen Service-Aufruf beibehalten werden. Damit können Software-Services an Dienstleister ausgelagert werden.

Web 2.0 und SOA basieren auf der räumlichen Trennung von Rechenleistung und Nutzung. Sie beinhalten einerseits starke zentrale Elemente, unterstützen und ermöglichen andererseits dezentrale Architekturen.

Mobilität und Verschmelzung von Geschäfts- und Privatwelt: Ein weiteres wichtiges Innovationsfeld, das im Zusammenhang mit Services zu sehen ist, sind die künftigen Entwicklungen der Endgeräte und Client-Systeme. Während hier der klassische Desktop-PC an Bedeutung verliert, wenden sich die Anwender in wachsendem Maße neuartigen Endgeräten zu – vom Smartphone über Spielkonsolen, Mediacenter, Laptop bis zum Web-Terminal. Die Herausforderung lautet hier Integration. Das bedeutet beispielsweise im Geschäftsumfeld, dass die Nutzer auf ihre E-Mails, Termine und Adressen vom Laptop, Smartphone oder Terminal aus zugreifen wollen.

Auch die Ansprüche der Konsumenten steigen; sie verlangen nach einheitlicher Bedienung aller Geräte und zunehmend auch nach zentralisierter Datenhaltung – in idealer Weise im Web –, sowie einfachem Management ihrer Benutzerkonten und Identitäten im Netz. In der modernen Arbeitswelt geht es primär um Zugriffe auf die richtigen Informationen zur richtigen Zeit in einer zunehmend mobilen Umgebung. Der Anwender benötigt Online/Offline-Arbeitsmöglichkeiten ohne Unterbrechung, wobei rollenbasierte Zugriffsrechte notwendig sind. Privat- und Geschäftswelt verschmelzen und beeinflussen sich gegenseitig. Auch aus Konsumentensicht gewinnen Services an Bedeutung. Im „Digital Lifestyle“ steht der PC nicht mehr im Mittelpunkt, sondern konkurriert mit anderen digitalen Endgeräten, wobei der Anwender einerseits die Synchronisation von privaten und geschäftlichen Informationen über verschiedene Endgeräte hinweg fordert, andererseits eine komfortable und intuitive Bedienung erwartet. Der Trend zur Mobilität bedingt die Trennung von Rechenleistung und Nutzung, denn die mobilen Endgeräte sind vergleichsweise ressourcenarm.

Trends und Geschäftsmodelle

Die Geschäftsmodelle von Cloud Computing-Anbietern stützen sich zurzeit vor allem auf ökonomische Optimierungsaspekte in der Produktion und die hochgradige Automatisierung von Dienstleistungsabläufen. Die Grundlage für erfolgreiche Geschäftsmodelle bilden partnerschaftliche Beziehungsgeflechte auf der Basis von Vertrauen in Netzwerken. Denn Teilleistungen von Cloud Services können aus unterschiedlichen Clouds bereitgestellt und bezogen werden. Damit steigen die Anforderungen an die Beherrschbarkeit und Orchestrierbarkeit unterschiedlichster Applikationen und Infrastruktur. Aus technischer Sicht wird die Integration durch Web-Standards einfacher, hingegen steigt die Komplexität hinsichtlich Prozessintegration und Service-Management. Die klassischen Systemintegratoren und IT-Beratungshäuser werden deswegen weiter gefordert sein, wenn auch nicht mehr für alle Arten von IT-Dienstleistungen und nicht in gleichem Maße.

Durch die deutlich reduzierten Einstiegskosten für die Verwendung einer professionellen IT-Infrastruktur in der Cloud eine Vielzahl von kleinen, innovativen Unternehmen, die mit minimaler Kapitalbindung und mit flexiblen Betriebskosten neue IT-Dienstleistungsangebote auf den Markt bringen können. Es entsteht so ein Cloud Computing-Ökosystem von IT-Dienstleistungsanbietern (vgl. dazu auch das z.Zt. rapide Wachstum von sog. App-Stores auf dem Mobilfunkmarkt). Anbieter fördern solche Ökosysteme, indem sie einfach zu verwendende Basis-IT-Leistungen und Middleware-Komponenten als Web-Services zur Verfügung stellen. Durch diese Ökosysteme werden auch neue Dienstleistungen wie z.B. Service Brokering und Service Aggregation, Vertrauens- und Reputationsbewertungen erforderlich.

Den Ausgangspunkt für die Ausbildung tragfähiger Cloud Computing-Business-Modelle bildet die grundsätzliche Cloud Computing-Struktur mit den Elementen „Software as a Service“ (SaaS), „Plattform as a Service“ (PaaS) und „Infrastructure as a Service“ (IaaS).

Für den Bereich SaaS ergeben sich Geschäftsmodell-Varianten auf der Basis reiner SaaS-Lösungen mit eigenständigen Architekturen. Darüber hinaus gibt es die Möglichkeit, bestehende Lizenzmodelle für Softwareprodukte in ein SaaS-Modell zu überführen oder hybride Lösungen anzubieten.

Bei „Plattform as a Service (PaaS)“ finden sich Geschäftsmodell Ausprägungen basierend auf den Leistungsentwicklungsstufen Softwareentwicklung und Bereitstellung, Software-Ablaufumgebung und einer „Full Scope Plattform as a Service“, die beide Aspekte abdeckt. In der Praxis zeigt sich, dass auch SaaS-Applikationsanbieter zusätzlich in ihrem Geschäftsmodell zumindest einige Funktionalitäten einer Softwarebereitstellungs-Plattform integrieren. Andere Geschäftsmodell-Varianten konzentrieren sich u.a. auf abgeschlossene logische Einheiten, wie z.B. Mailing- und Collaboration-Plattformen. Einige Anbieter gehen bereits dazu über, größere, geschäftskritische Anwendungen aus der Public Cloud auch in einer privaten, abgesicherten Cloud anzubieten. Sämtliche PaaS Lösungen unterstützen - in unterschiedlichem Maße – die Integration von SaaS-Applikationen via Cloud-fähiger Entwicklungsumgebung in die darunter liegende Infrastruktur. Es handelt sich in der größten Ausprägung um umfangreiche Middleware-Komponenten.

Ein weiterer Aspekt von PaaS wird zu weiteren Geschäftsmodell- Varianten führen: für eine verbrauchsabhängige Abrechnung sind Funktionalitäten wie Messung, Überwachung (Monitoring) und Rechnungsstellung unverzichtbar. Diese entscheiden darüber, wie stark ausgeprägt die verbrauchsabhängige Bezahlung ist.

Die neue Art von Applikationen

Während man immer noch auf fundamental neue Applikation wartet die durch das Cloud Computing entstehen, existieren doch heute schon mehrere wichtige Klassen von Applikationen, welche durch das Cloud Computing attraktiver werden und weiter zu dem Momentum beitragen, welches neue Dienste produzieren wird. Als Jim Gray die technologischen Trends im Jahr 2003 untersuchte [P1] kam er zu dem Schluss, dass es aus ökonomischer Sicht notwendig ist, Daten nahe der Applikation zu speichern, denn die Kosten für Wide-Area-Networking fallen langsamer und bleiben verhältnismäßig hoch verglichen mit anderen Hardware Kosten in der IT. Obwohl sich die Hardware Kosten seit dem verändert haben, die Idee seines „Breakeven Points“ ist immer noch aktuell. Grays Einsichten sind immer noch ein guter Ausgangspunkt, um zu untersuchen, welche Art von Applikationen gute Möglichkeiten anbieten, um Cloud Computing weiter voranzutreiben.

Tim O’Reilly glaubt, dass „die Zukunft jenen Services gehört, welche in Echtzeit mit Informationen Antworten die entweder von den Usern selbst oder von Sensoren zur Verfügung gestellt werden.“ (siehe [P2]). Solche Services würden vorzüglich innerhalb einer Cloud implementiert und aufgestellt werden, nicht nur, weil diese hoch verfügbar sein müssen, sondern auch, weil derlei Dienste in der Regel auf großen Datenmengen basieren die wiederum am bequemsten in einem großen Datenzentrum gespeichert werden. Dies gilt besonders für Services die mehrere Datenquellen und Services miteinander kombinieren, wie z.B. Mashups. Obwohl nicht alle mobile Endgeräte zu 100% online sind, muss dies kein Hindernis für Cloud Services sein, denn dieses Problem wurde bereits adressiert und effektive Lösungen wurden entwickelt (z.B. Google gears).

Obwohl Cloud Computing meist mit interaktiven SaaS in Verbindung gebracht wird, eröffnet es auch einzigartige Möglichkeiten für paralleles Batch-Processing und Analyseaufgaben welche Terabytes an Daten durchforsten und Stunden brauchen um abgearbeitet zu werden. Solange ausreichend Parallelitäten in der Datenstruktur vorkommen, können die neuen kosteneffizienten Möglichkeiten einer Cloud, hunderte von Computern kurze Zeit miteinander zu verbinden, billiger und effektiver sein, als wenige Computer für lange Zeit zu beschäftigen. Peter Harkins hat z.B. bei der Washington Post 200 EC2 (Amazon Computing Service) Instanzen (gleich 1.407 Serverstunden) benutzt, um 17.481 Seiten von Hillary Clintons Reisedokumenten in ein freundlicheres WWW Format zu bringen und das 9 Stunden nachdem diese veröffentlicht wurden (siehe [P3]). Programmabstraktionsmechanismen wie Googles MapReduce [P5] oder dessen Opensource Gegenstück Hadoop [P4] erlaubt es Programmierern solche Aufgaben zu formulieren und gleichzeitig die Komplexität der Choreographie zu verstecken die entsteht, wenn man über hunderte von Cloud Computing Rechnern verstreute Aufgaben parallel zueinander ausführt.

Tatschlich ergreift die Firma Cloudera (siehe [P6]) die Gelegenheit, genau in diesem Bereich ein Geschäftsmodell aufzubauen. Um auf Grays Kosten/Nutzen Analyse zurückzukommen, muss man die Kosten für das Speichern von großen Datenmengen in Datenzentren abwägen gegen die höhere Geschwindigkeit der Datenanalyse. Das Geschäftsmodell der Amazon Web Services hat genau diese Rechnung im Sinn. Datenanalyse rückt immer mehr ins Zentrum. Während früher die großen Datenbankanbieter sich auf Transaktionsmanagement konzentrierten, wird das in diesen Tagen immer weniger wichtig. Ein immer größerer Anteil an Rechenressourcen wird dafür aufgewendet um Kundenverhalten, Produktionsketten, Kaufverhalten und Produktranking zu verstehen.

Während das Volumen an Datentransaktionen immer langsamer wächst steigt der Bedarf an Entscheidungshilfen basierend auf gespeicherten Informationen rapide an. Das verschiebt auch die Gewichtung beim Datenprocessing von Transaktionsmanagement Richtung Businessanalyse. Und letzteres ist die Erweiterung von rechenintensiven Desktopapplikationen. Die aktuellen Versionen von Mathematik-Software wie MatLab oder Mathematica können Cloud Computing einsetzen um komplexe rechenintensive Evaluationen durchzuführen. Andere Desktopapplikationen können in gleicher Weise von dieser unkomplizierten Ausdehnung in die Cloud profitieren. Wie bereits gesagt ist hier der Vergleich von Kosten die durch das Rechnen in der Cloud entstehen plus der Kosten des Übertragens der Daten in und aus der Cloud mit der Zeitersparnis durch die Benutzung der Cloud. Simulationen oder symbolische Mathematik bei denen Unmengen an Datenrecords bearbeitet werden sind ein anderes Beispiel. Das Modell hier ist die Speicherung der Daten und die Berechnung in der Cloud und der Präsentation der Ergebnisse am Rechner des Benutzers. Dabei muss eine entsprechende Bandbreite für die Kommunikation von Desktop in die Cloud und vice versa gegeben sein. Offline Rendering oder 3D Animationen sind ein weiteres Beispiel. Bei einer kompakten Beschreibung der Objekte und der Bestimmung der Beleuchtungscharakteristiken wird das rendern einer 3D Szene zu einem extrem parallelisierbarem Prozess mit einem hohen Rechenzeit zu Datenvolumen Verhältnis.

Der Einsatz anderer Applikationen, welche eigentlich gute Kandidaten für die Parallelität und Elastizität der Cloud wären, wird durch deren Datenübertragungskosten und den unumstößlichen Grenzen bezüglich Übertragungszeiten und -Verzögerungen vereitelt. Z.B.: Während die Datenanalysen um Langzeitprognosen für finanzielle Entscheidungen ein typisches Szenario für die Cloud abgeben, erfordert der Handel an der Börse eine Aktualität der Ergebnisse oft sogar im Millisekundenbereich. Das kann die Cloud zur Zeit nicht bieten. Solange die Übertragungskosten und Übertragungsverzögerungen nicht gesenkt werden können, sind solche Applikationen keine Kandidaten für Cloud Computing (vergleiche [I3]).

Utility Computing

Jede Applikation braucht Computation- oder Rechenmodell, ein Speichermodell und, auch wenn diese nur auf triviale Weise verteilt sein sollte, ein Kommunikationsmodell. Das statistische Multiplexing, welche notwendig ist, um Elastizität und den Eindruck einer schier unbegrenzten Kapazität an Ressourcen zu vermitteln erfordert, dass diese Ressourcen virtualisiert werden. Dadurch werden die Implementation dessen, wie diese gemultiplexed und verteilt werden vom Programmierer verborgen. Verschiedene Utility Computing Angebote sollten deswegen diesbezüglich unterschieden werden, basierend auf dem Grad an Abstraktion der dem Programmierer präsentiert wird und den Möglichkeiten Ressourcen zu managen.

Amazons EC2 Service ist an einem Ende des Spektrums. Eine EC2 Instanz sieht etwa so aus wie ein Stück Hardware und Benutzer können quasi den gesamten Software Stack kontrollieren, vom Kernel-Layer aufwärts. Die angebotene API ist dabei eher „schlank“, ein paar Duzend API Aufrufe, um die virtualisierte Hardware anzufordern und zu konfigurieren. Es gibt a priori keine Einschränkungen bezüglich der Applikationen die auf einer EC2 Instanz laufen können. Das untere Ende der Virtualisierung, die bloßen CPU Zyklen und die IP Konvektivität erlauben den Entwicklern welchen Code auch immer zu implementieren. Dadurch wird es für Amazon allerdings sehr schwierig, automatische Skalierbarkeit und Failover zu gewährleisten, denn die Funktionalität und Steuerung die man braucht, um Replikation und andere State-Management Abzudecken sind stark abhängig von der Applikation selbst. Deshalb bietet Amazon Web Services eine Reihe von High-Level Managed Services an, darunter mehrere verschiedene Speicher und Persistenzmanagement Dienste in Verbindung mit EC2, z.B. SimpleDB. Allerdings haben diese Zusatzservices eine hohe Verzögerung beim Aufruf und bestehen aus nicht standardisierten APIs und werden deswegen nicht so intensiv verwendet wie Angebote der Amazon Web Services.

Am anderen Ende des Spektrums, quasi als Gegenthese zu den Amazon Webservices, sind applikationsorientierte Plattformen, wie die Google AppEngine oder Force.com, eine SalesForce Business-Software Entwicklungsplattform. AppEngine ist ausschließlich auf traditionelle Web-Applikationen ausgerichtet welche eine strenge Trennung zwischen Stateless Computation Tier und Statefull Storagetier erzwingt (siehe 3-Tier Architektur).

Außerdem wird von AppEngine Applikationen erwartet, dass sie Request-Response orientiert aufgebaut sind und dass die CPU Zeit die sie verbrauchen streng rationiert und auf die Request Verarbeitung aufgeteilt wird. Das eindrucksvolle automatische Skalieren, die Hochverfügbarkeitsmechanismen und der proprietäre Datenspeichermechanismus MegaStore (verwendet Google BigTable, zum verteilten Speichern strukturierter Datensätze), welche allen AppEngine Applikationen zur Verfügung stehen, basieren alle auf den eben genannten Einschränkungen. AppEngine (im Gegensatz zu EC2) ist nicht geeignet, um beliebige Applikationen umzusetzen. Auf ähnliche Weise wurde Force.com entwickelt, um Business Applikationen zu unterstützen, die die salesforce.com Datenbank verwenden und nichts anderes.

Microsofts Azure nun liegt in der Mitte des Spektrums zwischen Flexibilität und Programmierkomfort. Azure Applikationen verwenden die .Net Bibliotheken und werden für die Common Language Runtime (CLR) kompiliert, die programmiersprachenunabhängige Laufzeitumgebung für .Net. Das System unterstützt das Programmieren beliebiger Applikationen eher als die Fertigstellung von Programmen die einer bestimmten Kategorie angehören. Wie bei .Net können sich die nutzer die Programmiersprache aussuchen, nicht aber das Betriebssystem, auf dem die Programme laufen sollen. Die Bibliotheken bieten einen gewissen Grad an automatischer Netzwerkkonfiguration und Failover und Skalierbarkeit an, sie fordern vom Entwickler aber auf deklarative Weise die Eigenschaften der Applikation anzugeben, um dies erreihen zu können. Azure steht in der Mitte zwischen den virtuellen Maschinen von Amazons EC2 und der applikationsspeziefischen Umgebung von Googles AppEngine.

Die Tabelle unten fasst die bisher dargestellten Eigenschaften zusammen. Die Diskrepanz zwischen skalierbarem Datenspeicher basierend auf einer (proprietären) API und dem Funktionsreichtum von SQL bleibt ein offener Punkt und eine Streitfrage der Forschung. Amazon hat zwar damit begonnen Oracle Datenbanken auf Ihren Webservice System anzubieten, allerdings ist dies aus ökonomischer lizenzpolitischer Sicht kein Modell das gut zum Cloud Computing passt.

Nun, welches der eben vorgestellten Modelle wird das Rennen machen? Diese Frage kann man analog zu der Situation bei Programmiersprachen und Frameworks betrachten. Low-level Sprachen wie C oder gar Assembler erlauben die Kontrolle und enge Kommunikation mit dem „blanken Metall“, der Hardware, aber wenn der Entwickler eine Webapplikation schreiben soll, dann sind die Mechanismen von Socket Management, Anfragenverteilung und so weiter nur sehr mühsam zu Kodieren, selbst dann wenn gute Bibliotheken zu Verfügung stehen. Am anderen Ende der Skala stehen dann High-Level Frameworks wie Ruby on Rails, diese machen solche Mechanismen transparent für Entwickler sind aber nur dann von Nutzen, wenn die Applikation der Request-Response Abstraktion und anderen Regeln von Rails entspricht. Für jegliche Abweichung vom Üblichen muss man tief ins Framework abtauchen und die Aufgaben sind nur sehr schwer oder überhaupt nicht zu kodieren. Kein Ruby Entwickler würde die Überlegenheit von C für den Einsatz auf bestimmten Gebieten anzweifeln, gleiches gilt auch für C Programmierer. Die Antwort auf unsere eben gestellte Frage sollte also lauten, dass es für bestimmt Einsatzgebiete bestimmte Utility Computing Systeme gibt, die für die eben gestellte Aufgabe optimal sind. Alle haben Ihre Vorteile, abhängig vom Problem das bearbeitet werden soll.

Die Analogie der Computersprachen kann man fortführen: So wie High-Level Sprachen mit Hilfe von Low-Level Sprechen implementiert werden, können stark verwaltete automatisierte Plattformen auf kaum verwalteten manuell steuerbaren Plattformen laufen. Z.B. könnte AppEngine auf Azure oder EC2 implementiert und deployed werden und Azure könnte man auf EC2 aufsetzen. Natürliche stellen AppEngine und Azure jeweils viele proprietäre Funktionalitäten zur Verfügung, welche man dann auf der jeweils unterliegenden Plattform nachprogrammieren müsste, eine komplexe („ehrerfüllende“ ;-) Aufgabe.

Tab. 2: Vergleich von Utility Systemen (Quelle [I3])

Amazon Web Services

Google AppEngine

Microsoft Azure

Rechen-modell, Virtual Machine (VM)

X86 CPU Instruktionen (ISA) via Xen VM, a Virtual Machine Monitor for CPU Instruktionsets,

Skalierbarkeit ist möglich, aber die Entwickler müssen die „Maschinerie“ dafür selbst schreiben oder Plattformen wie RightScale benutzen

Eine vorgegebene Programmstruktur und ein API Framework. Vom Programmierer in Python geschriebene Handler. Alle persistenten Daten sind in MegaStore außerhalb des Python Interpreters gespeichert, in MegaStore (Indizierte Datenrecords)

Hoch und runter skalierbar für Rechenressourcen und Datenspeicher, mit Failover für Server und Netzwerk, konform zur 3-Tier Middleware Architektur

Microsoft Common Language Runtime CLR VM. Abstrakter Zwischencode im .net Managed Environment.

Die Maschinen können provisioniert werden basierend auf deklarativen Statements, z.B.: Angaben darüber welche Rollen repliziert werden können; load balancing geschieht automatisch

Speichermodell

Unterstützt eine Reihe von Modellen, von Block Store (EBS) bin hin zu Augmented Key/Blob Store (SimpleDB), abhängig davon ist das automatische Skalieren, kein Skalieren oder Verteilen bei EBS bis hin zu vollautomatischen Methoden bei SimplDB oder S3. Gleiches gilt für die Zusicherung für Datenkonsistenz. Die APIs sind standardisiert wie bei EBS, oder proprietär.

MegaStore/BigTable

SQL Datenservice, eine reduzierte Version von SQL Server, oder Azure Storage Service

Netzwerkmodell

Eine deklarative Spezifikation der IP Leveltopologie, Security Groups bestimmen, welche Knoten Kommunizieren können, Availability Zones abstrahieren unabhängige Netzwerk up und downtimes, Dynamische („elastische“) IP Adressen gewähren durchgehend routbare Netzwerknamen

Fixe Topologie um die 3-Tier Architektur abzubilden

Hoch und Runter Skalieren geschieht automatisch und ist transparent für den Programmierer

Automatisch basierend auf den vom Programmierer deklarativ erstellen Konfigurationen bezüglich Application-Components (Rollenvergabe)

Die Top 10 Probleme und deren Lösungen

Folgende sind die Top 10 Probleme des Cloud Computing:

Verfügbarkeit der Services

LÖSUNG: Benutzen von mehreren Cloud Computing Providern. Benutzung von Elastizität (Multiplexing etc,) um z.B. DDOS Attacken abzuwehren.

Data Lock-In: Wenn man Daten einmal in bestimmter Form für einen bestimmten Service abgelegt hat, dann wird es schwer den Service oder den Provider zu wechseln, da andere Services zwar das gleiche tun aber Ihre Daten anders strukturieren, man wäre dann einem Service Provider ausgeliefert. Siehe Microsoft Office vs. Rest der Welt Problem.

LÖSUNG: APIs müssen standardisiert werden. Kompatible Software muss produziert werden, um „Surge Computing“ das problemlose Wechseln zwischen privaten und öffentlichen Clouds zu ermöglichen
Datengeheimnis und Validierung

LÖSUNG: Der Einsatz von Verschlüsselung, VLANs und Firewalls. Um nationales Recht gültig zu machen sollte ein geographischer Datenspeichermechanismus zum Einsatz kommen (Gegenbeispiel: Das Google Data Center in Panama, Warum dort?)

Engpässe bei der Datenübertragung, in Bezug auf Geschwindigkeit und Kosten
LÖSUNG: Große Backups und Archivdaten können via Post auf Disks verschickt werden. Die Wide Area Network Kosten sollten reduziert werden und LAN Switches mit hoher Übertragunsrate sollten angeschafft werden.
Unbestimmte Leistungszusicherungen, es kann nicht immer genau gesagt werden, wie schnell die Konten in der Cloud brauchen, um ein Ergebnis zurückzuschicken.
LÖSUNG: Die virtuellen Maschinen sollten verbessert werden; Flash Memory sollte eingesetzt werden, die Scheduling Mechanismen der VMs müssen optimiert werden.
Fehlende skalierbare Datenspeicherung
LÖSUNG: Diese Funktion muss noch entwickelt werden
Hohe Wahrscheinlichkeit von Fehlern in sehr großen verteilten Systemen.
LÖSUNG: Ein Debugger muss entwickelt werden der verteilte VMs beobachten kann und selbst darauf aufbaut.
Schnelles Skalieren
LÖSUNG: Ein Auto-Skalierer muss entwickelt werden, der Machine Learning einsetzt.
„Reputation Fate Sharing“, „Ist der Ruf erst ruiniert...“, Wie kann man einen schlechten Ruf in der Cloud wieder loswerden, z.B. wenn man dynamische IPs bekommt, die auf einer Blacklist sind, oder was wenn man in einem Subnetz in dem auch ein Spam-Computer ist.
LÖSUNG: „Reputation-Guarding“, Reputationsüberwachung sollte ähnlich wie bei eMailing eingesetzt werden.
Software Lizenzierung
LÖSUNG: Pay-for-use Lizenzen oder Bulk-Use Lizenzen

Die Wolke von Morgen

Eine lang geträumte Vision von Computern als Gebrauchsgegenstand nimmt langsam Form an. Die Flexibilität eines solchen Gebrauchsgegenstandes entspricht dem Bedarf, Business Services dem Kunden direkt über das Internet anzubieten. Früher brauchte es Jahre, um ein Geschäft auf mehrere Millionen Kunden wachsen zu lassen, heutzutage kann das in wenigen Monaten geschehen (vergleiche [I3]).

Für Cloud Provider besteht nun die Möglichkeit, riesige Datenzentren für Bedarfs-Computing, Datenspeichern und Netzwerken anzubieten, basierend auf einem Pay-as-you-Go Modell. Und das mit Kosten die geringer sind als die für mittelgroße Datenzentren. Man kann Gewinn machen kann indem man mit statistischem Multiplexen über große Kundengruppen hinweg die Ressourcen optimal einsetzen kann. Für die Kunden bietet die Cloud den Vorteil, dass man nicht in teure Hardware und Datenzentren investieren muss, zumal man dessen Service nur gelegentlich benötigt. Zu anderen Zeiten würde dann die eigene IT nur Kosten erzeugen, ohne Verwendung zu finden. Selbst große Unternehmen wie Zeitungen (Washington Post), die Filmindustrie (Pixar) oder große Universitäten nutzen bereits diese Möglichkeit. Firmen wie Suchmaschinen Provider können ihr Geschäft erweitern und mit der Masse an Kunden bei niedrigen Gewinnmarchen Profit erzielen. Außerdem haben derlei Unternehmen ohnehin bereits die Erfahrung und die notwendige Hardware für Ihr Kerngeschäft. Warum diese Services also nicht auch für Kunden öffnen.

Deswegen würden Software Entwickler gut daran tun, ihre Systeme der nächsten Generation in die Cloud zu geben, dort kann man über hunderte oder gar tausende von virtuellen Maschinen skalieren, während man sich sonst mit nur einer Maschine begnügen müsste.

Applikationen der Zukunft werden wahrscheinlich aus einem Teil bestehen, der auf einem Client (Desktop, Mobile, etc.) läuft, und einem Teil, der in der Cloud ausgeführt wird. Der Cloud-Teil muss beides, schnell hoch und runter skalieren können, was zu einer neuen Anforderung für Software Systeme werden wird. Der Client Teil muss auch dann noch nutzbar sein, wenn keine Verbindung zu Cloud besteht. Zu Zeit ist das für viele Web2.0 Applikationen leider nicht der Fall. Außerdem muss derlei Software ein Pay-for-Use Lizenzmodell anbieten, um den Notwendigkeiten der Cloud gerecht zu werden.

Bei der Infrastruktursoftware oder Middleware muss man sich dessen bewusst sein, dass sie in Zukunft nicht mehr auf „blankem Metall“, also auf Hardware, sondern in virtuellen Maschinen ausgeführt wird. Außerdem muss die Vergebührungsfunktionalität von Beginn an mit eingeplant und eingebaut werden. Das Retrofit eines Accounting-Systems wäre sehr komplex und fehleranfällig. Die Hardware wird in Zukunft nicht mehr aus Single-Racks bestehen, sondern aus einem skalierbaren Container der viele Racks aufnehmen kann.

„Green Computing“ ist nicht nur deswegen ein Hype dieser Tage weil man der Umwelt etwas gutes tun will, sondern auch, weil die großen Cloud Provider Kosten sparen und Gewinn maximieren wollen. Dabei spielt die Reduzierung des Energieverbrauch der großen Serverfarmen eine wichtige Rolle. Zu guter letzt müssen auch noch Bandbreiten erhöht und Übertragungskosten reduziert werden. Das gilt für WAN/Internet Router genauso wie für die Datenzentrum internen Switches.

Zum Abschluss nun eine kleine Fragerunde darüber, was in den nächsten fünf Jahren im Bereich Cloud Computing geschehen wird.

Veränderungen bei Technologie und Pricing: Wie werden die Vergebührungseinheiten für die komplexen Services aussehen? Wie will man die Nutzung der vielen verschiedenen Ressourcen nachverfolgen? Die Anzahl der Kerne pro Chip wird mit der Zeit weiter ansteigen und sich wohl alle 2 bis 4 Jahre verdoppeln. Der Flash Speicher ist eine weitere Möglichkeit einen weiteren schnellen Speicherlayer in der klassischen Hierarchie einzuziehen. Wie kann man das mit welchen Einheiten Vergebühren? Werden Technologie oder Geschäftsideen die Bandbreitenvergebührung mehr beeinflussen? Letzteres erfährt zur Zeit die niedrigste Innovationsrate.

Auf der Virtualisierungsebene: Wird Cloud Computing nun von low-level Virtual Maschinen wie Amazons EC2, von medium-level Sprachen und Systemen wie Microsofts Azure, oder von high-level Installationen wie Googles AppEngine dominiert? Werden die Value Addes Service Provider der unabhängigen Firmen wie RightScale, Heroku oder EngineYard im Zeitalter des Utility Computing überleben, oder werden die erfolgreichen Services in Zukunft von den Cloud Providern zur Verfügung gestellt. Wenn man sich auf einen einzelnen Virtualisierungslayer einigen könnte, würden mehrere Firmen dann mit dem gleichen Standard arbeiten? Wird es ähnlich wie bei den Netzwerkprovidern zu einem Billigpreiskampf kommen, oder wird man durch die Differenzierung der eigenen Services und Service Qualität Gewinn machen können?

Fragen zum Verständnis

Beantworten sie aus Ihrer Sicht folgende Fragen:

Wie werden die Vergebührungseinheiten für die komplexen Services aussehen? Wie will man die Nutzung der vielen verschiedenen Ressourcen nachverfolgen?
Werden Technologie oder Geschäftsideen die Bandbreitenvergebührung mehr beeinflussen? (In positivem und negativem Sinn)
Wird Cloud Computing nun von low-level Virtual Maschinen wie Amazons EC2, von medium-level Sprachen und Systemen wie Microsofts Azure, oder von high-level Installationen wie Googles AppEngine dominiert?
Wird es im Cloud Computing zu einem Billigpreiskampf kommen, oder wird man durch die Differenzierung der eigenen Services und Service Qualität Gewinn machen können?

↑ „A distributed System is one in which (hardware or software) components located at networked computers comunicate and coordinate their acttions only by passing messages“
↑ „A distributed system is one on which I cannot get any work done because some machine I have never heard of has crashed. “
↑ Frei übersetzt nach Roger N. Needham (1989): „What’s different about distributed systems? They’re not centralised!“
↑ Rechenzeitprovider
↑ Large Hadron Collider
↑ 1 PB (Petabyte) = 10¹⁵ bytes
↑ RFC 2768
↑ Arnold K., O’Sullivan B., Scheifler R.W., Waldo J. und Wollrath A. The Jini Specification. Addison-Wesley, 1999 (URL: http://www.jini.org)

[1] „A distributed System is one in which (hardware or software) components located at networked computers comunicate and coordinate their acttions only by passing messages“

[2] „A distributed system is one on which I cannot get any work done because some machine I have never heard of has crashed. “

[3] Frei übersetzt nach Roger N. Needham (1989): „What’s different about distributed systems? They’re not centralised!“

[4] Rechenzeitprovider

[5] Large Hadron Collider

[6] 1 PB (Petabyte) = 10¹⁵ bytes

[7] RFC 2768

[8] Arnold K., O’Sullivan B., Scheifler R.W., Waldo J. und Wollrath A. The Jini Specification. Addison-Wesley, 1999 (URL: http://www.jini.org)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

@@ Zeile 290: / Zeile 290: @@
 In den 90-er Jahren des letzten Jahrhunderts hat ein Paradigmenwechsel eingesetzt der Peer-to-Peer Systeme den traditionellen Client/Server Lösungen bevorzugte. P2P Systeme sind autonom, skalierbar, dynamisch, anonym, dezentral und selbst-organisierend. Peer-to-Peer Datenverkehr macht mittlerweile mehr als die Hälfte des Internet Verkehrsvolumens aus.
-{|
-! width="50%" | [[File:media/image21.png|195x183px]]<br>
-zentralisiertes P2P a la Napster
-! width="50%" | [[File:media/image22.png|186x175px]]
-reines P2P a la Gnutella
-|-
-|
-[[File:media/image23.png|227x186px]]
-hybrid P2P a la Fasttrack
-|
-[[File:media/image24.png|199x186px]]
-DHT a la Bittorrent
-|-
-|
-[[File:media/image25.png|37x38px]]Server, [[File:media/image26.png|37x31px]] Peer, [[File:media/image27.png|39x32px]] Super-Peer, [[File:media/image28.png|21x27px]] Daten,
-[[File:media/image29.png|36x19px]] Query, [[File:media/image30.png|37x18px]] Response, [[File:media/image31.png|38x20px]] Datentransfer
-|
-|}
-[[Datei:IT523 18.png|300px|none|thumb|Peer-to-Peer Modelle ]]
 Man unterscheidet heute mindestens drei Generationen von Peer-to-Peer Netzwerken: 1. Generation – zentralisierte P2P Netze, 2. Generation reine P2P und hybrid P2P Netzwerke und 3. Generation – 3. Generation DHT (Distributed Hash Tables) P2P Netzwerke a la Bittorrent.

Verteilte Systeme - Grundlagen: Unterschied zwischen den Versionen

Version vom 13. Jänner 2022, 07:32 Uhr

Grundlagen Verteilter Systeme

Einführung, Konzepte und Technologien

Kommunikation in Verteilten Systemen

Nachrichtenkodierung

Remote Procedure Calls, Middleware und verteilte Objekte

Naming Services

Peer-to-Peer Netzwerke

Praxis Verteilter Systeme

Das Client Server Modell

Interprozess-Kommunikation

Synchrone Middleware

Asynchrone Middleware

Nachrichtenorientierte Middleware

Enterprise Applikationen und e-Business

Praktische Übungen 1: Parallel-Quicksort

Parallel Quicksort Implementierung mit Threads

Parallel Quicksort Implementierung mit TCP/Sockets

Parallel Quicksort Implementierung via HTTP GET/POST

Parallel Quicksort Implementierung via XML-RPC

Parallel Quicksort Implementierung via Java RMI

Praktische Übungen 2: Verteilte Datenspeicherung

Verteilte Datenspeicherung via XML-RPC

Verteilte Datenspeicherung via Java RMI

Verteilte Datenspeicherung via SOAP

Grid Computing – Computer im Raster

Was ist das Grid?

Virtual Organizations (VOs)

Grid Architektur Allgemein

Interoperabilität

Protokolle

Services

APIs

Überblick über internationale, europäische und nationale Forschungsprojekte im Grid Computing Bereich

Internationale Grid Projekte

Globus/Globus Alliance: Globus Toolkit

Gridbus

Legion

UNICORE

Europäische Grid Projekte

GRIA

EU Data Grid

GEMSS

Nationale Grid Projekte

UK eScience

OGSA-DAI

TeraGrid

Austrian Grid

Webservices – Anbieten, Verhandeln und Abarbeiten

REST

REST meint: Das Web ist einfach

Große Webservices sind nicht einfach

Grundlagen moderner Webservices

Das SaaS Konzept

Begriffsdefinition Webservice

Eigenschaften von Webservices

Service Interface und Implementation, XML als Basis für SOAP

SOA

SOAP

Das SOAP Protokoll (incl. SOAP über HTTP)

Die SOAP Nachricht

Fehlerbehandlung in SOAP

SOAP und WSDL

SOAP und UDDI

SOA im Detail

Erklärung und Definition

Rollenvergabe für und Ablauf von Services

Praktische Übung

Cloud Computing: Services auf Wolken

Einführung und Definition: Vom Mainframe zur Cloud

Trends und Geschäftsmodelle

Die neue Art von Applikationen

Utility Computing

Die Top 10 Probleme und deren Lösungen

Die Wolke von Morgen

Fragen zum Verständnis

Navigationsmenü

Suche