11. Многопользовательские системы. Файл-серверная и клиент-серверная технологии. Трехзвенная архитектура.

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

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

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

Каждый монитор должен быть подключен к графическому выводу. Некоторые видеокарты имеют несколько выходов и поддерживают подключение нескольких мониторов. К примеру, для создания четырёхместной системы понадобятся: четыре монитора, четыре usb-клавиатуры и четыре usb-мыши (так как большинство ПК имеют только два вывода PS/2). Так как основная часть современных машин имеют только один слот PCIe или AGP, придется использовать видеокарты стандарта PCI

Где используется:

Библиотеки, музеи, читальные залы Интернет-кафе Выставки, семинары, конференции, презентации Для применения в бухгалтерии (проверялось компанией 1С) Рабочие места в офисах, банках, почтовых отделениях Кассовые терминалы, регистрационные пункты в домах отдыха, отелях, больницах Компьютерное тестирование и обучение Школы и университеты Для домашнего пользования

2. Файл-серверная архитектура программы.

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

Проиллюстрирую это на модели музыкального магазина: - Продавец в стороне, а коробки с компакт-дисками доступны покупателям. - Покупатели самостоятельно выбирают то, что им нужно. Продавец никак не вмешивается в процесс, только принимает деньги в случае покупки. Неизбежные издержки:- Ошибки поиска - покупатель пришел к выводу, что нужного диска нет (в коробках не нашел), а диск есть - просто его вертел в руках другой покупатель. Повертел-повертел и положил на место;- Порча товара - поломают, помнут, а то и украдут...;- Неизбежность конфликтов - "я первый взял...", "не толкайся...", "это поломал не я, а вот этот субъект..."; - Конечное количество покупателей, что могут иметь доступ к коробкам. ВСЕ ЭТО И ЕСТЬ ФАЙЛ-СЕРВЕРНАЯ АРХИТЕКТУРА.Главная особенность - данными никто не управляет. Программы самостоятельно роются в них. Компьютер, в памяти которого хранятся файлы с данными, обычно называют "файл-сервером". Обращаю внимание: "файл-сервер" - это именно компьютер ("железо"), а не программа. И программа, и данные могут быть расположены на одном компьютере. Это дела не меняет.

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

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

Клиент-серверная СУБД — СУБД, использующая технологию «клиент-сервер».

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

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

Трёхзвенная архитектура — вариант архитектуры клиент — сервер, в котором пользовательский интерфейс, бизнес-логика, доступ к данным и хранение данных разрабатываются и функционируют как независимые модули, зачастую на различных платформах. Авторство термина «трёхзвенная архитектура», также как и термина «многозвенная архитектура», по-видимому, принадлежит Rational Software.

Трехзвенная архитектура "клиент - сервер(-а) приложений - сервер данных (хранилище)".

Трехзвенная архитектура "клиент - сервер(-а) приложений - сервер данных (хранилище)". Серверная часть SWR-PDM является интегрированным сервером СУБД и сервером приложений и отвечает за работу всего комплекса, за физическое хранение и безопасность данных. Клиентская часть представляет собой автономное приложение для работы с любыми системами, которые повседневно используются для подготовки инженерной документации. Клиентское приложение разработано в виде проводника хранилища SWR-PDM, и является естественным инструментом для пользователей, привыкших к проводнику Windows.

Трехзвенная архитектура До сих пор мы обсуждали самую простую архитектуру для работы с WWW и простыми бизнес-приложениями - клиент/сервер. Однако эту архитектуру не так-то просто нарастить по мере роста и изменения ваших приложений. В ней также трудно использовать преимущества объектно-ориентированного программирования. Первая проблема недавно нашла отражение в дискуссиях относительно «тонких клиентов». Потребность в тонких клиентах происходит из беспокоящей тенденции в передаче клиенту все больших объемов обработки. Эта проблема проявилась в PowerBuilder и VisualBasic - инструментах, которые прямо вытаскивают данные из базы в GUI, а затем все операции над этими данными проводят в GUI. Такая тесная привязка интерфейса пользователя к ядру базы данных приводит к появлению программ, которые трудно модифицировать и невозможно масштабировать при увеличении числа пользователей и объема данных. Если у вас есть опыт разработки интерфейсов пользователя, то вы сталкивались с проблемой переработки интерфейса в зависимости от каприза пользователя. Чтобы изолировать последствия такой переработки, проще всего оставить для GUI только одну задачу- действовать в качестве интерфейса пользователя. Такой интерфейс пользователя действительно является тонким клиентом. Влияние на масштабируемость сказывается и с другой стороны. Когда требуется переработать приложение, чтобы оно могло справляться с возросшим числом пользователей и объемом данных, модификация может быть осуществлена в результате изменений, вносимых в базу данных, в том числе таких, которые состоят в распределении базы данных по нескольким серверам. Навечно привязав свой интерфейс к базе данных, вам приходится делать изменения в этом GUI для решения проблем масштабирования - проблем, связанных исключительно с сервером. Тонкие клиенты - не единственное сегодняшнее поветрие. Другая тенденция - повторное использование кода. Общий для разных приложений код тяготеет к обработке данных, обычно называемой деловой логикой. Если вся ваша деловая логика располагается в интерфейсе пользователя, то добиться повторного использования кода будет, по меньшей мере, трудно. Решением этих проблем является разбиение приложения на три, а не на две части. Такая архитектура называется трехзвенной. Когда мы говорим об интерфейсе пользователя у клиента, то имеем в виду логическое различие. Разновидностью тонкого клиента, иногда называемой «сверхтонким клиентом», является то, что обычно всеми воспринимается как Web-страница. Web-страница может динамически создаваться на Web-сервере. В этом случае большая часть работы клиента происходит на сервере в виде динамической генерации HTML-страниц. Две главные задачи сервера приложений - это изоляция подключений к базе данных и обеспечение централизованного хранилища для деловой логики. Интерфейс пользователя имеет дело только с отображением и вводом данных, а ядро базы данных занимается только проблемами базы данных. При перемещении обработки данных в центральное место одну и ту же программу сервера приложений могут использовать различные интерфейсы пользователя, и устраняется необходимость писать правила обработки данных всякий раз, когда вы создаете новое приложение.