Ответ 1

В оставшейся части этого поста я собираюсь использовать Linux в качестве примера программного обеспечения с открытым исходным кодом. Где я упоминаю "Linux", это в основном краткий/простой способ обратиться к программному обеспечению с открытым исходным кодом в целом, но не к чему-то конкретному для Linux.

COM vs..NET

COM на самом деле не ограничивается C и C++, и .NET фактически не заменяет COM. Однако .NET в некоторых ситуациях предоставляет альтернативы COM. Одним из распространенных применений COM является предоставление элементов управления (элементов управления ActiveX). .NET предоставляет/поддерживает свой собственный протокол для элементов управления, который позволяет кому-то написать элемент управления на одном языке .NET и использовать этот элемент управления с любого другого языка .NET - более или менее то же самое, что COM предоставляет за пределами .NET Мир.

Аналогичным образом .NET предоставляет Windows Communication Foundation (WCF). WCF реализует SOAP (простой протокол доступа к объектам) --which, возможно, изначально все было просто, но в лучшем случае превратилось в нечто гораздо менее простое. В любом случае WCF предоставляет многие из тех же возможностей, что и COM. Хотя сам WCF специфичен для .NET, он реализует SOAP, и сервер SOAP, построенный с использованием WCF, может взаимодействовать с сервером, реализованным без WCF (и наоборот). Поскольку вы упоминаете накладные расходы, вероятно, стоит упомянуть, что WCF/SOAP имеют тенденцию добавлять больше накладных расходов, чем COM (я видел где-то от почти равного примерно удвоения накладных расходов, в зависимости от ситуации).

Различия в требованиях

Для Linux первые две точки имеют тенденцию иметь относительно низкую актуальность. Большая часть программного обеспечения имеет открытый исходный код, и многие пользователи в любом случае привыкли строить из исходного кода. Для таких пользователей двоичная совместимость/повторное использование не имеет большого значения или не имеет никакого значения (на самом деле, довольно многие пользователи могут отклонить все программное обеспечение, которое не распространяется в форме исходного кода). Хотя двоичные файлы обычно распространяются (например, с помощью apt-get, yum и т.д.), Они в основном просто кэшируют двоичный файл, созданный для конкретной системы. То есть в Windows у вас может быть один двоичный файл для использования на любом компьютере, от Windows XP до Windows 10, но если вы используете apt-get на, скажем, Ubuntu 18.02, вы устанавливаете двоичный файл, созданный специально для Ubuntu 18.02, а не тот, который пытается быть совместимым со всем обратно в Ubuntu 10 (или что-то еще).

Возможность загрузки и запуска (с ограниченными возможностями) при отсутствии компонента также чаще всего является проблемой с закрытым исходным кодом. Программное обеспечение с закрытым исходным кодом, как правило, имеет несколько версий с различными возможностями для поддержки разных цен. Вендору удобно иметь возможность создавать одну версию основного приложения и предоставлять различные уровни функциональности в зависимости от того, какие другие компоненты поставляются/опускаются.

Это в первую очередь для поддержки различных уровней цен, хотя. Когда программное обеспечение бесплатное, существует только одна цена и одна версия: потрясающая версия.

Доступ к функциональным возможностям библиотеки между языками снова имеет тенденцию основываться больше на исходном коде, а не на двоичном интерфейсе, например на SWIG, позволяющем использовать исходный код C или C++ из таких языков, как Python и Ruby. Опять же, COM в основном лечит проблему, которая возникает главным образом из-за отсутствия исходного кода; при использовании программного обеспечения с открытым исходным кодом проблема просто не возникает с самого начала.

Похоже, что RPC с низкими накладными расходами для кодирования в других процессах, в основном, связан с программным обеспечением с закрытым исходным кодом. Когда/если вы хотите, чтобы Microsoft Excel мог использовать некоторые внутренние "вещи", например, в Adobe Photoshop, вы используете COM, чтобы позволить им общаться. Это добавляет накладные расходы времени выполнения и дополнительную сложность, но когда один из фрагментов кода принадлежит Microsoft, а другой - Adobe, это в значительной степени то, с чем вы застряли.

Совместное использование уровня исходного кода

Однако в программном обеспечении с открытым исходным кодом, если проект A имеет некоторые функциональные возможности, полезные в проекте B, вы, скорее всего, увидите (не более) форк проекта A для превращения этих функций в библиотеку, которая затем связывается в остальная часть проекта A и в проект B, а также, вполне возможно, проекты C, D и E - и все это без наложения накладных расходов на COM, межпроцессный RPC и т.д.

