Bee (dt. Biene) ist eine Produktionsreife Implementierung des Core Clients in der Programmiersprache Rust. Teile aus allen vorherigen Entwicklungen werden zu einer einheitlichen Plattformlösung zusammengeführt.
Das Ziel von Bee ist es, eine Standardisierte unternehmensfertige modulare EEE Softwarearchitektur zu entwickeln.
EEE steht für „Environment Entity Effect“, das ist eine ereignisgesteuerte Softwarearchitektur, sie stellt die gesamte Kommunikationsinfrastruktur zwischen den Softwarekomponenten bereit.
Diese Softwarearchitektur beinhaltet einen Publish/Subscribe-Messaging-Mechanismus, der eine asynchrone Kommunikation über alle Softwaremodule hinweg ermöglicht, ohne dass sie direkt voneinander abhängig sind, wodurch das System sehr modular und lose gekoppelt werden kann.
Durch die Entkopplung wird verhindert, dass Entitäten wie einzelnen Softwaremodule direkt miteinander interagieren, stattdessen wird den Entitäten ermöglicht, “Effekte” (in der Regel Zeichenfolgen) an einem bestimmten Ort (Umgebung) auszugeben. Andere Entitäten (Module) können diese Umgebungen abonnieren, um alle ihnen übermittelten “Effekte” zu erhalten. Dies ermöglicht es den unterschiedlichen Modulen, sich gegenseitig zu abonnieren, dazu muss die ausgebende Entität nicht einmal von der Existenz ihrer Abonnenten wissen.
Diese Softwarearchitektur ist sehr leistungsfähig und durch Pub/Sub-Modell insgesamt widerstandsfähiger gegen partielle Systemausfälle, zudem ermöglicht das Pub/Sub-Modell eine hohe Erweiterbarkeit, sodass Softwaremodule (Plug-ins) problemlos hinzugefügt werden können, ohne den vorhandenen Code zu beschädigen oder zu verändern.
Modularer Aufbau:
Am Ende der Entwicklung wird Bee die Referenzimplementierung sein, mit ihr kann auch andere Node-Software ausgeführt werden, die den Protokollregeln entspricht.
Mit der modularen ereignisgesteuerten Softwarearchitektur (EEE) wird es möglich sein, durch die Erweiterungen von unterschiedlichen Softwaremodulen Bee so anzupassen, dass alle Arten von Nodes für unterschiedliche Anforderungen (Full, Light, Custom, etc.) ausgeführt werden können.
Beispielsweise könnte so das neue IOTA Streams nur bei Bedarf implementiert werden, zudem wird es sogar möglich sein, dass Module von Drittanbietern implementiert werden können.
Auch die Implementierung einer Bridge-Erweiterung für eine sprachübergreifende Unterstützung ist viel einfacher als bei dem alten IXI-Modulen (Bridge.ixi). Somit sollte auch bei Bee jeder Developer in der Lage sein, Softwaremodule in der gewünschten Programmiersprache zu schreiben, was sich positiv auf die Gesamtentwicklung auswirkt.
Bee wird praktisch eine “IOTA Node Fabrik”, daher ist es sinnvoll, Bee als Ausgangsplattform für angepasste Node-Software zu verwenden und anzupassen, anstatt von Grund auf neu zu programmieren.
Lightweight Software:
Bee läuft auch auf Ressourcen armen Kleinstgeräten und benötigt dabei noch weniger Systemressourcen als das alte Ict. Bee funktioniert ohne festgelegte Mindestanforderungen an Ram etc., es werden die Systemressourcen verwendet, welche zur Verfügung stehen. Daher wird es möglich sein, Bee auf einem eingeschränkten Gerät mit nur 128 MB RAM auszuführen, dann werden zwangsläufig nicht so viele Transaktionen gespeichert, als wenn Bee auf einem 64 GB RAM-Server ausgeführt wird.
Quellen
https://blog.iota.org/introducing-ict-0-6-and-bridge-ixi-9c5168a16b07