Lernen Sie Bond und Microsoft Bond kennen – ein neues Framework zur Datenserialisierung

Microsoft Bond ist ein neues Serialisierungsframework für schematisierte Daten, das von Microsoft erstellt wurde.

Lassen Sie uns zusammenfassen, wo die Datenserialisierung am häufigsten verwendet wird:

• Datenpersistenz in Dateien, Streams, NoSQL und BigData.
• Datenübertragung in Netzwerken, IPC etc.

Üblicherweise müssen diese Anwendungen mit schematisierten Daten umgehen, wobei Schema bedeutet:

• Struktur: Hierarchie, Beziehungen, Ordnung.
• Semantik: Alter in Jahren seit der Geburt.

Tatsächlich haben alle Daten ein Schema, selbst wenn es implizit definiert oder von Ihrer Programmiersprache standardmäßig unterstützt wird. Wenn es um komplexe Datenstrukturen geht, schreiben wir am Ende unterstützende Datenübertragungsobjekte (DTOs) und Code, der für IO verantwortlich ist, oft in verschiedenen Sprachen. Sobald es wächst und sich entwickelt, wird es schnell zu einem Albtraum, all diese Teile zu pflegen. Hier gewinnen die Serialisierungs-Frameworks das Spiel.

Zunächst einmal definiert jedes Serialisierungs-Framework eine Abstraktion für die Datenschemadefinition, die nicht an eine bestimmte Programmiersprache oder Plattform gebunden ist. Diese Abstraktion ist als DSL (domänenspezifische Sprache) bekannt.

Mit einer solchen DSL können wir Datenschemata für eine bestimmte Anwendung definieren. Die Definition wiederum kann in mehreren Formen ausgedrückt werden, aber Serialisierungsframeworks unterstützen häufig eine einzelne Form, die für ihre DSL gut geeignet ist. Zu kompliziert? Hier ist ein bekanntes Beispiel: XSD und XML.

XSD definiert eine DSL, XML wird (empfohlen), um Dokumente zu definieren, die dem XSD-Schema entsprechen. Sie können aber auch „xsd.exe“ verwenden, um DTO-Klassen zu generieren, die der XSD entsprechen, daher sind die generierten Klassen nur eine andere Form. Beachten Sie, dass Sie XML aus DTOs und umgekehrt generieren können und dass sie semantisch identisch sind, da die Semantik gleich ist: Sie wird mit der XSD definiert. Zusammenfassend stellt Ihnen ein Serialisierungs-Framework eine DSL zur Verfügung, mit der Sie Datenschemata in einem bestimmten Format definieren, das vom jeweiligen Framework am besten unterstützt wird.

Das abstrakte Datenschema soll schließlich in einer Menge von Entitäten materialisiert werden, die in einer Programmiersprache ausgedrückt werden. Alle Serialisierungs-Frameworks bieten spezielle Tools, sogenannte Code-Generatoren.

Sie generieren den gesamten unterstützenden Code für Zielprogrammiersprachen, der für Clients erforderlich ist, um mit schematisierten Daten zu arbeiten: DTOs, Proxy usw. Dies ist letztendlich für stark typisierte Sprachen erforderlich, während es für ententypisierte (dynamische) Sprachen optional sein kann .

Der letzte Punkt ist die Datenpersistenz auf der Leitung. Die eigentlichen Daten sollen schließlich in Rohbytes (oder Text) serialisiert und zurück deserialisiert werden.

Alle Frameworks zur Datenserialisierung bieten hier eine weitere Abstraktion, die als Protokolle bezeichnet wird. Ein Protokoll definiert eine Reihe von Regeln, die definieren, wie strukturierte Daten gemäß ihrem Schema serialisiert oder deserialisiert werden sollen. Jedes Protokoll wird normalerweise für alle Programmiersprachen und Plattformen implementiert, die vom gegebenen Serialisierungsframework unterstützt werden. Je mehr Programmiersprachen/Plattformen es unterstützt, desto mehr Implementierungen soll es bereitstellen.

Stellen Sie sich vor, ein Framework ist bereit, das JSON-Protokoll zu unterstützen, dann muss es JSON-Reader/Writer für beispielsweise C#, C++, Windows, Linux usw. bereitstellen.

Alles zusammen: Jedes moderne Framework zur Datenserialisierung bietet Ihnen Folgendes:

• Abstraktionen: DSL und Protokolle.
• Tools zur Codegenerierung.
• Protokollimplementierungen.

Microsoft Bond ist ein modernes Framework zur Datenserialisierung. Es bietet leistungsstarke DSL- und flexible Protokolle, Codegeneratoren für C++ und C#, effiziente Protokollimplementierungen für Windows, Linux und Mac OS X.

