Лекция 3. Технологии и Фреймворки для обеспечения клиент-серверного взаимодействия

Использование Фреймворков позволяет абстрагироваться от низкоуровневых деталей реализации сетевых протоколов и выполнять разработку клиент-серверных приложений на более высоком уровне.

Перед рассмотрением Фреймворков и конкретных деталей, связанных с ними, необходимо рассмотреть стадии проектирования клиент-серверного приложения.

Клиент-серверное проектирование состоит из четырех стадий: концептуальной, логической, физической и перспективной. Этот путь от простого к сложному позволяет реализовать ПО, предназначенное для решения конкретной задачи.

Концепция

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

Логика

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

Физическое решение

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

Перспектива

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

Особенности клиента

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

Особенности сервера

В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).

Клиент-серверная система управления базой данных может опираться на несколько типов распределения обязанностей между клиентом и сервером:

– «интеллектуальные» клиенты;

– «интеллектуальный» сервер;

– смешанные системы;

– многоуровневые системы. Схему реализации выбирают на основе анализа требований к:

– сетевому графику;

– ресурсам клиента и сервера;

– производительности базы данных.

«Интеллектуальные» клиенты

Это один из самых распространенных методов реализации клиент-серверных приложений. «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.

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

Достоинства «интеллектуальных» клиентов

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

Наличие хорошо известных и достаточно мощных средств разработки.

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

Смешанные системы

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

Недостатки смешанных систем

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

Модернизация приложения требует распространения новых версий клиентской части среди широкой аудитории.

Многоуровневые системы

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

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

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

Сервисная модель — это метод рассмотрения приложения как набора средств или сервисов, которые удовлетворяют запросы клиентов. Моделирование программы в виде набора отдельных сервисов позволяет повторно использовать компоненты, предоставляет доступ к ним другим приложениям и помогает распределять их выполнение между несколькими компьютерами сети.

SignalR и WebSocket

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

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

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