Verteilte Systeme: Web Services - home.hs

Wegweiser
Verteilte Systeme:
Web Services
Einführung
1
SOA – Service Oriented
Architecture
Frontend
Business Logik
Service Consumer
Persistenz
Service Provider
• Div. Design Prinzipien
– Lose Kopplung
– Abstraktion
– Wiederverwendbarkeit
– Zustandslosigkeit
–…
Einführung
 Web Services
2
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
SOAP Envelope
SOAP Header
Headers
<?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>
SOAP Body
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:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
Einführung
4
WSDL
Quelle: W3C
Einführung
5
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
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
Einführung
8
REST Beispiel
Einführung
9
REST Encoding
• JSON, XML, YAML, HTML oder beliebig
{“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>
• Chunking
• Compression
• Multipart
Einführung
10
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)
Quelle: Martin Fowler
• HATEOAS (Hypermedia as the Engine of Application
State): Dynamische Ressource Links, weg von der
statischen Interfacedefinition
Einführung
14
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
Scaling
Filesystem
Storage
Netzwerk
DB
RAM
Einführung
Processing
17
Wegweiser
DB Scaling
Einführung
18
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
19
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: Riak, CouchDB, MongoDB
• Graph DBs: InfoGrid, Neo4j
• Object DBs: ZopeDB, Gemstone
• …
Einführung
20
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“ Schema
Einführung
21
Apache
• Open Source, Ursprünglich Entwickelt von
Facebook
• Viele Konzepte von Amazons Dynamo (der
Core Entwickler von Cassandra hatte vorher
Dynamo mitentwickelt) und Google BigTable
• Kommerzieller Support von DataStax
Einführung
22
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
23
Cassandra Konzepte (2)
•
•
•
•
Key-Value++ / Column Based
Cassandra Query Language (CQL)
Lightweight Transactions => PAXOS
Map/Reduce support => Integration in
Hadoop
Einführung
24
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 ReplikaKnoten
Einführung
25
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
Publikumsfrage –
Beispiele für verschiedene
Lese Schreibszenarien
Einführung
26
Cassandra Datenmodell
Keyspace (=>Datenbank)
Bestimmt den
zuständigen Knoten
=> Consistent
Hashing
Column Family (=>Tabelle )
Row
Column
Row Key:
Row Key:
Row
Name:Value
…
…
…
Einführung
Name:Value
Name:Value
…
Der Inhalt der Row
liegt „linear“ auf
der Platte
27
Cassandra Datenmodell Beispiele
Keyspace: StudiDB
Column Family: Student
123:
Vorname:Paul
124:
Vorname:Lisa
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‘
…
Nachname:
Muster
Note:1plus
Email:[email protected]
…
get Student[‚123‘]
=>(colum-Vorname, value=Paul, timestamp=34324)
=>(column-Nachname=Muster, timestamp=132423)
=>(column…
get Student where note=‚1plus‘
Einführung
Secondary
Index muss
gesetzt sein
28
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
Level:ANY
Level:ONE
• 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
29