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

БД, работающие по технологии ФАЙЛ-СЕРВЕР;

БД, работающие по технологии КЛИЕНТ-СЕРВЕР.

Файл-сервер

- Обращение к БД (запрос)
- Перекачка данных с блокировкой доступа других пользователей
- Обработка данных на компьютере пользователя

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

Недостатки ФАЙЛ-СЕРВЕРНОЙ системы очевидны:

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

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

Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.

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

Клиент-сервер

Обработка запроса одного пользователя:
- Обращение к БД (SQL-запрос)
- Передача ответа - результата обработки

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

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

Таким образом, все вышеперечисленные недостатки ФАЙЛ-СЕРВЕРНОЙ схемы устраняются в архитектуре КЛИЕНТ-СЕРВЕР:

Массивы данных не перекачиваются по сети от сервера БД на компьютер пользователя. Требования к пропускной способности сети понижаются. Это делает возможным одновременную работу большого числа пользователей с большими объемами данных.

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

Блокировки (захвата) данных одним пользователем не происходит.

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

Рассмотрев отличие ФАЙЛ-СЕРВЕРА от КЛИЕНТ-СЕРВЕРА, можно завершить рассмотрение понятия "хранилище информации". Важно подчеркнуть, что от вида используемой СУБД во многом зависит работа корпоративной системы. Совершенно очевидно, что для крупных предприятий, с большим количеством пользователей, с огромным числом записей в БД, файл-серверная схема совершенно неприемлема. С другой стороны, отличия в базах данных есть и по другим параметрам и возможностям:

типам данных, которые могут храниться в БД (числа, даты, текст, рисунки, видео, звук и т.д);

по организуемым самой БД технологиям доступа к данным в базе и уровню защиты информации от несанкционированного доступа;

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

по предоставляемым средствам и методикам анализа информации (данных), которые могут быть применены в информационной системы на основе данной БД;

по надежности и устойчивости, то есть (грубо) количеству записей (заполненных полей) в БД, при которых обеспечивается надежная и бесперебойная возможность доступа, изменения, анализа информации в БД;

по быстродействию - времени, затраченному на доступ и обработку информации;

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

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

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

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

Клиент-серверные технологии

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

Рис. 4.1. Типовая архитектура клиент-серверной технологии

Часть функций центральных ЭВМ взяли на себя локальные компьютеры. Любое программное приложение в этом случае представляется из трех компонентов: компонент представления, реализующий интерфейс с пользователем; прикладной компонент, обеспечивающий выполнение прикладных функций; компонент доступа к информационным ресурсам (менеджер ресурсов), выполняющий накопление информации и управление данными.

На основе распределения этих компонентов между рабочей станцией и сервером сети выделяют модели архитектуры «клиент-сервер»:

· модель доступа к удаленным данным (рис. 4.2). На сервере расположены только данные:

Рис. 4.2. Модель доступа к удаленным данным

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

· модель сервера управления данными (рис. 4.3):

Рис. 4.3. Модель сервера управления данными

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

· модель комплексного сервера (рис. 4.4):

Рис. 4.4. Модель комплексного сервера

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

· трехзвенная архитектура «клиент-сервер» (рис. 4.5). Используется при усложнении и увеличении ресурсоемкости прикладного компонента.

Рис. 4.5. Трехзвенная архитектура

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

В рамках архитектуры «клиент-сервер» существуют два основных понятия:

· «тонкий» клиент. Используется мощный сервер БД и библиотека хранимых процедур, позволяющих производить вычисления, реализующие основную логику обработки данных, непосредственно на сервере. Клиентское приложение, соответственно, предъявляет невысокие требования к аппаратному обеспечению рабочей станции;

· «толстый» клиент реализует основную логику обработки на клиенте, а сервер представляет собой в чистом виде сервер БД, обеспечивающий исполнение только стандартных запросов на манипуляцию с данными (как правило - чтение, запись, модификацию данных в таблицах реляционной БД).

