Поделиться через

Технический обзор COM

В этом разделе представлен обзор объектной модели компонента Майкрософт (COM):

Общие сведения о COM

Объектная модель компонента Майкрософт (COM) определяет стандарт двоичного взаимодействия для создания многократно используемых библиотек программного обеспечения, взаимодействующих во время выполнения. Библиотеки COM можно использовать без необходимости их компиляции в приложение. COM является основой для ряда продуктов и технологий Майкрософт, таких как проигрыватель Windows Media и Windows Server.

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

Спецификация COM предоставляет все основные понятия, позволяющие повторно использовать кроссплатформенное программное обеспечение:

  • Двоичный стандарт для вызовов функций между компонентами.
  • Обеспечение строго типизированного группирования функций в интерфейсы.
  • Базовый интерфейс, обеспечивающий полиморфизм, обнаружение признаков и отслеживание времени существования объектов.
  • Механизм, который однозначно идентифицирует компоненты и их интерфейсы.
  • Загрузчик компонентов, который создает экземпляры компонентов из развертывания.

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

  • система узла, которая предоставляет среду выполнения, соответствующую спецификации COM.
  • интерфейсы , которые определяют контракты функций, и компоненты , которые реализуют интерфейсы.
  • серверы, предоставляющие компоненты системе, и клиенты , которые используют функции, предоставляемые компонентами.
  • реестр, который отслеживает, где компоненты развертываются на локальных и удаленных хостах.
  • Service Control Manager, который находит компоненты на локальных и удаленных узлах и подключает серверы к клиентам.
  • Протокол структурированного хранилища, который определяет, как перемещаться по содержимому файлов в файловой системе узла.

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

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

Объекты и интерфейсы

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

Интерфейсы строго типизированы. Каждый интерфейс имеет собственный уникальный идентификатор интерфейса с именем IID, который устраняет столкновения, которые могут возникать с именами, доступными для чтения человеком. IID — это глобальный уникальный идентификатор (GUID), который совпадает с универсальным уникальным идентификатором (UUID), определенным в среде распределенных вычислений (DCE) Open Software Foundation (OSF). При создании нового интерфейса необходимо создать новый идентификатор для этого интерфейса. Когда вызывающий использует интерфейс, он должен использовать уникальный идентификатор. Эта явная идентификация повышает надежность, устраняя конфликты именования, что приведет к сбою во время выполнения.

При определении нового интерфейса можно создать определение интерфейса с помощью языка определения интерфейса (IDL). Из этого определения интерфейса компилятор Microsoft IDL создает файлы заголовков для использования приложениями с помощью интерфейса и исходного кода для обработки удаленных вызовов процедур. IDL, предоставляемый корпорацией Майкрософт, основан на простых расширениях DCE IDL, который является отраслевым стандартом для распределенных вычислений на основе вызова удаленных процедур (RPC). IDL — это инструмент для удобства конструктора интерфейсов и не является центральным для взаимодействия COM. При использовании IDL вам не нужно создавать файлы заголовков вручную для каждой среды программирования. Дополнительные сведения см. в Определении COM-интерфейсов.

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

Реализация интерфейса

Невозможно создать экземпляр COM-интерфейса самостоятельно. Вместо этого создается экземпляр класса, реализующего интерфейс. В C++интерфейс COM моделировается как абстрактный базовый класс, что означает, что интерфейс является классом C++, который содержит только чистые функции виртуальных членов. Библиотека C++ реализует COM-объекты, принимая сигнатуры функций из одного или нескольких интерфейсов, переопределяя каждую функцию и предоставляя реализацию для каждой функции.

Вы можете использовать любой язык программирования, поддерживающий концепцию указателей функций для реализации COM-интерфейса. Например, в C интерфейс представляет собой структуру, содержащую указатель на таблицу указателей функций, по одному для каждого метода в интерфейсе.

При реализации интерфейса класс должен предоставить реализацию для каждой функции в интерфейсе. Если класс не должен выполнять работы в функции интерфейса, реализация может состоять из одного оператора возврата.

