Добавлен: 04.04.2023
Просмотров: 279
Скачиваний: 2
Терминал – это интерфейсный (обычно графический) компонент, который представляет собой первый уровень, приложение для конечного пользователя. Первый уровень по требованиям безопасности не должен иметь прямых связей с базой данных, по требованиям масштабируемости быть нагруженным основной бизнес-логикой и по требованиям надежности хранить состояние приложения. На первый уровень может быть вынесена и чаще всего выносится простейшая бизнес-логика, такая как: интерфейс авторизации, проверка вводимых значений на допустимость и соответствие формату, алгоритмы шифрования, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. Второй уровень является основным. На нем сосредоточена большая часть бизнес-логики. К нему не относятся экспортируемые на терминалы, фрагменты. На третьем уровне хранятся процедуры и триггеры.
Сервер базы данных выносится на третий уровень и обеспечивает хранение данных. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Третий уровень может представлять собой базу данных вместе с хранимыми процедурами, триггерами и схемой, которая описывает приложение в терминах реляционной модели, а второй уровень строится как программный интерфейс, который связывает клиентские компоненты с прикладной логикой базы данных.
В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов.
С точки зрения надежности, безопасности, масштабирования конфигурации сервер базы данных находится на выделенном компьютере (кластере). К нему по сети подключены один или несколько серверов приложений. К серверам-приложениям подключаются терминалы.
Плюсами данной архитектуры являются:
• масштабируемость;
• клиентское ПО не нуждается в администрировании;
• конфигурируемость – изолированность уровней друг от друга, что позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или в том числе при плановом обслуживании на одном из уровней;
• высокая надежность и безопасность;
• низкие требования к производительности и техническим
характеристикам терминалов, следовательно, снижение их стоимости;
• очень низкие требования к скорости сети между терминалами и сервером приложений;
Минусами данной архитектуры являются:
• более высокая сложность создания приложений;
• повышение сложности серверной части, что ведет к затратам на администрирование и обслуживание;
• сложности в разворачивании и администрировании;
• высокие требования к производительности серверов приложений и серверов базы данных, а, следовательно, высокая стоимость серверного оборудования;
• высокие требования к скорости канала-сети между сервером базы
• данных и серверами приложений.
Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено в рамках технологии «клиент-сервер». В них наравне с клиентской частью приложения и сервером баз данных появились серверы приложений (ApplicationServers).
В идеальном виде программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ, затем сервер приложений реализует бизнес-логику и дальше обращается с запросами к серверу «третьего уровня» (например, серверу базы данных за данными), который обслуживает запросы сервера приложений. Программа-клиент, таким образом, может быть «тонкой».
Преимущества такой архитектуры очевидны:
так как звенья не обмениваются между собой большими объемами информации, то снижаются нагрузки на сеть;
изменения на каждом из звеньев можно осуществлять независимо;
обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего все звенья, в том числе обновление СУБД, терминального оборудования, серверного парка и т.д.;
приложения могут создаваться на стандартных языках третьего или четвертого поколения (C/C++, Java).[1]
Следующим логическим шагом является увеличение числа звеньев. Здесь вся бизнес-модель представляется как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы компонентов, которые взаимодействуют между собой на разных уровнях. Программные системы могут являться клиентом для одних компонентов и серверами для других.
Ключевой проблемой систем, которые основаны на двухзвенной архитектуре «клиент-сервер», или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. И если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Более проблемный аспект этого вопроса связан с возможностью использовать разные представления данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Единое решение проблемы мобильности такого рода систем - использование технологий, реализующих протоколы удаленного вызова процедур (RPC - RemoteProcedureCall) стандартизованным и платформо-независимым способом. При использовании указанных технологий обращение к сервису в удаленном узле представляется как обычный вызов процедуры (методы удаленных объектов). Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Особенность сетевой среды и протоколов скрыта от прикладного программиста.[2]
При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-
независимые форматы, и затем преобразование в форматы данных сервера.
При передаче ответных параметров производятся обратные преобразования.
Таким образом, если система реализована на основе стандартного пакета
RPC, она с легкостью может быть перенесена в любую открытую среду.
Некоторые авторы представляют многозвенную архитектуру
(трехзвенную) в виде пяти уровней (рис 4)
1. Представление;
2. Уровень представления;
3. Уровень логики;
4. Уровень данных;
5. Данные.
Рис. 4. Пять уровней многозвенной архитектуры «клиент-сервер»
К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы таблицы стилей, изображения.
Уровень представления содержит все, что относится к общению пользователя с системой. К основным функциям слоя представления можно отнести отображение информации и интерпретацию вводимых пользователем команд с реконструкцией их в определённые операции в контексте логики и данных.[6]
Уровень логики включает главные функции системы, которые предназначаются для достижения определенной цели. К этим функциям можно отнести вычисления на основе вводимых и хранимых данных,проверку всех элементов данных и обработку команд, поступающих от слоя представления и передачу информации уровню данных.
Под уровнем доступа к данным понимается подмножество функций, которые обеспечивают взаимодействие со сторонними системами, выполняющими задания в интересах приложения.
Данные системы обычно хранятся в базе данных. [6]
Вывод:
Двухуровневая архитектура по сравнению с многоуровневой простая, потому что запросы управляются одним сервером. Однако она ненадежна и для нее используются повышенные требования к производительности сервера. У многоуровневой архитектуры распределение действий идет между серверами. Это дает высокую гибкость, защиту и производительность. Основная проблема данных систем заключается в том, что нет мобильности в классе аппаратно-мобильных сред.3. Программные средства разработки
3.1 Универсальные средства
Для разработки клиентских приложений существует большое число универсальных пакетов программ, которые имеют возможность выполнить соединение с сервером и разработать для пользователя удобный графический интерфейс, позволяющий эффективно работать с данными. Часть из этих средств для разработки приложений в архитектуре «клиент-сервер» перечислены в таблице.[7]
3.2 Персональные СУБД
При разработке клиентских приложений в большинстве случаев вместо универсальных средств разработки удобнее использовать персональные СУБД. Использование персональных СУБД дает не только эффективно организовывать работу с бизнес-правилами, но и возможность поддержать независимую работу клиентского приложения за счет наличия собственных форматов хранения данных. Краткая характеристика некоторых персональных СУБД приведена в таблице.[2]
3.3 Программы расширения серверной части
Основной причиной использования программ-расширений серверной части на промежуточном уровне является возможность применять стандарты, существующих для двух крайних уровней, путем осуществления трансляции между ними. Прочие применения расширений серверной части состоят в поддержании соединений между БД с целью сократить трафик в сети и в поддержании резерва соединений между БД для сокращения затрат ресурсов на открытие/закрытие БД. Расширения серверной части к тому же поддерживают взаимозаменяемость в своих стандартных интерфейсах. В связи с чем серверы БД и Web-серверы можно сравнительно легко заменять или наращивать.[2]
Существует три категории расширений серверной части: с API, обычным CGI и гибридным CGI.
Вывод:
Быстродействие - это основной фактор для разработки систем для клиент-серверной архитектуры. Использование различных программных средств быстрой разработки позволяет разработчикам создавать прикладные системы для клиент-серверной архитектуры в очень короткие сроки.
Заключение
В результате выполнения курсовой работы можно сделать выводы.
В современном мире широко используются сетевые технологии «клиент-сервер». Они создают надежные, целостные, многопользовательские информационные системы. Технологии «клиент-сервер» содержат централизованную базу данных, которая не зависит от аппаратной части (также может и программной) сервера баз данных. Они поддерживают графический интерфейс пользователя на клиентских станциях. Станции в свою очередь связаны локальной сетью.