Разделение приложений на части
Очевидно, что можно предложить различные схемы разделения приложений на части, причем Для каждого конкретного приложения можно предложить свою схему. Существуют и типовые модели распределенных приложений. В следующей, достаточно детальной модели предлагается разделить приложение на шесть функциональных частей:
средства представления данных на экране, например средства графического пользовательского интерфейса;
логика представления данных на экране описывает правила и возможные сценарии взаимодействия пользователя с приложением: выбор в системе меню, выбор элемента в списке и т. п.;
прикладная логика — набор правил для принятия решений, вычислительные процедуры и операции;
логика данных — операции с данными, хранящимися в некоторой базе, которые нужно выполнить для реализации прикладной логики;
внутренние операции базы данных — действия СУБД, вызываемые в ответ на выполнение запросов логики данных, такие как поиск записи по определенным признакам;
файловые операции — стандартные операции с файлами и файловой системой, которые обычно являются функциями операционной системы.
На основе этой модели можно построить несколько схем распределения частей приложения между компьютерами сети.
Двухзвенные схемы
Распределение приложения между большим числом компьютеров может повысить качество его выполнения (скорость, количество одновременно обслуживаемых пользователей и т. д.), но при этом существенно усложняется организация самого приложения, что может просто не позволить воспользоваться потенциальными преимуществами распределенной обработки. Поэтому на практике приложение обычно разделяют на две или три части и достаточно редко — на большее число частей. Наиболее распространенной является двухзвенная схема, распределяющая приложение между двумя компьютерами. Перечисленные типовые функциональные части приложения можно разделить между двумя компьютерами различными способами.
Рассмотрим сначала два крайних случая двухзвенной схемы, когда нагрузка в основном ложится на один узел — либо на центральный компьютер, либо на клиентскую машину.
В централизованной схеме (рис. 10.1, а) компьютер пользователя работает как терминал, выполняющий лишь функции представления данных, тогда как все остальные функции передаются центральному компьютеру. Ресурсы компьютера пользователя задействуются в этой схеме в незначительной степени, загруженными оказываются только графические средства подсистемы ввода-вывода ОС, отображающие на экране окна и другие графические примитивы по командам центрального компьютера, а также сетевые средства ОС, принимающие из сети команды центрального компьютера и возвращающие данные о нажатии клавиш и координатах указателя мыши. Программа, работающая на компьютере пользователя, часто называется эмулятором терминала — графическим или текстовым, в зависимости от поддерживаемого режима. Фактически, эта схема повторяет организацию многотерминальной системы на базе мэйнфрейма, с тем лишь отличием, что вместо терминалов используются компьютеры, подключенные не через локальный интерфейс, а через сеть, локальную или глобальную.
Рис. 10.1. Варианты распределения частей приложения по двухзвенной схеме
Главным и очень серьезным недостатком централизованной схемы является ее недостаточная масштабируемость и плохая отказоустойчивость. Производительность центрального компьютера всегда будет ограничителем количества пользователей, работающих с данным приложением, а отказ центрального компьютера приведет к прекращению работы всех пользователей. Именно из-за этих недостатков централизованные вычислительные системы, представленные мэйнфреймами, уступили место сетям, состоящим из мини-компьютеров, RISC- серверов и персональных компьютеров. Тем не менее централизованная схема иногда применяется благодаря простой структуре программы, которая почти целиком работает на одном компьютере, и наличию большого парка локальных приложений.
В схеме файлового сервера (рис. 10.1, б) на клиентской машине выполняются все части приложения, кроме файловых операций. В сети имеется достаточно мощный компьютер, имеющий дисковую подсистему большого объема. Этот компьютер хранит файлы, доступ к которым необходим большому числу пользователей. Он играет роль файлового сервера, представляя собой централизованное хранилище данных, находящихся в разделяемом доступе. Распределенное приложение в этой схеме мало отличается от полностью локального приложения. Единственным отличием является обращение не к локальным, а к удаленным файлам. Для того чтобы в этой схеме можно было использовать локальные приложения, в сетевые операционные системы ввели такой компонент сетевой файловой службы, как редиректор, который перехватывает обращения к удаленным файлам (с помощью специальной нотации для сетевых имен, например //serverl/doc/filel.txt) и направляет запросы в сеть, освобождая приложение от необходимости явно задействовать сетевые системные вызовы.
Файловый сервер представляет собой компонент наиболее популярной сетевой службы — сетевой файловой системы, которая лежит в основе многих распределенных приложений и некоторых других сетевых служб. Первые сетевые ОС (NetWare компании Novell, IBM PC LAN Program, Microsoft MS-Net) обычно поддерживали две сетевые службы — файловую службу и службу печати, оставляя реализацию остальных функций разработчикам распределенных приложений.
Такая схема обладает хорошей масштабируемостью, так как дополнительные пользователи и приложения лишь незначительно увеличивают нагрузку на центральный узел — файловый сервер. Однако эта архитектура имеет и свои недостатки:
во многих случаях резко возрастает сетевая нагрузка (например, многочисленные запросы к базе данных могут приводить к загрузке всей базы данных в клиентскую машину для последующего локального поиска нужных записей), что приводит к увеличению времени реакции приложения;
компьютер клиента должен обладать высокой вычислительной мощностью, чтобы справляться с представлением данных, логикой приложения, логикой данных и поддержкой операций базы данных.
Другие варианты двухзвенной модели более равномерно распределяют функции между клиентской и серверной частями системы. Наиболее часто используется схема, в которой на серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловых операций (рис. 10.1, в). Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер — функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой ОС, а являются независимой распределенной прикладной системой. Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений. Не все СУБД являются распределенными, но практически все мощные СУБД, позволяющие поддерживать большое число сетевых пользователей, построены в соответствии с описанной моделью клиент-сервер. Сам термин клиент-сервер справедлив для любой двухзвенной схемы распределения функций, но исторически он оказался наиболее тесно связан со схемой, в которой сервер выполняет функции управления базами данных (и, конечно, файлами, в которых хранятся эти базы) и часто используется как синоним этой схемы.