Итак, в информационной системе, созданной на основе технологии «клиент-сервер», происходит разделение функций этой системы на следующие четыре группы:
1. функции ввода и отображения данных;
2. прикладные функции, характерные для данной предметной области;
3. функции хранения и управления информационными ресурсами;
4. служебные функции, реализующие связи между функциями первых трех групп.
В соответствии с этим в любой системе выделяются следующие три логических компонента:
компонент представления, реализующий функции первой группы;
прикладной компонент, поддерживающий функции второй группы;
компонент доступа к информационным ресурсам, поддерживающий функции третьей групп, а также уточняющий и способы (протоколы) взаимодействия.
Критерием, позволяющим отнести информационную систему к архитектуре «клиент-сервер» является то, что хотя бы один из трех ее компонентов полностью выполняется на другом узле сети, а взаимодействие между компонентами на разных узлах осуществляется через некоторую среду.
Практическая реализация систем на основе технологии «клиент-сервер» может быть различной. Это различие определяется факторами:
используемым программным обеспечением для реализации функций компонент системы;
распределением компонент между узлами сети;
механизмами связи компонент между собой.
На основе этих различий можно выделить различные модели этой технологии.
Выделяются четыре различных подхода при использовании этой технологии на практике:
модель файлового сервера (File Server - FS);
модель доступа к удаленным данным (Remote Data Access – RDA);
модель севера базы данных (DataBase Server - DBS);
модель сервера приложений (Application Server - AS).
FS-модель в недалеком прошлом являлась популярной среди отечественных разработчиков, использовавших такие системы как FoxPRO, Clipper, Clarion, Paradox и т.д.
Суть этой модели заключает в том, что один из компьютеров сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам и обеспечивает доступ к ресурсам, представленным в виде файлов.
На других узлах в сети функционирует приложение (СУБД), совмещающее компонент представления и прикладной компонент.
При обращении к данным СУБД отправляет запрос на файловый сервер, указывая список файлов, в которых содержаться требуемые данные. В ответ на запрос файловый сервер направляет по сети требуемый блок данных (файлов), а затем СУБД выполняет описанные в прикладной программе действия над ними.
Недостатки:
• высокий сетевой трафик, т.к. осуществляется передача множества файлов необходимых приложению.
• средства защиты данных только на уровне файловой системы.
RDA-модель отличается от FS-модели характером компонента доступа к информационным ресурсам. В этой модели компонент представления и прикладной компонент также совмещены и выполняются на клиенте, т.е. он обеспечивает как функции ввода и отображения данных, так и чисто прикладные функции.
Клиент направляет запросы к ресурсам, расположенным на сервере. В задачи сервера входит обработка данных и выполнение предписанных в запросах действий, и возвращение результата клиенту. Возникает проблема: Запросы должны быть понятны как серверу, так и клиенту. Следовательно, их необходимо формулировать на специальном языке.
Самым распространенным средством общения между клиентом и сервером в этом случае является SQL (структурированный язык запросов) – стандартный непроцедурный язык, ориентированный на обработку данных.
Достоинства:
• унификация интерфейса «клиент-сервер» в виде языка SQL.
• уменьшение загрузки сети за счет того, что теперь передаются запросы на языке SQL, объем которых незначителен, и пользователю предоставляются только те данные, которые ему необходимы. Однако за счет передачи SQL-запросов сетевой трафик все же остается значительным.
Недостатки:
• главным недостатком этой модели является отсутствие централизованного контроля прикладного компонента, который в случае изменения правил необходимо модифицировать во всех приложениях, входящих в состав информационной системы.
DBS-модель устраняет описанные выше недостатки за счет использования механизма хранимых процедур, которые составляют прикладной компонент и доступны для запуска клиентами. Хранимые процедуры объединяют последовательность команд, которая вызывается по назначенному имени и выполняется сервером как единое целое.
Теперь прикладной компонент, оформленный в виде процедур, функционирует на сервере базы данных, там же выполняется и компонент доступа к данным, составляющий ядро СУБД. Клиент в этой модели выполняет лишь вызов нужной хранимой процедуры и представление результатов ее работы.
Достоинства:
• Использование такого подхода позволяет уменьшить сетевой трафик за счет того, что теперь вместо SQL-запросов направляются лишь вызовы хранимых процедур.
• Наличие возможности централизованного управления прикладными функциями обеспечивает легкость администрирования, т.е. в случае изменения правил нет необходимости модифицировать клиентское программное обеспечение, достаточно изменить хранимые процедуры на сервере.
Недостатки:
• ограниченность средств, используемых для написания процедур, которые представляют собой расширения SQL, представляющего ограниченные возможности по сравнению с такими языками программирования как C или Pascal. Кроме этого большинство СУБД не имеют никаких средств для отладки и тестирования разрабатываемых хранимых процедур.
Практическое использование этой модели опирается на смешанную модель, в которой поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).
Эта модель реализуется в таких реляционных СУБД как Informix, Ingres, Sybase, Oracle и SQL-Server.
AS-модель. В этом случае клиент отвечает за интерфейс с пользователем, т.е. выполняет только операции визуализации и ввода пользовательских данных. За выполнением услуг клиент обращается к прикладному компоненту, который называется сервером приложения (Application Server - AS).
Операции над информационными ресурсами выполняются компонентом доступа к данным, который обеспечивает работу с ресурсами разных типов – базы данных, почтовые службы и др. По отношению к нему сервер приложения играет роль клиента. Чаще всего, в AS-модели компоненты прикладной логики и управления данными реализуются раздельно.
Архитектуру сервера приложений часто называют так называемым «тонким» клиентом, функции которого сводятся к выводу результатов обработки данных, осуществляемой на сервере.
Клиент лишь посылает серверу список задач, необходимых для выполнения, и принимает уже обработанные данные. «Тонкий» клиент является вариантом, когда ресурсов, доступных на рабочих местах пользователей, недостаточно для исполнения логики приложения.
Наиболее ярким примером реализации данной архитектуры является реализация взаимодействия навигатора Интернета и Web-узла, с помощью которого осуществляется доступ к хранилищу данных. При этом для «тонкого» клиента неважно, где находится сервер баз данных.
Выбор той или иной модели реализации технологии «клиент-сервер» осуществляется при анализе многих показателей. Например, таких как:
необходимость одновременного обращения к данным большого количества пользователей;
объем данных очень велик и будет возрастать еще больше;
высокие требования в защите и целостности данных;
требуется обработка и оптимизация сложных запросов;
необходима высокая надежность системы;
ценовой фактор.
