”A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“ - W3C Zitat
Das W3C schreibt in ihrem Zitat das Web-Services ein Softwaresystem ist, dass interoperable Maschine zu Maschine Interaktion über das Internet ermöglicht. Die speziellen Schnittellen sollen in einem Maschinenformat lesbaren Format (WSDL) definiert werden. Dadurch können andere Maschinen, die Daten interpretieren. Dabei dient das SOAP Protokol, dass dafür verwendet, dass mehrere Maschinen miteinander kommunizieren. Dieses Protokol verpackt die Daten, die die Services untereinander austauschen sollen. SOAP setzt wiederum auf HTTP auf oder anderen Web Protokollen. Die Nutzdaten die von den Services bereitgestellt werden in XML realisiert.
Die fünf grundlegenden Standards für Web-Services
1. XML
Dient als das grundlegende Format für Modelle, Formate und Datentypendefinitionen.
2. HTTP
Wird bei Web-Services als ein Kommunikationsprotokoll verwendet un ermöglicht die Verwendung von REST und SOAP.
3. WSDL
Dient für die Definition von Serviceschnittstellen. Besteht aus drei Teilen: Signatur, Binding und Location.
Die Signatur ist die Servicekennung mit Namen und Parametern und zusätzlich mit den den Hinweis welche Werte durch den Web-Service wieder zurückgeliefert werden. Dies ist besonders wichtig für jede Datenautomatisierung. Das Binding klärt welches Protokoll verwendet wird. Location klärt wo der konkrete Service zu finden ist. Diese gesamten Informationen werden in XML realisiert.
Das Types dient um einen eigenständigen Namensraum zu definieren, um zu klären welches Präfix die deklarierten Typen erhalten .
Das Element definiert die gegebenen Variablennamen und den Ausgabewert. Es sind alle XML Schematypen erlaubt wie string, integer, float , bool usw. An dieser Stelle können auch komplexere Datenstrukturen definiert werden.
Das Interface kapselt das Operations- und Faulttag und stellt die Verbindung zum Web-Service und dessen Operation her.
Es können die Operation benannt werden, die der Service anbietet und es können auch Fehler benannt werden die geworfen werden.
Das Binding ist die Stelle wo das Kommunikationsprotokoll definiert wird und auf die entsprechende Referenz des SOAP Protokolls verwiesen wird. Zusätzlich wird ein Message Exchange Pattern festgelegt. Für jede Methode wird geklärt wohin das Request oder Response geht.
Der Service ist die Stelle wo Kommunikationsendpunkte definiert werden. An dieser Stelle wird erneut die Schnittelle referenziert.
In der Zusammenfassung gibt WSDL an, welche Methoden ein Web-Service anbietet. Es werden Fragen geklärt wie z.B. an wen muss sich der Client wenden, um diese definierten Methoden zu verwenden. Welche Nachrichten muss der Client dafür senden und mit welchen Nachrichten muss der Client rechnen wenn der Web-Service aufgerufen wird. Wenn diese Definition einmal steht kann aus dieser Grundlage eine Automatisierung dieser Daten erfolgen, die dann auf den festgelegten Parametern und Rückgabewerten aufbaut.
4. SOAP
Ist das Protokoll, um die Interaktion von anderen Systeme mit dem Web Service zu ermöglichen. Die Nachrichten werden mittels eines separaten Transportprotokolls versendet. Das bedeutet SOAP benötigt ein zusätzliches Web-Protokoll auf dem es aufsetzen kann oft ist es HTTP . Es kann aber auch SMTP sein. Die Bestandteile von SOAP ist der Nachrichtenaufbau und das Verarbeitungsmodell wie die Nachrichten verarbeitet werden. Auch Abbildung auf verschiedenen Transportprotokolle werden in diesen Standard festgelegt.
Das SOAP Envelope Grundgerüst besteht aus der XML Syntax in der zwei logische Blöcke (Header und Body) definiert werden.
Im Header werden alle möglichen Informationen gesammelt, die die Infrastruktur benötigt, um diese Nachrichten weiterzuleiten z.B. Routinghinweise. dass die Nachricht über spezielle Knoten verschickt werden muss oder Sicherheitsinformationen.
Im Body wird die Nutzlast definiert. Die Daten die der Consumer an den Web-Service verschickt oder die Daten die der Consumer vom Web-Service zurück erhalten hat zuzüglich möglicher Fehlermeldungen die während des Prozessablaufs auftreten können.
Desweiteren stellt SOAP spezifische Knoten bereit unter anderem den Senderknoten aus dem die Initialnachricht verschickt wird. Dies kann der Service Consumer oder der Service Provider sein. Es existieren verschiedene Zwischenstationsknoten die, die Nachrichten übertragen bzw.weiterleiten. Diese Knoten können Header-Blöcke lesen, modifizieren oder sogar löschen. Der Empfängerknoten ist letztendlich der Knoten, der die verschickte Nachricht erhält. Die Adressierung dieser Knoten geschieht über Universal Resource Identifier (URI).
Die SOAP Nachrichten landen im Body von HTTP-Nachrichten und haben einen eigen Content-Type: application/soap+xml
Es existieren zwei Methoden HTTP-GET um zu lesen und HTTP-POST um eine modifizierte Anfrage zu stellen.
SOAP wird heutzutage nur noch selten bei bestimmten Applikationen verwendet und wurde fast vollständig von REST verdrängt.
Es ist heutzutage nicht mehr zeitgemäß mit SOAP zu arbeiten. Das Problem an SOAP ist die sog. WS-* Hölle die dieser Technologie das Genick gebrochen hat. Dort wurde für jeden spezifischen Nachrichtenaustausch eine Spezifikation definiert und dieses extreme detailstandasierte Verhalten auf ein Verteiltes System zu integrieren ist viel zu aufwendig.
5. UDDI
Wird für das Management von Web-Services eingesetzt. Eine Registry wo sich die Web-Services anmelden und die Service Consumer sich über die Web-Services informieren können welche im System vorhanden und bereit sind. An dieser Stelle werden die in WSDL generierten Services angemeldet.
Im ersten Schritt läd der Service Provider die Service Description im WSDL Format in das Directory hinein. Im zweiten Schritt kann ein Service Consumer dementsprechend das Verzeichnis durchsuchen und durch gezielte Abfragen nach einen bestimmten Service schauen. Ist der gesuchte Web-Service gefunden worden, wird dieser im dritten Schritt beim Service Provider angefragt. Im vierten Schritt versendet der Service Provider die Antwort direkt an den Service Consumer mit allen wichtigen Web-Service Informationen die Angefragt worden sind weiter.
REST - Representational State Transfer
REST ist ein Architekturstil für verteilte Systeme. REST Architekturen werden über HTTP realisiert.
REST - Fünf Prinzipien
Wenn ein verteiltes System realisiert werden soll, dann werden Ressourcen mit einer 1. eindeutigen Identifikation benötigt.
Diese Ressourcen werden verteilt und müssen wieder auffindbar sein. Die Ressourcen müssen sich auch gegenseitig finden können.
Die Ressourcen sind untereinander verknüpft. Die 2.Verknüpfung wird über Hypermedialinks realisiert.
Es gibt 3.Standardmethoden und dort ist die Abweichung zu Web-Services und SOAP deutlich sichtbar. An dieser Stelle werden Methoden verwendet die das REST Protokoll den Anwender zur Verfügung stellt. Es gibt 4. unterschiedliche Repräsentationen für die Daten die ausgetauscht werden und die gesamte 5. Kommunikation ist statuslos . Es muss sich also kein Server bestimmte Zustände merken was an Performance spart.
1. eindeutigen Identifikation
Alle Instanzen, die für die Software die verteilt wird von Bedeutung sind, erhalten eine eindeutige ID.
Innerhalb HTTP wird das Vorhaben durch URIs umgesetzt z.B. http://example.com/customers/1234 so können die Daten relativ einfach abgegriffen werden. Die Umsetzung passiert im Hintergrund und ist gekapselt innerhalb der Datenstruktur.
Welche Ressourcen sollen auf die Identifier abgebildet werden?
Es werden hier für a) Primärresourcen definiert diese sind z.B. Abstraktionen der Software also die Buisness Objects, die umgesetzt werden sollen. Beispiele sind Kunden oder Bestellungen. Danach werden die b) Sub-Ressources definiert also Teile von Primärressourcen, die aber besonders wichtig sind für die weitere Verarbeitung, wo oft darauf zugegriffen wird und dadurch eine eigenständige Separierung Vorteile mit sich bringt. Beispiele hierfür sind Lieferadressen oder Bestellpositionen. Innerhalb von c) Listen werden gleichartige Ressourcen zusammengefasst wie z.B. alle Kunden, Rechnungen usw. Diese werden dann komfortabel über die URI angefordert und der letzte Teil, der Innerhalb des REST Systems separiert wird sind d) Aktivitäten. Aktivitäten bilden z.B. Teile von Geschäftsprozessen wo angelegt, storniert wird usw.
2. Verknüfungen - Hypermedialinks
Die Daten und Funktionen werden verknüpft. Dadurch werden Strukturen geschaffen. In dem unterliegenden JSON Beispiel ist durch die Antwort der REST-Schnittelle der Kunde oder das bestellte Produkt direkt auffindbar. Zusätzlich kann die Bestellung über die Aktivität ./cancellations storniert werden. Dadurch kann der Zustand der Applikation gesteuert werden. An dieser Stelle ist das Stateless Prinzip deutlich sichtbar indem diese Stornierung in keiner Datenbank vermerkt wird.
3. Standardmethoden
Kein SOAP Interface mehr sonder die Werkzeuge die HTTP mit sich bringt werden jetzt eingesetzt. Nur diese Methoden werden in einem Restful-System eingesetzt. Die Logik wird jetzt anhand der URIs abgebildet. Der Vorteil ist eine relativ lose Kopplung.
Die Kombination dieser Methoden reicht aus um jeden logischen Aufruf zu starten. Es können auch zusätzliche Parameter an die URI mitgeliefert werden falls der Bedarf besteht. z.B:
4. unterschiedliche Repräsentationen
Die unterschiedlichen Repräsentation der Daten werden innerhalb von HTTP über Content Negotiation übergeben. Das bedeutet das beim Aufruf eines REST - Service schon definiert wird welche Daten erwartet werden. Die Rückgabe der Daten kann in unterschiedlichen Formaten erfolgen kann aber auch zwischen den Beteiligten spezifiziert werden.
5. Statuslose Kommunikation
Die Zustände innerhalb der Kommunikation bzw. Verarbeitungen werden auf dem Server nicht vorgehalten. Es sind keine Sessions notwendig. Der Zustand wird vom Client gehalten oder er wird vom Server direkt in einem Ressourcenzustand umgewandelt. Es gibt also kein Client Server Prinzip und es existiert ein entkoppelter Sachstand.
Eigene Meinung und Gedanken
Grundsätzlich fand ich die Vorlesung sehr informativ mit einen Haken. Wir hatten sehr viel Zeit damit verbracht die SOAP Architektur uns näher anzuschauen nur um am Ende zu erfahren das SOAP eigentlich nicht mehr zeitgemäß ist. Mir würde es lieber gefallen wenn diese wichtige Information vor dem Themenbeginn von SOAP gekommen wäre und das Thema als solche wesentlich kürzer abgehandelt werden würde, umso dafür genauer und schneller auf das REST Thema zukommen und diesem Thema mehr Zeit zu widmen.