Разделы



Физическая архитектура многоуровневой экономической информационной системы.

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

Архитектура файл/сервер ( File Server – FS ) до недавнего времени являлась базовой для локальных сетей персональных компьютеров. Она была достаточно распространенной среди разработчиков, использующих такие СУБД, как FoxPro , CAClipper , Paradox , dBase , Clarion . Суть архи тектуры файл/сервер заключается в следующем. Один из компьютеров в сети является файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Сервер файловой системы, исполняющий ся на нем под управлением некоторой сетевой операционной системы (наиболее часто Novell NetWare ), играет роль компонента доступа к ин формационным ресурсам. На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент. Все данные, необходимые приложению, разме щены на одном или нескольких файловых серверах.

Архитектура файл/сервер послужила фундаментом для расширения возможностей персональных СУБД в направлении поддержки много пользовательского режима. В МРИС, созданных по такой архитектуре на нескольких персональных компьютерах выполняется как пользователь ская программа, так и СУБД (или её часть), а сама база данных хранится в разделяемых файлах, которые находятся на файловых серверах. В про цессе работы пользовательская программа обращается к локальной части СУБД, которая в свою очередь исполняет запрос непосредственно на сервере файловой системы, содержащем базу данных. В процессе исполнения запроса файловый сервер представляет доступ по сети к требуемым данным, а СУБД, получив данные, выполняет над ними действия, которые были декларированы в пользовательской программе (рис.5).

Недостатками модели файлового сервера являются: высокий сете вой трафик (на сетевую станцию передается множество лишних данных, отбрасываемых после проведения поиска в файлах базы данных; поскольку поиск происходит на компьютере клиента пославшего запрос, то по сети необходимо передавать многочисленные фрагменты индекс ных файлов); обработка данных на пользовательских местах; отсутствие адекватных средств безопасности (защита только на уровне файловой системы). Архитектура файл/сервер может оказаться пригодной для реа лизации небольших прикладных программ, используемых в рамках ра бочей группы или малого предприятия, где требования к безопасности и скорости доступа невелики. Стоимость разработки этих систем чрезвычайно мала, а для их построения нет необходимости в высокой квалифи кации персонала.

п»ї

На смену архитектуры файл/сервер для обеспечения решения задачи “облегчения” клиентских мест была разработана архитектура клиент/сервер. Под “облегчением” следует понимать использование на пользовательских местах менее производительных и, соответственно, более дешевых рабочих станций. Таким образом, используя множество недорогих компьютеров, разработчики систем клиент/сервер могут в полном объеме эмулировать вычислительную мощность Main Frame , распределяя вычислительные ресурсы по различным рабочим станциям и серверам. Каждый из них берет на себя свою часть вычислительной нагрузки, используя информацию совместно с другими компьютерами, подключенными к сети, и мощность системы в целом повышается не за счет наращивания производительности отдельного компьютера, а за счет суммирования вычислительных ресурсов.

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

Архитектура клиент/сервер предполагает распределение вычислительной нагрузки между двумя (или более) отдельными процессами21. Если процессов всего два, то один из них является клиентом, а другой сервером. Сервер – это логический процесс, который обеспечивает обслуживание запрашивающих его процессов и возврат результатов рабо ты. Клиент – это процесс, посылающий серверу запрос на обслуживание. Хотя и клиент, и сервер могут находиться на одном и том же компьютере, большинство систем архитектуры клиент/сервер запускают клиент ский процесс на одном компьютере, а процесссервер на другом, исполь зуя для обмена информацией сетевые связи. При этом один процесс может работать независимо от другого, выполнять определенные задания и разделять вычислительную нагрузку. Процессы взаимодействуют по схеме "запросответ ". Клиент выполняет активную функцию, т. е. инициирует запросы, а сервер пассивно на них отвечает. При этом в различ ный момент времени роли процесса могут меняться, так например неко торый процесс может одновременно выполнять функции сервера по от ношению к одному процессу и клиента по отношению к другому.

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

В современной МРИС должны присутствовать функциональные части, обеспечивающие хранение данных в базе данных (уровень храни лище данных), обработки (уровень бизнесправила ) пользовательского интерфейса (уровень документы). Как было отмечено выше, каждая из этих частей может быть реализована независимо от двух других. Напри мер, не изменяя программные модули, обеспечивающие хранение и об работку данных, можно изменить интерфейс с пользователем таким об разом, что одни и те же данные будут совершенно поразному отображаться на рабочем столе (экране монитора) в виде текстов, таблиц, диаграмм и т.д.; не меняя программные модули обеспечивающие хранение данных определенных форматов, можно внести изменения в програм мы, обеспечивающие их обработку, например изменив алгоритм выпол нения выборки, фильтрации или сортировки; и наконец, не меняя про граммные модули представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, например, к другой файловой системе.

