Orientation in Objects
Beispiel 9: Zugriff auf URL verbieten
6.2 Generische Schnittstelle
REST bietet mit den Methoden GET, POST, PUT und DELETE ein generisches Interface. In SOAP müssen alle Methoden für jede Anwendung selbst definiert werden. Die Entwicklung von generischen Tools und Diensten im Web wird dadurch behindert.
6.3 Standards
REST empfiehlt die Verwendung von etablierten Standards. Dem Entwickler stehen beispielsweise die folgenden "Technologien" zur Verfügung:
• URIs für die Adressierung
• HTTP Methoden für den Zugriff
• XML, XHTML, HTML, PNG, ... für die Datenformate
• MIME Typen
Zentral sind die Standards für HTTP und URIs. Für die Formate der Repräsentationen können dagegen beliebige Formate eingesetzt werden. Auch zukünftige Technologien können
verwendet werden.
Für SOAP wird jetzt erst eine Reihe von Standards wie WSDL, UDDI, Security, WS-Transactions oder BPEL4WS neu geschaffen, die ausschließlich für SOAP gedacht sind. Bei den Standards für REST handelt es sich um "richtige" Web Standards, die für viele Zwecke, nicht nur für REST, eingesetzt werden können.
7 Wie erstellt man eine REST Anwendung...
... oder macht eine bestehende Anwendung RESTful? Verteilte Anwendungen basieren auf Funktionen oder Methoden, die auf Objekten arbeiten. Der Client kann über entfernte
Methoden auf die Objekte des Servers zugreifen. Eine REST Anwendung macht Ihre Objekte über URIs nach außen sichtbar. Geschäftsobjekte müssen über eine URL erreichbar sein und mit einem Dokument, vorzugsweise in XML, repräsentiert werden können.
Der Kern eines REST Servers unterscheidet sich nicht von einer RPC Anwendung. Der Unterschied liegt in der Schnittstelle, die sich bei REST grundlegend von einer RPC Anwendung unterscheidet. REST verwendet die HTTP Methoden, die auf über URI adressierbare Resourcen arbeiten, während RPC ein komponentenbasiertes Interface mit spezialisierten Methoden oder Funktionen zur Verfügung stellt.
8 REST und das Semantische Web
Bei SOAP und REST muss der Client die Nachrichten des Servers zu interpretieren verstehen.
Mit RDF als Nachrichtenformat und entsprechenden Interferenz-Maschinen wären Clients denkbar, die zur Laufzeit lernen können. Roger L. Costello schreibt in seiner Präsentation Representational State Transfer [2] :
... ,dynamic learning of response data combined with dynamic reasoning of link traversals would yield a self-reasoning automata. This is the next step of the Web!
9 Grenzen von REST
REST verwendet für den Transport HTTP und transportiert ganze Repräsentationen von Objekten zum Client. Bei Internetanwendungen, die sowieso mit einer hohen
Verzögerungszeit rechnen müssen ist dies in Ordnung. Zwischen spezialisierten lokalen Servern z.B. zwischen Application Server und Datenbank benötigt man effizientere Protokolle wie CORBA, RMI oder DCOM.
Das Serialisieren und Deserialisieren von und nach XML wird in REST nicht angesprochen.
Der Programmierer muss sich selbst darum kümmern oder ein XML Binding Framework einsetzen.
REST ist ein Architekturstil, der für große Anwendungen mit unbekannter Anzahl von Anwendern und Objekten geeignet ist.
10 Toolunterstützung
REST basiert auf eingeführten Standards, für die es bereits eine Unzahl von Tools gibt. REST fähig sind Web Server wie Apache oder IIS, Web Container wie Tomcat und Proxy Server wie Squid. Spezialisierte REST Tools sind nicht notwendig. Es ist durchaus denkbar, dass zukünftig Bibliotheken, Frameworks oder Tools die Entwicklung von REST Anwendungen gezielt unterstützen.
11 Öffentliche REST Services
Es gibt bereits eine Reihe von öffentlichen Web Services, die bewußt RESTful Schnittstellen verwenden. Zu den bekannteren gehören Web Services von Amazon, Google oder O'Reillys Meerkat.
Einige Dienste im Web wie beispielsweise Wiki Webs sind von Haus aus zumindest teilweise REST konform.
Pacemaker
clusterlabs.org. Abgerufen am 05. 07 2013 von http://clusterlabs.org/
Pacemaker is an Open Source, High Availability resource manager suitable for both small and large clusters.
"Someone said something awesome about Pacemaker here." - Anon
Features
• Detection and recovery of machine and application-level failures
• Supports practically any redundancy configuration
• Supports both quorate and resource-driven clusters
• Configurable strategies for dealing with quorum loss (when multiple machines fail)
• Supports application startup/shutdown ordering, regardless machine(s) the applications are on
• Supports applications that must/must-not run on the same machine
• Supports applications which need to be active on multiple machines
• Supports applications with multiple modes (eg. master/slave)
• Provably correct response to any failure or cluster state.
The cluster's response to any stimuli can be tested offline before the condition exists
Background
Pacemaker has been around since 2004 and is primarily a collaborative effort between Red Hat and Novell, however we also receive considerable help and support from the folks at LinBit and the community in general.
The core Pacemaker team is made up of full-time developers from Australia, USA, Austria, Germany, and China. Contributions to the code or documentation are always welcome.
Pacemaker ships with most modern enterprise distributions and has been deployed in many critical environments including Deutsche Flugsicherung GmbH (DFS) which uses Pacemaker with Heartbeat to ensure its air traffic control systems are always available
Currently Andrew Beekhof is the project lead for Pacemaker.
Configuration Tools
Pacemaker's internal configuration format is XML, which is great for machines but terrible for humans. The community's best minds have created GUIs and Shells to hide the XML and allow the configuration to be viewed and updated in a more human friendly format.
Command Line Interfaces (Shells)
crmsh - The original configuration shell for Pacemaker. Written and maintained by SUSE, it may be used either as an interactive shell with tab completion, for single commands directly on the shell's command line or as batch mode scripting tool.
pcs - An alternate vision for a full cluster lifecycle configuration shell and web based GUI.
Handles everything from cluster installation through to resource configuration and status.
GUI Tools
pygui - The original GUI for Pacemaker written in Python by IBM China. Mostly deprecated on SLES in favor of Hawk
hawk - Hawk is a web-based GUI for managing and monitoring Pacemaker HA clusters. It is generally intended to be run on every node in the cluster, so that you can just point your web browser at any node to access it. It is documented as part of the SUSE Linux Enterprise High Availability Extension documentation
LCMC - The Linux Cluster Management Console (LCMC) is a GUI with an inovative
approach for representing the status of and relationships between cluster services. It uses SSH to let you install, configure and manage clusters from your desktop.
pcs - An alternate vision for a full cluster lifecycle configuration shell and web based GUI.
Handles everything from cluster installation through to resource configuration and status.
Other Add-ons
booth - The Booth cluster ticket manager extends Pacemaker to support geographically distributed clustering. It does this by managing the granting and revoking of 'tickets' which authorizes one of the cluster sites, potentially located in geographically dispersed locations, to run certain resources.
Regenachsen
regenachsen.de. Abgerufen am 27. 06 2013 von
http://www.regenechsen.de/phpwcms/index.php?krypto_asym_eg
Asymmetrische Verfahren: ElGamal
Asymmetrische Verfahren: ElGamal
In PGP, GnuPG und in S/MIME wird für die Verschlüsselung des Sitzungsschlüssels ein
asymmetrisches Verfahren gewählt. Neben RSA ist hier Diffie-Hellmann und ElGamal vorgesehen . In diesem Kapitel soll die grundlegende Funktionsweise und der Vorgang für das Verfahren nach ElGamal [Selke][Schneier][Gerold][Gerold, Vorlesung TU München] beschrieben werden. Die Darstellung richtet sich nicht an Mathematiker und Kryptospezialisten, sondern an einfache, interessierte Anwender von Krypto-Software.
Das Verfahren wurde 1985 von ElGamal veröffentlicht. Es eignet sich sowohl zur Verschlüsselung als auch für digitale Signaturen. Seine Sicherheit beruht auf der Schwierigkeit, diskrete Logarithmen zu bestimmen. Das heißt, es ist einfach eine Zahl mit einer anderen zu potenzieren (y=ab), aber zur Zeit ist kein mathematisches Verfahren bekannt, diesen Prozess ohne Kenntnis von b korrekt
umzukehren, ohne raten zu müssen.
1. Schritt
Zunächst benötigen wir eine große Primzahl Z. Sicherheitshalber sollte diese Zahl um Eins verringert und dann halbiert (Z-1)/2 ebenfalls prim sein. Je nach Schlüssellänge ist diese Zahl viele Bit lang, in unserem Falle soll ihr Wert aber nur 11 betragen.
2. Schritt
Wir benötigen zwei weitere beliebige Zahlen y und g, die größer als Eins, aber kleiner als die Zahl Z sein müssen. Nehmen wir für unser Beispiel y=2 und g=3. Aus diesen Werten, zusammen mit Z, bilden wir:
p=yg mod Z
Also y wird mit g potenziert, durch Z geteilt und der Rest wird als p weiterverwertet. p, y und Z sind öffentlich und werden auch im öffentlichen Schlüssel verwendet. g dagegen ist geheim und darf nie veröffentlicht werden.
Betrachten wir das Ergebnis in unserem Beispiel:
p = 23 mod 11
= 8/11
= 0 Rest 8
p = 8
Damit hätten wir bis jetzt: Z = 11 p = 8 y = 2 g = 3 Verschlüsselung
Die Klartextnachricht soll lauten: 05070810
Die zu verschlüsselnde Nachricht muss einen Wert aufweisen, der kleiner als Z ist, sonst muss er in Teile zerlegt werden. Für unser Beispiel gilt daher für die Nachricht:
05 07 08 10
Der Absender benötigt noch eine zufällige Zahl x, die größer Eins, aber kleiner Z-1 sein muss und keinen gemeinsamen Teiler mit Z haben soll. Wir nehmen den Wert x=5 an. Der Absender erzeugt zunächst mal die Hilfsgröße c1:
c1= yx mod Z
und außerdem für jeden zu verschlüsselnden Klartextteil c2=(k px) mod Z mit k= Klartextteil.
In unserem Beispiel wäre c1 damit
c1
= 25 mod 11
= 32/11
= 2 Rest 10
c1 = 10
und für c2 ergäbe sich mit k=05
c2
= (5*85) mod 11
= 163840/11
= 14894 Rest 6 usw.
k c2
05 06
07 04
08 03
10 01
Die chiffrierte Nachricht lautet 06 04 03 01 Zusätzlich wird der Wert c1=10 übermittelt.
Entschlüsselung
Der Empfänger weiß nichts von der Hilfszahl x, benötigt diese aber für die Rückrechnung auch nicht.
Für die Entschlüsselung gilt k= (c2 c1(Z-1-g)
) mod Z
Im ersten Teil der Nachricht 06 ergibt dies:
k
= (6*10(11-1-3)) mod 11
= (6*107) mod 11
= 6*10000000/11
= 5454545 Rest 5
c2 k
06 05
04 07
03 08
01 10
Die Darstellung zeigt, dass ähnlich wie bei RSA der Vorgang sehr simpel und die Mathematik nicht schwierig ist (sieht man mal vom Umgang mit sehr großen Zahlen ab). Sie ist bewusst sehr einfach gewählt und hat, dem besseren Verständnis dienend, unrealistisch kleine Werte verwendet.