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

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

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

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

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

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

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

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

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

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

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