Класс COM определяется с помощью уникального 128-разрядного идентификатора класса (CLSID), который связывает класс с определенным развертыванием в файловой системе, которая для Windows является библиотекой DLL или EXE. CLSID — это GUID, что означает, что ни один другой класс не имеет того же CLSID. Использование уникальных идентификаторов классов предотвращает столкновения имен между классами. Например, два разных поставщика могут писать класс CStack, но оба класса имеют уникальный CLSID, поэтому любая возможность столкновения избегается.

Вы получите новый CLSID с помощью функции CoCreateGuid или с помощью средства разработки COM, например Visual Studio, который вызывает эту функцию внутренне.

Интерфейс IUnknown

Все интерфейсы COM наследуются от интерфейса IUnknown. Интерфейс IUnknown содержит основные операции COM для полиморфизма и управления временем существования экземпляров. Интерфейс IUnknown имеет три функции-члена с именем QueryInterface, AddRefи Release. Для реализации интерфейса IUnknown требуются все com-объекты.

Функция-член QueryInterface обеспечивает полиморфизм для COM. Вызовите QueryInterface, чтобы определить, поддерживает ли com-объект определенный интерфейс во время выполнения. Объект COM возвращает указатель интерфейса в параметре ppvObject, если он реализует запрошенный интерфейс, в противном случае возвращается NULL. Функция-член QueryInterface позволяет навигацию среди всех интерфейсов, поддерживаемых COM-объектом.

Время существования экземпляра COM-объекта управляется счетчиком ссылок. Функции-члены IUnknownAddRef и Release управляют подсчетом. AddRef увеличивает количество, а Release уменьшает количество. Когда число ссылок достигает нуля, метод Release может освободить экземпляр, поскольку вызывающие его больше не используют.

Модель клиента или сервера

Класс COM реализует ряд COM-интерфейсов. Реализация состоит из двоичных файлов, выполняемых при взаимодействии вызывающего объекта с экземпляром класса COM. COM позволяет использовать класс в разных приложениях, включая приложения, написанные без знания определенного класса. На платформе Windows классы существуют либо в динамической библиотеке (DLL), либо в другом приложении (EXE).

На своей хост-системе COM ведет базу данных регистрации всех CLSID для объектов COM, установленных в системе. База данных регистрации — это сопоставление между каждым CLSID и расположением библиотеки DLL или EXE, в которой размещается соответствующий класс. COM запрашивает эту базу данных всякий раз, когда вызывающий объект хочет создать экземпляр класса COM. Вызывающий должен знать только CLSID, чтобы запросить новый экземпляр класса.

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

COM-клиент — это любой вызывающий, который передает CLSID системе для запроса экземпляра COM-объекта. Самый простой способ создания экземпляра — вызвать com-функцию, CoCreateInstance.

Функция CoCreateInstance создает один экземпляр указанного CLSID и возвращает указатель интерфейса типа, запрошенного клиентом. Клиент отвечает за управление временем существования экземпляра, вызывая функцию освобождения , когда завершит работу с ним. Чтобы создать несколько объектов на основе одного CLSID, вызовите функцию CoGetClassObject. Чтобы подключиться к объекту, который уже создан и запущен, вызовите функцию GetActiveObject.

COM-сервер предоставляет COM-реализацию системе. Сервер связывает CLSID с com-классом, размещает реализацию класса, реализует фабрику классов для создания экземпляров класса и обеспечивает выгрузку сервера.

Заметка

COM-сервер не совпадает с com-объектом, который он предоставляет системе.

 

Чтобы включить создание COM-объекта, COM-сервер должен предоставить реализацию интерфейса IClassFactory. Клиенты могут вызывать метод CreateInstance для запроса нового экземпляра COM-объекта, но обычно такие запросы инкапсулируются в функции CoCreateInstance.

Com-сервер можно развернуть как общую библиотеку, которая загружается в процесс клиента во время выполнения (DLL на платформах Windows) или в виде исполняемого модуля (EXE на платформах Windows). Дополнительные сведения см. Регистрация COM-приложений.

Диспетчер управления службами