Сетевые ИТ

Электронная почта . Возникшая самой первой, эта форма обмена электронными сообщениями (e-mail) продемонстрировала саму возможность практически мгновенного общения посредством компьютерных сетей. Архитектурно предназначенная для обмена сообщениями между двумя абонентами, она позволила обмениваться информацией группам людей. Такой модификацией стали группы или списки рассылки. С помощью ПО для работы с электронной почтой можно создавать электронные сообщения и делать вложения в них. Функция вложения используется для отправки по почте документов любого типа, например текстовых документов, электронных таблиц, мультимедиа файлов, файлов БД и т.д. Разработанное позже ПО для фильтрации текста расширило возможности электронной почты, чтобы помочь пользователю в структурировании, направлении и фильтрации сообщений. Потребность в этих услугах обусловлена тем, что постоянно растет количество почты, которая почти или совсем не нужна пользователю (Spam). ПО для фильтрации может обеспечивать доставку пользователям только персональных сообщений, содержащих важные для них новости, а также помогает находить информацию, необходимую пользователям в процессе принятия решений.

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

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

Наиболее распространенными современными средствами интерактивного общения являются Web-приложения, которые поддерживают следующие формы организации общения:

o Гостевые книги. Первая и самая простая форма. Простейшая гостевая книга представляет собой список сообщений, показанных от последних к первым, каждое из которых оставлено в ней каким-либо посетителем.

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

o Блоги (Web Log - Web-журнал, Web-протокол). В этих сервисах каждый участник ведет собственный журнал - оставляет записи в хронологическом порядке. Темы записей могут быть любыми, самый распространенный подход - это ведение блога как собственного дневника. Другие посетители могут оставлять комментарии на эти записи. В этом случае пользователь, помимо возможности вести свой журнал, получает возможность организовывать листинговый просмотр - список записей из журналов «друзей», регулировать доступ к записям, искать себе собеседников по интересам. На базе таких систем создаются сообщества по интересам - журналы, которые ведутся коллективно. В таком сообществе его членом может быть свободно размещено любое сообщение по направлению деятельности сообщества.

В целом все современные системы обеспечения работы сетевых сообществ обладают несколькими общими чертами:

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

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

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

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

На основе последнего подхода появилось и быстро набрало популярность довольно большое количество социальных Web-сервисов, объединенных общим названием сервисы Web 2.0. Можно указать некоторые такие ресурсы:

o Социальные закладки . Некоторые веб-сайты позволяют пользователям предоставлять в распоряжение других список закладок или популярных веб-сайтов. Такие сайты также могут использоваться для поиска пользователей с общими интересами. Пример: Delicious.

o Социальные каталоги напоминают социальные закладки, но ориентированы на использование в академической сфере, позволяя пользователям работать с БД цитат из научных статей. Примеры: Academic Search Premier, LexisNexis Academic University, CiteULike, Connotea.

o Социальные библиотеки представляют собой приложения, позволяющие посетителям оставлять ссылки на их коллекции, книги, аудиозаписи, доступные другим. Предусмотрена поддержка системы рекомендаций и рейтингов. Примеры: discogs.com, IMDb.com.

o Многопользовательские сетевые игры имитируют виртуальные миры с различными системами подсчета очков, уровней, состязательности, победителей и проигравших. Пример: World of Warcraft.

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

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

o Профессиональные социальные сети создаются для общения на профессиональные темы, обмена опытом и информацией, поиска и предложения вакансий, развития деловых связей. Примеры: Доктор на работе, Профессионалы.ру, MyStarWay.com, LinkedIn, MarketingPeople, Viadeo.

o Сервисные социальные сети позволяют пользователям объединяться в online режиме вокруг общих для них интересов, увлечений или по различным поводам. Например, некоторые сайты предоставляют сервисы, с помощью которых пользователи могут размещать для общего доступа персональную информацию, необходимую для поиска партнеров. Примеры: LinkedIn, ВКонтакте.

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

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

