Классы приложений клиент-сервер

⇐ ПредыдущаяСтр 9 из 16Следующая ⇒

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

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

Схемы некоторых основных вариантов приложений баз данных показаны на рис 17.6.

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

На рисунке изображены четыре класса приложений с разными вариантами распределения задач между сервером и клиентом.

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

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

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

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

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

Рис. 17.6. Классы приложений клиент-сервер

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

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

Рисунок 17.6, в и г соответствует конфигурациям, в которых существенная нагрузка ложится на клиента.

Эта так называемая модель «толстого» клиента стала популярной благодаря появлению таких инструментальных средств как PowerBuilder корпорации Powersoft и SQL Windows корпорации Gupta.

Данные инструментальные средства рассчитаны на создание приложений уровня подразделения с поддержкой от 25 до 150 пользователей [34].

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

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

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

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

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

5. Объектные распределенные системы

Вызов удаленных процедур.

Идея вызова удаленных процедур (Remote Procedure Call – RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть.

Средства вызова удаленных процедур предна- значены для облегчения организации распределенных вычислений.

Наибольшая эффективность использования RPC достигается в тех приложениях, в кото- рых существует интерактивная связь между удаленными компонентами с не- большим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными [2].

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

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

Эти и некоторые другие проблемы решает широко распространенная тех- нология RPC, лежащая в основе многих распределенных операционных систем.

Базовые операции RPC

Чтобы понять работу RPC, рассмотрим вначале выполнение вызова ло- кальной процедуры в обычном компьютере, работающем автономно.

Чтобы осуществить вызов, вызывающая процедура помещает параметры в стек в об- ратном порядке.

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

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

RPC достигает прозрачности следующим путем. Когда вызываемая проце- дура действительно является удаленной, в библиотеку помещается вместо ло- кальной процедуры другая версия процедуры, называемая клиентским стабом (англ. stub – заглушка).

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

5.1.2 Этапы выполнения RPC Взаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 10.

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

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

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

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

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

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

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

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

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

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

⇐ Предыдущая 4 5 6 7 8910 11 12 13 Следующая ⇒