devel.one ist das Peer-to-Peer Netzwerk für dein Next-Generation-Projekt:
Keinen Server, keinen Message-Broker, keine Middleware. Lass' alles hinter deinen Firewalls. Keine sternförmige Verkabelung, sondern ein organisches, redundantes Mesh-Network.
Verteilte Systeme können so einfach sein.
devel.one ist ein Peer-to-Peer Netzwerk zur Entwicklung von verteilten Anwendungen in JAVA™. Die Kommunikationsmöglichkeiten können ohne Probleme in bestehende JAVA™-Anwendungen integriert werden.
Schau dich mal um. Und probiere etwas wirklich Neues.
Die Stärken von P2P kommen insbesondere bei Real-Life-Netzwerken zum Tragen. Das können Netze von Kunden, Netze für die Wartung von Maschinen oder spontane Netze sein. Derartige Netze lassen sich selbst mit Middleware nur schlecht abbilden.
Für devel.one spielt der Aufbau des Netzes sowie die Verteilung der Services im Netz keine Rolle. Services können in der Cloud wie auch in Filialen hinter Firewalls untergebracht werden. Clients können sich untereinander vernetzen. Die Anbindung von Workgroups kann spontan erfolgen. Alles ist erreichbar, solange es einen Weg von NODE zu NODE zum Ziel gibt.
Was wäre, wenn jedes Objekt in einem Netzwerk direkt mit Messages ansprechbar wäre?
devel.one ist eine Bibliothek für die asynchrone Software-Entwicklung, bei der sich der Programmierer weder mit Threads noch mit TCP/IP auseinander setzen muss.
Sie verwendet ein HighSpeed RealTime Messaging zwischen Objekten (nicht Queues). Objekte können in anderen Threads, in anderen Programmen oder auf anderen Rechnern liegen.
Objekte werden direkt über ihre D1-Adresse adressiert. Und die Nachricht kommt mit einer Antwort zurück - automatisch, und mit Fehlercode. Keine Überflutung mit Nachrichten, die an Interessentenlisten gehen, sondern blitzschnelle 1:1 Requests.
Full-Featured. Natürlich werden die alten Pattern unterstützt. Services, Observer, Listener, Benachrichtigung... niemand bleibt uninformiert. Alles ist trackbar.
Die Arbeit mit devel.one ist kinderleicht. Einfach eine Klasse von CTarget ableiten, ein oder mehrere Messagehandler hinzufügen, und dann das Target im System registrieren. Dabei bekommt das Target eine Adresse zugewiesen. Das war es schon.
Messages haben eine Absender- und eine Empfänger-Adresse, wie ein Brief. Also: Nachricht verfassen, Adresse auf den Umschlag, und verschicken. Absender wird automatisch eingetragen. Das System sorgt für die Zustellung, auch wenn der Empfänger sich auf einem anderen NODE befindet. Und wenn man noch das Häkchen setzt, dass man eine Antwort haben möchte, dann bekommt man sie auch, automatisch. Im Fehlerfall auch ohne Häkchen. Damit man nicht im Dunkeln tappt.
Konsequentes Messaging führt zu extrem skalierbaren Systemen. Denn Message-Empfänger können beliebig auf NODES quer über das Mesh-Netzwerk verteilt werden, und innerhalb der NODES auf Namespaces (Threads) und Cores. Die Verteilung kann auch jederzeit geändert werden, ohne dass etwas neu programmiert werden müsste. Da die Laufzeit der Nachrichten auch über Kontinente hinweg sehr gering ist, (binäre Nachrichten, kein XML-Parsing, stehende TCP-Verbindungen), ist keine Verzögerung in den Applikationen zu spüren.
devel.one ist optimal auf die Verwendung auf Cloud-Rechnern vorbereitet. NODES laufen auf Linux-Servern genauso gut wie auf Windows™-Rechnern. Der Speicher- und CPU-Bedarf eines NODE hängt natürlich vom Workload ab. Für den NODE selber reicht z.B. die kleinste virtuelle Maschine, die Google auf der Cloud Platform für ein paar Cent am Tag anbietet. Cloud-Rechner bieten sich auch an für die Einbindung von Clients und Filial-Netzwerken ins Peer-to-Peer-Netzwerk.
devel.one-NODES auf verschiedenen Rechnen verbinden sich automatisch, wenn man ihnen über die Konfiguration mitteilt, mit welchen NODES sie sich verbinden sollen (IP + Port).
Dabei ergibt sich ein feinmaschiges Netz aus miteinander redundant verbundenen NODES: Ein Mesh-Netzwerk, verbunden mit offenen TCP-Verbindungen. NODES tauschen sich automatisch über ihre Eigenschaften und ihre Verbindungen aus. Dazu nutzen sie ihre Peer-to-Peer-Protokolle.
Nachrichten wandern auf den Verbindungen zwischen den NODES entlang (es werden keine neuen Connects on Demand geöffnet.) Die einzelnen NODES können für jede Nachricht die schnellste Route bestimmen. Dazu werden die einzelnen Verbindungen zwischen den NODES überwacht. Bricht eine Teilstrecke zusammen, routen die NODES die Nachricht auf die schnellste verbleibende Verbindung um (Djikstra & Co).
Die NODES versuchen automatisch, unterbrochene Verbindungen wieder herzustellen. Das Netz repariert sich somit selbst - soweit es das kann ;-)
Jede Nachricht kann auf Wunsch mit einer Antwort quittiert werden. Das erfolgt automatisch. Im Fehlerfall (z.B. Empfänger nicht gefunden, Exception bei der Verarbeitung durch den Empfänger usw.) wird die Antwort auch ohne Wunsch zurückgesandt.
Die Antworten enthalten Fehler-Codes und -Texte. Selbst wenn eine Antwort nicht bearbeitet wurde, sieht der Absender dieses an dem Fehler-Code in der Antwort.
Zwischen verschiedenen NODES werden die Nachrichten komprimiert und verschlüsselt. Dazu wird ein RSA-Verfahren mit Schlüsselaustausch, Session-Keys und symmetrischer Verschlüsselung genutzt. Die Verschlüsselung erfolgt von Punkt zu Punkt, also jeweils zwischen Sender und Empfänger, damit andere Rechner im Mesh-Netzwerk nicht mitlesen können.
Die einzelnen NODES können per Konfiguration mit RSA Schlüssel gesichert werden, so dass nur erlaubte NODES eine Verbindung aufbauen können.
Die Rechtevergabe erfolgt per TCP-Port. Ein Gate-Service überwacht den Nachrichten-Eingang. Nur Nachrichten, welche explizit erlaubt sind, könnnen das Gate passieren. In Kombination mit RSA-Schlüssel beim Port ermöglicht dieses ein fein abgestuftes Rechtesystem.
Nicht erlaubte Nachrichten werden mit Fehlercode abgewiesen und protokolliert.
Damit nicht alle Nachrichten 1:1 hart verdrahtet werden müssen, gibt es das System der Services. Targets publizieren Services unter einer eindeutigen ID. Benutzer-Targets, welche den Service nutzen wollen, richten einfach die Nachricht an diese Service-ID. Wer dann tatsächlich für die Erledigung des Services angesprochen wird, ist dann nebensächlich.
Service-Beschreibungen in XML dienen auch als API für Kunden oder Zulieferer. Alle Nachrichten-Klassen, welche zu der API gehören, können dann mit einem devel.one-Tool (RecordGenerator) automatisch als Code generiert werden, in der Sprache, die der Kunde programmiert (zur Zeit nur für JAVA™...). Das ist nur eine Erleichterung, denn Nachrichten an eine API kann man auch einfach zu Fuß programmieren.
Services können überwacht werden (Bereitstellung, Abbau und Nutzung). Sie dienen auch zur Verbreitung von Notifikationen. Beispiel: Observer an Service "SonneGehtAuf" kleben, und warten, bis der Service getriggert wird...
NetzwerkServices dienen dem Auffinden von Services im Netzwerk. Da es in einem Peer-to-Peer-Netzwerk keine Server gibt, nutzen sie P2P-Protokolle zur Bekanntmachung. Ein Vorteil davon ist, dass Server ausfallen können. Redundante P2P-Registries eher nicht.
RealTime heißt in diesem Fall: Hin und zurück, so schnell es geht. Das heißt im selben Thread 2 Millionen Nachrichten hin und zurück. In nur einer Sekunde. Ohne Nutzdaten sogar 10 Millionen. Zwischen den Threads sind es noch 100.000 Nachrichten pro Sekunde. Und zwischen verschiedenen NODES noch weniger, je nach Latenz.
Die Zahlen kann man nicht vergleichen mit Zahlen von anderen Systemen (z.B. Message-Brokern). Denn dort werden Nachrichten nur in eine Richtung gepumpt. Wir messen auch die Zeit, bis die Nachricht wieder zurück gekommen ist, und dann erst schicken wir die nächste Nachricht los.
Wir verschwenden keine Bandbreite. Die Nachrichten sind binär, also keine serialisierten Objekte, und kein XML. Zudem können auf langsamen Verbindungen die Nachrichten komprimiert werden, wenn die dadurch gewonnene Einsparung größer ist als die Zeit für das Packen und Entpacken. Und da offene TCP-Verbindungen genutzt werden, fällt auch die Zeit für den Verbindungsaufbau weg.
Zwischen den devel.one-NODES werden Nachrichten priorisiert. Eine wichtige Nachricht (z.B. eine Antwort) wird schneller versandt als eine nicht so wichtige (z.B. eine LOG-Nachricht, ein Download).
Das Resultat ist eine verzögerungsfreie Ausführung der Programme, auch über Kontinente hinweg. Kein Vergleich mit dem Web.
