Что такое dcom сервер
Что такое dcom сервер
DCOM (англ. Distributed COM ) — расширение Component Object Model для поддержки связи между объектами на различных компьютерах по сети.
Принцип работы
Для создания объекта на удалённой машине, библиотека COM вызывает менеджер управления сервисами (SCM) локального компьютера, который связывается с SCM сервера и передаёт ему запрос на создание объекта. Имя сервера может задаваться при вызове функции создания объекта или храниться в реестре.
Для вызова удалённого объекта параметры должны быть извлечены из стека (или из регистров процессора), помещены в буфер и переданы через сеть. Процесс извлечения параметров и помещения их в буфер называется маршалинг. Этот процесс нетривиален, так как параметры могут содержать указатели на массивы и структуры, которые, в свою очередь, могут содержать указатели на другие структуры. На сервере производится обратный процесс воссоздания стека, называемый демаршалинг, после чего вызывается требуемый объект. После завершения вызова производится маршалинг возвращаемого значения и выходных параметров и отправка их клиенту.
Для выполнения маршалинга и демаршалинга необходимо иметь точное описание метода, включая все типы данных и размеры массивов. Для описания используется язык описания интерфейсов (IDL), входящий в стандарт DCE RPC. Полученные файлы описания компилируются специальным компилятором IDL в исходный код на языке Си, производящий маршалинг и демаршалинг для указанных интерфейсов. Код, запускаемый на стороне клиента, называется «прокси», на стороне объекта – «заглушка» и загружается библиотекой COM по необходимости.
Объектный RPC
Протокол DCOM, известный как объектный RPC (ORPC) является расширением протокола DCE RPC. ORPC использует стандартные пакеты RPC с дополнительной, необходимой для DCOM информацией. Заголовок вызова содержит идентификатор указателя интерфейса (IPID), который используется для идентификации необходимого интерфейса необходимого объекта на сервере, а параметры начинаются с дополнительного неявного аргумента.
Данные в пакете ORPC передаются в стандартном формате NDR с дополнительным типом данных, представляющем собой идентификатор объекта.
Клиент должен периодически подтверждать свою активность путём «пингования» сервера. Если период пингования истёк без получения «пинга», считается, что клиент завершил работу аварийно и все его ссылки на интерфейсы объекта уничтожаются.
Контакты • DVD Maker • Факсы и сканирование • Internet Explorer • Журнал • Экранная лупа • Media Center • Проигрыватель Windows Media • Программа совместной работы • Центр устройств Windows Mobile • Центр мобильности • Экранный диктор • Paint • Редактор личных символов • Удалённый помощник • Распознавание речи • WordPad • Блокнот • Боковая панель • Звукозапись • Календарь • Калькулятор • Ножницы • Почта • Таблица символов • Исторические: Movie Maker • NetMeeting • Outlook Express • Диспетчер программ • Диспетчер файлов • Фотоальбом
Chess Titans • Mahjong Titans • Purble Place • Пасьянсы (Косынка • Паук • Солитер) • Сапёр • Пинбол • Червы
Autorun.inf • Фоновая интеллектуальная служба передачи • Файловая система стандартного журналирования • Отчёты об ошибках • Планировщик классов мультимедиа • Теневая копия • Планировщик задач • Беспроводная настройка
Active Directory • Службы развёртывания • Служба репликации файлов • DNS • Домены • Перенаправление папок • Hyper-V • IIS • Media Services • MSMQ • Защита доступа к сети (NAP) • Службы печати для UNIX • Удалённое разностное сжатие • Службы удаленной установки • Служба управления правами • Перемещаемые профили пользователей • SharePoint • Диспетчер системных ресурсов • Удаленный рабочий стол • WSUS • Групповая политика • Координатор распределённых транзакций
Настройка DCOM для работы OPC серверов в Windows 7
В чем заключается настройка DCOM OPC? Для корректной работы OPC серверов по сети, необходимо настроить сетевые параметры и параметры безопасности DCOM.
Настройка DCOM для компьютера
Distributed Component Object Model (DCOM) — это протокол, с помощью которого компоненты программного обеспечения поддерживают связь по сети. Модель DCOM (прежнее название — «Network OLE») может использовать несколько сетевых транспортов, включая протоколы Интернета (например, протокол HTTP).
Поддержка DCOM встроена в Windows, начиная с версии Windows NT 4.0.
Первым шагом к настройке DCOM OPC всегда является добавление пользователя для работы с OPC. Если у вас пользователь настроен, то приступим к настройке сети и параметров безопасности.
В данном разделе нужно настроить свойства DCOM по умолчанию на сервере, чтобы «все работало». Приступим.
1. Запустим окно настройки DCOM
Настройка параметров DCOM выполняется с помощью служебной команды «dcomcnfg». Для запуска «dcomcnfg» нажмите на клавиатуре Win+R, чтобы открыть окно запуска программ из командной строки.
Откроется окно Службы компонентов, в котором нужно будет раскрыть список Службы компонентов, а затем и список Компьютеры, где мы увидим еще один вложенный список Мой компьютер, на который нужно нажать правой кнопкой мыши и выбрать пункт меню Свойства.
2. Настройка свойств компьютера для DCOM
В появившемся окне свойств выбираем вкладку Свойства по умолчанию и устанавливаем следующие настройки:
После жмем кнопку OK. Система может предупредить о том, что будут изменены свойства DCOM — соглашайтесь. Окно Службы компонентов не закрывайте, оно нам еще понадобится.
Те же настройки необходимо провести и на клиенте за исключением пунктов 3.2 и 3.3 — они не повлияют на работу, но и не повредят. Самое главное, чтобы DCOM был разрешен.
Настройка безопасности DCOM
Переходим на вкладку Безопасность и устанавливаем умолчания на права доступа и на запуск и активацию.
Кликните по кнопке №1. В появившемся диалоговом окне:
Повторите действия в диалоговом окне «Разрешение на запуск и активацию» которое появляется при клике на кнопке №2 «Изменить умолчания».
На вкладке Набор протоколов должен быть только один протокол, как на скриншоте
Настройка DCOM для OPC Enum
Настройка OPC Enum по умолчанию
Если вы настроили умолчания для компьютера, то чаще всего эта настройка не нужна. Нужно только убедиться, что все настройки выставлены так, как надо.
Настройка OPC Enum вручную
Но иногда почему-то настройки по умолчанию не работают. Тогда настраиваем DCOM для OPC Enum вручную.
Служба OpcEnum отвечает за отображение OPC-серверов. Если ее настроить некорректно, то при браузинге серверов, вы не увидите ничего, кроме ошибок. Эту службу нужно настроить на сервере.
Вкладка Общие
Откроется окно свойств, и во вкладке Общие в списке Уровень проверки подлинности выбрать Подключиться.
Вкладка Размещение
Во вкладке Размещение должен быть выбран пункт Запустить приложение на данном компьютере. Остальные галки должны быть сняты.
Вкладка Безопасность
Далее переходим к вкладке Безопасность, где будем раздавать права на удаленный запуск, доступ и изменение настроек OpcEnum.
Во всех трех случаях выбираем пункт Настроить, т.е. у нас должны быть активны три кнопки Изменить.
Открываем окошко Разрешение на изменение настроек.
Вкладка Удостоверение
Переходим ко вкладке Удостоверение окна свойств OpcEnum.
Для службы OpcEnum возможно два варианта запуска:
Определившись нажимаем OK и переходим к перезапуску службы OpcEnum. Это можно сделать из того же окна: слева выбираем Службы (локальные), справа в списке ищем OpcEnum, выбираем и перезапускаем нажатием на появившуюся ссылку.
Но при попытке достучаться до тэгов прилетает отказ. Этого следовало ожидать, ведь мы еще не настраивали наш OPC сервер.
Настройка DCOM для OPC сервера
Мы вплотную подобрались к настройке ПО, которое будет выдавать нам теги на клиенте. Настройка не сильно отличается от процедуры, описанной в предыдущем разделе.
Технический Обзор DCOM
DCOM — это последовательное развитие СОМ, а значит, ваши инвестиции в создание СОМ-приложений, компонентов, инструментария плавно переносятся в сферу стандартизованных распределенных решений.
DCOM возьмет на себя низкоуровневые детали сетевых протоколов, а вы сможете сфокусироваться на вашем настоящем деле: создании хороших решений для пользователей.
Почему я должен прочесть эту статью?
Если вы CIO, архитектор решений или разработчик приложений, который хочет создавать качественные приложения, работающие одинаково хорошо на интранет, Интернет и т.д., DCOM может вам помочь. Этот материал содержит общий обзор возможности использования DCOM для решения сложнейших проблем, связанных с распределенными приложениями. Ваши приложения когда-нибудь нуждались (или будут нуждаться) в:
устойчивой работе в случае аварии аппаратного обеспечения?
работе как по обслуживанию небольшой рабочей группы, так и в качестве большого корпоративного сайта?
устойчивости в работе при авариях сети?
в работе на пользовательских машинах с различными параметрами или в различных географических зонах?
большей эффективности в условиях загруженности сети?
Ниже будет описано, каким образом DCOM поможет вам решить эти и другие проблемы для новых или уже существующих приложений.
Как следует читать эти страницы?
Эти Белые Страницы являются первыми в серии, посвященной СОМ и DCOM. Здесь предложено объяснение дизайнерских решений, которые предлагаются DCOM:
Независимость от местоположения.
Полоса пропускания и латентность.
Устойчивость к авариям.
Гибкость в перераспределении.
Безболезненная интеграция с другими протоколами Интернет.
Начав с этого материала, вам следует обратиться к другим страницам серии для более подробного ознакомления по определенным вопросам.
Если вы действительно хотите понять сам механизм совместной работы компонентов, обратитесь к тем статьям, ссылки на которые есть на этих страницах и которые вы можете увидеть на “Technology Preview CD”.
“DCOM-Архитектура”. Это пособие по внутренней и внешней работе DCOM, воспользовавшись которым, вы увидите, как легко DCOM реализует работу в распределенной среде без ущерба гибкости, масштабируемости или отказоустойчивости.
Эти страницы вводят вас в мир распределенного программирования. Здесь показаны некоторые проблемы, с которыми вы столкнетесь или уже столкнулись, и даны некоторые соображения, как можно их устранить, используя уникальные возможности DCOM.
Как получить DCOM?
В данный момент DCOM поставляется с Windows NT 4.0 и до конца 1996 года будет поставляться с Windows 95. В начале 1997 года Microsoft предложит вам DCOM для Apple Macintosh. Кроме того, с начала 1997 года будет доступен инструментарий DCOM для большинства UNIX-платформ, включая его исходные коды. COM и DCOM больше не являются монополией Microsoft, а управляются независимым консорциумом ActiveX (ActiveX Consortium).
Для чего создаются распределенные приложения?
Разработка распределенных приложений дает системному менеджеру большое преимущество в виде гибкости в перераспределении.
К тому же, распределенные приложения являются гораздо более масштабируемыми, нежели их монолитные собратья. Если вся логика комплексного приложения сосредоточена в едином модуле, есть единственный способ ускорить работу без настройки приложения: более скоростное аппаратное обеспечение. Сегодняшние серверы и операционные системы легко модифицируются, однако чаще бывает дешевле приобрести еще одну такую же машину, нежели сделать upgrade, чтобы ускорить сервер вдвое. При правильно сконструированном распределенном приложении в начале работы все компоненты могут запуститься с одного сервера. При увеличении загрузки некоторые компоненты могут перераспределяться на дополнительные, менее дорогостоящие машины.
Архитектура DCOM
DCOM является развитием многокомпонентной модели (СОМ). СОМ определяет, каким образом компоненты взаимодействуют со своими клиентами. Это взаимодействие осуществляется таким образом, чтобы клиент и компонент могли соединяться без необходимости использовать некоторый промежуточный компонент системы и клиент мог вызывать методы компонента. Рисунок 1 иллюстрирует это с точки зрения многокомпонентной модели.
Рис. 1 – COM-компоненты
в одном процессе
В сегодняшних операционных системах процессы изолированы друг от друга. Клиент, которому нужно связаться с компонентом другого объекта, не может вызвать компонент напрямую, а должен использовать некоторую форму связи между процессами, предусмотренную операционной системой. СОМ организует подобное соединение в полностью прозрачной манере: он перехватывает вызовы со стороны клиента и адресует их компоненту другого процесса. Рис. 2 показывает, как run-time библиотеки COM/DCOM организуют соединение между клиентом и компонентом.
Рис. 2 – COM-компоненты в разных процессах
Когда клиент и компонент находятся на различных машинах, DCOM просто заменяет локальное соединение между процессами сетевым протоколом. При этом ни клиент, ни компонент и не подозревают, что провода, соединяющие их, стали чуть длиннее.
Рис. 3 показывает архитектуру DCOM в общем: СОМ run-time предлагает клиентам и компонентам объектно-ориентированные сервисы и использует RPC и провайдер безопасности для генерации стандартных сетевых пакетов, соответствующих стандарту протокола DCOM.
Рис. 3 – DCOM: COM-компоненты на различных машинах
Компоненты и их повторное использование
Большая часть распределенных приложений разрабатывалась не наспех и не в вакууме. Существующая инфраструктура аппаратного обеспечения, существующее программное обеспечение, существующие компоненты и инструменты должны быть интегрированы и призваны уменьшить время и стоимость разработки и перераспределения. В смысле инвестиций DCOM имеет несомненные преимущества перед любыми СОМ компонентами и инструментами. Огромный рынок компонентов позволяет уменьшить время разработки с помощью интегрирования стандартизованных решений в пользовательское приложение. Многие разработчики знакомы с СОМ и могут легко применить свои знания в создании распределенных DCOM-приложений.
Независимость от местоположения
Когда вы начинаете использовать распределенное приложение в реальной сети, выявляется несколько особенностей:
Компоненты, взаимодействующие чаще, должны быть “ближе” друг к другу.
Некоторые компоненты могут работать на определенных машинах или в определенных местах.
Использование меньших по размеру компонентов увеличивает гибкость в перераспределении, но при этом увеличивается сетевой трафик.
Компоненты большего размера уменьшают сетевой траффик, но зато уменьшается и гибкость в перераспределении.
С помощью DCOM эти критические моменты обходятся достаточно легко, поскольку в исходном коде не определены детали перераспределения. DCOM полностью скрывает местоположение компонента, будь он в том же процессе, что и клиент, или на другом конце света. В любом случае способы, которыми клиент соединяется с компонентом и вызывает методы компонента, идентичны. DCOM не нуждается не только в изменениях исходного кода, но даже и в рекомпиляции программы. Простая реконфигурация изменяет способ, которым компоненты соединяются друг с другом.
Рис. 4 демонстрирует, как один и тот же компонент может быть перенесен на машину клиента при удовлетворительной полосе пропускания между машиной “клиент” и машиной “среднего слоя”, и на машине сервера, если клиент работает с приложением по медленному сетевому соединению.
Рис. 4 – Независимость от местоположения
Благодаря независимости DCOM от местоположения, приложение может перемещать взаимодействующие компоненты с “близлежащих” машин на одну и ту же машину или даже в один процесс. Даже если функциональность большого логического модуля организуется большим числом маленьких компонентов, они могут по-прежнему эффективно взаимодействовать друг с другом. Компоненты могут работать на машине, на которой это наиболее целесообразно: пользовательский интерфейс находится на машине клиента или “рядом” с ней. Компонент, работающий с базой данных, – на сервере “близко” к базе данных.
Независимость от языка
Управление соединением
Сетевые соединения не так устойчивы, как соединения внутри машины. Компоненты распределенного приложения должны знать, что клиент более не активен, даже – или в особенности – в случае сетевой или аппаратной аварии.
DCOM управляет соединением компонентов, предназначенных для одного клиента, так же, как и компонентов, обслуживающих несколько клиентов, используя счетчик ссылок для каждого компонента. Когда клиент соединяется с компонентом, DCOM увеличивает значение счетчика ссылок компонента. Когда клиент разрывает соединение, DCOM уменьшает значение счетчика ссылок компонента. Если значение счетчика достигает нуля – компонент свободен.
Для определения активности клиента DCOM использует эффективный протокол отслеживания (см. раздел 0 “Управление распределенным соединением между приложениями”). Машина клиента посылает периодическое сообщение. При нарушении соединения DCOM уменьшает счетчик и освобождает компонент, если значение счетчика станет равным нулю. С точки зрения компонента, случай отключения клиента, случай аварии сети и случай поломки машины клиента регистрируются одним и тем же механизмом подсчета. Приложения могут использовать такой механизм подсчета соединений для своего высвобождения.
Во многих случаях поток информации между компонентом и его клиентами не однонаправлен: компоненту нужно инициировать некоторые действия со стороны клиента, например, извещение о том, что длительный процесс завершился, обновляются данные, просматриваемые пользователем (обзор новостей), или поступило следующее сообщение в телеконференции или многопользовательской игре. Многие протоколы усложняют процесс осуществления такого типа симметричной связи. В DCOM каждый компонент может быть одновременно провайдером и потребителем функциональности. Один и тот же механизм, одни и те же возможности управляют связью в обоих направлениях, облегчая организацию связи и взаимодействия клиент/сервер.
Масштабируемость
Критическим фактором распределенных приложений является их способность модифицироваться в соответствии с числом пользователей, объемом данных и требуемой функциональностью. Приложение должно быть маленьким и быстрым при минимальной потребности в нем, но оно должно обеспечить и дополнительные потребности без ущерба быстродействию или надежности. DCOM предлагает ряд возможностей, улучшающих масштабируемость вашего приложения.
Симметричная многопроцессорная обработка (SMP)
DCOM использует возможность Windows NT поддерживать симметричную многопроцессорную обработку. Для приложений, использующих модель свободных потоков, DCOM организует объединение потоков входящих запросов. На многопроцессорных машинах это объединение потоков оптимизируется в соответствии с числом доступных процессоров: чрезмерно большие потоки приводят к слишком частому переключению между содержимым, в то время как слишком маленькие потоки могут привести к простою некоторых процессоров. DCOM ограждает разработчика от деталей управления потоками и обеспечивает оптимальное быстродействие, что может обеспечить лишь кодирование управления объединением потоков вручную, требующее больших затрат.
Используя поддержку симметричной многопроцессорной обработки Windows NT, DCOM-приложения могут безболезненно масштабироваться от уровня однопроцессорных машин до уровня огромных многопроцессорных систем.
Гибкость в перераспределении
Самые скоростные многопроцессорные машины могут не справиться с удовлетворением потребностей при увеличении загруженности приложения (даже если ваш бюджет выдержит приобретение такой машины). Независимость DCOM от местоположения облегчает осуществление перераспределения компонентов на другие компьютеры, предлагая, тем самым, более легкую и недорогую организацию масштабируемости.
Рис.5 – Параллельное перераспределение
Рис. 6 – Изоляция критических компонентов
Модель программирования DCOM с ее независимостью от местоположения облегчает схемы перераспределения по мере разрастания приложения: первоначально машина сервера может содержать все компоненты, соединяясь с ними как с очень эффективными серверами в процессе. Фактически приложение выглядит как хорошо отлаженное монолитное приложение. По мере увеличения потребностей можно добавить другие машины с перераспределением компонентов на эти машины без всякого изменения кода.
Рис. 7 – Поточный метод
Эволюция функциональности – контроль версий
Кроме масштабируемости при изменении числа пользователей или количества транзакций, приложению необходимо масштабироваться при возникновении необходимости в новых функциях. С течением времени должны внедряться новые задачи, а существующие – модифицироваться. В идеале все клиенты и компоненты должны модифицироваться одновременно, либо старый компонент должен модифицироваться после обновления всех клиентов – серьезная, с трудом решаемая в условиях большой географической дисперсии сайтов или пользователей проблема.
DCOM предоставляет гибкие механизмы эволюции для клиентов и компонентов. СОМ и DCOM позволяют клиенту динамично запрашивать функциональность компонента. Вместо объявления своей функциональности в виде монолитной совокупности методов и возможностей, СОМ-компонент может отвечать различным клиентам по-разному. Клиент, использующий определенную возможность, нуждается только в определенных методах. Клиент может использовать более одной возможности компонента одновременно. Добавление к компоненту новых возможностей никак не влияет на старого, не осведомленного о них клиента.
Поскольку функциональность в DCOM-модели программирования сгруппирована в интерфейсы, вы можете проектировать новые клиентские приложения для работы со старыми серверами, новые серверы – для работы со старыми клиентами или комбинировать эти возможности для удовлетворения ваших запросов. В обычных моделях объектов даже малейшее изменение метода серьезно сказывается на взаимодействии между клиентом и компонентом. Некоторые модели позволяют добавлять новые методы в конец списка методов, но при этом нет возможности безопасной проверки взаимодействия новых методов со старыми компонентами. Рассмотрение этого вопроса в сетевом аспекте вносит еще большие осложнения, ведь обычно кодирование и наличие проводной связи влияет на набор методов и параметров. Добавление или изменение методов и параметров значительно изменяет и сетевой протокол. DCOM устраняет все эти проблемы единственным, изящным, унифицированным решением и для объектной модели, и для сетевого протокола.
Быстродействие
Масштабируемость нельзя назвать серьезным достоинством при изначально неудовлетворительном быстродействии. Всегда приятно осознавать, что более скоростное аппаратное обеспечение может обеспечить вашему приложению следующий шаг в развитии, но ведь нужно подумать и о потребностях на сегодняшнем уровне. Вы считаете, что не все возможности масштабируемости реализуемы? Что делать, если нет удовлетворительного быстродействия поддержки всех языков от COBOL до Ассемблера? Что делать, если компонент, из-за его удаленного местоположения, исключается из работы в процессе в качестве клиента?
Насколько быстр этот механизм RPC? Для определения этого есть различные параметры быстродействия:
Насколько быстр вызов пустого метода?
Насколько быстры реальные вызовы методов, посылающие и возвращающие данные?
Насколько быстра работа по сети?
В Таблице 1 показаны некоторые реальные значения быстродействия для СОМ и DCOM. Вы можете сравнить быстродействие DCOM с другими протоколами.
Первые две колонки представляют вызов пустого метода (пересылка и возврат 4-байтного целого). Последние две колонки можно рассматривать как вызов реальных СОМ-методов (параметры размером 50 байт).
Таблица показывает, что компоненты в процессе имеют высокое быстродействие (строки 1 и 2).
Вызовам пересекающихся процессов (строки 3 и 4) нужно, чтобы параметры заносились в буфер и пересылались в другой процесс. Быстродействие порядка 2000 вызовов в секунду на стандартном desktop-компьютере удовлетворяет большинству требований. Все локальные вызовы ограничиваются скоростью процессора (и в определенной мере доступной памятью) и хорошо масштабируются на многопроцессорных машинах. Удаленные вызовы (строки 5 и 6) ограничиваются параметрами первичной сети и в этих условиях быстродействие DCOM на 35% выше быстродействия TCP/IP (для TCP/IP время вызова по сети составляет 2 мс).
Вскоре Microsoft обнародует значения быстродействия для большинства платформ, что покажет способность DCOM к масштабируемости с учетом числа клиентов и числа процессоров сервера.
Преимущества DCOM в масштабируемости и быстродействии в целом могут быть получены только при использовании хорошо организованного управления объединением потоков и тестовых протоколов (pinging protocols). Большая часть распределенных приложений даже при значительных вложениях не получат приближенно такого же увеличения быстродействия, как при использовании стандартизованных DCOM-протокола и модели программирования.
Полоса пропускания и латентность
Распределенные приложения пользуются преимуществами сети, связывая компоненты. DCOM полностью скрывает тот факт, что компоненты работают на разных компьютерах. Однако на практике приложения вынуждены учитывать два параметра сетевого соединения:
Полоса пропускания: размер параметров вызова метода постоянно влияет на время, которое требуется для выполнения вызова.
Латентность: физическое расстояние и число задействованных элементов сети (таких как маршрутизаторы и линии коммуникаций) значительно влияют на задержку даже маленьких пакетов данных. В случае глобальной сети, такой как Интернет, эта задержка может измеряться секундами.
Распределенное управление соединением между протоколами
Многие протоколы нуждаются в постоянном управлении. Компонентам нужно знать, что на машине клиента возникла серьезная авария аппаратного обеспечения или сетевое соединение между клиентом и компонентом прервалось на длительное время.
Общим решением этой проблемы является постоянная пересылка сообщений с определенной периодичностью (pinging). Если сервер не получает сообщения в течение определенного времени, это значит, что связи с клиентом нет.
DCOM использует такие сообщения для каждой из машин. Даже если машина клиента использует 100 компонентов с машины сервера, единственное тестовое сообщение поддерживает связь всех клиентов. В дополнение к использованию тестовых сообщений, DCOM минимизирует размер этих тестовых сообщений путем посылки разницы между ними (delta-pinging). Вместо посылки 100 идентификаторов клиентов создается мета-идентификатор, представляющий все 100 ссылок. При изменении набора ссылок пересылается только разница между двумя последовательными наборами ссылок. И, наконец, DCOM накладывает тестовое сообщение на обычные пересылаемые сообщения. Только в случае, если машина клиента простаивает по отношению к машине сервера, с 2-минутным интервалом пересылаются сами тестовые сообщения (рис.9).
DCOM позволяет различным приложениям (даже из различных источников) использовать единое, оптимизированное, постоянное управление и протокол определения аварий сети, незначительно уменьшая полосу пропускания. Если на сервере работает 100 разных приложений с сотней различных пользовательских протоколов, этот сервер должен принять по одному тестовому сообщению для каждого из приложений, от каждого из подключенных клиентов. Загрузка сети в целом может быть уменьшена только в случае, если эти протоколы некоторым образом координируют свою тестовую стратегию. DCOM автоматически предоставляет такое координирование среди пользовательских COM-протоколов.
Оптимизация сетевого обмена
Общей проблемой при разработке распределенных приложений является интенсивный сетевой обмен между компонентами различных машин. В Интернет каждый из таких сетевых обменов вызывает задержку в 1 секунду, а чаще – значительно большую. Даже в случае быстрой локальной сети время обмена измеряется в миллисекундах – достаточно много для таких масштабов.
Общим способом уменьшения интенсивности сетевого обмена является “увязывание” многочисленных вызовов методов в единственный запрос метода (пакетирование или упаковка). DCOM использует этот способ для таких задач, как подключение к объекту или создание нового объекта и запрос его функциональности. Недостатком такого способа для большинства компонентов является то, что модель программирования сильно отличается в локальном и удаленном случаях.
Пример. Компонент базы данных предусматривает метод перечисления результатов запроса по одной или более строк за один раз. В локальном случае разработчик может просто использовать этот метод для последовательного добавления строк к окну списка. В удаленном случае это решение приводит к сетевому обмену при перечислении каждой строки. При использовании метода со способом пакетирования разработчику необходимо локализовать достаточно большой буфер для того, чтобы все строки хранились в очередности и пересылались одним вызовом с последующим поочередным добавлением к окну. Поскольку при этом модель программирования значительно изменяется, то, чтобы приложение работало эффективно и в распределенном окружении, разработчик должен пойти на некоторые компромиссы в конструировании..
DCOM облегчает дизайнерам компонентов выполнение подобного пакетирования без того, чтобы клиентам нужно было использовать API пакетирования. Механизм маршалинга DCOM позволяет компоненту передавать код, называемый “заместителем объекта” (proxy object) и позволяющий перехватывать многочисленные вызовы методов и упаковывать их в единственный вызов удаленной процедуры клиенту:
Пример. Разработчик из предыдущего примера продолжает перечислять методы один за другим, поскольку это способ, который необходим логике приложения. (Это нужно списку API). Однако, первый вызов для начала перечисления пересылается в заместитель объекта, определенный приложением, который вызывает все строки (или набор строк) и кэширует их в объект-заместитель. Затем последующие вызовы исходят из этого кэша без дополнительных сетевых обменов. Разработчик продолжает работать с простой моделью программирования, хотя в целом приложение уже оптимизировано (рис.10).
Рис. 10 – Компонентная модель: кэширование со стороны клиента
Кроме того, DCOM позволяет выполнять эффективную переадресацию с одного компонента на другой. Если компонент содержит ссылку на другой компонент второй машины, он может передать эту ссылку клиенту, работающему на третьей машине (ссылка клиента на другой компонент, работающий на другой машине). Когда клиент использует эту ссылку, он напрямую соединяется со вторым компонентом. DCOM стыкует эти ссылки и позволяет оригиналу компонента и машине выйти из этой схемы взаимодействия. Это предоставляет пользователю сервисы директорий, позволяющие возвращать ссылки на широкий диапазон удаленных компонентов.
Пример 1. Приложение “шахматы” позволяет игрокам, ищущим партнера, регистрироваться в сервисе каталога шахмат. Другие игроки могут запросить этот список или встать в очередь. При выборе игроком партнера сервис каталога шахмат возвращает ссылку на компонент клиента партнера. DCOM автоматически соединяет двух игроков; в дальнейших транзакциях сервис каталога более не участвует.
Пример 2. Компонент “Брокер” имеет соединение с 20 машинами с серверами, на которых работают идентичные компоненты. Происходит постоянная проверка загрузки серверов и определение того, изменилось ли количество серверов. Когда клиент нуждается в компоненте, он подключается к компоненту “брокер”, который возвращает ссылку на компонент сервера с минимальной загрузкой. DCOM автоматически соединяет клиента с сервером; после этого компонент “брокер” выпадает из схемы взаимодействия.
Рис. 11 – Переадресация
Если необходимо, DCOM даже позволяет компонентам включаться в произвольные пользовательские протоколы, использование которых подразумевает работу вне механизма DCOM. Компонент может использовать пользовательский маршалинг для пересылки заместителя объекта в процесс клиента, который в дальнейшем может использовать любой произвольный протокол для общения с компонентом.
Пример 1. Компонент со стороны сервера может использовать ODBC-соединение для работы с базой данных SQL-сервера. При обращении клиента к этому объекту, прямая связь между машиной клиента и SQL-сервером базы данных (с использованием ODBC) может оказаться более эффективной, нежели использование DCOM для связи с машиной сервера, которая работает с SQL-сервером базы данных. Используя пользовательский маршалинг DCOM, компонент базы данных может первоначально скопироваться на машину клиента и подключиться к SQL-серверу даже без уведомления клиента, что тот подключен не к компоненту базы данных сервера, а к локальной копии компонента той же базы данных.
Пример 2. Торговой системе необходимо наличие двух типов коммуникационных механизмов: безопасного канала с аутентификацией от клиента до центральной системы, который используется для размещения и удаления объектов, и канала распространения, который пересылает информацию о заказах одновременно всем подключенным клиентам. В то время, как канал клиент/сервер эффективно и легко организуется современным безопасным и синхронизированным DCOM-соединением, канал оповещения для обеспечения распределения информации между многими слушателями требует более сложного механизма. DCOM позволяет безболезненно встроить такой пользовательский протокол (“надежное оповещение”) в архитектуру приложения: компонент приемника данных может инкапсулировать этот протокол и сделать его полностью прозрачным как для клиента, так и для сервера. Для небольших систем с малым количеством пользователей могут использоваться стандартные протоколы DCOM “точка-точка “(point-to-point), в то время как сайты с большим числом пользователей должны все-таки использовать усложненный протокол оповещения пользователей. Если DCOM предложит подобный стандартизованный транспортный механизм в будущем, приложение сможет безболезненно перейти к новому протоколу.
Рис. 12 – Замена DCOM пользовательскими протоколами
DCOM предоставляет множество способов совместить реальный сетевой протокол с сетевым траффиком без изменения взаимодействия клиента с компонентом: кэширование со стороны клиента, переадресация ссылок и замена сетевого транспорта при необходимости – лишь часть возможных способов.
Безопасность
При отсутствии поддержки безопасности со стороны разработанной распределенной платформы, каждое приложение должно было бы применять свои механизмы обеспечения безопасности. Обычный механизм использует запрос имени пользователя и пароля – обычно зашифрованного. Приложение сопоставляет эти идентификаторы с каталогом или базой данных пользователя и возвращает некоторый динамичный идентификатор, используемый для будущих вызовов метода. При всех последующих вызовах метода безопасности клиенты должны будут пройти этот идентификатор безопасности. Каждое приложение должно уметь хранить список имен пользователей и паролей, управлять им, защищать каталог пользователя от несанкционированного доступа и управлять изменением паролей, а также обеспечивать надежность при таком действии, как пересылка паролей по сети.
Распределенная платформа должна предусматривать наличие framework, отвечающего за безопасность для того, чтобы была обеспечена возможность различать отдельных клиентов и отдельные группы клиентов. Тогда система или приложение будут иметь возможность определять, кто пытается начать работать с компонентом. DCOM использует framework повышенной безопасности, предлагаемый Windows NT. Windows NT предусматривает серьезный набор встроенных провайдеров безопасности, поддерживающий многочисленные механизмы идентификации и аутентификации, от традиционных моделей доменов доверия (trusted-domain) до нецентрализованно управляемых, хорошо масштабируемых механизмов безопасности. Центральной частью framework, отвечающего за безопасность, является каталог пользователя, который содержит информацию, необходимую для подтверждения прав пользователя (имя пользователя, пароль). Большинство DCOM-реализаций на отличных от Windows NT платформах предусматривают такой же или подобный механизм, какой бы провайдер безопасности ни был доступен для данной платформы. Большая часть UNIX-реализаций DCOM будут включать Windows NT-совместимый провайдер безопасности.
Перед тем, как ближе ознакомиться с Windows NT-провайдерами каталогов и безопасности, давайте обсудим, как DCOM использует этот общий framework безопасности для облегчения создания защищенных приложений.
Конфигурирование безопасности
DCOM может обеспечить безопасность распределенному приложению без встраивания специализированного кодирования безопасности в клиент или компонент. Модель программирования DCOM скрывает потребность в безопасности со стороны компонента точно так же, как скрывает и его местонахождение. Тот же двоичный код, который работает на одной машине, где безопасность – не главное требование, может использоваться и в распределенном приложении с обеспечением защищенности.
DCOM достигает подобной прозрачности в безопасности, позволяя разработчикам и администраторам конфигурировать установки защищенности для каждого компонента. Точно так же, как файловая система Windows NT позволяет администратору установить списки управления доступом (ACL) для файлов и каталогов, DCOM содержит списки управления доступом для компонентов. Эти списки показывают, какие пользователи или группы пользователей имеют право доступа к компонентам определенного класса. Эти списки могут легко конфигурироваться инструментом конфигурирования DCOM (DCOMCNFG) или программироваться с помощью реестра Windows NT и функций обеспечения безопасности Win32.
Когда бы клиент ни вызвал метод или создал пример компонента, DCOM получает текущее пользовательское имя клиента, связанного с текущим процессом (на самом деле – текущий исполняемый поток). Windows NT гарантирует, что данный пользовательский идентификатор аутентичен. После этого DCOM передает имя пользователя машине или процессу, где работает этот компонент. На машине компонента DCOM снова проверяет имя пользователя, используя аутентификационный механизм, и проверяет список управления доступом для данного компонента (на самом деле — для первого компонента, работающего в процессе, содержащего интересующий компонент. Более детально это описано в Белых Страницах “Архитектура DCOM”.) Если имя клиента не включено в этот список (прямо или косвенно – в качестве члена группы пользователей), DCOM просто отклоняет этот вызов еще до того, как компонент вовлекся в работу. Этот обычный механизм безопасности полностью прозрачен как для клиента, так и для компонента и оптимизирован. Он базируется на framework безопасности Windows NT, который является наиболее интенсивно используемой (и оптимизированной!) частью операционной системы Windows NT: при каждом доступе к файлу или даже к такому примитиву синхронизации потоков, как сигнализация или событие, Windows NT выполняет идентичную проверку доступа. Тот факт, что Windows NT по-прежнему может неплохо конкурировать в быстродействии с другими операционными системами и сетевыми операционными системами, показывает, насколько эффективен этот механизм безопасности (рис.13).
Рисунок 13 – Конфигурирование безопасности
DCOM предлагает чрезвычайно эффективный механизм обеспечения безопасности, который позволяет разработчику создавать распределенные приложения, не опасаясь за его защищенность. Любой провайдер безопасности, поддерживаемый Windows NT, может использоваться механизмом безопасности DCOM.