2010-08-24 8 views
6

Ich schreibe Software für ein neues Hardwaregerät, auf das jede neue Anwendung von Drittanbietern zugreifen soll, wenn sie möchte.Sollte ich CORBA, MessagePack RPC oder Thrift oder etwas ganz anderes verwenden?

Die Software ist ein systemeigener Prozess (C++), der von Spielen und Anwendungen von Drittanbietern, die das Hardwaregerät unterstützen möchten, abgefragt werden kann. Diese Drittanbieter-Apps sollten auch Ereignisse aus dem nativen Prozess auf Abonnementbasis empfangen können. Neben dem nativen Prozess werde ich den Entwicklern von Drittanbietern auch "Connector" -Bibliotheken zur Verfügung stellen, damit sie alle Plattformen/Sprachen (Java, C++, Python usw.) in ihre Apps einbetten können, damit sie sich einfach verbinden können zum Gerät mit kaum extra Code, der von ihnen geschrieben werden muss. Ich möchte alle Desktop/Laptop OS-Plattformen ansprechen und habe eine ziemlich gute Vorstellung davon, welche Funktionen ich bereitstellen möchte, aber idealerweise möchte ich nicht zu fest sitzen (dh ich möchte, dass es sowohl von Client als auch von Server elegant skalierbar ist Perspektiven).

Ich bin auf der Suche nach Zuverlässigkeit in der Zukunft, Leistung, Wartbarkeit in Zukunft und plattformübergreifender/Sprachflexibilität und einfacher Entwicklung in dieser Reihenfolge.

Was soll ich verwenden?

CORBA, MessagePack-RPC, Sparsamkeit oder etwas ganz anderes?

(Ich habe ICE weggelassen, weil es die Lizenzierung ist)

+4

CORBA ist * alt *. Es ist auch Schwergewicht und veraltet. Es gibt fast sicher eine bessere Lösung. – skaffman

+4

Skaffman, die Adjektive alt, Schwergewicht und veraltet mich überhaupt nicht. Die Speichermenge pro ORB beträgt nur ein paar Megabyte, was für eingebettete, aber für Desktop-Computer absolut in Ordnung ist, und die Leistung ist schnell. Ich bin besorgt über die Geschwindigkeit der Leistung, plattformübergreifende Flexibilität, einfache Entwicklung, Wartbarkeit und Zuverlässigkeit in der Zukunft. Solange es das Beste in diesen Abteilungen überhaupt ist, ist es egal, was andere darüber "denken", noch muss es nicht "die neueste Modeerscheinung" sein, es würde gewinnen. Ich frage mich nur, ob es das Beste für das ist, was ich mache. – Navigateur

+1

Wir können einfach keine offene Frage beantworten, ohne Ihre Anforderungen zu kennen, was Ihre Software ist/tut, die Zielgruppe, den Upgrade-Pfad, die Plattformen, auf denen sie läuft usw. –

Antwort

1

CORBA ist die einzige freie "RPC" Sache, die für mein System im Moment funktionieren würde, obwohl es sehr schlecht skaliert. Thrift ist noch nicht Windows-freundlich. Weder ist MessagePack-RPC noch in allen Sprachen und Betriebssystemen verfügbar, obwohl es noch in Entwicklung ist. Wenn CORBA elegant skalierbar wäre, wäre es wahrscheinlich überhaupt nicht obsolet geworden.

Protokoll Puffer und Messaging würde funktionieren, ich würde sowohl eine Client-und Service-Implementierung für jede Plattform/Sprache entwickeln müssen. Es wäre auch sehr skalierbar. Ich habe mich dafür entschieden.

+0

Warum denken Sie, dass CORBA "sehr schlecht skaliert"? Es gibt viele Systeme mit sehr hohem Volumen, die CORBA heute verwenden. –

+2

Wird eine neue Eigenschaft hinzugefügt, wird dies elegant in CORBA gehandhabt, wenn Leute alte Clients mit dem neuen Server verwenden, oder neue Clients mit einer alten Version des Servers (beides ist in meinem Fall möglich)? Mein Eindruck ist, dass CORBA bricht. Das ist schlecht - es hätte nicht so sein müssen. CORBA hätte die Welt erobert, wenn es nahtlos mit dem Anhängen und Entfernen von Eigenschaften und Funktionen umgehen würde. Die Leute wollen ihre Architekturen ständig aktualisieren: Jegliche erforderliche Versionierung, Einschränkungen und Handhabung sollten die Aufgabe des Entwicklers außerhalb von CORBA sein. RPC selbst sollte zu 100% skalierbar/skalierbar sein. – Navigateur

+1

Nicht viele RPC-Systeme verarbeiten nahtlos die Versionsverwaltung. Einer der Gründe ist, dass es bei jedem einzelnen CORBA-Aufruf zu einem übermäßigen Overhead kommen würde. –

2

