Wegweiser

Verteilte Systeme:

Web Services

Einführung 1

SOA – Service Oriented Architecture

• Div. Design Prinzipien

– Lose Kopplung

– Abstraktion

– Wiederverwendbarkeit

– Zustandslosigkeit

– …

Einführung 2

Service Consumer

Frontend

Service Provider

Business Logik Persistenz

Web Services

SOAP

• Entstanden 1999

• XML basiert

• HTTP typisch als Transport, aber nicht erforderlich

• Struktur: Envelope, Header, Body

• WSDL als Beschreibungssprache

• (tot: UDDI)

Einführung 3

SOAP Nachrichtenaufbau

Einführung 4

SOAP Envelope

SOAP Header

SOAP Body

Headers

XML Content

SOAPFault

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">

<m:GetStockPrice>

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">

<m:GetStockPriceResponse>

<m:Price>34.5</m:Price>

</m:GetStockPriceResponse>

</soap:Body>

</soap:Envelope>

WSDL

Einführung 5

Quelle: W3C

Beispiel: SoapUI

Einführung 6

REST (REpresentational State Transfer)

• SOA mit REST -> ROA

• Erdacht 2000 von Roy Fielding als Doktorarbeit

• Stark an HTTP gebunden, URL adressierbar

• Response Encodings: XML, JSON, HTML, andere denkbar

• Zustandslos, CRUD

Einführung 7

HTTP Methoden bei REST

Einführung 8

Primitive Bedeutung

GET Ressource lesen, ohne Status zu verändern

POST Ressource anlegen und sonstige Operationen

PUT Ressource anlegen/ändern

PATCH Teilweise Änderung einer Ressource

DELETE Ressource löschen

HEAD Metadaten zu einer Ressource erfragen

OPTIONS Methoden zum Ressourcenzugriff abfragen

REST Beispiel

Einführung 9

REST Encoding

• JSON, XML, YAML, HTML oder beliebig

• Chunking

• Compression

• Multipart

Einführung 10

{“id“:23,“nachName“:“Magschok“,“vorName“:“Georg“,“alter“:23}

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

<person id=„23">

<alter>23</alter>

<vorName>Georg</vorName>

<nachName>Magschok</nachName>

</person>

Beispiel: Enunciate

Einführung 11

REST in Java: JAX-RS

@Path("/greeting")

@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })

@Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })

public class GreetingService {

@GET public Response message() {

return new Response("Hi REST!");

}

@POST public Response lowerCase(final Request message) {

return new Response(message.getValue().toLowerCase());

}

}

Einführung 12

REST: WADL

Einführung 13

HATEOAS & RMM

• Rest Maturity Model (Leonard Richardson)

• HATEOAS (Hypermedia as the Engine of Application State): Dynamische Ressource Links, weg von der statischen Interfacedefinition

Einführung 14

Quelle: Martin Fowler

Andere Mechanismen zur verteilten Kommunikation

• RPC

• DCOM

• CORBA

• RMI

• XML-RPC

• DCE

• RMI-IIOP

• Thrift

• …

Einführung 15

Wegweiser

Scaling:

wie kriegen wir die Cloud groß genug?

Einführung 16

Scaling Dimensionen

Einführung 17

Scaling

Storage

Filesystem DB RAM

Netzwerk Processing

Wegweiser

DB Scaling

Einführung 18

DB Anwendungsebenen Cloud

1. Cloud Provider bieten Datenbanken als IaaS und SaaS Angebote an

– Meist individuell entwickelt

– Teilweise als open source veröffentlicht

– Die Geschichte der Systeme und Experten ist stark vernetzt.

2. Cloud-Entwickler nutzen verteilte Datenbanksysteme auf Cloud-Infrastrukturen

– Anspruch an Verteilung, Replikation, CAP-Entscheidungen

Einführung 19

Umgang mit Relationalen DBMSs

• Siehe Einführung

– Scale-Up

– Scale-Out

• Normalisierung + De-Normalisierung!

• Sharding

• Dimensionen:

– Storage

– Zugriffe/Performance

– technische DB-Optimierung (z.B. Indizes, Caching)

• … Einführung 20

Zoo an Alternativen aka NoSQL

• In Memory DBs: SAP HANA; memcached, eXtremeDB

• Caches: memcached, redis

• Key-Value Stores: redis, Amazon Dynamo, Apache Cassandra

• Dokumenten DBs: CouchDB, MongoDB

• Graph DBs: InfoGrid, Neo4j

• Object DBs: ZopeDB, Gemstone

• …

Einführung 21

NoSQL: Häufige Eigenschaften

• Nomen est Omen – keine SQL basierte Abfrage => aber bewegt sich in die Richtung

• Verzicht auf striktes ACID