2.1. Файл-серверные приложения

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

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

Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов для PC.)

Рис. 2.1. Классическое представление информационной системы в архитектуре "файл-сервер"

Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Почему-то часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. База данных есть база данных. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Естественно, сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области. Но, собственно, из чего должно следовать, что файл-серверные приложения пригодны только в простых предметных областях?

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

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

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

Длинноезамечание:
Для сохранения четкости дальнейшего изложения нам необходимо несколько уточнить терминологию. Мы недаром написали "сервер баз данных" в кавычках применительно к СУБД Informix SE. При использовании этой системы копия программного обеспечения СУБД поддерживалась для каждого инициированного пользователем сеанса работы с СУБД. Грубо говоря, для каждого пользовательского процесса, взаимодействующего с базой данных создавался служебный процесс СУБД, который выполнялся на том же процессоре, что и пользовательский процесс (т. е. на стороне клиента). Каждый из этих служебных процессов вел себя фактически так, как если бы был единственным представителем СУБД. Вся синхронизация возможной параллельной работы с базой данных производилась на уровне файлов внешней памяти, содержащих базу данных. Условимся впредь называть такие СУБД не серверами баз данных, а системами управления базами данных, основанными на файл-серверной архитектуре (СУБД-ФС).

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

Истинные серверы баз данных существенно сложнее по организации, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное управление базами данных. Везде далее в этом курсе при употреблении термина "сервер баз данных" мы будем иметь в виду истинные серверы баз данных.

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

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

В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 2.2).

Рис. 2.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре

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

Клиент-серверные приложения

Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных (см. длинное замечание в конце раздела 2.1). Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 2.3.

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

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)

Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"

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

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

Здесь необходимо сделать еще два замечания.

Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных.

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

дополнительные операторы

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

Рис. 2.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре

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

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

Рис. 2.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

Сформулируем некоторые предварительные выводы. Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию.

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

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

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

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

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

Клиентские технологии

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

Клиентские технологии применяются главным образом для повышения интерактивности приложений, например для проверки корректности вводимых данных без дополнительного обращения к серверу, и для создания удобного пользовательского интерфейса. Так, современные веб-браузеры и некоторые почтовые клиенты способны интерпретировать код на скриптовых языках, выполнять Java-аплеты и элементы управления ActiveX, использовать другие дополнения, такие как Macromedia Flash Player, средства просмотра презентаций QuickTime, средства воспроизведения мультимедиаданных.

Код, интерпретируемый браузером

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

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

Java-аплеты

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

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

Элементы управления ActiveX

Некоторые из современных браузеров (в частности, Microsoft Internet Explorer) могут служить контейнерами для элементов управления ActiveX специальных COM-серверов, выполняющихся в адресном пространстве браузера. Ссылки на такие элементы управления могут содержаться в составе веб-страницы. Сами элементы управления ActiveX представляют собой динамически загружаемые библиотеки, выполняющиеся в адресном пространстве браузера.

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

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

Отметим, что сегодня элементы управления ActiveX применяются главным образом в интрасетях, а не на общедоступных веб-сайтах.

Приложения Macromedia Flash

Еще одна очень популярная веб-технология, основанная на выполнении кода в клиентском приложении, приложения Macromedia Flash. Macromedia Flash Player, как и виртуальная Java-машина, обладает ограниченными возможностями с точки зрения доступа к ресурсам клиентского компьютера. Так, приложения Flash не имеют доступа к файловой системе, за исключением служебного каталога Macromedia Flash Player, а доступ к внешним устройствам ограничивается микрофонами и видеокамерами. Доступ к сетевым ресурсам ограничивается доменом, с которого было получено данное приложение. Отметим, что, так же как и Java-аплеты и элементы управления ActiveX, приложения Flash могут управляться с помощью кода JavaScript, присутствующего на той же странице. Поскольку Macromedia Flash Player для Microsoft Internet Explorer сам по себе является элементом управления ActiveX, он использует некоторые возможности элементов управления ActiveX для доступа к свойствам приложений Flash из скриптовых языков.

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

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

