Клиент-серверная архитектура (курсовая), страница 3
Описание файла
PDF-файл из архива "Клиент-серверная архитектура (курсовая)", который расположен в категории "". Всё это находится в предмете "распределённые ис и базы данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "распределённые ис и базы данных" в общих файлах.
Просмотр PDF-файла онлайн
Текст 3 страницы из PDF
[8]142.2.2. Двухуровневая клиент-серверная архитектура.Эта архитектура получила распространение с начала 1990-х годов нафоне роста рынка персональных компьютеров и снижения спроса намэйнфреймы.Первоначальноклассическойвышеописанныедвухуровневойсистемыклиент-сервернойбазировалисьархитектурена(Two-tierarchitecture). Под клиент-серверным приложением в этом случае понимаетсяинформационная система, основанная на использовании серверов базданных.Схематически такую архитектуру можно представить, как показано на рис.2.2.2.1Рис. 2.2.2.1. Классическое представление архитектуры "клиент-сервер"КомпаниейGartnerспециализирующейсяGroup,вобластиисследования информационных технологий, была предложена следующаяклассификациядвухзвенныхмоделей15взаимодействияклиент-сервер(двухзвенными эти модели называются потому, что три компонентаприложения различным образом распределяются между двумя узлами):Рис.
2.2.2.3. Классификация двухзвенных моделей взаимодействия клиентсервер.Исторически первой появилась модель распределенного представленияданных, которая реализовывалась на универсальной ЭВМ с подключеннымикнейнеинтеллектуальнымитерминалами.Управлениеданнымиивзаимодействие с пользователем при этом объединялись в одной программе,натерминалпередаваласьтолько"картинка",сформированнаянацентральном компьютере.Затем, с появлением ПК и локальных сетей, были реализованы моделидоступа к удаленной базе данных. Некоторое время базовой для сетей ПКбыла архитектура файлового сервера. При этом один из компьютеровявляется файловым сервером, на клиентах выполняются приложения, вкоторых совмещены компонент представления и прикладной компонент(СУБД и прикладная программа).
Протокол обмена при этом представляетнабор низкоуровневых вызовов операций файловой системы. Такая16архитектура, реализуемая, как правило, с помощью персональных СУБДимеет очевидные недостатки - высокий сетевой трафик и отсутствиеунифицированного доступа к ресурсам.С появлением первых специализированных серверов баз данныхпоявилась возможность другой реализации модели доступа к удаленной базеданных. В этом случае ядро СУБД функционирует на сервере, протоколобмена обеспечивается с помощью языка SQL. Такой подход по сравнению сфайловым сервером ведет к уменьшению загрузки сети и унификацииинтерфейса "клиент-сервер".
Однако, сетевой трафик остается достаточновысоким,кромеадминистрированиетого,по-прежнемуприложений,невозможнопосколькувудовлетворительноеоднойпрограммесовмещаются различные функции.Позже была разработана концепция активного сервера, которыйиспользовалмеханизмхранимыхпроцедур.Этопозволилочастьприкладного компонента перенести на сервер (модель распределенногоприложения). Процедуры хранятся в словаре базы данных, разделяютсямежду несколькими клиентами и выполняются на том же компьютере, что иSQL-сервер.Преимущества такого подхода:возможно-централизованноеадминистрированиеприкладныхфункций,- значительно снижается сетевой трафик (т.к.
передаются не SQLзапросы, а вызовы хранимых процедур).Недостаток - ограниченность средств разработки хранимых процедурпо сравнению с языками общего назначения (C и Pascal).На практике обычно используется смешанный подход: простейшие прикладные функции выполняются хранимымипроцедурами на сервере; более сложные прикладные функции реализуются на клиентенепосредственно в прикладной программе; [9]17На стороне клиента выполняется код приложения, в которыйобязательно входят компоненты, поддерживающие интерфейс с конечнымпользователем, производящие отчеты, выполняющие другие специфичныедля приложения функции.
Клиентская часть приложения взаимодействует склиентской частью программного обеспечения управления базами данных,которая, фактически, является индивидуальным представителем СУБД дляприложения. Интерфейс между клиентской частью приложения и клиентскойчастью сервера баз данных, как правило, основан на использовании языкаSQL. Поэтому такие функции, как, например, предварительная обработкаформ, предназначенных для запросов к базе данных, или формированиерезультирующих отчетов выполняются в коде приложения. Наконец,клиентская часть сервера баз данных, используя средства сетевого доступа,обращается к серверу баз данных, передавая ему текст оператора языка SQL.В продуктах практически всех компаний сервер получает от клиентатекст оператора на языке SQL.
Сервер производит компиляцию полученногооператора. Далее (если компиляция завершилась успешно) происходитвыполнение оператора.Разработчики и пользователи информационных систем, основанных наархитектуре "клиент-сервер", часто бывают неудовлетворенны постоянносуществующими сетевыми накладными расходами, которые следуют изпотребности обращаться от клиента к серверу с каждым очереднымзапросом. На практике распространена ситуация, когда для эффективнойработы отдельной клиентской составляющей информационной системы вдействительности требуется только небольшая часть общей базы данных.Это приводит к идее поддержки локального кэша общей базы данных настороне каждого клиента.Фактически, концепция локального кэширования базы данных являетсячастным случаем концепции реплицированных баз данных.
Как и в общемслучае, для поддержки локального кэша базы данных программноеобеспечение рабочих станций должно содержать компонент управления18базами данных – упрощенный вариант сервера баз данных, который,например, может не обеспечивать многопользовательский режим доступа.Отдельнойпроблемойявляетсяобеспечениесогласованности(когерентности) кэшей и общей базы данных.
Здесь возможны различныерешения – от автоматической поддержки согласованности за счет средствбазового программного обеспечения управления базами данных до полногоперекладывания этой задачи на прикладной уровень.Преимуществами данной архитектуры являются:3. возможность,ввычислительнойбольшинствесистемыслучаев,междураспределитьнесколькимифункциинезависимымикомпьютерами в сети;4.
все данные хранятся на сервере, который, как правило, защищенгораздо лучше большинства клиентов, а также на сервере прощеобеспечить контроль полномочий, чтобы разрешать доступ к даннымтолько клиентам с соответствующими правами доступа;5. поддержка многопользовательской работы;6. гарантия целостности данных.Недостатками данной архитектуры являются:неработоспособность сервера может сделать неработоспособной всювычислительную сеть;администрирование данной системы требует квалифицированногопрофессионала;высокая стоимость оборудования;бизнес логика приложений осталась в клиентском ПО.При проектировании информационной системы, основанной наархитектуре "клиент-сервер", большее внимание следует обращать награмотность общих решений. Технические средства пилотной версии могутбыть минимальными (например, в качестве аппаратной основы сервера баз19данных может использоваться одна из рабочих станций).
После созданияпилотной версии нужно провести дополнительную исследовательскуюработу, чтобы выяснить узкие места системы. Только после этогонеобходимо принимать решение о выборе аппаратуры сервера, которая будетиспользоваться на практике.Увеличение масштабов информационной системы не порождаетпринципиальных проблем. Обычным решением является замена аппаратурысервера (и, может быть, аппаратуры рабочих станций, если требуется переходк локальному кэшированию баз данных). В любом случае практически незатрагивается прикладная часть информационной системы.Данный вид архитектуры называют еще архитектурой с "толстым"клиентом. Здесь логика представления данных и бизнес-логика размещаютсяна клиенте, который (скажем, в случае, когда сервером является СУБД)общается с логикой хранения и накопления данных на сервере, используяязык структурированных запросов SQL.
Однако необходимость установки"толстых клиентов", требующих значительного количества специальныхбиблиотек и специальной настройки окружения, на большое числопользовательских компьютеров с различными операционными средами, какправило, вызывает массу проблем.Как альтернатива возникла также двухзвенная архитектура "с тонкимклиентом".Приэтомвидеалепрограмма-клиентреализуетлишьграфический интерфейс пользователя (GUI) и передает/принимает запросы, ався бизнес-логика выполняется сервером. В идеале клиентом является простоинтернет-браузер, который имеется в стандартной операционной сределюбого пользовательского компьютера и не требует специальной настройки,установки специализированного ПО и т.п. К сожалению, такая схема тоже несвободна от недостатков, хотя бы уже потому, что серверу иногдаприходится брать на себя несвойственные для него функции реализациибизнес логики приложения (например, серверу СУБД приходится выполнятьрасчеты).
[10]202.2.3 Многоуровневая архитектура клиент-сервер (Multitier architecture).Multitier architecture - разновидность архитектуры клиент-сервер, вкоторой функция обработки данных вынесена на один или несколькоотдельных серверов. Это позволяет разделить функции хранения, обработкиипредставленияданныхдляболееэффективногоиспользованиявозможностей серверов и клиентов.Средимногоуровневойархитектурыклиент-сервернаиболеераспространена трехуровневая архитектура (трехзвенная архитектура, threetier), предполагающая наличие следующих компонентов приложения:клиентское приложение (обычно говорят "тонкий клиент" или терминал),подключенное к серверу приложений, который в свою очередь подключен ксерверу базы данных.Схематически такую архитектуру можно представить, как показано нарис 2.2.3.1.Рис.