Что-нибудь более высокого уровня и более всеобъемлющее, чем каналы/сокеты?
Что ближе всего к Windows COM/DCOM в мире Linux?
comment
Спасибо всем - это было в значительной степени мое понимание того, где обстоят дела. Я принял ответ @MarkR, поскольку он, казалось, хорошо подвел итог.
- person fakeleft schedule 27.07.2009
Ответы (7)
Да, есть много вещей, но нет такой "Стандартной", как COM/DCOM. По крайней мере, в Windows COM/DCOM используются "Windowsish" вещами, а другие механизмы RPC используются "не-Windowsish" вещами.
В Linux нет ничего подобного, вместо этого вещи, которым требуются протоколы RPC более высокого уровня, обычно используют то, что предоставляет их язык, или определенную библиотеку, которая лучше всего соответствует потребностям приложения. Примерами этого могут быть RMI в Java, «пиро»-модуль Python и т. Д., Который обеспечит (некоторое) функциональное равенство с DCOM.
Corba немного тяжеловесен, но некоторые люди, по-видимому, его используют.
Многие приложения используют собственные библиотеки RPC. Не делайте этого без необходимости, это противно.
person
MarkR
schedule
26.07.2009
Делает ли Sun RPC -ONC то же самое, что и COM/DCOM?
- person dexterous; 02.04.2014
ONC RPC больше соответствует DCE/RPC или MSRPC . Его IDL намного проще и имеет меньше возможностей. Distributed COM основан на MSRPC для связи, но он обрабатывает многие сложные вещи выше этого уровня, такие как в качестве кэширования прокси-объектов, чтобы избежать
AddRef и QueryInterface круговых поездок, проверки связи для сборки мусора, управления памятью, специфичного для COM, и т. д.
- person acelent; 22.07.2016
В Linux нет ничего подобного: я бы сказал, что dbus подходит очень близко: приложения могут предоставлять методы и события rpc, вы можете анализировать эти методы, а затем вызывать их удаленно. Многие приложения используют собственные библиотеки RPC. Не делайте этого без необходимости, это противно Я определенно вижу в этом смысл. С другой стороны, я бы сказал, что такие вещи, как emacs и gimp, имеют довольно хорошие библиотеки RPC. Думаю, чем сложнее приложение, тем больше оно заслуживает собственного механизма rpc!
- person Att Righ; 03.09.2017
Для межпроцессного взаимодействия D-Bus является стандартным механизмом более высокого уровня. И GTK, и Qt имеют привязки к D-Bus, большинство сред рабочего стола (или, по крайней мере, GNOME и KDE) предоставляют различные службы через D-Bus, а многими настольными приложениями можно управлять через интерфейс D-Bus. Системная шина также полезна для получения различной низкоуровневой информации о системе с помощью стандартных системных служб.
KDE4 (построенный на основе Qt4) также включает в себя технологию под названием KParts, которую часто сравнивают с COM в Window.
person
Kitsune
schedule
26.07.2009
Для межпроцессного взаимодействия стандартным механизмом является D-Bus. Это? Сокеты, разделяемая память, очереди сообщений и семафоры — это то, что я бы сказал, если бы меня спросили, каковы стандартные механизмы межпроцессного взаимодействия в любой среде POSIX.
- person smcameron; 26.07.2009
D-Bus — это более высокий уровень, чем перечисленные вами элементарные механизмы, более сравнимый с COM/DCOM и широко распространенный в Linux (все остальные унаследованы от многих других версий Unix — D-Bus построен поверх таких низкоуровневых механизмов). механизмы конечно).
- person Alex Martelli; 26.07.2009
Вы можете написать контроллеры Pigin IM, которые работают через D-Bus, вместо плагина pigin. Запустите dbus-monitor --session и вы увидите, что pigdin передает все ваши разговоры на D-Bus.
- person Sean A.O. Harney; 26.07.2009
Я немного скорректировал это предложение, чтобы уточнить, что я имел в виду инфраструктуру более высокого уровня (поскольку именно об этом был вопрос). Кроме того, D-Bus становится все более популярным среди инструментов более низкого уровня, таких как PolicyKit и HAL.
- person Kitsune; 26.07.2009
Кроме того, почти каждое приложение KDE имеет интерфейс D-Bus (некоторые интерфейсы довольно обширны). Список проектов, использующих Freedesktop.org, невероятно неполный.
- person Kitsune; 26.07.2009
Нет, это не так. Становление все более популярным не является стандартным.
- person Ben; 30.01.2012
Становление все более популярным было в отношении инструментов более низкого уровня. Движение по замене приложений SUID/GUID в Linux обычно использует системную шину D-Bus для выполнения этих замен. Настольный Linux, с другой стороны, уже получил широкое распространение D-Bus еще в 2009 году. Он не заменил розетки/трубы, но и не должен. Различные специализированные платформы часто имеют свои собственные механизмы, но они, как правило, зависят от платформы, и их еще сложнее назвать стандартным механизмом IPC Linux более высокого уровня. Не думайте, что все стандарты действуют де-юре.
- person Kitsune; 31.01.2012
DBus больше похож на DDE, чем на COM. Это нормально для того, что он делает.
- person Ben; 02.03.2012
D-Bus
- D-Bus использует логическую шину, по которой подключенные приложения могут обмениваться данными.
- связь осуществляется через простую объектную модель, которая поддерживает механизмы RPC и публикации-подписки.
- D-Bus включает в себя стандартный механизм самоанализа для запроса интерфейсов объектов во время выполнения, приложения, подключенные к шине, могут запрашивать доступность объектов, вызывать для них удаленные методы и запрашивать уведомление о сигналах, которые они испускают.
- до: GNOME Bonobo, KDE DCOP, CORBA, Sun RPC.. , в настоящее время люди, кажется, предпочитают D-Bus
- компонентная модель на основе интерфейса, как COM и CORBA
- все UNO-интерфейсы должны быть производными от интерфейса, который предлагает получение, освобождение и метод queryInterface (сравнимый с COM)
- время жизни UNO-объектов контролируется глобальным подсчетом ссылок.
- компоненты обмениваются данными только через свои интерфейсы o каждый компонент находится в Uno Runtime Environment (URE), для компонентов, созданных в одной и той же URE, нет дополнительных затрат на производительность, например, в C++ вызов компонента A к компоненту B является просто виртуальный звонок
- UNO-интерфейсы указаны в IDL
- исключения используются для обработки ошибок.
- похоже на Microsoft COM
- Интерфейсы в XPCOM определяются на диалекте IDL, который называется XPIDL.
- недостаток заключается в том, что XPCOM добавляет много кода для сортировки объектов между разными контекстами использования, что приводит к раздуванию кода в системах на основе XPCOM.
...другой альтернативой для рассмотрения может быть Java RMI
Также стоит ознакомиться с сопутствующими вопросами:
Есть ли эквивалент COM в системах *nix? Если нет, то каким был подход *nix к повторному использованию?
Аналог программирования COM в Linux/UNIX
person
LihO
schedule
08.03.2013
Сразу приходит на ум проект Mono. Главным образом потому, что CLR/.NET — это новый COM — в конце концов, COM изначально продавался как независимые от языка, совместимые с двоичными файлами объекты.
Я предполагаю, что DCOM (то есть COM с более длинным проводом) будет удаленным взаимодействием .NET? Или, возможно, некоторые веб-сервисы с сериализацией объектов. Я считаю, что Mono поддерживает оба.
person
ars
schedule
26.07.2009
Вы можете проверить Corba, он также работает в Linux и Windows.
person
On Freund
schedule
26.07.2009
Существует технология Mozilla XPCOM, кросс-платформенная объектная модель компонентов. Концептуально похоже на COM или DCOM.
Вот приведен список относительно небольшого числа программ, использующих D-bus.
person
Sean A.O. Harney
schedule
26.07.2009
DCOM доступен в Linux. Это не «способ ведения дел в Linux», но, эй, если вы хотите «как DCOM, но Linux», тогда просто используйте DCOM в Linux и сделайте...
person
Ben
schedule
29.01.2012