Серверные технологии

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

Скрипты и исполняемые файлы

Одной из первых технологий создания веб-приложений, выполняющихся на серверах, была Common Gateway Interface (CGI). Она позволяла создавать и выполнять серверные приложения, обращение к которым происходит посредством указания их имени (а иногда и параметров) в URL. Входной информацией для таких приложений служит содержимое HTTP-заголовка либо тело запроса, в зависимости от применяемого протокола. CGI-приложения это консольные приложения, которые генерируют HTML-код, передаваемый браузеру. Подобные приложения могут представлять собой код на скриптовых языках, интерпретируемый на сервере, либо исполняемый файл, который можно создать с помощью практически любого средства разработки, генерирующего консольные приложения для операционной системы, под управлением которой функционирует веб-сервер.

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

Библиотеки, загружаемые в адресное пространство веб-сервера

Проблему ограниченной производительности веб-приложений, которые выполняются в отдельном адресном пространстве, можно решить, создав приложение в виде библиотеки, загружающейся в адресное пространство веб-сервера и при необходимости остающейся там для обработки последующих запросов от других клиентов (понятно, что в этом случае веб-сервер должен поддерживать загрузку таких библиотек). Подобные приложения для Microsoft Internet Information Servise носят название ISAPI (Internet Server Application Program Interface), а такие библиотеки для весьма популярного веб-сервера Apache называются Apache DSO (Dynamic Shared Objects). Означенные технологии существуют уже довольно продолжительное время, но все еще весьма популярны.

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

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

Веб-страницы с фрагментами серверного кода

ASP и ASP .NET

Очередным шагом в развитии технологий создания Интернет-приложений стало появление средств, позволяющих отделить задачи веб-дизайна от задач, связанных с реализацией функциональности приложений. Первой подобной технологией стала Active Server Pages (ASP). Основная идея ASP заключается в создании веб-страниц с внедренными в них фрагментами кода на скриптовых языках. Однако, в отличие от рассмотренных выше средств применения скриптовых языков для расширения функциональности браузеров, указанные фрагменты кода интерпретируются не браузером, а предназначенной для этого ISAPI-библиотекой, входящей в состав Internet Information Server. Внедренный фрагмент кода замещается результатом его выполнения, а полученная таким образом динамическая страница передается в пользовательский браузер.

Одной из наиболее популярных сегодня технологий, реализующих идею создания веб-страниц с фрагментами кода, является ASP .NET ключевая в архитектуре Microsoft .NET Framework. Основное отличие этой технологии от ASP в плане архитектуры приложений заключается в том, что код, присутствующий на веб-странице, не интерпретируется, а компилируется и кэшируется, что способствует повышению производительности приложений. Кроме того, указанная технология позволяет создавать так называемые серверные компоненты, возвращающие в браузер HTML-код с интерпретируемыми браузером фрагментами кода на скриптовых языках и способные предоставить более удобный пользовательский интерфейс, нежели обычный HTML-код. Важными особенностями серверных компонентов ASP .NET являются возможность обработки на сервере событий, возникающих в клиентском приложении, и возможность генерировать HTML-, WML- и CHTML-код в зависимости от типа клиента и поддерживаемых им языков разметки и протоколов передачи данных.

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

Java Server Pages

Наряду с ASP и ASP .NET существуют и другие технологии, реализующие идею размещения внутри веб-страницы кода, выполняемого веб-сервером. Наиболее известной из них сегодня является технология JSP (Java Server Pages), основная идея которой однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Веб-приложения, основанные на применении веб-страниц с внедренными в них фрагментами серверного кода

