Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Blockchains werden in der Regel von einem Peer-to-Peer-Computernetzwerk (P2P) als öffentliches verteiltes Buch verwaltet, in dem die Knoten gemeinsam ein Konsensalgorithmusprotokoll befolgen, um neue Transaktionsblöcke hinzuzufügen und zu validieren. Obwohl Blockchain-Datensätze nicht unveränderlich sind, da Blockchain-Forks möglich sind, können Blockchains an sich als sicher angesehen werden und stellen ein Beispiel für ein verteiltes Computersystem mit hoher byzantinischer Fehlertoleranz dar.

Was hat es mit dem byzantinischen Fehler auf sich?

Als byzantinischen Fehler bezeichnet man in der Informationstechnik Fehler, bei denen sich ein System beliebig falsch verhält. Beispielsweise schickt ein Server gelegentlich falsche Antworten und erreicht gelegentlich falsche Systemzustände. Ein byzantinischer Fehler beschreibt im Allgemeinen ein schwer zu erfassendes Fehlermodell. In Mehrprozessor-Systemen bezeichnet der byzantinische Fehler eine Fehlerklasse. Falls eine Komponente an verschiedene Prozessoren unterschiedliche (protokollkonforme) Ergebnisse liefert, spricht man von einem byzantinischen Fehler.

Wer hat es erfunden und wofür?

Die erste Blockchain wurde von einer Person, oder einer Gruppe von Personen, unter dem Namen bzw. dem Pseudonym Satoshi Nakamoto im Jahr 2008 geschaffen. Dieser sollte als öffentliches verteiltes Hauptbuch für Bitcoin-Kryptowährungstransaktionen dienen. Dieser Arbeit basiert auf früheren Arbeiten von Stuart Haber, W. Scott Stornetta und Dave Bayer. Der Source Code ist Open Source und kann auf GitHub unter https://github.com/bitcoin/bitcoin eingesehen. Die Implementierung der Blockchain in Bitcoin, machte es zur ersten digitalen Währung, die das Problem der doppelten Ausgaben ohne die Notwendigkeit einer vertrauenswürdigen Behörde bzw. Institution oder eines zentralen Servers löste. Das Bitcoin-Design hat andere Anwendungen und Blockchains inspiriert, die für die Öffentlichkeit zugänglich sind und von Kryptowährungen bzw. NFT Projekten in großem Umfang genutzt werden. Die Blockchain kann als eine Art Zahlungsschiene betrachtet werden.

Zentrale Einheiten einer Blockchain

Distributed-Ledger-Technologie (DLT)

Alle Netzwerkteilnehmenden haben Zugriff auf ein verteiltes „Kontobuch“ (distributed Ledger) mit nicht manipulierbaren Datensätzen der Transaktionen. In diesem gemeinsam genutzten Kontobuch werden Transaktionen nur ein einziges Mal aufgezeichnet, wodurch die für traditionelle Unternehmensnetzwerke typische Doppelarbeit entfällt.

Nicht manipulierbare Datensätze

Keiner der Teilnehmenden kann eine Transaktion verändern oder manipulieren, nachdem diese im gemeinsam genutzten Kontobuch aufgezeichnet wurde. Falls ein Transaktionsdatensatz einen Fehler enthalten sollte, muss eine neue Transaktion hinzugefügt werden, die diesen Fehler korrigiert, und beide Transaktionen sind in der Folge sichtbar.

Smart Contracts

Um Transaktionen zu beschleunigen, wird ein Regelwerk – Smart Contract genannt – in der Blockchain gespeichert und automatisch ausgeführt. Ein Smart Contract kann beispielsweise Bedingungen für die Übertragung von Unternehmensanleihen, Bedingungen für eine zu zahlende Reiseversicherung und vieles mehr definieren. In dem Beitrag von gestern gehe ich Explizit auf dieses Thema ein.

Fazit

Bei einer Blockchain hat man als Mitglied eines nur auf Mitglieder begrenzten Netzwerks die Sicherheit, dass man präzise und termingerechte Daten erhält und das die vertraulichen Blockchain-Datensätze nur mit den anderen Netzmitgliedern geteilt werden, denen man ausdrücklich den Zugriff gewährt hat. Von allen Netzmitgliedern wird Konsens zur Korrektheit der Daten verlangt und sämtliche validierten Transaktionen sind nicht manipulierbar, weil sie permanent aufgezeichnet werden. Niemand kann eine Transaktion löschen oder ändern. Dies stellt eine immense Sicherheit dar.

Bei einem verteilten Kontobuch, dass von Mitgliedern eines Netzwerks gemeinsam genutzt wird, entfällt der Bedarf nach einem zeitaufwendigen Abgleichen von Datensätzen. Und zur Beschleunigung von Transaktionen lässt sich ein Regelwerk – Smart Contract genannt – in der Blockchain speichern und automatisch ausführen. Dies wiederum steigert die Effizienz ungemein. Häufig vergeudet man wertvolle Arbeitszeit mit der Pflege von Duplikaten, Datensätzen und mit Validierungen anderer Anbieter. Traditionelle Aufzeichnungssysteme können anfällig für Betrugsversuche und Cyberangriffe sein. Eingeschränkte Transparenz kann die Verifizierung von Daten behindern. Und durch das IoT (Internet of Things = Internet der Dinge) sind das Volumen von Transaktionsdaten explosionsartig gestiegen. All dies verlangsamt die Prozesse bzw. das Geschäft, belastet das Ergebnis – und bedeutet, dass wir bessere Methoden benötigen. Hier kann die Blockchain Abhilfe schaffen.

Der Beitrag Blockchain – Dezentralisierte, transparente und vertrauenswürdige Systeme erschien zuerst auf CEOsBay.