DCOM — что это такое
Для создания объекта на удалённой машине, библиотека COM:
- вызывает менеджер управления сервисами (SCM) локального компьютера
- в свою очередь SCM локального компьютера связывается с SCM сервера и передаёт ему запрос на создание объекта.
Имя сервера может задаваться при вызове функции создания объекта или храниться в реестре.
Для вызова удалённого объекта параметры должны быть извлечены из стека (или из регистров процессора), помещены в буфер и переданы через сеть (маршалинг)
На сервере производится обратный процесс воссоздания стека, называемый демаршалинг, после чего вызывается требуемый объект.
После завершения вызова производится маршалинг возвращаемого значения и выходных параметров и отправка их клиенту.
Для выполнения маршалинга и демаршалинга необходимо иметь точное описание метода, включая все типы данных и размеры массивов. Для описания используется язык описания интерфейсов (IDL), входящий в стандарт DCE RPC.
Полученные файлы описания компилируются специальным компилятором IDL в исходный код на языке Си, производящий маршалинг и демаршалинг для указанных интерфейсов.
Термины
- на стороне клиента, называется «прокси»
- на стороне объекта – «стаб» (то есть на «удалённой» стороне)
Код загружается библиотекой COM по необходимости.
Объектный RPC
Протокол DCOM, известный как объектный RPC (ORPC) является расширением протокола DCE RPC. ORPC использует стандартные пакеты RPC с дополнительной, необходимой для DCOM информацией.
Заголовок вызова содержит идентификатор указателя интерфейса (IPID), который используется для идентификации необходимого интерфейса необходимого объекта на сервере, а параметры начинаются с дополнительного неявного аргумента.
Данные в пакете ORPC передаются в стандартном формате NDR с дополнительным типом данных, представляющем собой идентификатор объекта.
Клиент должен периодически подтверждать свою активность путём «пингования» сервера. Если период пингования истёк без получения «пинга», считается, что клиент завершил работу аварийно и все его ссылки на интерфейсы объекта уничтожаются.
Dcom сервера что это
Обычные СОМ объекты имеют один важный недостаток — их можно использовать только в пределах отдельного компьютера, т.е. и СОМ-сервер и СОМ-клиент должны работать в рамках одной операционной системы. Их нельзя разместить на разных компьютерах и организовать общение через сетевую среду, т.е. в рамках технологии обычной СОМ нельзя создать распределенную программную систему.
Для того, чтобы устранить этот недостаток, специалисты Microsoft разработали распределенную модель СОМ — DCOM. Модель DCOM расширяет возможности СОМ, позволяя обращаться к СОМ объектам в режиме удаленного доступа.
Распределенная модель DCOM разработана для того, чтобы обеспечить взаимодействие между СОМ объектами в режиме удаленного доступа. Это позволяет СОМ серверу и СОМ клиентам располагаться на разных компьютерах и связываться по сети. По сути, механизм поддержки DCOM реализует те же задачи, что и механизм поддержки СОМ, но дополнительно он обеспечивает безопасность приложений в сетевой среде. Создание DCOM стало возможным в результате расширения возможностей механизма удаленного вызова процедур RPC и превращение его в объектный (Object) RPC. В настоящее время эту модель можно рассматривать как средство реализации распределенных многоплатформенных приложений.
В модели DCOM используется концепция «прозрачности размещения», которая подразумевает, что можно, не изменяя программного кода, выполнить приложение СОМ сервера на разных компьютерах сети. При этом ни приложение-сервер, ни приложение-клиент не «знают», на каком компьютере фактически работает «собеседник». Они могут выполняться на одном компьютере, на разных компьютерах локальной сети, или даже на разных компьютерах, подключенных к глобальной сети, например Internet. Приложение-клиент «узнает» о существовании сервера из данных в системном реестре, которые могут быть легко изменены.
Но за такую «прозрачность» приходится платить. В данном случае приходится предпринимать дополнительные меры для обеспечения безопасности. В средствах поддержки DCOM эта задача решается в рамках сетевой системы доменов, уже давно реализованной в Microsoft.
Клиентские и серверные DCOM-приложения должны следовать правилам аутентификации и авторизации. Это означает, что приложение должно пройти через определенную процедуру регистрации при попытке получить доступ к компьютеру, на котором выполняется серверное приложение. Сервер должен аутентифицировать (идентифицировать) клиента — проверить, действительно ли он является тем, за кого себя выдает, и авторизировать доступ — выяснить, имеет ли пользователь необходимые привилегии доступа.
Приложения DCOM могут полагаться на те параметры безопасности, которые хранятся в системном реестре Registry, или изменить эти параметры программно. Эти два подхода к реализации подсистемы безопасности получили наименования декларативной и программируемой безопасности.
Главной проблемой при программировании DCOM-приложений является как раз подсистема обеспечения безопасности.
модель DCOM базируется на модели СОМ. Целью создания СОМ была поддержка разработки компонентов, которые могли бы динамически активизироваться и взаимодействовать друг с другом. Компонент в СОМ — это исполняемый код, содержащийся в динамически компонуемой библиотеке (DLL) или исполняемой программе.
Сама по себе модель СОМ существует в виде библиотек, компонуемых с процессом. Изначально она разрабатывалась для поддержки так называемых составных документов (compound documents). Как мы говорили в главе 3, составные документы — это документы, построенные из разнородных частей, таких как текст (форматированный), изображения, электронные таблицы и т.п. Каждая из этих частей может быть отредактирована при помощи ассоциированного с ней приложения.
Для поддержки бесчисленного множества составных документов Microsoft нужен был обобщенный метод для разделения отдельных частей и объединения их в единую сущность. Вначале это привело к технологии связывания и внедрения объектов (Object Linking and Embedding, OLE), Первая версия OLE использовала для передачи информации между частями документа примитивный и негибкий способ обмена сообщениями. Вскоре она была заменена следующей версией, также называвшейся OLE, но построенной на базе более гибкого механизма СОМ, что привело к появлению структуры, представленной на рис. 5.
Рис. 5 — Общая структура ActiveX, OLE и COM
На рисунке также показан элемент ActiveX — этим термином в настоящее время называют все, что относится к OLE, плюс некоторые новшества, к которым относят гибкую (как правило) способность компонентов выполняться в разных процессах, поддержку сценариев и более или менее стандартную группировку объектов в так называемые элементы управления ActiveX. Среди экспертов по DCOM (даже внутри Microsoft) не существует согласия по вопросу о точном определении ActiveX, поэтому мы даже не будем пытаться дать подобное определение.
Модель DCOM добавила к этой структуре весьма существенную вещь — способность процесса работать с компонентами, размещенными на другой машине. Однако базовый механизм обмена информацией между компонентами, принятый в DCOM, очень часто совпадает с соответствующими механизмами СОМ. Другими словами, для программиста разница между СОМ и DCOM часто скрыта за различными интерфейсами. Как мы увидим, DCOM в первую очередь предоставляет прозрачность доступа. Другие виды прозрачности менее очевидны.
Как и в CORBA, объектная модель в DCOM построена на реализации интерфейсов. Грубо говоря, объект DCOM — это просто реализация интерфейса. Один объект может реализовывать одновременно несколько интерфейсов. Однако в отличие от CORBA в DCOM имеются только бинарные интерфейсы (binary interfaces). Такой интерфейс, в сущности, представляет собой таблицу с указателями на реализации методов, которые являются частью интерфейса. Разумеется, для определения интерфейса по-прежнему удобно использовать специальный язык определения интерфейса (IDL). В DCOM также имеется такой язык под названием MIDL (Microsoft IDL — язык IDL от Microsoft), при помощи которого генерируются бинарные интерфейсы стандартного формата.
Достоинство бинарных интерфейсов состоит в том, что они не зависят от языка программирования. В случае CORBA каждый раз для поддержки нового языка программирования необходимо отображать описания IDL на конструкции этого языка. Подобная стандартизация в случае бинарных интерфейсов не нужна. Разницу между этими двумя подходами иллюстрирует рис. 6.
Рис. 6 — Разница между интерфейсами
Каждый интерфейс в DCOM имеет уникальный 128-битный идентификатор, который называется идентификатором интерфейса (Interface Identifier, IID), Каждый IID абсолютно уникален, не существует двух интерфейсов с одинаковым идентификатором IID. Этот идентификатор создается путем комбинирования большого случайного числа, локального времени и адреса сетевого интерфейса текущего хоста. Вероятность того, что два сгенерированных индикатора совпадут, практически равна нулю.
Объект DCOM создается как экземпляр класса. Чтобы создать такой объект, необходимо иметь доступ к соответствующему классу. Для этой цели DCOM содержит объекты класса (class objects). Формально таким объектом может быть все, что поддерживает интерфейс IClassFactory. Этот интерфейс содержит метод Createlnstance, который похож на оператор new в языках C++ и Java. Вызов метода Createlnstance для объекта класса приводит к созданию объекта DCOM, содержащего реализацию интерфейсов объекта класса.
Таким образом, объект класса представляет собой коллекцию объектов одного типа, то есть реализующих один и тот же набор интерфейсов. Объекты, принадлежащие к одному классу, обычно различаются только в части текущего состояния. Путем создания экземпляров объекта класса становится возможным обращение к методам этих интерфейсов. В DCOM на любой объект класса можно сослаться по его глобальному уникальному идентификатору класса (Class Identifier, CLSID).
Все объекты реализуют стандартный объектный интерфейс lUnknown. Когда путем вызова Createlnstance создается новый объект, объект класса возвращает указатель на этот интерфейс. Самый важный метод, содержащийся в lUnknown, — метод Querylnterface, который на основании IID возвращает указатель на другой интерфейс, реализованный в объекте.
Важное отличие от объектной модели CORBA состоит в том, что все объекты в DCOM нерезидентные. Другими словами, как только у объекта не остается ссылающихся на него клиентов, этот объект удаляется. Подсчет ссылок производится путем вызова методов AddRef и Release, входящих в интерфейс lUnknown. Наличие исключительно нерезидентных объектов делает невозможным хранение каждым из объектов своего глобально уникального идентификатора. По этой причине объекты в DCOM могут вызываться только по указателям на интерфейсы. Соответственно, как мы увидим позднее, для передачи ссылки на объект другому процессу необходимо предпринять специальные меры.
DCOM также требует динамического обращения к объектам. Объекты, запросы к которым могут создаваться динамически, во время выполнения, должны иметь реализацию интерфейса IDispatch. Этот интерфейс подобен интерфейсу динамического обращения (DII) в системе CORBA.
Разница между CORBA и DCOM
CORBA и DCOM — это два промежуточных решения для обработки распределенных объектов. Эти решения обеспечивают лучшее управление распределенными вычислительными объектами, но вопрос в том, какая технология должна быть сделана стандартной. Давайте посмотрим на подробное сравнение между ними.
1. Общая архитектура посредника объектных запросов (CORBA):
Общая архитектура брокера объектных запросов — это подробная спецификация распределенных объектов. Он был представлен OMG (Object Management Group). Архитектура описывает язык с платформенно-независимой объектной шиной под названием ORB (Object Request Broker). Они продвигают объекты, чтобы сделать запрос и прозрачно получить ответ от удаленных объектов. Это также поддерживает обработку параллелизма и обработку исключений.
2. Распределенная объектная модель компонентов (DCOM):
Распределенная объектная модель компонентов была представлена Microsoft в Window NT в виде связного пакета. DCOM использовался с Internet Explorer, присутствующим внутри Windows, и ожидалось, что он привлечет разработчиков для использования того, что у них есть, а не для покупки. DCOM также является объектной шиной, которая помогает специфицировать интерфейсы объектов и вызывать динамический экспорт объектов, поддерживающий распределенную среду. Это поддерживает совместное использование кода if и требует, чтобы общий код был объявлен с помощью объектного интерфейса.