Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций...
Топ:
Техника безопасности при работе на пароконвектомате: К обслуживанию пароконвектомата допускаются лица, прошедшие технический минимум по эксплуатации оборудования...
Генеалогическое древо Султанов Османской империи: Османские правители, вначале, будучи еще бейлербеями Анатолии, женились на дочерях византийских императоров...
Устройство и оснащение процедурного кабинета: Решающая роль в обеспечении правильного лечения пациентов отводится процедурной медсестре...
Интересное:
Уполаживание и террасирование склонов: Если глубина оврага более 5 м необходимо устройство берм. Варианты использования оврагов для градостроительных целей...
Искусственное повышение поверхности территории: Варианты искусственного повышения поверхности территории необходимо выбирать на основе анализа следующих характеристик защищаемой территории...
Наиболее распространенные виды рака: Раковая опухоль — это самостоятельное новообразование, которое может возникнуть и от повышенного давления...
Дисциплины:
2017-07-01 | 291 |
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) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).
Клиент-серверная система управления базой данных может опираться на несколько типов распределения обязанностей между клиентом и сервером:
– «интеллектуальные» клиенты;
– «интеллектуальный» сервер;
– смешанные системы;
– многоуровневые системы. Схему реализации выбирают на основе анализа требований к:
– сетевому графику;
– ресурсам клиента и сервера;
– производительности базы данных.
«Интеллектуальные» клиенты
Это один из самых распространенных методов реализации клиент-серверных приложений. «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.
В этом случае функции сервера ограничены поддержкой собственно базы данных. Вся информация обрабатывается локально, что освобождает ресурсы сервера.
|
|
Типы оградительных сооружений в морском порту: По расположению оградительных сооружений в плане различают волноломы, обе оконечности...
Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...
Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций...
Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!