п»ї

На практике происходит разделение МРИС на несколько взаимо действующих компонент, которые в свою очередь могут выступать в ро ли клиента (и/или) сервера. Клиент взаимодействует с сервером по строго определенному алгоритму: установление связи с сервером; запрос конкретного вида обслуживания; получение от сервера результатов запроса; разрыв связи с сервером. Клиент и сервер могут выполняться как на одном, так и на разных компьютерах. Связь между клиентом и сервером в каждом конкретном случае может быть осуществлена с помощью различных механизмов: локальная вычислительная сеть; глобальная сеть; совместно используемая память одного компьютера.

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

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

Различают двухуровневую и трехуровневую архитектуру клиент/сервер. В двухуровневой архитектуре три логические компоненты распределяют между двумя физическими модулями. Обычно данные располагаются на сервере (например, сервере базы данных), интерфейс с пользователем  на стороне клиента, а бизнеслогику распределяют меж ду клиентской и серверной компонентой. В этом и заключается основ ной недостаток двухуровневой архитектуры, значительно усложняющий разработку программных решений под клиент /сервер. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух физических частей  либо на стороне клиента: – так называемый "толстый" клиент, либо на сервере: – "тонкий" клиент22.

Для решения перечисленных проблем используются многоуровневые (три и более уровней ) архитектуры клиент/сервер. Такие архитекту ры более оптимально распределяют компоненты обработки данных, ко торые в этом случае выполняются на одном или нескольких отдельных серверах. Данные компоненты выполняют функции сервера для интер фейсов с пользователями и клиента  для серверов баз данных. Кроме того, различные серверы приложений могут взаимодействовать между со бой, осуществляя точное разделение системы на функциональные блоки, выполняющие определенные роли. Трехуровневая архитектура кли ент/сервер обеспечивает распределение полномочий пользователей, ко торые получают права доступа не к самой базе данных, а к определен ным функциям сервера приложений. Характерной особенностью много уровневых архитектур является использование менеджеров транзакций, которые позволяют одному серверу приложений одновременно обмени ваться данными с несколькими серверами баз данных. Менеджер транзакций используется для управления распределенными разнородными операциями и согласования действий различных компонентов информа ционной системы. Примером такого согласования может являться си туация, когда часть информации на сервере баз данных хранится в фор мате Oracle , часть в формате Informix , а часть в виде текстовых файлов.

Рассмотрим более подробно подходы к построению приложений в архитектуре клиент/сервер. Различия в реализациях приложений клиент/сервер определяются в основном тем, как логические компоненты взаимосвязаны друг с другом и каким образом они распределяются меж ду компьютерами в сети. Наиболее известными моделями реализации являются:

♦       модель доступа к удаленным данным ( Remote Data Access – RDA );

♦       модель сервера базы данных ( DataBase Server – DBS );

♦       модель распределенной функциональной логики;

♦       модель распределенных услуг;

♦       распределенная одноранговая модель.

Модель доступа к удаленным данным ( RDA –модель) строится на основе специального языка запросов к серверу базы данных ( SQL серверу). В RDA модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютереклиенте , менед жер ресурсов и данные находятся на сервере. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как пра вило, операторами специального языка запросов23 или вызовами функ ций специальной библиотеки если имеется соответствующий интерфейс прикладного программирования. Клиент направляет запросы к менедже ру информационных ресурсов, находящемуся на удаленном компьютере, например, серверу базы данных). Последний обрабатывает и выполняет запросы, и возвращает клиенту результат, оформленный как блок данных. При этом инициатором манипуляций с данными выступают программы, выполняющиеся на компьютерах–клиентах, в то время как менеджеру ресурсов отводится пассивная роль – обслуживание запросов клиентов (рис. 6). Говоря об архитектуре клиент/сервер, в большинстве случаев имеют в виду именно эту модель.