Диспетчер управления службами (SCM) обрабатывает запрос клиента для экземпляра COM-объекта. В следующем списке показана последовательность событий:

  • Клиент запрашивает указатель интерфейса на COM-объект из COM-библиотеки, вызывая функцию, такую как CoCreateInstance с помощью CLSID данного COM-объекта.
  • Библиотека COM обращается к Диспетчеру управления службами, чтобы определить сервер, которому соответствует запрошенный CLSID.
  • SCM находит сервер и запрашивает создание COM-объекта из фабрики классов, предоставляемой сервером.
  • При успешном выполнении COM-библиотека возвращает клиенту указатель интерфейса.

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

При регистрации COM-сервера в системе узла можно указать различные способы активации сервера. В следующем списке показаны три способа активации COM-сервера SCM:

  • В процессе: SCM возвращает путь к файлу библиотеки DLL, содержащей реализацию сервера объектов. Библиотека COM загружает DLL и запрашивает у нее указатель интерфейса фабрики классов.
  • Local: SCM запускает локальный исполняемый файл, который регистрирует фабрику классов при запуске, а его указатель интерфейса доступен системе и клиентам.
  • Удаленный: локальный SCM получает указатель интерфейса фабрики классов из SCM, работающего на удаленном компьютере.

Когда клиент запрашивает COM-объект, библиотека COM обращается к SCM на локальном узле. SCM находит соответствующий COM-сервер, который может быть локальным или удаленным, а сервер возвращает указатель интерфейса на фабрику классов сервера. Когда фабрика классов доступна, библиотека COM или клиент могут использовать фабрику классов для создания запрошенного объекта. Дополнительные сведения см. в разделе Реализация IClassFactory.

Возможность повторного использования

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

В сдерживании внешний объект ведет себя как клиент внутреннего объекта. Внешний объект является логическим контейнером для внутреннего объекта, и когда внешний объект использует службы внутреннего объекта, внешний объект делегирует реализацию интерфейсам внутреннего объекта. Это означает, что внешний объект реализуется с точки зрения служб внутреннего объекта. Внешний объект может не поддерживать те же интерфейсы, что и внутренний объект, а внешний объект может использовать интерфейс внутреннего объекта для реализации частей другого интерфейса во внешнем объекте.

В агрегации внешний объект предоставляет интерфейсы из внутреннего объекта, как если бы они были реализованы на внешнем объекте. Это полезно, если внешний объект всегда делегирует каждый вызов одного из его интерфейсов в один и тот же интерфейс внутреннего объекта. Агрегирование — это удобство, позволяющее внешнему объекту избежать дополнительных затрат на реализацию.

Дополнительные сведения см. в разделе Повторное использование объектов.

Объекты хранилища и потоковой передачи

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

Спецификация постоянного хранилища COM предоставляет два типа элементов хранилища: объекты хранилища и объекты потока. Эти объекты реализуются библиотекой COM, а пользовательские приложения редко реализуют эти элементы хранения. Объекты хранилища реализуют интерфейсIStorageи потоковые объекты реализуют интерфейс IStream.

Объект потока содержит данные и концептуально похож на один файл в файловой системе. Каждый поток имеет права доступа и один указатель поиска. С помощью интерфейса IStream можно читать, записывать, искать и выполнять другие операции с базовыми данными потока. Поток называется с помощью текстовой строки. Он может содержать любую внутреннюю структуру, так как это плоский поток байтов. Кроме того, функции в интерфейсе IStream подобны стандартным функциям, основанным на файловых дескрипторах, таким как в библиотеке времени выполнения ANSI C.

Объект хранилища концептуально похож на каталог в файловой системе. Каждое хранилище может содержать неограниченное количество подхранилищ и потоков. Каждое хранилище имеет собственные права доступа. С помощью интерфейса IStorage можно выполнять такие операции, как перечисление, перемещение, копирование, переименование, создание и удаление элементов. Объект хранилища не хранит определяемые приложением данные, но сохраняет неявно имена элементов (хранилищ и потоков), которые он содержит.

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

