WebAssembly, kurz Wasm, hat sich dank seiner schnellen, nahezu nativen Ausführungsgeschwindigkeit, der großen Auswahl an Programmiersprachen und seines robusten Sandboxing-Modells, das standardmäßig jeglichen Zugriff verweigert, immer wieder als revolutionäre Technologie erwiesen. Es ist bereits im gesamten Web weitverbreitet und spielt auch auf der Serverseite eine bedeutende Rolle.
Jedes aufstrebende Ökosystem braucht eine Vision davon, wie all seine Bestandteile ineinandergreifen – und genau hier kommt das WebAssembly Component Model ins Spiel. Das Component Model ist ein System, das sowohl die Interaktion zwischen einzelnen WebAssembly-Codeeinheiten als auch zwischen WebAssembly-Code und einer Hostumgebung ermöglicht. Im Mittelpunkt steht das Konzept der WebAssembly-Komponenten, bei denen es sich im Wesentlichen um reguläre Wasm-Module mit kodierten Datentypen handelt. Diese Typen ermöglichen die Generierung von Glue-Code im Hintergrund, durch den Komponenten nahtlos miteinander kommunizieren können.
Das Komponentenmodell läutet ein neues Zeitalter der modernen Softwareentwicklung ein: Entwickler können Komponenten aus beliebigen Programmiersprachen-Ökosystemen auswählen und zu einer einzigen Anwendung zusammenfügen. Sie haben eine Datenverarbeitungsanwendung in Python, benötigen aber einen effizienten Parser aus dem Rust-Ökosystem? Kein Problem. Ein Team in Ihrem Unternehmen beherrscht Go, ein anderes programmiert jedoch ausschließlich in JavaScript? Auch das ist kein Problem: Jedes Team kann WebAssembly-Komponenten erstellen, die sich mühelos miteinander kombinieren lassen.
Warum wir es aus technischer Sicht brauchen
WebAssembly steht vor einem Problem, das wir bei fast jeder neuen Plattform zur Codeausführung beobachten: Wie lassen sich Daten sicher, geschützt und effizient zwischen separaten Codeeinheiten austauschen, die möglicherweise mit völlig unterschiedlichen Programmiersprachen-Toolchains erstellt wurden? Grundsätzlich könnten zwei separate WebAssembly-Module wie viele andere Systeme vorgehen und Daten als JSON, Protobuf oder in einem anderen weitverbreiteten Datenaustauschformat untereinander übertragen. Die Serialisierung und Deserialisierung dieser Formate ist jedoch relativ aufwendig. Da die beiden Module, die miteinander kommunizieren möchten, wahrscheinlich von derselben Laufzeitumgebung parallel und nicht über ein Netzwerk ausgeführt werden, lässt sich dies letztlich besser implementieren.
Die Schwierigkeit liegt darin, wie die einzelnen Programmiersprachen Daten darstellen. Sprachimplementierungen können unterschiedliche Kodierungen für Zeichenketten verwenden, und während eine Sprache sequenzielle Daten vielleicht bevorzugt in einem Array speichert, setzt eine andere möglicherweise eher auf verkettete Listen. Damit Code aus verschiedenen Sprachen miteinander kommunizieren kann, müssen sich die Sprachen auf eine gemeinsame Darstellung für alle Datentypen einigen. Diese wird als Application Binary Interface, kurz ABI, bezeichnet. In der Praxis herrscht jedoch keine Einigkeit. Soll in einer Sprache geschriebener Code mit Code kommunizieren, der in einer anderen Sprache geschrieben wurde, muss sich üblicherweise ein armer Entwickler hinsetzen und sorgfältig (und mühsam) Code schreiben, der zwischen den beiden Sprachen übersetzt. Dies erfordert genaue Kenntnisse der Funktionsweise beider Sprachen und ist äußerst fehleranfällig. In einigen Sprachökosystemen wurden Werkzeuge entwickelt, die dies automatisch erledigen können, doch selbst diese unterstützen nur ausgewählte Sprachen.
Glücklicherweise definiert das Komponentenmodell ein gemeinsames Datenformat für alle Sprachen, das als kanonische ABI bezeichnet wird. Um die Arbeit für Menschen zu erleichtern, gibt es außerdem eine Schnittstellenbeschreibungssprache namens WebAssembly Interface Types, kurz WIT, mit der sich Komponentenschnittstellen beschreiben lassen.
Die Welt von WIT
Wir haben also all diese Komponenten, aber woher wissen wir, wo wir sie einsetzen können? Schließlich läuft WebAssembly an vielen verschiedenen Orten – in Webbrowsern, auf Servern, am Edge, auf winzigen Geräten und mehr – und überall stehen unterschiedliche Funktionen zur Verfügung. WIT führt dafür das Konzept der Welten ein. Eine Welt ist die Schnittstelle, der eine Komponente entspricht – sie besteht aus einer Reihe von Funktionen, die eine Komponente importieren kann, und einer Reihe von Funktionen, die sie exportiert. Dadurch können wir recht einfach nachvollziehen, wie Komponenten aufgebaut sind und wie sie sich zusammensetzen lassen. Hier ist die Definition einer Komponente, die in der Welt `wasi:cli/command` angesiedelt ist. Diese beschreibt Komponenten, die in einer Terminal-Befehlszeile ausgeführt werden:
Quelle: https://github.com/WebAssembly/wasi-cli, der Kürze halber angepasst
Diese Komponente kümmert sich um Dinge wie das Dateisystem und Zufallswerte und stellt gleichzeitig Datenströme für die Ein- und Ausgabe bereit. Entscheidend ist jedoch, dass sie eine Funktion bereitstellt, die beim Aufruf des Befehls ausgeführt wird.
Worlds können von jedem definiert werden, es gibt jedoch eine Reihe standardisierter Worlds für Komponenten, die HTTP-Anfragen verarbeiten, auf USB-Geräte zugreifen, KI-Modelle verwenden können und vieles mehr. Hostumgebungen können angeben, welche Worlds sie implementieren, sodass Entwickler leicht erkennen können, welche Komponenten funktionieren. Da Komponenten miteinander kombinierbar sind, lassen sich manche Worlds auch auf Grundlage anderer Worlds implementieren und die beiden Komponenten miteinander verknüpfen. Wenn Sie beispielsweise eine Hostumgebung haben, die eine Sockets-World implementiert, aber eine Komponente verwenden möchten, die HTTP-Anfragen in einer HTTP-World stellen will, können Sie eine Adapterkomponente schreiben, die die HTTP-World mithilfe von Sockets implementiert:
Durch eine einfache Komposition kann Ihre Komponente jetzt ohne jegliche Änderungen in der Socket-Welt ausgeführt werden! Die Möglichkeiten sind grenzenlos.
Die Zukunft liegt vor uns
Das Komponentenmodell ist von enormer Bedeutung – nicht nur für WebAssembly, sondern für Entwicklerinnen und Entwickler auf der ganzen Welt. Es wird die Art und Weise, wie Software konzipiert und entwickelt wird, grundlegend verändern. Schon jetzt bietet es einen immensen Nutzen, und dabei stehen wir erst am Anfang. Verfolgen Sie die Entwicklungen im WebAssembly-Ökosystem, denn mit zunehmender Verbreitung werden sich zweifellos immer mehr überzeugende Anwendungsfälle ergeben.
Über den Autor
Ähnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.