Главным достоинством данной модели является возможность ис пользования клиентских пользовательских мест и разгрузка сервера. Пе ренос компонента представления и прикладного компонента на компью теры–клиенты обеспечивает разгрузку сервера, который освобождается от несвойственных ему функций; процессор (процессоры) сервера целиком осуществляет обработку данных, запросов и транзакций. По сравне нию с моделью файлового сервера уменьшается загрузка сети, так как по ней передаются только запрашиваемые клиентом данные, а не все файлы, в которых они содержатся. В настоящий момент существует множе ство инструментальных средств, обеспечивающих быстрое создание на стольных приложений, работающих с SQL –ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя и содержат средства автоматической генерации кода, в которых сме шаны прикладные функции и функции представления. Из наиболее популярных инструментальных средств можно назвать Power Builder от фирмы Powersoft , Visual Basic от Microsoft , Delphi от Inprise ( Borland ).


Основным недостатком RDA –модели является то, что взаимодействие клиента и сервера посредством SQL –запросов существенно загружа ет сеть. Поскольку приложение является нераспределенным и вся его ло гика реализована на компьютере клиенте, то приложение нуждается в передаче по сети данных большого объема, возможно избыточных. При увеличении числа клиентов сеть становится узким местом, снижая быст родействие МРИС.

Основу модели сервера базы DBS –модели составляет механизм хра нимых процедур – средство программирования ядра СУБД (реализован ный, например, в Oracle , Informix , Sybase , Adabas ). Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для ка ждой конкретной СУБД. Во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, чем выполнение программ, написанных на языках третьего и четвертого по коления.

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


Преимущества DBS –модели по сравнению с RDA –моделью характеризуется: – возможностью централизованного администрирования информационной системы; снижением сетевого трафика;24 сосредоточе нием всех прикладных функций на сервере, что делает менее болезненным процесс наращивания и сопровождения МРИС.

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

Часто вместо RDA – или DBS –моделей применяется смешанная мо дель распределенной функциональной логики . В этом случае поддержка целостности базы данных и некоторые простейшие прикладные функции реализованы как хранимые процедуры ( DBS –модель), а более сложные функции реализуются в прикладной программе, которая выполняется на компьютере клиенте ( RDA –модель). Такой подход позволяет обойти ограничения моделей, описанных выше, так как прикладные функции (функциональную логику приложения) можно разумно распределить между компьютером–клиентом и сервером, исходя из соображений уменьшения сетевого трафика и вычислительной нагрузки компьютеров. Недостатком модели распределенной функциональной логики являются ограниченные возможности управления. В приложениях с распределен ными функциями компоненты клиента и сервера настолько тесно связа ны, что изменить одну часть приложения, не затрагивая другую, доволь но трудно.

Модель распределенных услуг25 предусматривает не столь жесткие связи между клиентом и сервером и более гибкие формы распределен ной обработки. В этой модели компоненты приложения (представления, прикладной, доступа к информационным ресурсам) являются автономными и взаимодействуют через сеть при помощи стандартных интер фейсов. Компонент представления часто располагается на персональном компьютере, прикладной компонент (называемый также сервером при ложения) выполняется сервером среднего уровня под управлением операционной системы UNIX или Windows NT , а компонент доступа к данным и сами данные располагаются либо на мощных UNIX –серверах, либо на больших или миниЭВМ. Однако на практике все три компонента могут с успехом выполняться и на одном компьютере.

Основным элементом трехзвенной схемы является сервер приложе ния ( Application Server – AS ). В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как сервис ( service ) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый из них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент прило жения ( Application Client – AC ). Детали реализации прикладных функ ций в серверах приложений полностью скрыты от клиентов. Таким обра зом, нет необходимости, встраивать какую–либо функцию в каждое выполняющееся приложение, достаточно установить ее на сервер приложения и обеспечить доступ других приложений к соответствующему сервису. Кроме того, разработчики могут создавать, изменять или переносить любые компоненты приложения, практически не затрагивая других (рис. 8).

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

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

Модель распределенных услуг и одноранговая распределенная модель имеют более универсальный характер, чем RDA – и DBS – модели. Четкое разграничение логических компонентов и рациональный выбор программных сре дств дл я их реализации обеспечивают такой уровень гибкости, открытости и производительности, который невозможен в RDA – и DBS –моделях.

Несмотря на все преимущества технологии клиент/сервер, реализация МРИС, построенной по этой технологии, требует значительных финансовых вложений и характеризуется высокими начальными затратами на разработку и обучение пользователей; сложностью и высокой стоимостью поддержки и администрирования системы.

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

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

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

Читать далее: Реализация многоуровневой экономической информационной системы с использованием CORBA и Java & Intranet .