в этой главе:

Почему клиент/еервер?

Что такое

а рхтпектура клистп/ее])вер?

Об атюратпых сределпвах

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

т Проектщювапие для архитектур клиент /ccjteep

в Основы SQL*Nct

* Анатомия SQL-предложспия

* Появляется промежуточное звено

* Приемы upoeKmupoeamtH для apxumeKunjp клиент /eejtoej)

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

Архитектура клиент/сервер в последние пять-шесть лет является одной из самых популярных тем. В мире Oracle многие ранние приложения клиент/сервер работали прямо-таки катастрофически плохо - одно внутреннее Oracle-приложение давало ответ на тривиальнейший запрос через три минуты. Оно просуществовало в рабочем состоянии всего около трех часов и было отправлено на свалку . Многие из тех, кто участвовал в разработке Этого приложения, до сих пор работают в корпорации Oracle, но предпочитают об этом не вспоминать - это факт просто стерли из корпоративного сознания. Большинство причин, приведших к этой катастрофе, устранены благодаря усовершенствованию аппаратных средств и нововведениям в последних версиях ПО, но некоторые из ключевых причин существуют до сих пор. В этой главе мы не раз будем упоминать это неудачное приложение, Чтобы напомнить вам, как важно для проектировщиков учитывать особенности среды клиент/сервер.

Два ключевых момента являются залогом успешного проектирования приложений клиент/сервер:

учет числа операций обмена (пар сообщений), особенно там, где может использоваться глобальная сеть, - именно это и вызвало неудачу упомянутого выше приложения;

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

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

Почему клиент/сервер?

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

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

Переход к архитектуре клиент/сервер все-таки дает одно очень важное преимущество ~ возможность предоставить графический пользовательский интерфейс (ШИ), не модернизируя сервер. Стало очевидным, что во многих (даже, может быть, в большинстве) приложениях ГПИ стал считаться обязательным (а не просто желательным) по той простой причине, что пользователи персональных приложений к нему привыкли. Собираясь выполнять