Теперь, не поймите меня неправильно: я не пытаюсь выступать в качестве представителя программного обеспечения с открытым исходным кодом и не говорю, что закрытый исходный код ужасен, а открытый исходный код всегда значительно превосходит другие. Я хочу сказать, что COM определяется в основном на бинарном уровне, но для программного обеспечения с открытым исходным кодом люди, как правило, имеют дело с исходным кодом.

Конечно, SWIG - это только один пример из нескольких инструментов, которые поддерживают межязыковую разработку на уровне исходного кода. Хотя SWIG широко используется, COM отличается от него одним довольно важным способом: с помощью COM вы определяете интерфейс на одном нейтральном языке, а затем генерируете набор языковых привязок (прокси и заглушки), которые соответствуют этому интерфейсу. Это довольно сильно отличается от SWIG, где вы сравниваете напрямую из одного источника в один целевой язык (например, привязки для использования библиотеки C из Python).

Бинарное Общение

Все еще есть случаи, когда полезно иметь хотя бы некоторые возможности, аналогичные тем, которые предоставляет COM. Это привело к созданию систем с открытым исходным кодом, которые в большей степени напоминают COM. Например, ряд десктопных сред с открытым исходным кодом используют/реализуют D-bus. Если COM - это, в основном, RPC, D-bus - это согласованный способ отправки сообщений между компонентами.

Однако D-bus определяет вещи, которые он называет объектами. Его объекты могут иметь методы, которым вы можете отправлять сигналы. Хотя сама D-шина определяет это главным образом с точки зрения протокола обмена сообщениями, довольно просто написать прокси-объекты, которые делают вызов метода на удаленном объекте очень похожим на вызов метода на локальном объекте. Большая разница в том, что в COM есть "компилятор", который может принять спецификацию протокола и автоматически сгенерировать эти прокси для вас (и соответствующие заглушки на дальнем конце, чтобы получить сообщение, и вызвать соответствующую функцию на основе сообщения, которое он получено). Это не часть самой D-Bus, но люди написали инструменты, чтобы взять (например) спецификацию интерфейса и автоматически генерировать прокси/заглушки из этой спецификации.

Таким образом, хотя они не совсем идентичны, достаточно сходства, что D-шину можно (и часто используют) использовать во многих вещах того же типа, что и COM.

Системы, аналогичные DCOM

COM также позволяет создавать распределенные системы с использованием DCOM (Distributed COM). То есть система, в которой вы вызываете метод на одном компьютере, но (по крайней мере, потенциально) выполняете этот вызванный метод на другом компьютере. Это добавляет дополнительные издержки, но поскольку (как указано выше в отношении D-шины) RPC в основном является связью с прокси/заглушками, подключенными к концам, довольно легко сделать то же самое в распределенном режиме. Однако разница в накладных расходах, как правило, приводит к различиям в том, как системы должны быть спроектированы так, чтобы они работали хорошо, поэтому практическое преимущество использования точно такой же системы для распределенных систем, что и локальных систем, как правило, довольно минимально.

Таким образом, мир с открытым исходным кодом предоставляет инструменты для выполнения распределенных RPC, но обычно не усердно работает над тем, чтобы они выглядели так же, как нераспределенные системы. CORBA хорошо известна, но обычно рассматривается как большая и сложная, поэтому (по крайней мере, по моему опыту) текущее использование довольно минимально. Apache Thrift предоставляет некоторые из тех же общих возможностей, но в более простой и легкой форме. В частности, в тех случаях, когда CORBA пытается предоставить полный набор инструментов для распределенных вычислений (включая все от аутентификации до распределенного учета времени), Thrift гораздо ближе следует философии Unix, пытаясь удовлетворить ровно одну потребность: генерировать прокси и заглушки из определение интерфейса (написано на нейтральном языке). Если вы хотите делать подобные CORBA вещи с Thrift, вы, несомненно, можете, но в более типичном случае построения внутренней инфраструктуры, когда вызывающий и вызываемый абоненты доверяют друг другу, вы можете избежать больших накладных расходов и просто продолжать бизнес в рука. Аналогично, Google RPC предоставляет примерно те же самые возможности, что и Thrift.