Говоря о технологии JSP, нельзя не отметить относительно новую спецификацию Sun под названием Java Server Faces. Эта спецификация описывает правила создания веб-приложений с удобным пользовательским интерфейсом (схожим по функциональности с интерфейсом Windows-приложений) и разработки серверных компонентов, реализующих подобный интерфейс. Средства разработки Java-приложений, поддерживающие указанную спецификацию, в идеале должны позволить создавать веб-приложения, основанные на J2EE, примерно с той же скоростью и степенью удобства, что и средства разработки.NET-приложений.

Из других популярных технологий, реализующих создание веб-страниц с фрагментами кода, выполняемого на сервере, отметим PHP (Personal Home Pages). Данная технология основана на применении CGI-приложений, интерпретирующих внедренный в HTML-страницу код на скриптовом языке. Несмотря на наличие недостатков, присущих всем CGI-приложениям, PHP пользуется немалой популярностью благодаря простоте разработки и доступности для различных платформ, особенно при создании приложений, не отличающихся высокими требованиями к масштабируемости и надежности.

Применение инфраструктурного ПО общего назначения

Чем выше посещаемость сайта и больше объем обрабатываемых им данных, тем более строгими будут требования к производительности и масштабируемости веб-приложений. Чем более серьезные задачи решаются с помощью веб-приложения, тем выше требования к его надежности и безопасности. Чаще всего для удовлетворения этих требований бизнес-логика, реализованная в веб-приложении, а также службы обработки данных и реализации транзакций отделяются от пользовательского интерфейса приложений и реализуются в виде отдельных приложений, библиотек, сервлетов, которые в общем случае называются бизнес-объектами. Сегодня в подавляющем большинстве современных корпоративных решений применяются либо серверы, поддерживающие спецификацию Java2 Enterprise Edition, либо серверы, базирующиеся на применении служб серверных версий Windows, технологиях COM и Microsoft .NET.

Бизнес-объекты могут обладать различной функциональностью. Как правило, они предоставляют доступ к данным, управляемым какой-либо серверной СУБД, нередко доступ к данным корпоративных информационных систем. Довольно часто бизнес-объекты реализуют какую-либо часть корпоративной информационной системы, создание которой изначально предполагало включение внешнего веб-сервера в качестве составной части корпоративной информационной системы (например, в качестве одного из источников данных для CRM-приложения). Готовые CRM- и ERP-системы ведущих производителей, таких как SAP, PeopleSoft, Siebel, обычно содержат в своем составе подобные бизнес-объекты, а зачастую и обращающиеся к ним готовые веб-приложения, например порталы для клиентов и удаленных пользователей, приложения для осуществления электронной коммерции и иные приложения.

Веб-службы

информационным системам многих предприятий уже не один десяток лет. А поскольку предприятия нередко начинали свое развитие со стихийной автоматизации отдельных видов деятельности, то сегодня многие из них сталкиваются с проблемой интеграции приложений, создававшихся в разные годы для разных платформ. Одним из средств подобной интеграции является технология веб-служб, использующая для обмена данными стандартный протокол HTTP. Создавать веб-службы можно и в виде исполняемых файлов, и в виде библиотек, и в виде интерпретируемого кода; существуют также средства представления бизнес-объектов, основанных на различных технологиях, в виде веб-служб (эту технологию сегодня поддерживают все ведущие производители офисных продуктов), средств разработки, СУБД, серверов приложений и операционных систем. Методы веб-служб можно вызывать из обычных приложений, веб-приложений, других веб-служб. В последнее время наблюдается массовое появление приложений, использующих веб-службы, в том числе предназначенных для конечных пользователей (к таким приложениям, например, относятся приложения семейства Microsoft Office System, позволяющие при помощи веб-служб пользоваться данными словарей, энциклопедий, систем онлайнового перевода, служб онлайнового заказа товаров, см., например, статью «Интернет и офисные приложения», № 10’2004).

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

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

История

