Was genau ist devel.one?

Was unterscheidet devel.one von herkömmlicher Message Oriented Middleware (MOM)?

Implementiert devel.one nun ein Message-Passing? Oder ist es eher ein Message-Queueing? Kommt da vielleicht doch ein Publish & Subscribe zum Zuge? Ist es eine Implementierung des JAVA Message Service?

Nein. devel.one ist tatsächlich etwas Neues, und lässt sich nicht einfach durch einen einzigen Begriff beschreiben. Betrachten wir einmal die Merkmale:

• devel.one benutzt eine Punkt-zu-Punkt-Kommunikation zwischen devel.one-Objekten (Targets). Dabei werden allerdings vom Sender und Empfänger keine Queues eingerichtet, sondern die Targets werden in einem Namespace registriert. Aus der ID des NODES, in dem sich der Namespace befindet, aus der ID des Namespaces und der ID des Targets ergibt sich damit eine eindeutige Adresse. Das Peer-to-Peer Netzwerk an NODES ist in der Lage, eine Message mit einer devel.one-Empfänger-Adresse direkt zuzustellen, auch wenn viele andere NODES zwischen Absender und Empfänger liegen.
• Messages werden vom System automatisch zurückgeschickt, denn gerichtete Messages tragen auch eine Absender-Adresse. Der Sender erhält sehr kurz nach dem Abschicken der Nachricht schon ein Feedback. devel.one implementiert also ein schnelles Hin- und Zurück, was geeignet ist für eine "RealTime"-Kommunikation. Die Nachricht soll nur sehr kurzlebig sein; dafür kann sie aber in hoher Frequenz genutzt werden.
• devel.one speichert keine Nachrichten. Wenn ein Target nicht existiert, geht die Nachricht mit einem Fehlercode an den Sender zurück. Dadurch kann der Absender geeignet reagieren. Im Falle eines Ausfalls eines NODES kann der Empfänger z.B. auf einen redundanten Empfänger-NODE geändert werden. Um Programmabbrüche durch die Unterbrechung einer Leitung und damit Fehler bei der Zustellung zu minimieren, gibt es das Konzept des vermaschten Netzes, bei der viele Leitungen zum Ziel führen. devel.one-NODES werden Messages immer auf schnellstem und kürzestem Weg zum Ziel routen, auch wenn viele Routen denkbar wären.
• Das devel.one-Messaging ist immer asynchron, d.h. während der Zeit zwischen dem Absenden einer Nachricht und dem Empfang der Antwort kann der Sender weitere Nachrichten empfangen und bearbeiten. Es ist kein RPC-Mechanismus vorhanden.
• Ein Publish- und Subscribe-Mechanismus wird über die Services geboten. Diese sind sehr leichtgewichtig und vielseitig einsetzbar. Im Prinzip werden Observer an eine Service-ID gebunden. Wird nun eine Nachricht an den Service (und nicht direkt an ein Target) geschickt, wird eine Kopie der Nachricht an alle Observer geschickt. Das kann man als Notifikation nutzen (ein Trigger, viele Empfänger), als Service (ein Observer = Implementierer des Services), oder als Hook (Observer an Service kleben, mithören). Ebenso läßt sich so ein Load-Balancing realisieren.
• devel.one ist keine Middleware, sondern ein Peer-to-Peer Netzwerk von NODES und Links. NODES können pur genutzt werden (als Vermittlungsstelle). Sie können mit Microservices angereichert werden (als APPs oder Plug-ins) und dabei "Server"-Funktionalität übernehmen (obwohl kein Client direkt mit ihnen verbunden ist). NODES können auch User-Interfaces starten, wobei diese auch auf verschiedene Plug-ins aufgeteilt werden können. Man kann sie zur Ansteuerung von Geräte, Maschinen, und Sensoren verwenden, mit den entsprechenden Plug-ins. Oder eine Kombination aller Möglichkeiten, denn die starre Aufteilung zwischen Server und Client entfällt. Und schließlich können NODES in bestehende Software eingebettet werden, als eine kleine Library (z.Zt. ca. 750 KByte). Damit wird jedes JAVA™-Programm zum NODE.
• Der Programmierer entwickelt lediglich sein Business-Modell in Form von Plug-ins oder APPs.
• Das Protokoll ist unabhängig von Plattform und Programmiersprache. Den Anfang macht JAVA™.