Недостатки многоуровневых систем

Необходимы сервер и сеть. Увеличивается сетевой трафик.

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

Необходимо отличать понятие библиотеки и Фреймворка.

Библиотека в программировании – сборник подпрограмм или объектов, используемых для разработки программного обеспечения (ПО).

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

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

Также, в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, – «Фреймворк» может содержать в себе большое число разных по тематике библиотек.

Другим ключевым отличием «Фреймворка» от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во «Фреймворке», пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий – «абстрактный» код Фреймворка. При этом, «Фреймворк» вызывает функции (классы) пользовательского кода.

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

WebSocket – является веб-технологией, обеспечивающей полнодуплексные каналы связи поверх одного TCP соединения.

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

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

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

SignalR также раскрывает просторы для нового типа веб-приложений, где требуется быстрый обмен данными с сервером, а это игровые приложения в реальном времени.

SignalR имеет простой API для вызовов удаленных процедур от сервера к клиенту (RPC server-to-client), которые вызывают Javascript функции в клиентских браузерах из кода .NET сервера. SignalR также имеет API для управления соединениями (например, подключением или отключением) и группировкой соединений.

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

SignalR поддерживает функциональность "server push" (толкни сервер), когда код на сервере может отправить сообщения в браузеры, используя Remote Procedure Calls (RPC), это быстрее работает, чем обычная модель "запрос-ответ", существующая в вебе сегодня.

SignalR и WebSocket

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

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

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