Каждый объект хранилища и потока в структурированном файле имеет имя для его идентификации. Имя — это строка, которая соответствует определённому стандарту. Дополнительные сведения см. в разделе «Соглашения об именовании объектов хранилища». Имя передается функциям IStorage для указания, над каким элементом в хранилище будет выполняться операция. Имена корневых объектов хранилища совпадают с именами файлов в базовой файловой системе, и эти имена должны соответствовать соглашениям и ограничениям файловой системы. Строки, передаваемые функциям, связанным с именованием файлов, проходят через файловую систему без интерпретации или изменений.

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

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

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

  • IPersistStorage: COM-объект считывает и записывает постоянное состояние в объект хранилища. Клиент предоставляет объекту указатель IStorage через этот интерфейс. Это единственный интерфейс сохраняемости, включающий семантику для добавочного доступа.
  • IPersistStream: COM-объект считывает и записывает постоянное состояние в объект потока. Клиент предоставляет объекту указатель IStream через этот интерфейс.
  • IPersistFile: COM-объект считывает и записывает постоянное состояние непосредственно в файл в базовой системе. Этот интерфейс не включает IStorage или IStream, если доступ к базовому файлу не осуществляется через эти интерфейсы, но интерфейс IPersistFile не имеет семантики для хранилищ и потоков. Клиент предоставляет объекту имя файла и вызывает функции "Сохранить" или "Загрузить".

Передача данных

Структурированное хранилище предоставляет основу для обмена данными между COM-объектами и процессами, называемой единообразной передачей данных. До реализации COM в OLE 2 передача данных в Windows осуществлялась протоколами передачи, такими как буфер обмена и протоколы drag-and-drop. Каждый протокол передачи имел собственный набор функций, ограничивающих протокол к запросу, и для обработки каждой разной процедуры протокола и обмена требуется конкретный код. Единая передача данных представляет все передачи данных с помощью интерфейса IDataObject, который отделяет общие операции обмена данными от протокола передачи.

Интерфейс IDataObject инкапсулирует стандартные операции получения и задания данных, запросов и перечислений, а также уведомления, которые обнаруживают изменения данных в объекте. Однородная передача данных обеспечивает широкие описания форматов данных, а также использование разных носителей хранилища для передачи данных.

Во время единой передачи данных все протоколы обменивают указатель на интерфейс IDataObject. Сервер является источником данных и реализует один объект данных, который можно использовать в любом протоколе обмена данными. Клиент использует данные и запрашивает их из объекта данных, когда получает указатель IDataObject от любого протокола. После того как обмен указателем произошел, обе стороны обрабатывают обмен данными в единообразном режиме через интерфейс IDataObject.

COM определяет две структуры данных, которые обеспечивают единую передачу данных. Структура FORMATETC представляет обобщенный формат буфера обмена, а структура STGMEDIUM представляет носитель передачи в виде дескриптора памяти.

Клиент создает структуру FORMATETC, чтобы указать тип данных, которые он запрашивает из источника данных, и используется источником данных для описания форматов, которые он предоставляет. Клиент обращается к источнику данных для получения доступных форматов, запрашивая интерфейс IEnumFORMATETC . Дополнительные сведения см. в разделе Структура FORMATETC.

Клиент создает структуру STGMEDIUM и передает ее в метод GetData, а объект данных возвращает данные в предоставленной структуре STGMEDIUM.

Структура STGMEDIUM позволяет клиентам и источникам данных выбирать наиболее эффективный носитель обмена. Например, если данные для обмена очень большими, источник данных может указать дисковый носитель в качестве предпочтительного формата вместо основной памяти. Эта гибкость позволяет эффективно обмениваться данными, передача которых может быть такой же быстрой, как и передача указателя на IStorage или IStream. Дополнительные сведения см. в разделе Структура STGMEDIUM.

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

Удаленное взаимодействие

COM включает удаленные и распределенные вычисления. удаленное взаимодействие интерфейса позволяет функции-члену возвращать указатель интерфейса на COM-объект, который находится в другом процессе или на другом хост-компьютере. Инфраструктура, которая выполняет удалённое управление интерфейсом, прозрачна как для клиента, так и для сервера объектов. Ни клиент, ни сервер не нуждаются в деталях развертывания друг друга для обмена данными через удаленный интерфейс. Клиент вызывает методы на том же интерфейсе для взаимодействия с COM-объектом, который работает в процессе, вне процесса выполнения на локальном узле или на удаленном компьютере. Локальные и удаленные вызовы в одном интерфейсе неотличимы для клиента.

