 |
Логическая архитектура системы SFA c централизованной архитектурой
|
|
|
|
Увеличить
Источник: "Системные технологии", 2009
Средой передачи данных могут служить любые каналы связи. Ввиду повсеместной доступности используется, как правило, интернет. При этом эксперты рынка рекомендуют не забывать о критически важной вещи: пользователи с КПК должны работать через автономный модуль, так как беспроводные каналы связи в настоящее время остаются самыми ненадежными из всех доступных. Остальные же пользователи (офисные сотрудники) должны иметь возможность подключаться к системе через интернет с помощью любого доступного веб-браузера. Это очень удобно, поскольку позволяет не привязываться к одному рабочему месту.
Основным отличием централизованной архитектуры от распределенной является отсутствие дополнительных аппаратно-программных модулей SFA на каждой территориально выделенной площадке филиала, что влечет за собой ряд ключевых преимуществ. Во-первых, это малые первоначальные и дальнейшие вложения в инфраструктуру системы. Торговой компании нет необходимости обустраивать каждый узел сети. Нужно всего лишь организовать ядро системы, в дальнейшем модернизируя только один программно-аппаратный комплекс. Это позволит существенно уменьшить срок окупаемости проекта SFA. Второй существенный плюс - малая трудоемкость и простота внедрения. Фактически ритейлеру необходимо развернуть и настроить лишь центральный узел системы. Это несравнимо по трудозатратам с внедрением распределенной архитектуры и, соответственно, дает заказчику возможность уменьшить финансовые вложения на старте проекта.
Упрощается и задача по поддержке работоспособности системы – как с точки зрения денег, так и с точки зрения ресурсов. Ритейлеру придется обслуживать только один центральный узел распределенной сети, что минимизирует расходы на обслуживание SFA. Например, экономия на затратах по технической поддержке централизованной системы составляет более 50% по сравнению с поддержкой распределенной архитектуры. А среднестатистическое вероятное время простоя системы меньше минимум на 20% в год. Следовательно, возможная недополученная прибыль вследствие простоев системы тоже меньше на 20%.
|
|
|
Важным преимуществом централизованной архитектуры является также безопасность хранения данных. Обеспечить защиту распределенной информации значительно сложнее. Кроме того, создание сравнимой защищенности распределенной информации будет стоить во много раз дороже, чем централизованной. В случае же, когда вся информация хранится в центральной базе данных, ее гораздо проще защитить от несанкционированного доступа и злонамеренного разрушения. Каждый пользователь в центральной базе видит только свою часть данных - в зависимости от делегированных прав доступа.
При централизованной архитектуре торговой компании гораздо проще расширить партнерскую сеть или сменить партнера, на базе которого работает эксклюзивная торговая команда производителя. Для запуска в работу по общей схеме нового дистрибутора достаточно удаленно установить модуль интеграции с системой. Не требуется закупать дополнительное оборудование и программное обеспечение, не нужен даже выезд специалиста. Все это влечет за собой минимизацию временных и финансовых затрат на запуск.
59. Архитектура "файл-сервер".
Сетевое многопользовательское приложение строится по принципу файл-серверной архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файловый сервер принимает запросы, поступающие по сети от компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо управляет файлами MDB, содержащими данные. Единственная связь между этими независимыми действиями — файл блокировок (файл, который имеет имя, совпадающее с именем файла приложения, но с расширением Idb), который обязательно создается для каждого файла базы данных с расширением mdb. При этом каждая копия Jet выполняет изменения индексов, работу с системными таблицами и другие функции, входящие в компетенцию СУБД.
|
|
|
В архитектуре "клиент-сервер" сервер базы данных не только обеспечивает доступ к общим данным, но и берет на себя всю обработку этих данных. Клиент посылает на сервер запросы на чтение или изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все необходимые изменения или выборки, контролируя при этом целостность и согласованность данных, и результаты в виде набора записей или кода возврата посылает на компьютер клиента.
Недостатки архитектуры с файловым сервером очевидны и вытекают главным образом из того, что данные хранятся в одном месте, а обрабатываются в другом. Это означает, что их нужно передавать по сети, что приводит к очень высоким нагрузкам на сеть и, вследствие этого, резкому снижению производительности приложения при увеличении числа одновременно работающих клиентов. Вторым важным недостатком такой архитектуры является децентрализованное решение проблем целостности и согласованности данных и одновременного доступа к данным. Такое решение снижает надежность приложения.
Архитектура "клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.
60. Архитектура "клиент-сервер".
Клиент-серверная система характеризуется наличием двух взаимодействующих самостоятельных процессов - клиента и сервера, которые, в общем случае, могут выполняться на разных компьютерах, обмениваясь данными по сети.
|
|
|
Процессы, реализующие некоторую службу, например службу файловой системы или базы данных, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посылки запроса и последующего ожидания ответа от сервера, называются клиентами (clients).
По такой схеме могут быть построены системы обработки данных на основе СУБД, почтовые и другие системы. Мы будем говорить о базах данных и системах на их основе. И здесь удобнее будет не просто рассматривать клиент-серверную архитектуру, а сравнить ее с другой - файл-серверной.
В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..
Приложение на рабочей станции "отвечает за все" - за формирование пользовательского интерфейса, логическую обработку данных и за непосредственное манипулирование данными. Файловый сервер предоставляет услуги только самого низкого уровня - открытие, закрытие и модификацию файлов. Обратите внимание - файлов, а не базы данных. Система управления базами данных расположена на рабочей станции.
Таким образом, непосредственным манипулированием данными занимается несколько независимых и несогласованных между собой процессов. Кроме того, для осуществления любой обработки (поиск, модификация, суммирование и т.п.) все данные необходимо передать по сети с сервера на рабочую станцию (см. рис. Сравнение файл-серверной и клиент-серверной моделей)
Рис. Сравнение файл-серверной и клиент-серверной моделей
В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер, делящие между собой те функции, которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т.п..
Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).
|
|
|
Таким образом, непосредственным манипулированием данными занимается один процесс. При этом, обработка данных происходит там же, где данные хранятся - на сервере, что исключает необходимость передачи больших объемов данных по сети.
61. Трехзвенная архитектура "клиент – сервер".
В традиционных архитектурах клиент/сервер (двухзвенных архитектурах) взаимодействие клиентской программы и сервера баз данных происходит напрямую. При этом вся логика обработки данных делится между клиентскими программами и серверами баз данных. На серверах баз данных производится первичная обработка данных с помощью механизма хранимых процедур, а их вторичная обработка данных выполняется на клиентском рабочем месте. При этом подходе при изменении структуры базы данных, сервера базы данных, порядка выполнения определенных операций над данными необходимо менять либо хранимые процедуры сервера, либо программы клиента. Первый вариант более предпочтителен, но все равно, для изменения процедуры, которой активно пользуются клиенты, необходимо произвести отключение пользователей от сервера. Одним из основных недостатков этого подхода является отсутствие возможности абстрагирования клиента от терминологии СУБД, от понятия СУБД, от конкретных серверов баз данных. Другим недостатком такого подхода является сильная нагрузка на клиентские программы из-за необходимости дополнительной обработки данных совместно с управлением интерфейсом с пользователем. Также при использовании двухзвенных архитектур возрастает "бесполезная" нагрузка на сеть, поскольку решение о том, нужны данные или нет, может быть принято при вторичной обработке на клиенте.
При использовании трехзвенных архитектур появляется возможность снять часть нагрузки с клиента и сервера баз данных на специально выделенный сервер приложений. В этом случае появляется возможность проводить вторичную обработку данных отдельно от обработки интерфейса с пользователем и передавать только актуальные данные от сервера приложений к клиенту. При изменении алгоритма обработки необходимо менять некоторые модули на сервере приложений, а не все клиентские программы. При использовании сервера приложений можно организовать общение клиента с СП в абстрактных терминах, а не в терминах СУБД.
|
|
|
Таким образом, при использовании сервера приложений можно решить ряд проблем, возникающих перед разработчиками традиционных двухзвенных систем.
Итак, идея сервера приложений заключается в разбиении приложения на две части - собственно клиента и сервера данного приложения. Причем сервер приложений может быть один на много приложений. Клиенты общаются с сервером приложений (или с серверами приложений, никто не запрещает иметь несколько серверов приложений). Клиенты посылают серверу приложений запросы, а получают ответы. Клиенты могут обратиться и непосредственно к серверу базы данных за теми или иными данными. Обращение за данными к серверу базы данных может производить и сервер приложений.
Таким образом, имеем три типа взаимодействующих компонент - сервер базы данных, приложение (клиент) и сервер приложения. Они могут взаимодействовать друг с другом по следующей схеме: 
Именно по причине наличия трех компонент (приложение, сервер приложения, сервер баз данных), подобная архитектура называется трехсвязной (английский термин three-tier architecture).
62. Подходы, реализованные в моделях технологии "клиент – сервер" (FS, RDA, DBS, AS модели).
Рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
FS-модель
Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.
Основные свойства:
- выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;
- играет роль компонент доступа к информационным ресурсам;
- в остальных узлах функционирует приложение, в кодах которого совмещены компоненты представления и прикладной;
- протокол обмена — набор низкоуровневых вызовов.
Технология: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на компьютере-клиенте.
Недостатки: высокий сетевой трафик; небольшое число операций манипулирования; недостаточные требования к безопасности.
RDA-модель
Основные свойства:
-коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте;
-доступ к информационным ресурсам обеспечивается операторами непроцедурного языка SQL.
Технология:
клиентский запрос направляется на сервер, где функционирующее ядро СУБД обрабатывает запрос и возвращает результат (блок данных) клиенту. Ядро СУБД выполняет пассивную роль;
инициатор манипуляций с данными — программы на компьютере-клиенте.
Достоинства:
-процессор сервера загружается операциями обработки данных;
-уменьшается загрузка сети, т.к. по сети передаются запросы на языке SQL;
-унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.
Недостатки:
удовлетворительное администрирование приложений в RDA-модели невозможно из-за совмещения в одной программе различных по своей природе функций (представления и прикладных).
DBS-модель
Реализована в реляционных СУБД Informix, Ingres, Oracle.
Основные свойства:
-основа модель-механизм хранимых процедур — средство программирования SQL-сервера;
-процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на компьютере, где функционирует SQL-сервер;
-компонент представления выполняется на компьютере-клиенте;
-прикладной компонент и ядро СУБД на компьютере-сервере базы данных.
Достоинства:
-возможность централизованного администрирования;
-вместо SQL-запросов по сети передаются вызовы хранимых процедур, что ведет к снижению сетевого трафика.
Недостатки:
-в большинстве СУБД недостаточно возможностей для отладки и типизирования хранимых процедур;
ограниченность средств для написания хранимых процедур.
На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.
AS-модель
Основные свойства:
-на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;
-этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);
-прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (AS);
-все операции над БД выполняются соответствующим компонентом, для которого AS — клиент.
RDA- и DBS-модели имеют в основе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.
В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, имеющий стандартизированные интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки транзакций.
Язык запросов — это искусственный язык, на котором делаются запросы к базам данных и другим информационным системам, особенно к информационно-поисковым системам.
SQL — де-факто стандартный язык запросов к реляционным базам данных.
Language Integrated Query — расширение для некоторых языков программирования в.NET Framework, добавляющее к ним SQL-подобный язык запросов.
XQuery — язык запросов, разработанный для обработки данных в формате XML.
XPath — язык запросов к элементам XML-документа.
|
|
|