Чтобы лучше понять, что представляют собой современные серверы, кратко рассмотрим историю их возникновения. Изначально, вся электронная обработка данных проходила на мощных ЭВМ - мейнфреймах, у пользователей был лишь терминал для доступа к данным. Терминал представлял собой алфавитно-цифровой дисплей и клавиатуру, которые подключались к мейнфрейму. Сам по себе мейнфрейм (от англ. mainframe - основная стойка) представлял собой мощную, универсальную ЭВМ для массового одновременного обслуживания нескольких тысяч пользователей. Мейнфреймы на тот момент поставляли всего несколько компаний, но, как правило, их продукция была несовместима между собой, а, следовательно, компании-потребители были замкнуты на решения одного поставщика, который поставлял все аппаратное и программное обеспечение. Компьютерные системы были очень дорогими, а переход с одной системы на другую был очень болезненным. В 1971 г. компанией Intel был разработан первый микропроцессор (i4004), что сделало возможным появление персонального компьютера - IBM PC. С ростом мощности и количества ПК произошел постепенный переход от централизованной обработки информации к распределенной (на персональных компьютерах). Терминалы стали замещаться ПК, а от мэйнфреймов постепенно отказались.

Однако с ростом количества ПК и их мощности, развитием локальных сетей вновь возникла потребность в централизованном хранении и обработке данных.

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

Изначально распространение получили файловые серверы, где пользователи хранили свои данные и обменивались ими. С ростом глобальной компьютерной сети интернет возникло новое направление - телекоммуникационные серверы (веб-серверы, ftp, доменных имен, почтовые). С развитием СУБД, в силу изменения формата хранения и доступа к данным, файловые серверы утратили свою популярность, и их во многом заменили серверы баз данных. Файловые серверы остаются и по сей день, но они приобрели второстепенное значение - их используют для хранения пользовательских файлов и различных архивов. Также на файловых серверах хранятся данные, предназначенные для совместной работы нескольких пользователей. В последнее время выросла популярность терминальных серверов - ПК пользователей служат лишь терминалом для отображения и ввода данных, а все пользовательские задачи выполняются на сервере. Таким образом достигается значительная экономия на ПК (на роль терминала годятся даже маломощные компьютеры), снижаются затраты на установку и поддержку программного обеспечения, решаются вопросы конфиденциальности и сохранности данных.

Для снижения совокупной стоимости владения (Total Cost of Ownership - TCO), куда входят затраты на оборудование, программное обеспечение и обслуживание техники, многие компании сегодня возвращаются к централизованной обработке данных.

Классификация серверных решений

Сегодня компании не замкнуты на одного поставщика аппаратного и программного обеспечения, имея возможность использовать различные программные и аппаратные решения от различных производителей - в первую очередь речь, идет о разнице в "глобальных" подходах (выбор между Windows - Unix системами и архитектурами CISC/RISC).

На сегодняшний день основным представителем архитектуры CISC (Complete Instruction Set Computer - компьютер с полным набором команд) являются процессоры x86 от AMD и Intel. Строго говоря, CISC/RISC архитектуры на самом деле являются идеализированными концепциями, поэтому классификация процессоров на их основе является несколько условной. Но процессоры х86 относят к CISC процессорам, поскольку они соответствуют наиболее важным характеристикам, свойственным CISC-системам:

сравнительно небольшое число регистров общего назначения (16 регистров у классических CISC-архитектур);
большое количество машинных команд (набор команд постоянно пополняется за счет нововведений производителей - MMX, SSE, 3DNow! и пр.);
большое количество методов адресации;
большое количество поддерживаемых форматов команд различной разрядности;
преобладание двухадресного формата команд.

Поскольку на сегодняшний день AMD только обозначил свое присутствие на рынке серверных процессоров, то далее речь пойдет о развитии серверных процессоров Intel.

