Файл: Технология построения распределенных информационных систем (Преимущества и недостатки использования распределённых информационных систем).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 19.06.2023

Просмотров: 146

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Рисунок 12

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

Рисунок 13

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

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

Рисунок 14

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

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


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

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

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

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

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

Рисунок 15

Благодаря независимости 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 использует эффективный протокол отслеживания. Машина клиента посылает периодическое сообщение. При нарушении соединения DCOM уменьшает счетчик и освобождает компонент, если значение счетчика станет равным нулю. С точки зрения компонента, случай отключения клиента, случай аварии сети и случай поломки машины клиента регистрируются одним и тем же механизмом подсчета. Приложения могут использовать такой механизм подсчета соединений для своего высвобождения.

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


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

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

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

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

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

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


Рисунок 16

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

Рисунок 17

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

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