Технология Клиент-Сервер 1998'1

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

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

Распределенный СОМ Microsoft (DCOM) развивает многокомпонентную модель (СОМ) до уровня поддержки связи между объектами различных компьютеров - по ЛВС, ГВС или даже Интернет. Исполнение вашего приложения при помощи DCOM может быть распределено по местам, наиболее удобным для пользователя.

DCOM — это последовательное развитие СОМ, а значит, ваши инвестиции в создание СОМ-приложений, компонентов, инструментария плавно переносятся в сферу стандартизованных распределенных решений.

DCOM возьмет на себя низкоуровневые детали сетевых протоколов, а вы сможете сфокусироваться на вашем настоящем деле: создании хороших решений для пользователей.

Почему я должен прочесть эту статью?

Если вы CIO, архитектор решений или разработчик приложений, который хочет создавать качественные приложения, работающие одинаково хорошо на интранет, Интернет и т.д., DCOM может вам помочь. Этот материал содержит общий обзор возможности использования DCOM для решения сложнейших проблем, связанных с распределенными приложениями. Ваши приложения когда-нибудь нуждались (или будут нуждаться) в:

Ниже будет описано, каким образом DCOM поможет вам решить эти и другие проблемы для новых или уже существующих приложений.

Как следует читать эти страницы?

Эти Белые Страницы являются первыми в серии, посвященной СОМ и DCOM. Здесь предложено объяснение дизайнерских решений, которые предлагаются DCOM:

Начав с этого материала, вам следует обратиться к другим страницам серии для более подробного ознакомления по определенным вопросам.

Если вы хотите узнать, как использовать DCOM в определенных приложениях и решениях, обратитесь к материалу Microsoft “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).

Для чего создаются распределенные приложения?

Распределение приложений - это не самоцель. Распределенные приложения предоставляют вам абсолютно новые решения в проектировании и развитии. Для того, чтобы получить эти дополнительные возможности, необходимо сделать значительные вложения. Некоторые приложения являются распределенными изначально: многопользовательские игры, приложения для обмена мнениями, для телеконференций - все это примеры подобных приложений. Для них преимущества устойчивой инфраструктуры очевидны. Многие другие приложения также являются распределенными в том смысле, что они имеют как минимум два компонента, работающие на различных машинах. Но, поскольку эти приложения не были созданы для использования в распределенной среде, они достаточно ограничены в масштабируемости и в гибкости перераспределения. Любой тип поточных или групповых приложений, большинство приложений клиент/сервер и даже некоторые desktop-приложения обязательно управляют способом коммуникаций и кооперации своих пользователей. Рассмотрение таких приложений в качестве распределенных и работа с нужным компонентом в нужном месте предоставляют пользователю преимущества и оптимизируют использование сетевых и компьютерных ресурсов. Приложения, которые разрабатывались как распределенные, могут совмещать различных клиентов с различными мощностями посредством работы компонента со стороны клиента, если это возможно, и - со стороны сервера, когда это необходимо.

Разработка распределенных приложений дает системному менеджеру большое преимущество в виде гибкости в перераспределении.

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

Архитектура DCOM

DCOM является развитием многокомпонентной модели (СОМ). СОМ определяет, каким образом компоненты взаимодействуют со своими клиентами. Это взаимодействие осуществляется таким образом, чтобы клиент и компонент могли соединяться без необходимости использовать некоторый промежуточный компонент системы и клиент мог вызывать методы компонента. Рисунок 1 иллюстрирует это с точки зрения многокомпонентной модели.

1.gif (1728 bytes)

Рис. 1 – COM-компоненты в одном процессе

В сегодняшних операционных системах процессы изолированы друг от друга. Клиент, которому нужно связаться с компонентом другого объекта, не может вызвать компонент напрямую, а должен использовать некоторую форму связи между процессами, предусмотренную операционной системой. СОМ организует подобное соединение в полностью прозрачной манере: он перехватывает вызовы со стороны клиента и адресует их компоненту другого процесса. Рис. 2 показывает, как run-time библиотеки COM/DCOM организуют соединение между клиентом и компонентом.

2.gif (2987 bytes)

Рис. 2 – COM-компоненты в разных процессах

Когда клиент и компонент находятся на различных машинах, DCOM просто заменяет локальное соединение между процессами сетевым протоколом. При этом ни клиент, ни компонент и не подозревают, что провода, соединяющие их, стали чуть длиннее.