OS X Specific

Cocoa предоставляет распределенные объекты, которые довольно похожи на COM. Это основано на Objective-C, хотя, и я считаю, что сейчас это устарело.

Apple также предлагает XPC. XPC больше относится к межпроцессному взаимодействию, чем к RPC, поэтому я бы посчитал его более сопоставимым с D-шиной, чем с COM. Но, как и в случае с D-шиной, она имеет много тех же базовых возможностей, что и COM, но в другой форме, в которой больше внимания уделяется обмену информацией, а не тому, чтобы все выглядело как вызовы локальных функций (и многие теперь все равно предпочитают обмен сообщениями RPC).).

Резюме

Программное обеспечение с открытым исходным кодом имеет достаточно различных факторов в своем дизайне, чтобы меньше требовалось что-то, обеспечивающее такое же сочетание возможностей, которое Microsoft COM предоставляет в Windows. COM в значительной степени является единственным инструментом, который пытается удовлетворить все потребности. В мире с открытым исходным кодом меньше возможностей для предоставления этого единого всеобъемлющего решения и больше склонности к набору инструментов, каждый из которых выполняет свою задачу хорошо, и которые можно объединить в решение для конкретной задачи.

Будучи более коммерчески ориентированной, Apple OS X, вероятно, имеет (по крайней мере, возможно) более близкие аналоги COM, чем большая часть более чистого мира с открытым исходным кодом.

Ответ 2

Быстрый ответ на последний вопрос: COM еще не устарел. Почти все в мире Microsoft основано на COM, включая движок .NET(CLR) и включает в себя новую Windows 8.x Windows Runtime.

Вот что говорит Microsoft о .NET на своих последних страницах С++ Добро пожаловать в С++ (Modern С++):

С++ переживает ренессанс, потому что власть снова короля. Языки, такие как Java и С#, хороши, когда производительность программиста но они показывают свои ограничения, когда мощность и производительность имеют первостепенное значение. Для высокой эффективности и мощности, особенно на устройствах которые имеют ограниченное аппаратное обеспечение, ничто не сравнится с современным С++.

PS: это немного шокирует для разработчика, который вложил более 10 лет в .NET: -)

Ответ 3

В мире Linux чаще всего разрабатываются компоненты, которые статически связаны или запускаются в отдельных процессах и обмениваются сообщениями (возможно, JSON или XML) взад и вперед.

Некоторые из них связаны с традицией. Разработчики UNIX делали такие вещи задолго до того, как существовали CORBA или COM. Это "путь UNIX".

Как говорит Джерри Коффин в своем ответе, когда у вас есть исходный код для всего, двоичные интерфейсы не так важны, а на самом деле просто усложняют работу.

COM был изобретен, когда персональные компьютеры были намного медленнее, чем сегодня. В те дни загрузка компонентов в пространство приложений и вызов собственного кода часто были необходимы для достижения разумной производительности. Теперь разбор текста и запуск интерпретируемых скриптов не стоит бояться.

CORBA никогда не попадала в мир с открытым исходным кодом, потому что первоначальные реализации были проприетарными и дорогостоящими, и к тому времени, когда были доступны высококачественные бесплатные реализации, спецификация была настолько сложной, что никто не хотел ее использовать, t требуется для этого.

Ответ 4

В значительной степени проблемы, решаемые COM, просто игнорируются в Linux.

Верно, что двоичная совместимость менее важна, когда у вас есть исходный код. Однако вам все равно придется беспокоиться о модуляции и управлении версиями. Если две разные программы зависят от разных версий одной и той же библиотеки, вам необходимо как-то поддержать это.

Тогда есть случай одной и той же программы, используя разные версии одной и той же библиотеки. Это часто полезно при работе с крупными устаревшими программами, где обновление может быть слишком дорогостоящим, но вы все равно хотите использовать новые функции. С COM старые части программы можно просто оставить в покое, так как новые версии библиотек легче сделать обратно совместимыми.

Кроме того, необходимость компиляции из источника вместо бинарной совместимости - огромная проблема. Особенно, если вы на самом деле разрабатываете программное обеспечение, поскольку двоичная несовместимость означает, что вам приходится перекомпилировать гораздо чаще. Если одна маленькая часть изменяется в большой программе на С++, вам может потребоваться перекомпиляция 30 минут. Если разные части совместимы, необходимо перекомпилировать только измененную часть.