выгрузки-загрузки, обеспечивающий обмен информацией между клиентом и сервером за относительно короткий сеанс и позволяющий пользователям работать в значительной степени автономно. Все было бы намного проще, если бы удаленных пользователей можно было рассматривать как локальных. Поскольку SQL*Net поддерживает много протоколов, включая WinSock, то существует потенциальная возможность работать, скажем, с Oracle Forms по коммутируемой линии. Проблема в том, что быстродействие линии и задержки при передаче сообщений часто делали это приложение неработоспособным. С появлением более скоростных модемов и технологий (например, ISDN) ситуация несколько улучшилась, но, тем не менее, ее всегда следует учитывать при проектировании - приложение должно обеспечивать приемлемую скорость работы по самому медленнодействующему из поддерживаемых им каналов.

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

Основные задачи проектирования для архитектур клиент/сервер

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

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

Теперь мы начинаем понимать, почему число операций обмена и время ответа так важны для производительности систем клиент/сервер. Если время ответа составляет полсекунды и в процессе обработки сервис запрашивается десять раз, то мы потратим минимум пять секунд на ожидание, даже если сервер ответит на каждый отдельный запрос мгновенно. Возможно, вам приходилось встречаться с такой ситуацией, работая с Web-броузером, который выдает 15-20 сообщений о завершении загрузки документа, прежде чем вы наконец увидите результат.

Решение проблемы, связанной с операциями обмена, состоит в том, чтобы свести число запросов к минимуму или, что более правильно, составлять сложные запросы типа: Сделать А, сделать В, сделать С, а затем передать мне ответ . Использование хранимых процедур PL/SQL в базе данных позволяет упростить реализацию запросов этого вида средствами Oracle. Что же касается Web-броузеров, то, скорее всего, здесь все зависит от способа доставки ответа сервером.

Нам постоянно приходится слышать, как руководители и технические специалисты говорят о быстродействии или пропускной способности сети как о критическом факторе для систем клиент/сервер. Это не всегда так. При использовании SQL*Net большинство сообшений между клиентом и сервером довольно короткие (десятки или сотни байтов, а не тысячи и миллионы). Поэтому скорость, с которой сеть может передать файл объемом 1 Мбайт, практически не имеет значения - может быть, поэтому поставщики сетей так любят указывать ее! Ключевыми статистическими данными являются время ответа и максимальная скорость передачи пакетов сервером. Время ответа в большинстве ТСР/1Р-сетей можно измерить с помощью команды ping имя хоста (или ping -s имя хоста, если ping просто сообщает о том, что данный хост работает). Это время находится в диапазоне от 1 мс (если клиент и сервер находятся в одной локальной сети) до 400 мс (когда используется мост Х.25). Максимальная скорость передачи пакетов обычно колеблется в пределах от 1000 до 2000 пакетов в секунду, что является абсолютным аппаратным пределом для сетевой интерфейсной платы.

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

Проектирование для архитектур клиент /сервер

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

Модель рабочей нагрузки

в архитектуре клиент/сервер

Модель, представленная на рис. 11.2, была предложена специалистами Gartner Group для того, чтобы показать разнообразие вариантов распределения рабочей нагрузки между клиентом и сервером.

Управлен! интерфейс >

Управление 1 Управление s Управление i Управление г интерфейсом! интерфейсом! интерфейсом! интерфейсом<

Прикладн; логика

Управлен данным

Управление данными

Управлени( интерфейсе

Прикладнэ!

Управлен данным!

Распределенная Удаленное Распределенная Удаленное Распредел! ! база данных управление логика представление представление

данными данных данных

Рис. 112. Типы вычислений клиент/сервер

Эта модель распределения рабочей нагрузки оказалась полезной, и ее можно распространить на трехуровневые архитектуры, но она не дает возможности увидеть общую ощибку, которая заключается в попытке распределить все функции - представления данных, логики и управления данными - между клиентом и сервером. Чем жестче вы примените инкапсуляцию к своей схеме, тем меньще вероятность того, что маленькие фрагменты логики управления представлением окажутся глубоко запрятанными в коде управления данными (во многих случаях и довольно большие сегменты задачи управления данными оказываются закодированными непосредственно в уровне представления). В противном случае вы получите сложный, очень чувствительный к изменениям прикладной код, который часто невозможно сопровождать с какой-либо степенью надежности. К сожалению, такой стиль очень распространен в проектах на базе Oracle. В значительной степени это является наследием SQL*Forms версий 2 и 3, способствующих созданию так называемых ключевых триггеров (для управления