Рис. 3 показывает архитектуру DCOM в общем: СОМ run-time предлагает клиентам и компонентам объектно-ориентированные сервисы и использует RPC и провайдер безопасности для генерации стандартных сетевых пакетов, соответствующих стандарту протокола DCOM.

3.gif (4437 bytes)

Рис. 3 – DCOM: COM-компоненты на различных машинах

Компоненты и их повторное использование

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

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

Независимость от местоположения

Когда вы начинаете использовать распределенное приложение в реальной сети, выявляется несколько особенностей:

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

Независимость DCOM от местоположения значительно упрощает задачу распределения компонентов приложения для получения оптимального быстродействия в целом. Представим, например, что определенные компоненты должны находиться на определенных машинах или в определенных местах. Если приложение имеет большое число маленьких компонентов, вы можете уменьшить загрузку сети перемещением их в нужный сегмент ЛВС, на нужную машину или даже в нужный процесс. Если приложение состоит из меньшего числа больших компонентов, загрузка сети - меньшая из проблем, так как вы можете разместить компоненты на более быстрые из доступных машин.

Рис. 4 демонстрирует, как один и тот же компонент может быть перенесен на машину клиента при удовлетворительной полосе пропускания между машиной “клиент” и машиной “среднего слоя”, и на машине сервера, если клиент работает с приложением по медленному сетевому соединению.

4.gif (6066 bytes)

Рис. 4 – Независимость от местоположения

Благодаря независимости DCOM от местоположения, приложение может перемещать взаимодействующие компоненты с “близлежащих” машин на одну и ту же машину или даже в один процесс. Даже если функциональность большого логического модуля организуется большим числом маленьких компонентов, они могут по-прежнему эффективно взаимодействовать друг с другом. Компоненты могут работать на машине, на которой это наиболее целесообразно: пользовательский интерфейс находится на машине клиента или “рядом” с ней. Компонент, работающий с базой данных, – на сервере “близко” к базе данных.

Независимость от языка

Общим вопросом при проектировании и разработке распределенного приложения является выбор языка или инструмента для данного компонента. Язык обычно выбирают с учетом затрат на разработку, с учетом имеющейся квалификации и необходимого быстродействия. Как развитие СОМ, DCOM абсолютно не зависит от языка. Теоретически для создания СОМ-компонентов может использоваться любой язык и эти компоненты могут использоваться большим числом языков и инструментов. Java, Microsoft Visual C++, Microsoft Visual Basic, Delphi, PowerBuilder и Micro Focus COBOL - все они хорошо взаимодействуют с DCOM.

Нейтральность DCOM по отношению к языку позволяет разработчику приложения выбирать язык и инструменты, с которыми он чувствует себя наиболее свободно. Независимость от языка, кроме того, позволяет выполнять быстрое прототипирование: вначале компоненты могут быть разработаны на языке высокого уровня, таком как Microsoft Visual Basic, а позже - на другом языке, таком как C++ или Java, лучше использующем преимущества таких продвинутых функций DCOM, как многопоточность и объединение потоков.

Управление соединением

Сетевые соединения не так устойчивы, как соединения внутри машины. Компоненты распределенного приложения должны знать, что клиент более не активен, даже – или в особенности – в случае сетевой или аппаратной аварии.

DCOM управляет соединением компонентов, предназначенных для одного клиента, так же, как и компонентов, обслуживающих несколько клиентов, используя счетчик ссылок для каждого компонента. Когда клиент соединяется с компонентом, DCOM увеличивает значение счетчика ссылок компонента. Когда клиент разрывает соединение, DCOM уменьшает значение счетчика ссылок компонента. Если значение счетчика достигает нуля – компонент свободен.

Для определения активности клиента DCOM использует эффективный протокол отслеживания (см. раздел 0 “Управление распределенным соединением между приложениями”). Машина клиента посылает периодическое сообщение. При нарушении соединения DCOM уменьшает счетчик и освобождает компонент, если значение счетчика станет равным нулю. С точки зрения компонента, случай отключения клиента, случай аварии сети и случай поломки машины клиента регистрируются одним и тем же механизмом подсчета. Приложения могут использовать такой механизм подсчета соединений для своего высвобождения.

