Адаптации растений и животных к жизни в горах: Большое значение для жизни организмов в горах имеют степень расчленения, крутизна и экспозиционные различия склонов...
История создания датчика движения: Первый прибор для обнаружения движения был изобретен немецким физиком Генрихом Герцем...
Топ:
Выпускная квалификационная работа: Основная часть ВКР, как правило, состоит из двух-трех глав, каждая из которых, в свою очередь...
Оценка эффективности инструментов коммуникационной политики: Внешние коммуникации - обмен информацией между организацией и её внешней средой...
Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов...
Интересное:
Мероприятия для защиты от морозного пучения грунтов: Инженерная защита от морозного (криогенного) пучения грунтов необходима для легких малоэтажных зданий и других сооружений...
Распространение рака на другие отдаленные от желудка органы: Характерных симптомов рака желудка не существует. Выраженные симптомы появляются, когда опухоль...
Влияние предпринимательской среды на эффективное функционирование предприятия: Предпринимательская среда – это совокупность внешних и внутренних факторов, оказывающих влияние на функционирование фирмы...
Дисциплины:
2017-07-01 | 290 |
5.00
из
|
Заказать работу |
|
|
Лекция 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, так как он наиболее эффективно использует память сервера, имеет наименьшее время ожидания, содержит в себе много полезных функций (например, полная дуплексная связь между клиентом и сервером).
Лекция 3. Технологии и Фреймворки для обеспечения клиент-серверного взаимодействия
Использование Фреймворков позволяет абстрагироваться от низкоуровневых деталей реализации сетевых протоколов и выполнять разработку клиент-серверных приложений на более высоком уровне.
Перед рассмотрением Фреймворков и конкретных деталей, связанных с ними, необходимо рассмотреть стадии проектирования клиент-серверного приложения.
Клиент-серверное проектирование состоит из четырех стадий: концептуальной, логической, физической и перспективной. Этот путь от простого к сложному позволяет реализовать ПО, предназначенное для решения конкретной задачи.
Концепция
На концептуальной стадии основное внимание уделяется сценариям использования приложения. Они должны отражать требования пользователей к решению конкретных проблем бизнеса. Здесь определяется бизнес-проблема и вырабатывается подход, отвечающий нуждам и требованиям пользователей.
Логика
На этой стадии на основе сценариев использования проектируются бизнес-объекты и необходимые сервисы. Логическая структура приложения представляет собой основу формальной модели для команды проектировщиков и базу для оценки различных вариантов физического решения.
Физическое решение
На этой стадии проектируются физические компоненты для объектов и сервисов. Структура и дизайн компонентов должны отражать исходные бизнес-объекты и, естественно, сценарии использования. Дополнительные задачи на этой стадии – учет существующей инфраструктуры и технологий для минимизации риска и сокращения цикла разработки.
|
Перспектива
Сценарии перспективного использования приложения или системы – основа будущего расширения возможностей приложения. Они отражают мнение пользователей о будущем бизнес-решения и должны быть детализированы настолько, насколько это необходимо для понимания перспективы. Например, конкретное приложение может помимо текущего сценария платежей по чекам включать и перспективный – для расчетов по кредитным карточкам.
Особенности клиента
Пользователям, работающим в сети, часто требуется запускать приложения с сетевого сервера. Клиентские компоненты должны включать средства поддержки локальной информации (в том числе и информацию из локального реестра и локальных файлов) и средства, предоставляющие пользователю доступ к серверным компонентам.
Особенности сервера
В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).
Клиент-серверная система управления базой данных может опираться на несколько типов распределения обязанностей между клиентом и сервером:
– «интеллектуальные» клиенты;
– «интеллектуальный» сервер;
– смешанные системы;
– многоуровневые системы. Схему реализации выбирают на основе анализа требований к:
– сетевому графику;
– ресурсам клиента и сервера;
– производительности базы данных.
«Интеллектуальные» клиенты
Это один из самых распространенных методов реализации клиент-серверных приложений. «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.
В этом случае функции сервера ограничены поддержкой собственно базы данных. Вся информация обрабатывается локально, что освобождает ресурсы сервера.
|
|
Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций...
Опора деревянной одностоечной и способы укрепление угловых опор: Опоры ВЛ - конструкции, предназначенные для поддерживания проводов на необходимой высоте над землей, водой...
История создания датчика движения: Первый прибор для обнаружения движения был изобретен немецким физиком Генрихом Герцем...
Своеобразие русской архитектуры: Основной материал – дерево – быстрота постройки, но недолговечность и необходимость деления...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!