Файл: Модель клиент-сервер (применение технологии «клиент-сервер» при проектировании).pdf

Рисунок 11. Представление многоуровневой архитектуры «клиент-сервер»

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

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

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

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

В «правильной» (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы (рисунок 12) [14].

Рисунок 12. Преимущества и недостатки многозвенной архитектуры

Некоторые авторы (например, Мартин Фаулер) представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рисунок 13) [12]:

Рисунок 13. Пять уровней многозвенной архитектуры «клиент-сервер»

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

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

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

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

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

3.2 Применение технологии «клиент-сервер» при проектировании распределенных систем

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

Рисунок 14. Архитектура распределенных систем

Более 95 % данных, используемых в управлении предприятием могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы [16].

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

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

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

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

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

Рисунок 15. Архитектура распределенных систем с репликацией

Распределенные системы с элементами удаленного исполнения

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

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

У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рисунок 16).

Рисунок 16. Архитектура распределенных систем с удаленным исполнением

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

3.3 Применение технологии «клиент-сервер» при проектировании Веб-приложений

Обычно Веб-приложения создаются как приложения в архитектуре «клиент-сервер», но серверная часть имеет различные архитектурные решения.

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

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

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI является функцией Microsoft Internet Information Server. Приложения ISAPI это динамически загружаемые библиотеки (DLL), которые выполняются в адресном пространстве веб-сервера. Другие веб-серверы через некоторое время также имеют возможность запускать приложения, реализованные в виде библиотек. В случае веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). Довольно популярный веб-сервер Apache также имеет возможность запускать веб-приложения, реализованные в виде библиотек; эти библиотеки называются Apache DSO (динамические общие объекты).

Естественно, что при использовании как CGI, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачу генерации HTML-кода, позволил получить доступ к компонентам и использовать базы данных. Этот интерфейс является объектной моделью active Server Pages (ASP) на основе фильтра ISAPI.

Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Веб-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода. Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер. Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки (WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рисунке 17 [14].

Рисунок 17. Архитектура Веб-приложений

Другим способом поддержки различных типов клиентов является создание «разумных» серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET. Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.