Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Классификация по способу организации





 

По способу организации групповые и корпоративные информационные системы

подразделяются на следующие классы (рис. 1.3):

q системы на основе архитектуры файл-сервер;

q системы на основе архитектуры клиент-сервер;

q системы на основе многоуровневой архитектуры;

q системы на основе Интернет/интранет-технологий.

 

 

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

Таблица 1.1. Типовые функциональные компоненты информационной системы

 

Обозначение Наименование Характеристика
PS Presentation Services (средства представления) Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими то, что сообщает ему компонент логики представления PL, с использованием соответствующей программной поддержки
Обозначение Наименование Характеристика  
PL Presentation Logic Управляет взаимодействием между пользователем  
  (логика и ЭВМ. Обрабатывает действия пользователя  
  представления) при выборе команды в меню, нажатии кнопки  
    или выборе элемента из списка  
BL Business Набор правил для принятия решений, вычислений  
  or Application Logic и операций, которые должно выполнить приложение  
  (прикладная логика)    
DL Data Logic (логика Операции с базой данных (SQL-операторы), которые  
  управления данными) нужно выполнить для реализации прикладной логики  
    управления данными  
DS Data Services Действия СУБД, вызываемые для выполнения логики  
  (операции с базой управления данными, такие как манипулирование  
  данных) данными, определения данных, фиксация или откат  
    транзакций и т. п. СУБД обычно компилирует  
    SQL-предложения  
FS File Services Дисковые операции чтения и записи данных для СУБД  
  (файловые операции) и других компонентов. Обычно являются функциями  
    операционной системы (ОС)  

Архитектура файл-сервер

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интер­претации.

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

ПРИМЕЧАНИЕ:

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

Архитектура клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-сервер­ных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, пони­мающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД — наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже сер­верные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработ­ки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.

Большинство конфигураций клиент-сервер использует двухуровневую модель, в ко­торой клиент обращается к услугам сервера. Предполагается, что диалоговые ком­поненты PS и PL размещаются на клиенте, что позволяет обеспечить графиче­ский интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое опреде­ление архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД — на сервере (рис. 1.4.).

Поскольку эта схема предъявляет наименьшие требования к серверу, она обла­дает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, пото­му что там находится логика принятия решения. Такая схема приводит к допол­нительному усложнению администрирования приложений, разбросанных по раз­личным клиентским узлам.

 

Рис. 1.4. Классический вариант клиент-серверной информационной системы

 

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия реше­ний оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура — процедура с операторами SQL для доступа к БД, вызывае­мая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выпол­нения и сокращает нагрузку на сервер.

Хранимые процедуры улучшают целостность приложений и БД, гарантируют акту­альность коллективно используемых операций и вычислений. Улучшается сопро­вождение таких процедур, а также безопасность (нет прямого доступа к данным).

ПРИМЕЧАНИЕ:

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

 

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

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

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользовате­лей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

q нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программ­ный интерфейс для вызова приложения на среднем уровне;

q средний уровень представляет собой сервер приложений, на котором выполня­ется прикладная логика BL и с которого логика обработки данных DL вызыва­ет операции с базой данных DS;

q верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых опера­ций FS (без риска использования хранимых процедур).

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

Централизация логики приложения упрощает администрирование и сопровожде­ние. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их спе­циалистам узкого профиля. Наконец, изменения прикладной логики не затраги­вают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сер­вер приложений с помощью монитора транзакций обеспечивает интерфейс с кли­ентами и другими серверами, может управлять транзакциями и гарантировать це­лостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.

С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ори­ентированы на среду UNIX, однако прикладные серверы можно строить на базе Microsoft Windows NT с использованием вызова удаленных процедур для органи­зации связи клиентов с сервером приложений. На практике в локальной сети мо­гут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инстру­ментальные средства для гибкой сегментации приложений клиент-сервер по раз­личным узлам сети.

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







Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.