Bond blieb mehrere Jahre lang eine nur für den internen Gebrauch bestimmte Technologie, aber dank der Open-Source-Initiative von Microsoft wurde Bond auf GitHub verfügbar gemacht: Microsoft Bond.

Konkurrenten für die Datenserialisierung

Die Rivalität zwischen den Software-Giganten führte dazu, dass eine Reihe von Serialisierungs-Frameworks auftauchten:

• Google Inc. - Google-Protokollpuffer
• Facebook Inc. - Thrift, das jetzt von Apache verwaltet wird
• Apache Foundation-Software - Avro

Offensichtlich sind sie alle inkompatibel, was in Ordnung ist, es sei denn, Sie erstellen Ihre öffentliche API mit einer dieser APIs.

Jeder von ihnen hat Vor- und Nachteile, sodass Sie je nach Bedarf zwischen ihnen wählen können.

Warum Bindung?

Die offizielle Antwort auf diese Frage ist hier: „Why Bond“.

Hier ist die kurze Zusammenfassung:

• Bond unterstützt Rich-Type-Systeme einschließlich Generika.
• Bond unterstützt Schemaversionierung und Zwei-Wege-Kompatibilität.
• Bond unterstützt die Schemamanipulation zur Laufzeit.
• Bond unterstützt verschiedene Sammlungen: „Vektor , Karte , Liste “.
• Bond unterstützt typsichere faule Serialisierung: „bonded ”
• Bond unterstützt austauschbare Protokolle (Formate) mit Marshalling und Transcoding

Ein wichtiger Hinweis ist, dass Bond der „Pay-to-Play“-Strategie folgt. Je mehr Funktionen Sie hinzufügen/verwenden, desto mehr zahlen Sie für Größe und Geschwindigkeit. Dies gibt Entwicklern eine große Flexibilität.

Seien wir ehrlich und listen auch die Nachteile auf:

• Bond zielt auf den Microsoft-Stack ab, der C++ und C# unterstützt, aber (noch) nicht Java unterstützt.
• Bond unterstützt den Union-Typ („oneof“ in protobuf) nicht.

Was ist mit der Leistung?

Wenn es darum geht, ein Framework mit einem anderen zu vergleichen, suchen Entwickler oft nach Leistungsvergleichen. Aber erinnern wir uns, dass diese Frameworks aus DSL, Codegeneratoren und Protokollen bestehen. Wenn Sie nur die Protokollleistung betrachten, werden Sie die von DSL und Codegens bereitgestellten Funktionen vermissen. Manchmal ist ein besseres DSL viel wichtiger als ein paar Prozent Unterschied in der Serialisierungsgeschwindigkeit.

Neben der Geschwindigkeit könnten auch die platzsparenden Codierungen, die von einigen Protokollen unterstützt werden, wichtig sein. Ich ermutige Sie, einen Leistungs-/Platzvergleich mit Ihren domänenspezifischen Daten durchzuführen. Nur so können Sie alle Vorteile abschätzen, die Sie aus einem bestimmten Framework ziehen könnten.

Dieser Artikel enthält das Demoprojekt, das die Verwendung des Bond-Frameworks demonstriert, indem alle Datensätze aus dem Windows-Anwendungsereignisprotokoll gelesen, als Bond-Objekte serialisiert und wieder deserialisiert werden.

Um die Demo zu erstellen und auszuführen, müssen Sie keine andere Software als Visual Studio installieren.

Verwenden von Microsoft Bond

Bond bekommen

Sehen Sie sich den offiziellen Leitfaden an, um Bond für Ihre Plattform(en) zu erhalten.

Für .NET-Projekte ist dies so einfach wie:

 install-package Bond.CSharp

Das Paket beinhaltet:

• Codegenerator (gbc.exe) im bin-Ordner
• .NET-Bibliotheken
• MSBuild-Aufgaben

Arbeitsablauf

Der Arbeitsablauf umfasst die folgenden Schritte:

• Lernen Sie DSL kennen und definieren Sie das Datenschema, indem Sie „.bond“-Dateien schreiben.
• Verwenden Sie den Codegenerator („gbc.exe“), um DTOs für Ihre Programmiersprache zu erhalten.
• Verweisen Sie in Ihrem Projekt auf die generierten Dateien sowie Bond-Laufzeitbibliotheken.

Erwägen Sie die Verwendung von MSBuild-Aufgaben, die mit dem Framework bereitgestellt werden, um den Codegenerierungsschritt zu automatisieren.

Überblick über die DSL-Funktionen

Wenn Sie mit dem Schreiben Ihrer ersten „.bond“-Datei beginnen, müssen Sie deren Syntax und Funktionen kennen. Bitte besuchen Sie die offizielle Dokumentationsseite, die die IDL im Detail beschreibt. Lassen Sie uns nur grundlegende Funktionen überprüfen:

• Module: Das Schema kann in verschiedene Dateien aufgeteilt werden, die mit der „Import“-Anweisung enthalten sind.
• Namespace: haben dieselbe Bedeutung wie C++/C#.
• Benutzerdefinierte Strukturen: eine Einheit der Benutzertypdefinition.
• Die Vorwärtsdeklaration ist nützlich für rekursive Datenstrukturen.
• Grundtypen: „bool, uint8(bis 64), int8(bis 64), float, double, string, wstring“.
• Containertypen: „blob, list , Vektor , einstellen , map<K, T>, nullable “.
• Benutzerdefinierte typisierte Aliase und Zuordnungen, z. B. wenn Sie „DateTime“ in C# haben möchten, aber Ticks („int64“) auf der Leitung.
• Benutzerdefinierte Attribute: nützlich für die benutzerdefinierte Codegenerierung.

Gelangweilt? Hier ist ein Beispiel:

 namespace MyProject struct MyRecord { 0: string Name = "Noname"; 1: vector<double> Constants; }

wobei „0“ und „1“ die Feldordinalzahlen sind (können beliebige Ganzzahlen mit beliebigem Tempo sein) und = "Noname" der (optionale) Standardwert ist.

Codegenerierung

Das Bond-Framework bietet ein in Haskell geschriebenes Codegenerierungstool. So generieren Sie C#- und C++-Code aus einem „.bond“-Schema in der Befehlszeile:

 gbc c# example.bond gbc c++ example.bond

Unterstützte Protokolle (Formate)

Standardmäßig unterstützt Bond drei Arten von Protokollen:

• Markierte Protokolle: „CompactBinary“ und „FastBinary“

Getaggte Protokolle verschachteln Schema-Metadaten innerhalb der Nutzlast. Dadurch wird die Nutzlast selbstbeschreibend, sodass Verbraucher sie interpretieren können, auch ohne das vom Erzeuger verwendete Schema zu kennen.

• Ungetaggte Protokolle: „SimpleBinary“

Protokolle ohne Tags serialisieren nur Daten und erfordern daher, dass Verbraucher das Nutzdatenschema über einen Out-of-Band-Mechanismus kennen. Ungetaggte Protokolle werden häufig in Speicherszenarien verwendet, weil sie es ermöglichen, ein Schema einmal zu speichern (z. B. in einer Systemtabelle in einer Datenbank), wodurch der Metadaten-Overhead von vielen Datensätzen, die dasselbe Schema verwenden, eliminiert wird.

• DOM-basierte Protokolle: „SimpleJson“ und „SimpleXml“

Das DOM-basierte Protokoll analysiert die gesamte Nutzlast in ein In-Memory-Datenobjektmodell, das dann während der Deserialisierung abgefragt wird. Typischerweise wird diese Art von Protokoll verwendet, um textbasierte Kodierungen wie JSON oder XML zu implementieren.

Für jedes Protokoll stellt Ihnen die Bond-Laufzeitbibliothek die entsprechenden Reader- und Writer-Klassen zur Verfügung, die die eigentliche Serialisierung übernehmen.

Die Verwendung der Protokolle ist ziemlich einfach und etwas schwieriger als das berühmte „JsonConvert.SerializeObject()“:

 var record = new MyRecord { Name = "FooBar", Constants = { 3.14, 6.28 } }; var output = new OutputBuffer(); var writer = new CompactBinaryWriter<OutputBuffer>(output); Serialize.To(writer, record); var input = new InputBuffer(output.Data); var reader = new CompactBinaryReader<InputBuffer>(input); record = Deserialize<Example>.From(reader);

Was kommt als nächstes?

Wenn Sie Bond lieben und viel Freizeit zum Programmieren haben, sollten Sie eines dieser Elemente in die Entwicklung aufnehmen. Ich werde nicht alle Vorteile aufzählen, die Sie möglicherweise durch einen Beitrag erzielen, aber ich weiß, dass viele Entwickler nach Ideen suchen, zu denen sie beitragen können:

• Implementieren Sie eine Portierung nach Java. Ersetzen Sie Java durch andere Mainstream-Sprachen Ihrer Wahl.
• Implementieren Sie den Import/Export des Bond-Schemas zum Austausch mit anderen DSLs (z. B. „.proto <=> .bond“).

Wie auch immer Sie sich in Bezug auf Bond entscheiden, ich empfehle Ihnen, sich zuerst mit Adam Sapek in Verbindung zu setzen. Er ist der Leiter dieses Projekts und wird Sie mit den Anforderungen des Marktes anleiten.