В 1995 г. компанией Intel был разработан процессор Pentium Pro (150МГц, 512Кб кэш), позиционирующийся как серверный. Он отличался от настольных аналогов большим кэшем и продвинутой архитектурой, частично заимствованной у процессоров с архитектурой RISC. В процессоре Pentium Pro Intel впервые включила технологию динамического исполнения (Dynamic Execution), то есть инструкции могут исполняться не только последовательно, но и параллельно с помощью предсказания ветвей кода и переупорядоченного исполнения инструкций. Тем самым значительно повысилась эффективность процессора - количество команд, выполняемых за такт.

Вторым нововведением стал большой встроенный кэш L2. Для серверных систем наличие большего кэша является очень важным. Процессоры всегда работают на частотах, в несколько раз превышающих частоту памяти. Половина инструкций стандартных приложений представляет собой команды работы с памятью - загрузку и выгрузку данных (Load-Store). Работа с памятью происходит по следующей схеме: если данные не были найдены в кэше L1, то следует обращение к кэшу L2, на это уходит 9-16 процессорных циклов, если данных нет и в кэше L2, то на обращение к памяти уходит до 150 процессорных циклов, в течение которых процессор ждет данные. Большой кэш L2 повышает вероятность быстрого доступа к данным, а, следовательно, увеличивает эффективность работы процессора.

Можно говорить о том, что Intel впервые применяет и обкатывает свои новые продвинутые технологии именно на серверных процессорах, потом эти технологии постепенно распространяются и на персональные компьютеры. Это уже произошло с интегрированным кэшем L2, динамическим исполнением, многопоточностью (hyper-threading). На очереди 64 битная адресация памяти (ЕM64Т).

За Pentium Pro последовали другие серверные процессоры: в 1998 г. - Intel Pentium II Xeon (400-450МГц, 1-2Мб кэш), Pentium III Xeon (700-900Мгц, 1-2Мб кэш). В 2001 г. был выпущен серверный аналог Pentium 4, Хeon, который развивается и используется и в настоящее время.

Так сложилось, что на сегодняшний день на долю Intel приходится около 90% всех поставок рынка серверов, но лишь половина доходов этого рынка попадает в ее карманы: сегмент серверов начального уровня, где Intel доминирует с середины 90х, велик, но прибыли от него, в силу дешевизны продукции, несравнимы с сегментом мощных серверов. К примеру, по моей информации, на сегодняшний день в Республике Беларусь установлено несколько тысяч одно- и двухпроцессорных серверов начального уровня и только несколько 48-процессорных серверов RISC - общая стоимость систем примерно одинакова. При одинаковой общей стоимости прибыль, полученная производителями от продажи этих систем, существенно разнится. Дело в том, что Intel позволяет производить серверы на основе своих процессоров целому ряду сторонних производителей, получая прибыль не со всей стоимости сервера (5000-15000 USD), а только со стоимости своих комплектующих - в основном, процессоров (т.е. с 1000-3000 USD).

В последнее время Intel активно борется за этот самый прибыльный сегмент серверного рынка (системы с количеством процессоров от 4 до 256), где достаточно прочно обосновались системы на базе RISC архитектуры. Основной надеждой Intel являются 64-битные процессоры Intel Itanium 2. Предыдущий процессор Intel Itanium так и остался непопулярным - с момента начала поставок работоспособных систем на его основе и до выпуска Itanium 2, по данным Gartner, было продано лишь около 3 тысяч серверов на его основе (за тот же период серверов с процессорами RISC было продано 4.7 млн.).

Архитектура, называемая компьютером с сокращенным набором команд (Reduced Instruction Set Computer - RISC), появилась благодаря тому, что еще в середине 70-х годов XX века некоторые разработчики компьютерных архитектур заметили, что даже у компьютеров сложной архитектуры большая часть времени уходит на выполнение простых команд. Справедливым оказалось правило 20/80, а именно - 20% команд используется в 80% случаев, а оставшиеся 80% команд используются в 20% случаев.