Во многих случаях поток информации между компонентом и его клиентами не однонаправлен: компоненту нужно инициировать некоторые действия со стороны клиента, например, извещение о том, что длительный процесс завершился, обновляются данные, просматриваемые пользователем (обзор новостей), или поступило следующее сообщение в телеконференции или многопользовательской игре. Многие протоколы усложняют процесс осуществления такого типа симметричной связи. В DCOM каждый компонент может быть одновременно провайдером и потребителем функциональности. Один и тот же механизм, одни и те же возможности управляют связью в обоих направлениях, облегчая организацию связи и взаимодействия клиент/сервер.

DCOM предлагает устойчивый распределенный механизм регистрации соединений, который полностью прозрачен для приложения. DCOM - это одновременно симметричный сетевой протокол и модель программирования, предлагающие не только традиционное взаимодействие клиент/сервер, но и полноценную связь между клиентами и серверами.

Масштабируемость

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

Симметричная многопроцессорная обработка (SMP)

DCOM использует возможность Windows NT поддерживать симметричную многопроцессорную обработку. Для приложений, использующих модель свободных потоков, DCOM организует объединение потоков входящих запросов. На многопроцессорных машинах это объединение потоков оптимизируется в соответствии с числом доступных процессоров: чрезмерно большие потоки приводят к слишком частому переключению между содержимым, в то время как слишком маленькие потоки могут привести к простою некоторых процессоров. DCOM ограждает разработчика от деталей управления потоками и обеспечивает оптимальное быстродействие, что может обеспечить лишь кодирование управления объединением потоков вручную, требующее больших затрат.

Используя поддержку симметричной многопроцессорной обработки Windows NT, DCOM-приложения могут безболезненно масштабироваться от уровня однопроцессорных машин до уровня огромных многопроцессорных систем.

Гибкость в перераспределении

Самые скоростные многопроцессорные машины могут не справиться с удовлетворением потребностей при увеличении загруженности приложения (даже если ваш бюджет выдержит приобретение такой машины). Независимость DCOM от местоположения облегчает осуществление перераспределения компонентов на другие компьютеры, предлагая, тем самым, более легкую и недорогую организацию масштабируемости.

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

5.gif (4678 bytes)

Рис.5 – Параллельное перераспределение

Пример. Организация, офисы которой расположены в Нью-Йорке, Лондоне, Сан-Франциско и Сиднее (Австралия) может установить компоненты на свои серверы. Двести пользователей одновременно получают доступ к 50 компонентам сервера с определенным быстродействием. По мере поставки пользователям новых бизнес-приложений и приложений, частично использующих уже имеющиеся бизнес-компоненты, а частично - новые, нагрузка на сервер увеличивается до 600 пользователей и скорость работы в пиковые часы становится неприемлемой. Администратор добавляет второй сервер и перераспределяет 30 компонентов, размещая их только на новой машине. Двадцать компонентов остаются только на старом сервере, а оставшиеся 20 работают на обеих машинах.

Большая часть реальных распределенных приложений имеют один или более критический компонент, который участвует в большинстве операций. Это могут быть компоненты базы данных или компоненты, связанные с бизнесом, доступ к которым должен осуществляться постоянно для реализации политики “первым пришел - первым обслужен”. Компоненты такого типа не могут дублироваться, поскольку их предназначение заключается в организации единственной точки синхронизации среди всех пользователей приложения. Для увеличения быстродействия распределенного приложения в целом такие компоненты, создающие “узкие места”, должны перераспределяться на специально выделенный мощный сервер. DCOM помогает вам изолировать такие критические компоненты на ранних этапах проектирования, размещать первоначально компоненты на одной машине, а позже - переносить критические компоненты на отдельные машины.

6.gif (7691 bytes)

Рис. 6 – Изоляция критических компонентов

Для таких критических компонентов DCOM в целом может организовать более быстрое выполнение задачи. Подобные компоненты - это обычно часть последовательности процесса организации в электронной торговой системе заказов на покупку или продажу: запросы должны обрабатываться по мере поступления (первым пришел – первым обслужен). Одно из решений заключается в разделении задачи на меньшие компоненты с перераспределением каждого компонента на отдельную машину. Результат этого подобен поточному методу (pipelining), используемому в современных микропроцессорах: первый запрос обрабатывается первым компонентом (например, выполняющим проверку содержимого) и передается на следующий компонент (который, например, выполняет обновление базы данных). Как только первый компонент передал запрос на следующий, он готов обработать следующий запрос. Фактически, две машины параллельно обрабатывают множество запросов в определенном порядке их поступления. То же самое возможно выполнять и на одной машине (при использовании DCOM): многочисленные компоненты могут выполняться в различных потоках или процессах. В дальнейшем, когда потоки смогут быть распределены на одной многопроцессорной машине или на различные машины, этот подход облегчит масштабируемость.