Для взаимодействия с COM-объектом клиент всегда вызывает реализацию внутри процесса. Если объект COM является внутрипроцессным, вызов выполняется напрямую. Если COM-объект является внепроцессным или удаленным, COM предоставляет прокси реализацию, которая перенаправит вызов объекту с помощью протокола удаленного вызова процедур (RPC).

COM-объект всегда получает вызовы от клиента через внутрипроцессную реализацию. Если вызывающий объект находится в процессе выполнения, вызов является прямым. Если вызывающий объект является непроцессным или удаленным, COM предоставляет заглушку реализацию, которая получает удаленный вызов процедуры от прокси-сервера в процессе клиента.

маршалинг — это процедура упаковки стека вызовов для передачи от прокси к стабу. Демаршалинг — это распаковка данных, которая происходит при получении. Возвращаемые значения маршалируются и демаршалируются из заглушки в прокси. Этот вид связи также называется отправкой звонка по проводной.

У каждого типа данных есть свои правила преобразования. Указатели интерфейса также имеют протокол маршалинга, который инкапсулируется в функции CoMarshalInterface. В большинстве случаев стандартный интерфейс маршалинг, предоставляемый системой, является достаточным, но COM-объект может реализовать пользовательский маршалинг интерфейса для управления созданием прокси-серверов удаленных объектов к самому себе. Дополнительные сведения см. в разделе Inter-Object Коммуникации.

Безопасность

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

Безопасность активации применяется автоматически диспетчером управления службами (SCM). Когда SCM получает запрос на получение COM-объекта, он проверяет запрос на наличие сведений о безопасности, хранящихся в реестре.

Реализации SCM обычно предлагают конфигурацию на основе реестра для администрирования развернутых классов и для определенных учетных записей пользователей на узле. Дополнительные сведения см. в разделе Безопасность активации.

Безопасность вызовов применяется автоматически или применяется приложением. Если приложение предоставляет сведения о настройке, COM выполняет необходимые проверки для защиты приложения.

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

Автоматические и настраиваемые механизмы можно использовать вместе, поэтому приложение может попросить COM выполнить автоматическую проверку безопасности, а затем выполнить собственную.

Службы безопасности вызовов COM делятся на следующие категории:

  • Общие функции, вызываемые клиентами и серверами, которые позволяют инициализировать и автоматически регистрировать службы автоматической проверки подлинности. Общие API безопасности вызовов — это функцииCoInitializeSecurityи CoQueryAuthenticationServices.
  • Интерфейсы прокси-серверов клиента, которые позволяют клиенту управлять безопасностью при вызовах отдельных интерфейсов. Интерфейс IClientSecurity и функции CoQueryProxyBlanket, CoSetProxyBlanketи CoCopyProxy обеспечивают безопасность вызовов для удаленного объекта.
  • Серверные функции и интерфейсы контекста вызова, которые позволяют серверу получать информацию о безопасности вызова и имитировать вызывающего абонента. Интерфейс IServerSecurity и функции CoGetCallContext, CoImpersonateClient, CoRevertToSelf обеспечивают безопасность вызовов на стороне сервера.

Часто клиент запрашивает COM-объект для интерфейса IClientSecurity, который реализуется локально на уровне удаленного взаимодействия. Клиент использует этот интерфейс для управления безопасностью отдельных прокси-интерфейсов в COM-объекте перед вызовом одного из интерфейсов.

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

Вызовите функцию CoInitializeSecurity, чтобы инициализировать уровень безопасности и задать указанные значения в качестве значения по умолчанию безопасности. Если процесс не вызывает CoInitializeSecurity, COM вызывает его автоматически при первом маршалинге или демаршализации интерфейса, регистрируя системную безопасность по умолчанию. Функция CoInitializeSecurity позволяет клиенту установить безопасность вызовов по умолчанию для процесса, что позволяет избежать использования IClientSecurity для отдельных прокси-серверов. Функция CoInitializeSecurity позволяет серверу регистрировать службы автоматической проверки подлинности для процесса. Для получения дополнительной информации см. раздел Настройка Process-Wide безопасности с использованием CoInitializeSecurity.

COM-клиенты и серверы

определение COM-интерфейсов

регистрация COM-приложений

Безопасность в COM

Процессы, Потоки и Апартаменты