Модели распределенных приложений

Значительная часть приложений, работающих в компьютерных сетях, является сетевыми, но, конечно, не все. Существуют типовые модели распределенных приложений. Например, в следующей достаточно детальной модели приложение предлагается разделить на шесть функциональных частей [36]:

• средства представления данных на экране, например средства графического пользовательского интерфейса;

• логика представления данных на экране - описание правил и возможных сценариев взаимодействия пользователя с приложением, например выбор из системы меню, выбор элемента из списка и т. п.;

• логика данных - операции с данными, хранящимися в некоторой базе, которые нужно выполнить для реализации прикладной логики;

• прикладная логика - набор правил для принятия решений, вычислительные процедуры и операции;

• внутренние операции базы данных - действия СУБД, вызываемые в ответ на выполнение запросов логики данных, такие как, например, поиск записи по определенным признакам;

• файловые операции - стандартные операции над файлами и файловой системой, которые обычно являются функциями операционной системы.

На основе этой модели можно построить несколько схем распределения частей приложения между компьютерами сети. Эти схемы можно разделить на два вида: двухзвенные и трехзвенные.

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

В двухзвенной схеме возможны следующие варианты:

• обработка на сервере;

• обработка у клиента;

• обработка при сотрудничестве.

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

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

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

Тем не менее централизованная схема иногда применяется как из-за простоты организации программы, которая почти целиком работает на одном компьютере, так и из-за наличия большого количества нераспределенных приложений. Поскольку в этой схеме (рис. 5.22) клиентский компьютер может иметь небольшую производительность и выполняет незначительную часть общей работы, он в этой схеме получил название ≪тонкий клиент≫ (верхняя схема).

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

Файловый сервер представляет собой компонент наиболее популярной сетевой службы - сетевой файловой системы, которая лежит в основе многих распределенных приложений и некоторых других служб. Например, это может быть NetWare компании Novell, IBM PC LAN Program, MS-Net.

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

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

• компьютер клиента должен обладать высокой вычислительной мощностью, чтобы справляться с предоставлением данных, логикой приложений, логикой данных и поддержкой операций базы данных. Поэтому такой клиент называется ≪толстым≫ клиентом;

•приходится создавать высокоскоростную сеть, которая сможет выдержать интенсивные потоки данных между сервером и толстыми клиентами.

•проще и дешевле обновлять приложение на одном сервере, чем на сотнях пользовательских машин.

Рассмотрим третий вариант двухзвенной схемы - обработка при сотрудничестве.

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

рис 5.22

рис 5.23

 

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

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

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

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

Рис 5.24

 

Сервер баз данных, как и в двухзвенной схеме, выполняет функции двух последних слоев - операции внутри БД и файловые операции.

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

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

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

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

Например, такая ситуация. Аппарат SQL предложен с целью стандартизации доступа к локальным БД, независимо от того, локальный это доступ или удаленный. Хотя многие производители реляционных БД и поддерживает SQL, но добавляют к нему собственные расширения. Это дает возможность производителям выделить свой продукт среди прочих, однако создает проблемы потенциальной несовместимости. Промежуточное программное обеспечение позволяет совершенно одинаково обращаться к различным системам.

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

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

В крупных сетях для связи клиентских и серверных частей приложений используется ряд средств, относящихся к классу middleware (промежуточному ПО), в том числе:__

• средства асинхронной обработки сообщений (message-oriented middleware, MOM);

• средства удаленного вызова процедур (Remote Procedure Call, RPC);

• брокеры запроса объектов (Object Request Broker, ORB), которые находят объекты, хранящиеся на различных компьютерах, и помогают их использовать в одном приложении или документе.