Модель программирования DCOM с ее независимостью от местоположения облегчает схемы перераспределения по мере разрастания приложения: первоначально машина сервера может содержать все компоненты, соединяясь с ними как с очень эффективными серверами в процессе. Фактически приложение выглядит как хорошо отлаженное монолитное приложение. По мере увеличения потребностей можно добавить другие машины с перераспределением компонентов на эти машины без всякого изменения кода.

7.gif (3892 bytes)

Рис. 7 – Поточный метод

Эволюция функциональности – контроль версий

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

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

При такой структуризации компонента появляется новый тип развития: изначально компонент объявляет основной набор возможностей COM-интерфейса, к которым может получить доступ любой клиент. После приобретения компонентом новых возможностей, большая часть этих интерфейсов (а чаще - все) будет по-прежнему необходима; новые же функции и возможности появятся в дополнительных интерфейсах без изменения первоначальных интерфейсов. Старые клиенты так же имеют доступ к основному набору интерфейсов, как если бы ничего и не менялось. Новые клиенты могут проверить наличие новых интерфейсов и использовать их, если они есть; если же их нет - клиент может корректно деградировать до набора старых интерфейсов.

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

8.gif (3086 bytes)

Рис. 8 - Устойчивый контроль версий

Быстродействие

Масштабируемость нельзя назвать серьезным достоинством при изначально неудовлетворительном быстродействии. Всегда приятно осознавать, что более скоростное аппаратное обеспечение может обеспечить вашему приложению следующий шаг в развитии, но ведь нужно подумать и о потребностях на сегодняшнем уровне. Вы считаете, что не все возможности масштабируемости реализуемы? Что делать, если нет удовлетворительного быстродействия поддержки всех языков от COBOL до Ассемблера? Что делать, если компонент, из-за его удаленного местоположения, исключается из работы в процессе в качестве клиента?

В СОМ и DCOM клиент никогда не видит сам объект сервера, но клиент никогда и не отделяется от сервера системным компонентом до тех пор, пока это абсолютно необходимо. Такая прозрачность достигается поразительно просто: единственный способ, которым клиент может общаться с компонентом - это посредством методов последнего. Клиент получает адреса этих методов из таблицы адресов методов (vtable). Чтобы вызвать метод компонента, клиент получает адрес метода и вызывает его. Только преимущества программирования в СОМ по сравнению с традиционной функцией вызова C или Ассемблера позволяют легко находить адрес метода (косвенный вызов функции вместо прямого вызова функции). Если компонент является компонентом в процессе, работающим в том же потоке, что и клиент, вызов метода адресуется компоненту напрямую. При этом не добавляется никакого СОМ- или системного кода; СОМ лишь определяет стандарт таблицы адресов методов.

Что случается, когда клиент и компонент в действительности расположены не так близко - в различных потоках, процессах или на машинах, далеко отстоящих друг от друга? СОМ размещает код своего вызова удаленной процедуры (RPC) в таблице адресов методов и затем, упаковывая каждый вызов метода в стандартное представление, посылает его клиенту; затем происходит его распаковка и восстановление оригинального вызова метода: СОМ предлагает объектно-ориентированный механизм вызова удаленной процедуры.

Насколько быстр этот механизм RPC? Для определения этого есть различные параметры быстродействия:

В Таблице 1 показаны некоторые реальные значения быстродействия для СОМ и DCOM. Вы можете сравнить быстродействие DCOM с другими протоколами.

Первые две колонки представляют вызов пустого метода (пересылка и возврат 4-байтного целого). Последние две колонки можно рассматривать как вызов реальных СОМ-методов (параметры размером 50 байт).

Таблица показывает, что компоненты в процессе имеют высокое быстродействие (строки 1 и 2).

Вызовам пересекающихся процессов (строки 3 и 4) нужно, чтобы параметры заносились в буфер и пересылались в другой процесс. Быстродействие порядка 2000 вызовов в секунду на стандартном desktop-компьютере удовлетворяет большинству требований. Все локальные вызовы ограничиваются скоростью процессора (и в определенной мере доступной памятью) и хорошо масштабируются на многопроцессорных машинах. Удаленные вызовы (строки 5 и 6) ограничиваются параметрами первичной сети и в этих условиях быстродействие DCOM на 35% выше быстродействия TCP/IP (для TCP/IP время вызова по сети составляет 2 мс).

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

