Реализация СОМ
Занятие 2. Реализация СОМ
(Продолжительность занятия 15 минут)
Чтобы пользоваться всеми преимуществами технологии СОМ, важно понимать, как она реализована. Это занятие посвящено техническим аспектам реализации СОМ, включая контроль версий, регистрацию компонентов и связь между объектами.
Изучив материал этого занятия, Вы сможете:
- описать регистрацию компонентов в библиотеке COM;
- объяснить важность контроля версий для технологии компонентов;
- описать, как объекты COM взаимодействуют между собой.
Библиотека СОМ
Библиотека СОМ обеспечивает работу СОМ. Этот системный компонент инкапсулирует все действия; связанные с запуском компонентов и их связыванием (рис. 5.6). Обычно, создав компонент СОМ, приложение передает его идентификатор класса (CLSID) библиотеке СОМ. Библиотека использует CLSID для нахождения кода соответствующего сервера в регистрационной базе данных. Когда клиент запрашивает создание объекта этого класса, библиотека СОМ выполняет запрос для поиска и запуска соответствующего сервера.
Рис. 5.6 Библиотека СОМ
Взаимодействие процессов
Именно библиотека СОМ делает взаимодействие между процессами прозрачным. Теперь не приходится заботиться о местонахождении вызываемых компонентов. Объекты СОМ могут свободно взаимодействовать с другими компонентами, выполняющимися в рамках того же процесса, в другом процессе или на ином компьютере. Более того, код, необходимый для реализации или использования элемента, одинаков для любого из этих вариантов. Поэтому при появлении новой библиотеки СОМ с поддержкой межсетевого взаимодействия существующие компоненты могут работать в распределенной среде без изменений исходного кода, перекомпиляции и повторного распространения среди покупателей.
Контроль версий компонентов
По мере расширения функциональности компонентов все более необходим механизм контроля их версий. Такой механизм — фундамент СОМ. Время от времени требуется расширить функции серверного объекта, не затронув при этом клиенты. Именно в таких ситуациях незаменим встроенный в СОМ механизм контроля версий: серверные объекты продолжают поддерживать интерфейсы для старых клиентов, одновременно предоставляя новым клиентам интерфейсы самой свежей версии.
Поддержка эволюции компонентов
СОМ решает проблему контроля версий, обеспечивая возможность эволюции компонентов.
Существующие клиенты при изменении серверных объектов остаются совместимыми — средства СОМ обеспечивают поддержку как новых, так и старых интерфейсов. На стадии выполнения старые и новые клиенты безопасно сосуществуют с серверным компонентом СОМ. Ошибки возможны только во время связывания и вызова Query Interface, однако они легко поддаются обработке. СОМ гарантирует, что не случится ошибки, вызванной отсутствием ожидаемого метода или изменением параметров его вызова. Обратная совместимость Visual Basic реализует обратную совместимость путем сохранения информации об идентификаторах класса или интерфейса предыдущих версий компонента. Если Вы создаете новую версию компонента в Visual Basic, применяя режим Binary Compatibility, она сможет работать со старыми клиентами. При этом клиентские приложения, откомпилированные с ней, будут пользоваться новыми функциями, поскольку при их компиляции задействованы новые идентификаторы класса и интерфейса. И пока сохраняется двоичная совместимость, клиенты с отложенным связыванием смогут работать с Вашим компонентом. Добавление новых интерфейсов Обновление программного модуля — это обычно добавление каких-либо функций или модернизация существующих. Компонент СОМ приобретает новые возможности за счет поддержки последних версий интерфейсов. Поскольку существующие интерфейсы при этом не меняются, компоненты, использующие их, будут работать по-прежнему. Новые же компоненты смогут воспользоваться новыми интерфейсами. Поскольку при применении раннего связывания вызывается метод Query Interface интерфейса lUnknown, текущие возможности компонента СОМ можно выяснить при каждом его использовании. Этот механизм обеспечивает новым клиентам немедленный доступ к появившимся возможностям компонента. Механизм контроля версий Механизм контроля версий считают удачным, если он позволяет обновить один системный компонент без обновления других. Приложения могут создавать экземпляры Ваших классов, используя функцию CreateObject и программный идентификатор, как это показано ниже.
Пример Функция CreateObject находит идентификатор класса в реестре Windows и использует его для создания объекта, гарантируя тем самым создание самой последней версии. Dim X As Object
Set X = CreateObject("MyComponent. MyObject")
Взаимодействие между объектами
СОМ позволяет клиентам связываться с объектами независимо от того, где они выполняются: в том же самом процессе, на том же компьютере или на другом компьютере сети (рис. 5.7). Таким образом обеспечивается единая программная модель для объектов-клиентов и объектов-серверов.
Рис. 5.7 Взаимодействие между процессами
Стандартный маршалинг
Маршалинг (marshaling) — это упаковка всех параметров и возвращаемых значений и передача их через границы процессов. СОМ поддерживает так называемый стандартный маршалинг, который надежно работает для большинства объектов, значительно снижая требования к программной реализации и делая процесс мар-шалинга полностью прозрачным.
Произвольный маршалинг
Стандартный маршалинг есть не что иное, как частный случай произвольного мар-шалинга (custom marshaling). Вы можете реализовать свой вариант маршалинга, если нужно, чтобы объект выполнял один набор действий при сетевом доступе и другой — при локальном, эффективно маскируя это различие от клиента. Такая архитектура позволяет проектировать интерфейсы клиент-объект, не заботясь о производительности сети — эти вопросы можно решить позднее, без изменения разработанной инфраструктуры приложения.
Связь с клиентом
До некоторого момента все вызовы серверных функций клиентом являются внутри-процессными, однако рано или поздно возникает необходимость выхода за границы процесса. Поскольку виртуальные таблицы позволяют агенту (например, СОМ) перехватывать вызов функции (и возврат), агент может при необходимости переадресовать их механизму удаленного вызова процедур (Remote Procedure Call, RPC) так, что ни клиент, ни сервер этого не заметят. Единственное различие заключается в производительности — у внутрипроцессных вызовов она заметно выше.
Внутрипроцессные компоненты
Внутрипроцессные компоненты обычно реализуется в виде библиотек динамической загрузки (DLL). Они выполняются в том же адресном пространстве, что и клиент. Это самый эффективный метод связи между клиентом и компонентом — чтобы воспользоваться возможностями компонента, клиенту достаточно вызвать функцию.
Внепроцессные компоненты
Если объект находится вне процесса, вызов сначала переадресуется объекту-представителю (proxy), который предоставляется моделью СОМ или самим объектом (если его автор этого пожелает). Представитель упаковывает параметры вызова (включая любые указатели на интерфейс) и генерирует соответствующий RPC-вызов (или иной механизм в случае самостоятельно реализованных представителей), адресованный другому процессу или компьютеру, где реализован объект.
Связь с сервером
На сервере все вызовы функций интерфейса объекта выполняются через указатель на этот интерфейс. Указатель имеет смысл только в контексте конкретного процесса, поэтому роль вызывающего может играть только код того же процесса. Если объект внутрипроцессный, вызывающим будет сам клиент, в противном же случае — объект-«заглушка» (stub), предоставляемый СОМ или самим объектом. Заглушка принимает вызов RPC (или другого механизма в случае самостоятельно реализованного представителя) от представителя процесса-клиента, распаковывает параметры и вызывает соответствующий интерфейс серверного объекта. Независимо от конкретного механизма, клиент и сервер всегда считают, что взаимодействуют непосредственно с кодом внутри процесса.
Удаленный вызов процедур
Удаленный вызов процедур (Remote Procedure Call, RPC) основан на спецификации RPC распределенной среды программирования (Distributed Computing Environment, DCE-RPC) и по этой причине не зависит от платформы. СОМ-компоненты могут вызывать друг друга в гетерогенной среде, включающей платформы Windows 95, Windows NT, Unix и Macintosh и другие, поддерживающие DCE-RPC.
Резюме
СОМ позволяет клиентам связываться с объектами прозрачно, независимо от того, где они выполняются: в рамках того же процесса, в другом процессе или на ином компьютере.
Библиотека СОМ — основа прозрачного взаимодействия между процессами. Она инкапсулирует всю работу, связанную с запуском компонентов и установлением связи между ними, а также избавляет компоненты от контроля за их фактическим местонахождением.
Поддержка контроля версий и эволюции компонентов — фундамент СОМ. Благодаря ей, серверные объекты СОМ поддерживают интерфейсы для старых клиентов, одновременно предоставляя новым интерфейсы самой свежей версии.