• Eventual Consistent

• Einfache Skalierbarkeit durch Daten Verteilung / Sharding => siehe Consistent Hashing.

• Spezialisierter Use-Case

• Keine oder weniger „strikte“ Schemata

Einführung 22

Beispiel:

Apache

• Open Source, ursprünglich entwickelt von Facebook

• Konzepte übernommen von

– Amazons Dynamo DB (der Core Entwickler von Cassandra hat vorher an Dynamo mitentwickelt)

– Google BigTable

• Kommerzieller Support von DataStax

– (inkl. AWS Deployment, falls gewünscht)

Einführung 23

Cassandra Konzepte (1)

• Peer-to-Peer Modell - kein Master => Gossip Protokoll

• Automatische Replikation / Verteilung => Consistent Hashing

• Multi-Datacenter Support

• Tuneable Consistency Modell (per Operation) – read repair Konflikt Auflösung

• Hohe Performance => r/w skaliert weitestgehend linear mit Anzahl der Knoten

• Hohe Verfügbarkeit => definierbarer Replikationsfaktor, Hinted Handoff

Einführung 24

Cassandra Konzepte (2)

• Key-Value++ / Column based

• Cassandra Query Language (CQL)

• Lightweight Transactions => PAXOS

• Map/Reduce support => Integration in Hadoop

Einführung 25

Cassandra Tuneable Consistency

• Replikationsfaktor wird festgelegt

• Quorum = GanzZahligAbgerundet(Replikationsfaktor / 2 + 1)

• Verschiedene Konsistenzlevel (pro Operation wählbar)

• Konflikt Auflösung via Timestamp – neuster gewinnt

• Lesend (Auswahl): – ONE: Antwort des nächsten Knotens

– Quorum: Antwort mit aktuellstem Zeitstempel aus Quorum Knoten

– Local Quorum: wie Quorum aber nur aus einem Rechenzentrum

– ALL: Antwort mit aktuellstem Zeitstempel nach Abfrage aller Replika-Knoten

Einführung 26

Cassandra Tuneable Consistency

• Schreibend (Auswahl): – Any: Der Schreibzugriff muss persistiert sein (eventuell Lesen nicht

möglich wenn die zuständigen Knoten nicht verfügbar => Hinted Handoff)

– ONE: Der Schreibzugriff muss einem zuständigen Knoten persistiert sein (ist danach lesbar)

– Quorum: der Schreibzugriff muss bei Quorum Knoten erfolgreich sein

– Local Quorum: wie Quorum nur 1 RZ

– All: der Schreibzugriff muss bei allen Replika-Knoten erfolgreich sein

Einführung 27

Publikumsfrage – Beispiele für verschiedene

Lese-/ Schreibszenarien

Cassandra Datenmodell

Einführung 28

Keyspace (=>Datenbank)

Column Family (=>Tabelle )

Row

Name:Value

Column

Name:Value Name:Value

…

…

Row

Row Key:

Row Key: …

…

Bestimmt den zuständigen Knoten

=> Consistent Hashing

Der Inhalt der Row liegt „linear“ auf

der Platte

Cassandra Datenmodell Beispiele

Einführung 29

Keyspace: StudiDB

Column Family: Student

Vorname:Paul Nachname:

Muster Note:1plus 123:

Vorname:Lisa Email:l@d.de 124:

create keyspace StudiDB;

use StudiDB;

create column family Student;

set Student [‚123‘][‚Vorname‘] = ‚paul‘

set Student [‚123‘][‚Nachname‘] = ‚Muster‘

set Student [‚123‘][‚Note‘] = ‚1plus‘

set Student [‚124‘][‚Vorname‘] = ‚Lisa‘

…

…

get Student[‚123‘]

=>(colum-Vorname, value=Paul, timestamp=34324)

=>(column-Nachname=Muster, timestamp=132423)

=>(column…

get Student where note=‚1plus‘

Secondary Index muss gesetzt sein

Cassandra Randbedingungen

• Colums können hinten oder vorne hinzugefügt werden => implizite zeitliche Sortierreihenfolge möglich

• Löschen von Colums erzeugen „Tombstones“

– => z.B: Queues sind ein Anti-Pattern

• Schreibzugriffe schneller als Lesen (disk commit log => Memtable => DataFile (Sorted Strings Table) & SSTableIndex & Bloomfilter)

• Vorsicht bei secondary Indexen auf Columns

– Die Rows sind verteilt gespeichert

– Niedrige Kardinalität (viele Duplikate) von Vorteil

– Bei Hoher Kardinalität (und sehr kleine ausgeprägte Selektivität) zu hoher overhead => unnötige Anfragen an alle Knoten im Cluster

Einführung 30

Level:ANY Level:ONE