Основными чертами концепции RISC-архитектуры являются:

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

Основными чертами RISC архитектуры обладают процессоры SPARC (масштабируемая процессорная архитектура - Scalable Processor ARChitecture). Всеобщим заблуждением среди любителей является соотнесение архитектуры SPARC только с компанией Sun. На самом деле архитектура SPARC - это стандартизированная архитектура, в рамках которой целый ряд производителей выпускают процессоры и крупные вычислительные системы на их основе. Первый процессор SPARC был изготовлен компанией Fujitsu на базе вентильной матрицы, работающей на частоте 16.67 МГц еще в 1987 году.

Основными конкурентами на этом рынке долгое время оставались компании Sun Microsystems и Fujitsu. Но не так давно эти компании объявили о новом направлении сотрудничества, результатом которого станет появление новой линейки систем APL (Advanced Product Line) на платформе SPARC/Solaris. Эта линейка появится в 2006 году и соединит все достоинства существующих линеек Sun Fire и PrimePower. На европейском рынке линейку PrimePower поставляет концерн Fujitsu Siemens Computers.

Эти системы изначально проектировались как масштабные 64-разрядные вычислительные системы enterprise уровня. Как уже отмечалось, системы RISC доминируют в классе мощных серверов. На это есть ряд причин, а именно - архитектура SPARC позволяет организовать максимальную масштабируемость, кроме того, немаловажную роль играет наличие специализированного программного обеспечения для масштабных систем. В серверах PrimePower используется операционная система Solaris, достаточно давно разрабатываемая специально для этих целей. А на рынке программного обеспечения для CISC систем ситуация плачевна: оригинального программного обеспечения для процессоров Itanium мало, а то, что есть - еще не опробовано и "сыро", чтобы на него делали ставку заказчики мощных серверов. Задачи, для решения которых нужны такие машины (финансовое моделирование, построение крупных электронно-коммерческих систем и т.п.), требуют идеальной надежности и проверки временем. Системы на базе SPARC такую проверку уже прошли.

Следующий параметр для классификации серверов - используемое программное обеспечение. Можно долго и бесплодно спорить, что же лучше - системы на базе Windows или *nix систем, но серверный рынок самостоятельно решил для себя этот вопрос - в серверах начального уровня в подавляющем большинстве случаев используется Windows 2000/2003 Server, тогда как в серверах enterprise уровня - *nix системы (большей частью Solaris).

На мой взгляд, это связано прежде всего с тем, что, кроме непосредственной стоимости оборудования, в общую стоимость (ТСО) серверов входят также затраты на администрирование. И в этом свете администраторы Windows "стоят" куда "дешевле" своих коллег, администрирующих *nix системы, что связано с достаточной сложностью администрирования таких систем и явным недостатком соответствующих квалифицированных специалистов. Поэтому доля подобных расходов в ТСО серверов начального уровня значительно превосходит такую же долю в ТСО мощных серверов. А владельцы дорогостоящих RISC систем зачастую готовы платить соответствующие деньги своим специалистам, зная, что один час простоя такого сервера обойдется им в сумму, превышающую десятки годовых зарплат системного администратора.

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

Если в ходе прочтения этой статьи у вас возникли вопросы или замечания, направляйте их на мой электронный адрес.

Кроме того, 27 сентября в Минске состоится семинар, проводимый компанией Fujitsu Siemens Computers и ее партнером в Беларуси ИП "ИТЦ-М", посвященный современным серверным технологиям, системам хранения данных, опыту внедрения, эксплуатации и сопровождения серверов в крупных ВЦ и др. В ходе проведения семинара специалисты и руководители служб ИТ/АСУ, работающие в этой области, смогут пообщаться со специалистами крупнейшего в Европе производителя серверов и компьютерного оборудования и получить исчерпывающую информацию по всем интересующим их вопросам. Следите за объявлением о регистрации на сайте www.itc.by и в прессе.