Wenn alte und Schwergewicht setzen Sie nicht weg, veraltet sollte auf jeden Fall. Unabhängig davon kann ich Ihnen mitteilen, wofür wir kürzlich Google-Protokollpuffer bei der Arbeit verwendet haben, und sie sind ziemlich einfach zu verwenden.

Aus der Sicht des Entwicklers müssen Sie nur einen GPB-Build erstellen (was wirklich nicht so schwierig ist), und dann werden die Quelldateien für Sie generiert. Das Endergebnis ist eine plattformübergreifende binäre Message-Transport Message-Passing-Schnittstelle (denke XML und begrenzte RMI, nicht MPI-ähnliche Funktionalität).

Wir verwenden es unter Windows, um mit einem Arm-basierten Linux-System (TS-7200 von Embedded Arm) zu sprechen, das dieselbe Software ausführt. meines Wissens ist es mit vielen Sprachen kompatibel.

+0

Ist diese Nachricht? Sehr interessant! Angesichts der Flexibilität, wie würden Sie empfehlen, Protobuf in meiner Situation zu verwenden? Ich weiß, es ist "wie du willst", aber ich möchte, dass jeder neue Teil meines Systems mit jedem alten Teil abwärtskompatibel ist. (Das sieht voraus - ich habe noch nicht angefangen). Was ist der beste Weg, dies zu erreichen? – Navigateur

+0

Wenn Sie eine Google-Suche durchführen, finden Sie in ihrem Repo einige Dokumentationen, die einige Best Practices enthalten. Es hängt wirklich von Ihrer genauen Situation ab. Dies ist keine reine Nachrichtenübermittlung. Es ist eine plattformübergreifende/systemübergreifende binäre Serialisierungsmethode. Wenn Sie es nur für die Datenübertragung möchten, können Sie das tun. Wenn Sie ein RMI-Framework erstellen möchten, können Sie das tun. –

4

Thrift oder Message Pack ist die beste Option für die Zukunft. Beide sind schlank, leicht und fügen Ihrem Prozess nicht viel Latenz hinzu. Sie unterstützen die meisten gängigen Sprachen und befinden sich in der aktiven Entwicklung. In der jetzigen Phase würde ich die Sparsamkeit persönlich bevorzugen, aber Message Pack scheint eine Menge Funktionen zu versprechen.

Thought Sparsamkeit ist vielleicht nicht so Windows-freundlich, wie wir wollen, aber Leute benutzen es unter Windows. Dies ist ein Leitfaden für Sparsamkeit auf Windows. http://wiki.apache.org/thrift/ThriftInstallationWin32 Nur Installieren und Abrufen des Thrift-Compilers kann unter Windows mühsam sein. Die Verwendung der generierten Dateien hängt von der Sprache ab, die Sie auswählen, und viele Sprachen bieten eine gute Unterstützung für die Ausführung der Dateien durch Importieren von Bibliotheken.(Java ist es sehr einfach, MAVEN Artefakt)

Es gibt eine Diskussion über das RPC-Frameworks bei RPC frameworks available?

CORBA nach mir alt umständlich und sehr Schwergewicht.

0

Ich verwende derzeit Apache Thrift für ein Krankenhaus-Manager-Projekt. Es ist besser als CORBA in vielen Bereichen, nicht zu erwähnen, es ist leicht und viel einfacher zu implementieren und zu verstehen. Die Lernkurve für Thrift ist definitiv subtil im Vergleich zu CORBA, aber die Dokumentation für Thrift ist das Schlimmste.

Ich verwende einen Ruby Thrift-Server, mit dem sich Obj-C- und Java-Clients verbinden. Der Thrift-Parser oder "Compiler" macht einen ziemlich guten Job und erzeugt Quelldateien für die gewünschten Sprachen, obwohl es viel zu ausführlich ist. Ich würde definitiv in die Implementierung von Thrift oder Google ProtoBuffs schauen, wenn ich ein neues Projekt starten würde, da CORBA wirklich veraltet ist und in Zukunft keine neuen Technologien implementieren wird, ganz zu schweigen davon, dass es viele Schwachstellen und Exploits gibt, die auf CORBA abzielen gepatcht werden, da es nicht mehr in der Entwicklung ist und einige ernsthafte Sicherheitslücken in deinem neuen Projekt haben.

Thrift unterstützt viele Programmiersprachen: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml und Delphi zum Zeitpunkt der Erstellung. Die Unterstützung mehrerer Sprachen ist der Schlüssel, denke ich, für den Zweck Ihres Projekts.

+1

Ich ging am Ende mit ZeroMQ. Vielleicht möchten Sie es überprüfen. Es ist wirklich cool, weil Sie es so erweiterbar machen können, wie Sie es möchten (hinsichtlich Hinzufügen/Entfernen von Eigenschaften usw.). – Navigateur

Verwandte Themen