Принципы построения распределенных информационных приложений. Распределенное трех уровневое приложение. Необходимость использования приложений в средней школе. Системы управления контентом для создания сайта. Анализ сайтов учителей начальных классов.
Краткое сожержание материала:

Размещено на

1. Основные принципы построения распределенных информационных приложений

1.1 Клиент-серверная система

Клиент-сервер - это вид распределенной системы, в которой есть сервер, выполняющий запросы клиента, причем сервер и клиент общаются между собой с использованием того или иного протокола.

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

Понятие архитектуры клиент-сервер в системах управления предприятием связано с делением любой прикладной программы на компоненты или слои. Наиболее часто такая архитектура имеет три компонента

· компонент представления (визуализации) данных;

· компонент прикладной логики;

· компонент управления базой данных.

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

Для локальных приложений, полностью работающих на ПЭВМ (например, Word или Excel), все эти компоненты собраны вместе и не могут быть распределены между различными компьютеры. Такая программа является монолитной и использует для выполнения ресурсы только того компьютера, на котором выполняется.

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

Критерием, позволяющим отнести прикладную программы к архитектуре клиент-сервер, является то, что хотя бы один из трех ее компонентов полностью выполняется на другом компьютере, и взаимодействие между компонентами на разных компьютерах осуществляется через ту или иную сетевую среду посредством передачи запросов на получение того или иного ресурса.

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

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

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

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

Компонент хранения базы данных осуществляет физические операции, связанные с хранением данных, чтением информации из базы данных и записью в нее. В архитектуре клиент-сервер этот компонент всегда выполняется на сервере. [38]

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

1.2 Распределенное трех уровневое приложение

Трехуровневое приложение включает следующие:

· уровень представления

· уровень бизнес-логики

· уровень доступа к данным

Уровень представления представляет собой какую-либо разновидность «тонкого» клиента, который только вызывает сервер, отображает данные и принимает ввод от пользователя.

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

Уровень доступа к данным обычно представляет собой сервер базы данных.

На практике эти три уровня, как правило, располагаются на разных машинах. Трехуровневая модель (three-tier model) позволяет обеспечить работу гораздо большего числа клиентов, чем двухуровневая модель, состоящая только из базы данных и клиентского приложения («толстого» (fat) клиента). Трехуровневая модель является более гибкой, т. к. при изменении алгоритмов обработки данных часто достаточно изменить ПО на машине промежуточного звена, которая может обслуживать множество клиентских машин. Кроме того, мощные машины промежуточного звена могут выдерживать значительно большие нагрузки, чем клиентские машины. Введение промежуточного звена также облегчает синхронизацию доступа к базе данных. [38]

Рис. 1.1. Взаимодействие в 3-уровневой архитектуре

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

Рис. 1.2. Функциональная схема 3-уровневого приложения

3-х уровневая архитектура подразумевает четкое выделение бизнес-логики. Интересно отметить, что сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier.

Достоинства трехуровневого приложения. По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трехуровневой архитектуры:

· масштабируемость

· конфигурируемость - изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней.

· высокая безопасность

· высокая надежность

· низкие требования к скорости канала (сети) между терминалами и сервером приложений

· низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон.

Недостатки трехуровневого приложения. Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трехуровневой архитектуры:

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

· высокие требования к...