1. Zuhause
  2. Frage und Antwort
  3. Was kommt Windows COM/DCOM in der Linux-Welt am nächsten?

Was kommt Windows COM/DCOM in der Linux-Welt am nächsten?

2009-07-26 1 views

Antwort

8

Ja, es gibt viele Dinge, aber es gibt keine als "Standard" wie COM/DCOM. Zumindest in Windows wird COM/DCOM von "Windowsish" -Stücken verwendet, und andere RPC-Mechanismen werden von nicht "Windowsish" -Aufträgen verwendet.

Linux hat so etwas nicht, stattdessen verwenden Dinge, die RPC-Protokolle auf höherer Ebene benötigen, normalerweise, was auch immer ihre Sprache bietet, oder eine bestimmte Bibliothek, die am besten zu den Anforderungen einer App passt. Beispiele hierfür wären RMI in Java, Pythons "Pyro" -Modul usw., die (einige) funktionelle Parität mit DCOM bereitstellen.

Corba ist ein bisschen Schwergewicht, aber einige Leute benutzen es anscheinend.

Viele Anwendungen rollen ihre eigenen RPC-Bibliotheken. Tun Sie das nicht, es sei denn, Sie müssen es, es ist böse.

Quelle

2009-07-26 17:59:41 MarkR

+0

Ist Sun RPC-ONC dasselbe wie COM/DCOM? –

+0

[ONC RPC] (https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call) ist mehr auf Augenhöhe mit [DCE/RPC] (https://en.wikipedia.org/wiki/DCE/RPC) oder [MSRPC ] (https://en.wikipedia.org/wiki/Microsoft_RPC). Seine IDL ist viel einfacher und es hat weniger Funktionen. [Distributed COM] (https://en.wikipedia.org/wiki/Distributed_Component_Object_Model) basiert auf MSRPC für die Kommunikation, aber es behandelt viele komplexe Dinge über dieser Ebene, wie Proxy-Objekt-Caching, um 'AddRef' und' QueryInterface' zu ​​vermeiden Rundreisen, Ping für Garbage Collection, COM-spezifische Speicherverwaltung, etc. – acelent

+0

** Linux hat so etwas nicht **: Ich würde sagen * dbus * kommt ziemlich nah: Anwendungen können RPC-Methoden und Ereignisse offenlegen, können Sie Inspizieren Sie diese Methoden und rufen Sie sie dann remote ab. ** Viele Anwendungen rollen ihre eigenen RPC-Bibliotheken. Tun Sie das nicht, es sei denn, es ist böse. Ich sehe definitiv den Punkt. Auf der anderen Seite würde ich sagen, Dinge wie Emacs und Gimp haben ziemlich schöne RPC-Bibliotheken. Ich schätze, je komplizierter eine Anwendung ist, desto mehr verdient sie einen eigenen RPC-Mechanismus! –

11

Für Interprozesskommunikation ist D-Bus der Standardmechanismus auf höherer Ebene. Sowohl GTK als auch Qt haben Bindungen für D-Bus, die meisten Desktop-Umgebungen (oder zumindest GNOME und KDE) bieten verschiedene Dienste über D-Bus an, und viele Desktop-Anwendungen können über eine D-Bus-Schnittstelle gesteuert werden. Der Systembus ist auch nützlich zum Ermitteln verschiedener Informationen auf niedriger Ebene über das System unter Verwendung von Standard-Systemdiensten.

KDE4 (auf Qt4 gebaut) enthält auch eine Technologie namens KParts, die oft mit Windows COM verglichen werden.

Quelle

2009-07-26 04:52:10 Kitsune

+5

"Für Interprozesskommunikation ist D-Bus der Standardmechanismus." Es ist? Sockets, shared memory, Message Queues und Semaphore würden ich sagen, wenn ich gefragt würde, was die standardmäßigen Interprozess-Kommunikationsmechanismen einer POSIX-Umgebung wären. – smcameron

+3

D-Bus ist höher als die elementaren Mechanismen, die Sie auflisten, mehr vergleichbar mit COM/DCOM und weit verbreitet unter Linux (alle anderen werden von vielen anderen Versionen von Unix übernommen - D-Bus baut auf solchen niedrigeren Level-Mechanismen natürlich). –

+0

Sie können Pgin IM-Controller schreiben, die anstelle eines Pigin-Plugins über D-Bus arbeiten. Führen Sie dbus-monitor --session aus und Sie können Pigdin sehen, wie er mit D-Bus alles in Ihre Gespräche steckt. –

2

Es gibt Mozillas XPCOM-Technologie, Cross Platform Component Object Model. Ähnlich wie COM oder DCOM konzeptionell.

Here ist eine Liste der relativ wenigen Programme, die

Quelle

2009-07-26 04:55:41

3

Verwendung des D-Bus machen tun können Sie Corba Check-out, es auch unter Linux und Windows.

Quelle

2009-07-26 05:18:16

3

Das Mono-Projekt fällt mir ein. Hauptsächlich weil die CLR/.NET die neue COM ist - schließlich wurde COM zunächst als sprachunabhängige, binärkompatible Objekte verkauft.

Ich denke, DCOM (das heißt COM mit einem längeren Draht) .NET Remoting wäre? Oder vielleicht einige Web-Services mit Objektserialisierung. Ich glaube, Mono unterstützt beides.

Quelle

2009-07-26 05:59:56 ars

4
D-Bus
  • D-Bus verwendet einen logischen "Bus", über die verbundenen Anwendungen kommunizieren
  • Kommunikation über einen einfaches dauert Objektmodell, das Supp ortes sowohl RPC und Publish-Subscribe-Mechanismen
  • D-Bus enthält einen Standard-Introspektionsmechanismus für die Laufzeitabfrage von Objektschnittstellen, Anwendungen an den Bus angeschlossen können Abfrage für die Verfügbarkeit von Objekten, Remote-Methoden für sie aufrufen und anfordern Benachrichtigung für die Signale, die sie
  • vor aussenden: GNOME Bonobo, KDE DCOP, CORBA, Sun RPC ... heute scheinen die Menschen D-Bus
UNO
  • Schnittstelle basierend comp zu bevorzugen ontemodell, wie COM und CORBA
  • Alle UNO-Schnittstellen müssen von einer Schnittstelle abgeleitet sein, die acquire, release und eine queryInterface-Methode (vergleichbar mit COM)
  • Die Lebensdauer von UNO-Objekten wird durch globale Referenz gesteuert Zählen. Die Komponenten kommunizieren nur über ihre Schnittstellen. o Jede Komponente lebt in einer Uno-Laufzeitumgebung (Uno Runtime Environment, URE), es gibt keinen Leistungsaufwand für Komponenten, die innerhalb derselben URE instanziiert werden, z. B. in C++ ein Aufruf von Komponente A an B ist nur ein virtueller Anruf
  • UNO-Schnittstellen sind in IDL angegeben
  • Ausnahmen werden für die Fehlerbehandlung verwendet.
XPCOM
  • ähnlich wie Microsoft COM
  • Schnittstellen in XPCOM in einem Dialekt von IDL definiert genannt XPIDL
  • Nachteil ist, dass XPCOM eine Menge Code fügt für Objekte zwischen unterschiedlichen Nutzungs Rangier Kontexte, die zu Code Bloat in XPCOM-basierten Systemen führt

... eine weitere Alternative zu Cons ider könnte Java RMI sein als auch

Es lohnt sich auch Fragen im Zusammenhang zu sehen:
Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?
Analog of COM programming in Linux/UNIX

Quelle

2013-03-08 12:16:11 LihO

Verwandte Themen

 Verwandte Themen