Эти неофициальные, но повторяемые значения быстродействия показывают 35-процентное превышение быстродействия DCOM над TCP/IP для “пустых” вызовов. Это соотношение уменьшается при реальной работе сервера. Если серверу нужна 1 мс, например, для обновления базы данных, то соотношение уменьшается до 23 % и до 17 % - если серверу необходимо 2 мс.

Преимущества DCOM в масштабируемости и быстродействии в целом могут быть получены только при использовании хорошо организованного управления объединением потоков и тестовых протоколов (pinging protocols). Большая часть распределенных приложений даже при значительных вложениях не получат приближенно такого же увеличения быстродействия, как при использовании стандартизованных DCOM-протокола и модели программирования.

Полоса пропускания и латентность

Распределенные приложения пользуются преимуществами сети, связывая компоненты. DCOM полностью скрывает тот факт, что компоненты работают на разных компьютерах. Однако на практике приложения вынуждены учитывать два параметра сетевого соединения:

Как DCOM помогает приложению работать при таких ограничениях? DCOM минимизирует передачу данных по сети там, где это возможно для того, чтобы уменьшить латентность сети. Наиболее предпочтительный транспортный протокол для DCOM - это UDP-набор протокола TCP/IP без функции соединения: природа этого протокола позволяет выполнить определенную оптимизацию посредством слияния многих низкоуровневых пакетов с данными и тестовыми сообщениями. Даже при работе с протоколами, ориентированными на соединение, DCOM продолжает предоставлять значительные преимущества по сравнению с пользовательскими протоколами приложений.

Распределенное управление соединением между протоколами

Многие протоколы нуждаются в постоянном управлении. Компонентам нужно знать, что на машине клиента возникла серьезная авария аппаратного обеспечения или сетевое соединение между клиентом и компонентом прервалось на длительное время.

Общим решением этой проблемы является постоянная пересылка сообщений с определенной периодичностью (pinging). Если сервер не получает сообщения в течение определенного времени, это значит, что связи с клиентом нет.

DCOM использует такие сообщения для каждой из машин. Даже если машина клиента использует 100 компонентов с машины сервера, единственное тестовое сообщение поддерживает связь всех клиентов. В дополнение к использованию тестовых сообщений, DCOM минимизирует размер этих тестовых сообщений путем посылки разницы между ними (delta-pinging). Вместо посылки 100 идентификаторов клиентов создается мета-идентификатор, представляющий все 100 ссылок. При изменении набора ссылок пересылается только разница между двумя последовательными наборами ссылок. И, наконец, DCOM накладывает тестовое сообщение на обычные пересылаемые сообщения. Только в случае, если машина клиента простаивает по отношению к машине сервера, с 2-минутным интервалом пересылаются сами тестовые сообщения (рис.9).

DCOM позволяет различным приложениям (даже из различных источников) использовать единое, оптимизированное, постоянное управление и протокол определения аварий сети, незначительно уменьшая полосу пропускания. Если на сервере работает 100 разных приложений с сотней различных пользовательских протоколов, этот сервер должен принять по одному тестовому сообщению для каждого из приложений, от каждого из подключенных клиентов. Загрузка сети в целом может быть уменьшена только в случае, если эти протоколы некоторым образом координируют свою тестовую стратегию. DCOM автоматически предоставляет такое координирование среди пользовательских COM-протоколов.

9.gif (8000 bytes)

Рисунок 9 - Совмещенное постоянное управление

Оптимизация сетевого обмена

Общей проблемой при разработке распределенных приложений является интенсивный сетевой обмен между компонентами различных машин. В Интернет каждый из таких сетевых обменов вызывает задержку в 1 секунду, а чаще – значительно большую. Даже в случае быстрой локальной сети время обмена измеряется в миллисекундах – достаточно много для таких масштабов.

Общим способом уменьшения интенсивности сетевого обмена является “увязывание” многочисленных вызовов методов в единственный запрос метода (пакетирование или упаковка). DCOM использует этот способ для таких задач, как подключение к объекту или создание нового объекта и запрос его функциональности. Недостатком такого способа для большинства компонентов является то, что модель программирования сильно отличается в локальном и удаленном случаях.

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

DCOM облегчает дизайнерам компонентов выполнение подобного пакетирования без того, чтобы клиентам нужно было использовать API пакетирования. Механизм маршалинга DCOM позволяет компоненту передавать код, называемый “заместителем объекта” (proxy object) и позволяющий перехватывать многочисленные вызовы методов и упаковывать их в единственный вызов удаленной процедуры клиенту:

Пример. Разработчик из предыдущего примера продолжает перечислять методы один за другим, поскольку это способ, который необходим логике приложения. (Это нужно списку API). Однако, первый вызов для начала перечисления пересылается в заместитель объекта, определенный приложением, который вызывает все строки (или набор строк) и кэширует их в объект-заместитель. Затем последующие вызовы исходят из этого кэша без дополнительных сетевых обменов. Разработчик продолжает работать с простой моделью программирования, хотя в целом приложение уже оптимизировано (рис.10).

10.gif (4413 bytes)

Рис. 10 – Компонентная модель: кэширование со стороны клиента

Кроме того, DCOM позволяет выполнять эффективную переадресацию с одного компонента на другой. Если компонент содержит ссылку на другой компонент второй машины, он может передать эту ссылку клиенту, работающему на третьей машине (ссылка клиента на другой компонент, работающий на другой машине). Когда клиент использует эту ссылку, он напрямую соединяется со вторым компонентом. DCOM стыкует эти ссылки и позволяет оригиналу компонента и машине выйти из этой схемы взаимодействия. Это предоставляет пользователю сервисы директорий, позволяющие возвращать ссылки на широкий диапазон удаленных компонентов.

Пример 1. Приложение “шахматы” позволяет игрокам, ищущим партнера, регистрироваться в сервисе каталога шахмат. Другие игроки могут запросить этот список или встать в очередь. При выборе игроком партнера сервис каталога шахмат возвращает ссылку на компонент клиента партнера. DCOM автоматически соединяет двух игроков; в дальнейших транзакциях сервис каталога более не участвует.

Пример 2. Компонент “Брокер” имеет соединение с 20 машинами с серверами, на которых работают идентичные компоненты. Происходит постоянная проверка загрузки серверов и определение того, изменилось ли количество серверов. Когда клиент нуждается в компоненте, он подключается к компоненту “брокер”, который возвращает ссылку на компонент сервера с минимальной загрузкой. DCOM автоматически соединяет клиента с сервером; после этого компонент “брокер” выпадает из схемы взаимодействия.

11.gif (5943 bytes)

Рис. 11 – Переадресация

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

Пример 1. Компонент со стороны сервера может использовать ODBC-соединение для работы с базой данных SQL-сервера. При обращении клиента к этому объекту, прямая связь между машиной клиента и SQL-сервером базы данных (с использованием ODBC) может оказаться более эффективной, нежели использование DCOM для связи с машиной сервера, которая работает с SQL-сервером базы данных. Используя пользовательский маршалинг DCOM, компонент базы данных может первоначально скопироваться на машину клиента и подключиться к SQL-серверу даже без уведомления клиента, что тот подключен не к компоненту базы данных сервера, а к локальной копии компонента той же базы данных.

Пример 2. Торговой системе необходимо наличие двух типов коммуникационных механизмов: безопасного канала с аутентификацией от клиента до центральной системы, который используется для размещения и удаления объектов, и канала распространения, который пересылает информацию о заказах одновременно всем подключенным клиентам. В то время, как канал клиент/сервер эффективно и легко организуется современным безопасным и синхронизированным DCOM-соединением, канал оповещения для обеспечения распределения информации между многими слушателями требует более сложного механизма. DCOM позволяет безболезненно встроить такой пользовательский протокол (“надежное оповещение”) в архитектуру приложения: компонент приемника данных может инкапсулировать этот протокол и сделать его полностью прозрачным как для клиента, так и для сервера. Для небольших систем с малым количеством пользователей могут использоваться стандартные протоколы DCOM “точка-точка “(point-to-point), в то время как сайты с большим числом пользователей должны все-таки использовать усложненный протокол оповещения пользователей. Если DCOM предложит подобный стандартизованный транспортный механизм в будущем, приложение сможет безболезненно перейти к новому протоколу.

12.gif (4751 bytes)

Рис. 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.gif (7510 bytes)

Рисунок 13 – Конфигурирование безопасности

DCOM предлагает чрезвычайно эффективный механизм обеспечения безопасности, который позволяет разработчику создавать распределенные приложения, не опасаясь за его защищенность. Любой провайдер безопасности, поддерживаемый Windows NT, может использоваться механизмом безопасности DCOM.

по материалам Microsoft

Copyright © 1994-2016 ООО "К-Пресс"