COM в мире, отличном от Windows?
Надеюсь, этот вопрос не будет слишком расплывчатым. Читая спецификацию COM и книгу Essential COM от Don Box, много говорится о «проблемах, которые решает COM» — и все они звучат как важные, актуальные и ток.
Итак, как решаются проблемы, с которыми COM-адреса сталкиваются в других системах (Linux, Unix, OSX и Android)? Я думаю о таких вещах, как:
- двоичная совместимость между компиляторами и версиями компилятора
- повторное использование бинарных компонентов
- компилировать приложение так, чтобы оно имело зависимости во время выполнения, а не во время загрузки (чтобы оно работало даже при отсутствии зависимости)
- доступ к функциям библиотеки с других языков, кроме собственного
- вызовы удаленных процедур с умеренными накладными расходами на компоненты, загруженные в адресное пространство другого процесса
- и т. д. (я уверен, что список можно продолжить)
Я просто пытаюсь понять, почему, например, в Linux CORBA не похожа на COM в Windows (если это имеет смысл). Может быть, разработка программного обеспечения для Linux придерживается иной философии, нежели компонентная модель, предложенная COM?
И, наконец, COM ли это C / C ++? Несколько раз я сталкивался с комментариями людей, которые говорили, что COM «устарел» из-за .NET, но не объяснил, что они имели в виду.
Решение
На данный момент давайте рассмотрим Linux.
Для Linux первые две точки имеют тенденцию иметь относительно низкую актуальность. Большая часть программного обеспечения имеет открытый исходный код, и многие пользователи привыкли строить из исходного кода в любом случае. Для таких пользователей двоичная совместимость / повторное использование не имеет большого значения или не имеет никакого значения (на самом деле, довольно многие пользователи могут отклонить все программное обеспечение, которое не распространяется в форме исходного кода).
Возможность загрузки и запуска (с ограниченными возможностями) при отсутствии компонента также чаще всего является проблемой с закрытым исходным кодом. Программное обеспечение с закрытым исходным кодом, как правило, имеет несколько версий с различными возможностями для поддержки разных цен. Поставщику удобно иметь возможность создавать одну версию основного приложения и предоставлять различные уровни функциональности в зависимости от того, какие другие компоненты поставляются / опускаются.
Это в первую очередь для поддержки разных ценовых уровней. Когда программное обеспечение бесплатно, есть только одна цена и одна версия: потрясающее издание.
Доступ к функциональности библиотеки между языками снова имеет тенденцию основываться больше на исходном коде, а не на бинарном интерфейсе, например, при использовании 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).
В мире открытого исходного кода есть также инструменты для определения интерфейса на нейтральном языке определения интерфейса, а затем создания привязок для определенных языков из этого определения интерфейса. CORBA хорошо известна, но обычно рассматривается как большая и сложная, поэтому фактическое использование довольно минимально. Apache Thrift предоставляет некоторые из тех же общих типов возможностей, но более простым и легким способом. В частности, в тех случаях, когда CORBA пытается предоставить полный набор инструментов для распределенных вычислений (включая все от аутентификации до распределенного учета времени), Thrift гораздо ближе следует философии Unix, пытаясь удовлетворить ровно одну потребность: генерировать прокси и заглушки из определение интерфейса (написано на нейтральном языке). если ты хочу Вы, несомненно, можете делать такие вещи, похожие на CORBA, с Thrift, но в более типичном случае построения внутренней инфраструктуры, когда вызывающий и вызываемый абоненты доверяют друг другу, вы можете избежать больших накладных расходов и просто заняться делом.
Другие решения
Быстрый ответ на последний вопрос: COM далеко не устарел. Почти все в мире Microsoft основано на COM, включая движок .NET (CLR) и новые Windows 8.x Среда выполнения Windows.
Вот что Microsoft говорит о .NET в последних страницах C ++ Добро пожаловать обратно в C ++ (современный C ++):
С ++ переживает ренессанс, потому что сила снова король.
Такие языки, как Java и C # хороши, когда производительность программиста
важно, но они показывают свои ограничения, когда мощность и производительность
имеют первостепенное значение. Для высокой эффективности и мощности, особенно на устройствах
которые имеют ограниченное оборудование, ничто не сравнится с современным C ++.
PS: это немного шокирует разработчика, который вложил более 10 лет в .NET 🙂
В мире Linux чаще всего разрабатывают компоненты, которые статически связаны или работают в отдельных процессах и обмениваются данными по конвейеру (возможно, в формате JSON или XML) и обратно.
Отчасти это связано с традицией. Разработчики UNIX занимались такими вещами задолго до появления CORBA или COM. Это «путь UNIX».
Как говорит Джерри Коффин в своем ответе, когда у вас есть исходный код для всего, бинарные интерфейсы не так важны, и на самом деле просто все усложняют.
COM был изобретен еще тогда, когда персональные компьютеры работали намного медленнее, чем сегодня. В те дни загрузка компонентов в пространство процессов вашего приложения и вызов собственного кода часто были необходимы для достижения разумной производительности. Теперь разбирать текст и запускать интерпретируемые сценарии не стоит бояться.
CORBA никогда не завоевывала популярность в мире открытого исходного кода, потому что первоначальные реализации были проприетарными и дорогими, и к тому времени, когда стали доступны высококачественные бесплатные реализации, спецификация была настолько сложной, что никто не хотел ее использовать, если бы от нее не требовалось Сделай так.
В значительной степени проблемы, решаемые COM, просто игнорируются в Linux.
Это правда, что двоичная совместимость менее важна, когда у вас есть доступный исходный код. Тем не менее, вам все равно придется беспокоиться о модульности и версиях. Если две разные программы зависят от разных версий одной и той же библиотеки, вам нужно как-то это поддерживать.
Тогда есть случай тот же самый программа с использованием разных версий одной и той же библиотеки. Это часто полезно при работе с большими устаревшими программами, где обновление всего может быть чрезмерно дорогим, но вы все равно хотели бы использовать новые функции. С COM старые части программы могут быть оставлены в покое, поскольку новые версии библиотеки могут быть более легко сделаны обратно совместимыми.
Кроме того, необходимость компиляции из исходного кода вместо бинарной совместимости является большой проблемой. Особенно, если вы на самом деле разрабатываете программное обеспечение, так как двоичная несовместимость означает, что вам придется гораздо чаще перекомпилировать. Если одна маленькая деталь изменится в большой программе на C ++, возможно, вам придется подождать 30-минутную перекомпиляцию. Если различные части совместимы, то только часть, которая изменилась, должна быть перекомпилирована.