Введение в распределенные системы. Архитектура распределенной системы управления на основе реконфигурируемой многоконвейерной вычислительной среды L-Net Распределенная архитектура сети

(Материал сайта http://se.math.spbu.ru)

Введение.

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

Существует шесть основных характеристик распределенных систем.

1. Совместное использование ресурсов. Распределенные системы допускают совместное использование как аппаратных (жестких дисков, принтеров), так и программных (файлов, компиляторов) ресурсов.
2. Открытость. Это возможность расширения системы путем добавления новых ресурсов.
3. Параллельность. В распределенных системах несколько процессов могут одновременно выполнятся на разных компьютерах в сети. Эти процессы могут взаимодействовать во время их выполнения.
4. Масштабируемость . Под масштабируемостью понимается возможность добавления новых свойств и методов.
5. Отказоустойчивость. Наличие нескольких компьютеров позволяет дублирование информации и устойчивость к некоторым аппаратным и программным ошибкам. Распределенные системы в случае ошибки могут поддерживать частичную функциональность. Полный сбой в работе системы происходит только при сетевых ошибках.
6. Прозрачность. Пользователям предоставляется полный доступ к ресурсам в системе, в то же время от них скрыта информация о распределении ресурсов по системе.

Распределенные системы обладают и рядом недостатков.

1. Сложность . Намного труднее понять и оценить свойства распределенных систем в целом, их сложнее проектировать, тестировать и обслуживать. Также производительность системы зависит от скорости работы сети, а не отдельных процессоров. Перераспределение ресурсов может существенно изменить скорость работы системы.
2. Безопасность . Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться и перехватываться. Поэтому в распределенной системе намного труднее поддерживать безопасность.
3. Управляемость . Система может состоять из разнотипных компьютеров, на которых могут быть установлены различные версии операционных систем. Ошибки на одной машине могут распространиться непредсказуемым образом на другие машины.
4. Непредсказуемость . Реакция распределенных систем на некоторые события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как эти параметры могут постоянно изменятся , поэтому время ответа на запрос может существенно отличаться от времени.

Из этих недостатков можно увидеть, что при проектировании распределенных систем возникает ряд проблем, которые надо учитывать разработчикам.

1. Идентификация ресурсов . Ресурсы в распределенных системах располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система URL(унифицированный указатель ресурсов), которая определяет имена Web-страниц.
2. Коммуникация . Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако в некоторых случаях, когда требуется особая производительность или надежность, возможно использование специализированных средств.
3. Качество системного сервиса . Этот параметр отражает производительность, работоспособность и надежность. На качество сервиса влияет ряд факторов: распределение процессов, ресурсов, аппаратные средства и возможности адаптации системы.
4. Архитектура программного обеспечения . Архитектура ПО описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры является решающим фактором.

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

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

Про первые две модели было сказано уже не раз, остановимся подробнее на третьей.

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

Эта архитектура широко применяется в настоящее время и носит также название архитектуры веб-сервисов . Веб-сервис - это приложение, доступное через Internet и предоставляющее некоторые услуги, форма которых не зависит от поставщика (так как используется универсальный формат данных - XML) и платформы функционирования. В данное время существует три различные технологии, поддерживающие концепцию распределенных объектных систем. Это технологии EJB, CORBA и DCOM.

Для начала несколько слов о том, что такое XML вообще. XML - универсальный формат данных, который используется для предоставления Web-сервисов. В основе Web-сервисов лежат открытые стандарты и протоколы: SOAP, UDDI и WSDL.

1. SOAP (Simple Object Access Protocol ), разработанный консорциумом W3C, определяет формат запросов к Web-сервисам. Сообщения между Web-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes , иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
2. WSDL (Web Service Description Language). Интерфейс Web-сервиса описывается в WSDL-документах (а WSDL - это подмножество XML). Перед развертыванием службы разработчик составляет ее описание на языке WSDL, указывает адрес Web-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
3. UDDI (Universal Description, Discovery and Integration) - протокол поиска Web- сервисов в Internet (http://www.uddi.org/ ). Представляет собой бизнес-реестр, в котором провайдеры Web-сервисов регистрируют службы, а разработчики находят необходимые сервисы для включения в свои приложения.

Из доклада может показаться, что Web-сервисы - наилучшее и безальтернативное решение, и вопрос только в выборе средств разработки. Однако это не так. Альтернатива Web-службам существует, это семантический Web (Semantic Web ), о необходимости создания которого уже пять лет назад говорил создатель WWW Тим Бернерс-Ли .

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

Список литературы

1. Соммервилл И. Инженерия программного обеспечения.
2. Драница А. Java против.NET. - "Компьютерра ", #516.
3. Ресурсы интернет.

на основе реконфигурируемой многоконвейерной вычислительной среды L-Net

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

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

Архитектура распределенной системы управления

Обобщенная типовая архитектура распределенной системы управления (РСУ) включает в себя три иерархически связанных уровня: операторский уровень, уровень управления и уровень ввода-вывода (см. рис.1) .

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

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

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

Требования к РСУ

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

Обзор архитектур РСУ

Для проведения обзора архитектур РСУ были выбраны РСУ Siemens SIMATIC PCS 7 как одна из самых востребованных на рынке и RTS S3 как РСУ, реализованная на базе ОСРВ QNX.

Siemens SIMATIC PCS 7

Архитектура системы имеет все свойства обобщенной архитектуры РСУ . В качестве операторских станций выступают компьютеры на базе процессорной архитектуры x86 с ОС Windows и пакетом Siemens WinCC, предоставляющим ЧМИ. Имеются серверы с базами данных. Станции операторов, инженерные станции и серверы связаны локальной сетью на основе Ethernet. Операторский уровень связан с уровнем управления зарезервированной сетью Industrial Ethernet. На уровне управления находятся программируемые логические контроллеры (ПЛК) с возможностью резервирования за счет дублирования функционала. Имеется возможность подключаться к внешним системам и сетям и организовать удаленный доступ к системе.

RTS S3

Данная архитектура аналогично состоит из уровней обобщенной структуры РСУ . Операторские станции основаны на той же аппаратной платформе, что и в РСУ SIMATIC, но могут находиться под управлением как ОС Windows, так и Linux. Инженерные станции объединены с операторскими. Системой предоставляется единая среда разработки приложений. Сеть Ethernet соединяет узлы внутри операторского уровня и сам операторский уровень с уровнем управления с использованием стека протоколов TCP/IP. На уровне управления находятся промышленные компьютеры под управлением ОС QNX с собственной базой данных и возможностью резервирования путем дублирования функционала узла.

Недостатки описанных систем

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

Характеристики и функциональные особенности системы L-Net

При разработке системы L-Net ставилась задача создать такую систему управления, которая будет обладать нижеперечисленными характеристиками:

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

Для построения системы с вышеописанными характеристиками требуется операционная система, предназначенная преимущественно для создания систем управления и встраиваемых систем. Анализ существующих операционных систем показал, что наиболее подходящей операционной системой является ОС QNX 6 (Neutrino), которая обладает весьма эффективными ресурсораспределяющими и сетевыми возможностями . Широкие сетевые возможности обеспечиваются сетевым протоколом Qnet. Он решает задачу надежности и динамической балансировки нагрузки каналов связи, но при этом не решаются проблемы отказоустойчивости системы в целом . В результате была разработана инновационная система управления, основанная на распределенной реконфигурируемой многоконвейерной вычислительной среде. Разработанная система имеет одноранговую архитектуру, включающую три логических блока: блок ввода-вывода, блок коммутаторов общего назначения и блок реконфигурируемой вычислительной среды (РВС) (см. рис.2).

Основными преимуществами данной архитектуры являются:

• Одноранговый тип
• Децентрализованность
• Масштабируемость
• Пространственная распределенность

Функциональные особенности данной архитектуры:

• Конвейерная обработка данных
• Аппаратное резервирование
• Распределение нагрузки
• Реконфигурация «на лету»

На первом уровне архитектуры находится блок ввода-вывода (I/O), включающий в себя: узлы ввода-вывода, коммутатор узлов ввода-вывода, интерфейс ввода-вывода, датчики и исполнительные устройства. Блок отвечает за базовые механизмы формирования управляющих воздействий на основании данных с локальных датчиков и данных, полученных от других уровней системы управления. Поставленные задачи распределяются между работоспособными узлами ввода-вывода на основании их текущей относительной производительности или вручную оператором. Датчики и исполнительные устройства подключены с помощью шины ко всем узлам ввода-вывода в блоке, что позволяет любому узлу опрашивать любой датчик или вырабатывать воздействие на любое исполнительное устройство. Коммутатор узлов ввода-вывода обеспечивает связь между всеми узлами ввода-вывода для обмена данными между ними и другими уровнями архитектуры системы для получения управляющих и информационных данных. При наличии соответствующих аппаратных возможностей узлы связываются между собой и с узлами и коммутаторами на других уровнях системы непосредственно, что уменьшает время реакции в сети. Прямая связь между узлами и определенная загруженность узлов в текущем режиме работы блока ввода-вывода позволяет организовывать в блоке конвейерные вычисления, необходимые для функционирования этого блока без обращения к внешним вычислительным мощностям системы управления (РВС), что позволяет эффективно использовать свободные ресурсы, предоставленные для резервирования узлов блока ввода-вывода на момент отказа.

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

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

Распределение нагрузки

Одной из основных задач системы L-Net является распределение вычислительной нагрузки на узлах сети. Решение данной задачи основывается на построении вычислительных конвейеров. Для построения вычислительного конвейера предварительно строится граф задачи – схема обмена потоками данных от источника к получателю. В качестве источника выступают датчики, а в качестве получателя – исполнительные механизмы. Сам вычислительный конвейер представляет собой отображение графа задачи (см. рис.3) на граф вычислительной сети (см. рис.4) с учетом требований задачи к вычислительным ресурсам системы и текущему ее состоянию.

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

Отказоустойчивость

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

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

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

Заключение

Разработанная система L-Net в отличие от существующих аналогов предполагает использование широкого спектра аппаратных характеристик узлов РСУ при полной их программной совместимости. При работе узлов под управлением одной операционной системы (QNX Neutrino) обеспечивается возможность их построения на различных процессорных архитектурах (x86, ARM, MIPS и т.д.) с разнообразными наборами интерфейсов и периферийных устройств. Реализация узлов возможна в виде настольных, промышленных ПК, носимых ПК и одноплатных компьютеров. Все составляющие комплекса программного обеспечения разрабатываемой РСУ могут быть запущены на любом ее узле с ОС QNX, при этом остается возможность использования узлов с другой операционной системой. Такой подход позволяет использовать каждый узел для решения задач как операторского уровня, так и уровня управления. Следовательно, имеется гибкая система взаимодействия между одноранговыми узлами без жесткой иерархии уровней, присущей обобщенной архитектуре РСУ и системам использующих данную архитектуру как базовую. Одноранговость сети упрощает процессы развертывания, эксплуатации, масштабирования и отладки системы.

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

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

Вывод

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

1. http://kazanets.narod.ru/DCSIntro.htm .
2. http://kazanets.narod.ru/PCS7Overview.htm .
3. http://www.rts.ua/rus/news/678/0/409 .
4. Зыль С. QNX Momentics: основы применения. – СПб: БХВ-Петербург, 2005.
5. Кртен Р. Введение в QNX Neutrino. Руководство для разработки приложений реального времени. – СПб: БХВ-Петербург, 2011.

Ключевые слова: распределенная система управления, информационное обеспечение систем управления, распределенные реконфигурируемые системы.

Architecture of a distributed control system based on reconfigurable multi-pipeline computing environment L-Net

Sergey Yu. Potomskiy, Assistant Professor of National Research University «Higher School of Economics».

Nikita A. Poloyko, Fifth-year student of National Research University «Higher School of Economics». Study assistant. Programmer. Field of training: «Control and informatics in the technical systems».

Abstract. The article is devoted to a distributed control system based on reconfigurable multi-pipeline computing environment. The architecture of the system is given. Also, the basic characteristics and functional properties of the system are given too. The article presents a rationale for the choice of the operating system. The basic advantages of the system in comparison with existing similar developments are shown in the article.

Keywords: distributed control system, systems software support, distributed reconfigurable.

Вконтакте

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

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

Распределенная архитектура AggreGate необычайно гибка. Технически она основана на формировании одноранговых связей между серверами и прикреплении частей единой модели данных одних серверов («поставщиков») к другим («потребителям»).

Цели распределенных операций

Основными целями распределенной архитектуры являются:

• Масштабируемость . Серверы нижнего уровня могут быть сильно нагружены, собирая данные и управляя большим количеством устройств в режиме, близком к реальному времени. Однако на практике количество устройств, которые могут обслуживаться с помощью одного сервера, ограничено до нескольких тысяч. При масштабировании системы для управления большим числом устройств разумно установить несколько серверов и объединить их в рамках распределенной установки.
• Балансировка нагрузки . Каждый сервер в распределенной установке решает свою задачу. Серверы управления сетью проверяют доступность и производительность сетевой инфраструктуры, серверы контроля доступа обрабатывают запросы от контроллеров дверей и турникетов. Операции контроля, такие как генерация отчетов и их рассылка по почте, могут выполняться на центральном сервере.
• Защита от вторжений . Вторичные серверы-зонды могут быть установлены в удаленных местах и подключены к центральному серверу. Системные операторы подключаются только к центральному серверу, при этом отпадает необходимость в настройке VPN и проброса портов к этим серверам.
• Централизация . Вторичные серверы могут работать в полностью автоматическом режиме, в то время как их настройка и мониторинг осуществляется через основной сервер, установленный в центральной диспетчерской.

Распределение ролей сервера

В данном простом сценарии два сервера объединены в распределённую инфраструктуру. Операторы системы постоянно подключены к серверу мониторинга, выполняя свои ежедневные обязанности. Руководство компании подключается к серверу отчётности и аналитики тогда, когда нужно получить срез данных. Независимо от объёмов данных и нагрузки на сервер, данная операция не повлияет на работу операторов.

Крупномасштабная облачная IoT-платформа

Поставщики телекоммуникационных и облачных услуг предлагают IoT-сервисы по моделям IaaS/PaaS/SaaS. В этих случаях речь идёт о миллионах устройств, принадлежащих тысячам пользователей. Обслуживание такой огромной инфраструктуры требует сотни серверов AggreGate, большинство из которых можно объединить в две группы:

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

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

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

Многоуровневая инфраструктура Интернета вещей

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

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

Управление умным городом

Это пример основанной на AggreGate многоуровневой архитектуры для комплексной автоматизации большой группы зданий:

• Уровень 1 : физическое оборудование (сетевые маршрутизаторы, контроллеры, промышленное оборудование и т.д.)
• Уровень 2 : серверы управления (серверы мониторинга сети, серверы контроля доступа, серверы автоматизации зданий и другие)
• Уровень 3 : центры управления серверами зданий (один сервер на здание, который собирает информацию со всех серверов второго уровня)
• Уровень 4 : серверы районов города (конечный пункт назначения для эскалации оповещений более низкого уровня, мониторинг в реальном времени, интеграция с Service Desk-системами)
• Уровень 5 : серверы головного офиса (контроль серверов района, сбор и обобщение отчетов, оповещений)

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

Управление мультисегментной сетью

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

Таким образом, распределенная система мониторинга как правило состоит из следующих компонентов:

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

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

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

Высокопроизводительное управление событиями

Некоторые сценарии использования платформы AggreGate, такие как централизованное управление инцидентами, предполагают, что значительное количество событий должно получаться, обрабатываться и постоянно храниться в структурированном формате. Порой потоки могут достигать объёмов в миллионы событий в секунду, причём полученных из разных источников.

В подобных случаях один сервер AggreGate не справится со всем потоком событий. Организовать обработку событий поможет распределенная архитектура:

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

Цифровое предприятие

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

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

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

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

Все современные программные системы можно разделить на три больших класса.

1. Прикладные программные системы, предназначенные для работы только на одном персональном компьютере или рабочей станции. К ним относятся текстовые процессоры, электронные таблицы, графические системы и т.п.

2. Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др.

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

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

Выделено шесть основных характеристик распределенных систем.

1. Совместное использование ресурсов. Распределенные системы допускают совместное использование аппаратных и программных ресурсов, например жестких дисков, принтеров, файлов, компиляторов и т.п., связанных посредством сети. Очевидно, что разделение ресурсов возможно также в многопользовательских системах, однако в этом случае за предоставление ресурсов и их управление должен отвечать центральный компьютер.

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

3. Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.

4. Масштабируемость. В принципе все распределенные системы являются масштабируемыми: чтобы система соответствовала новым требованиям, ее можно наращивать посредством добавления новых вычислительных ресурсов. Но на практике наращивание может ограничиваться сетью, объединяющей отдельные компьютеры системы. Если подключить много новых машин, пропускная способность сети может оказаться недостаточной.

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

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

Разумеется, распределенным системам присущ ряд недостатков.

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

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

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

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

При обсуждении преимуществ и недостатков распределенных систем определяется ряд критических проблем проектирования таких систем (табл. 9.1).

Таблица 9.1. Проблемы проектирования распределенных систем

Проблема проектирования	Описание
Идентификация ресурсов	Ресурсы в распределенной системе располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система унифицированного указателя ресурсов URL, которая определяет адреса Web-страниц. Без легковоспринимаемой и универсальной системы идентификации большая часть ресурсов окажется недоступной пользователям системы
Коммуникации	Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако там, где на производительность, надежность и прочее накладываются специальные требования, можно воспользоваться альтернативными способами системных коммуникаций
Качество системного сервиса	Качество сервиса, предлагаемое системой, отражает ее производительность, работоспособность и надежность. На качество сервиса влияет целый ряд факторов: распределение системных процессов, распределение ресурсов, системные и сетевые аппаратные средства и возможности адаптации системы
Архитектура программного обеспечения	Архитектура программного обеспечения описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры оказывается решающим фактором

Задача разработчиков распределенных систем – спроектировать программное или аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Здесь выделяется два родственных типа архитектур распределенных систем.

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

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

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

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

Принципы создания системы обработки информации в масштабе предприятия

История развития компьютерной техники (и соответственно программного обеспечения) началась с обособленных, автономных систем. Ученые и инженеры были озабочены созданием первых ЭВМ и в основном ломали головы над тем, как заставить работать эти скопища электронных ламп. Однако такое положение вещей сохранялось недолго - идея объединения вычислительных мощностей была вполне очевидной и витала в воздухе, насыщенном гулом металлических шкафов первых ENIAK’ов и Mark’ов. Ведь мысль объединить усилия двух и более компьютеров для решения сложных, непосильных для каждого из них по отдельности задач лежит на поверхности.

Рис. 1. Схема распределенных вычислений

Однако практическая реализация идеи соединения компьютеров в кластеры и сети тормозилась отсутствием технических решений и в первую очередь необходимостью создания стандартов и протоколов взаимодействия. Как известно, первые ЭВМ появились в конце сороковых годов двадцатого века, а первая компьютерная сеть ARPANet, связавшая несколько компьютеров на территории США, - только в 1966 г., почти через двадцать лет. Конечно, такое объединение вычислительных возможностей современную распределенную архитектуру напоминало весьма отдаленно, но тем не менее это был первый шажок в верном направлении.

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

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

Именно в этот период стало очевидно, что основными преимуществами распределенных приложений являются:

· хорошая масштабируемость - при необходимости вычислительная мощность распределенного приложения может быть легко увеличена без изменения его структуры;

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

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

Шло время, и небольшие островки университетских, правительственных и корпоративных сетей расширялись, объединялись в региональные и национальные системы. И вот на сцене появился главный игрок - Internet.

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

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

Парадигма распределенных вычислений

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

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

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

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

Пространственное разделение. Подразделения организации разнесены в пространстве и зачастую имеют слабо унифицированное программное обеспечение.

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

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

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

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

Итак, парадигма распределенных вычислений подразумевает наличие нескольких центров (серверов) хранения и обработки информации, реализующих различные функции и разнесенных в пространстве. Эти центры помимо запросов клиентов системы должны выполнять и запросы друг друга, так как в ряде случаев для решения первой задачи могут понадобиться совместные усилия нескольких серверов. Для управления сложными запросами и функционированием системы в целом необходимо специализированное управляющее ПО. И наконец, вся система должна быть "погружена" в некую транспортную среду, обеспечивающую взаимодействие ее частей.

Распределенные вычислительные системы обладают такими общими свойствами, как:

· управляемость - подразумевает способность системы эффективно контролировать свои составные части. Это достигается благодаря использованию управляющего ПО;

· производительность - обеспечивается за счет возможности перераспределения нагрузки на серверы системы с помощью управляющего ПО;

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

· расширяемость - к распределенным приложениям можно добавлять новые составные части (серверное ПО) с новыми функциями.

Доступ к данным в распределенных приложениях возможен из клиентского ПО и других испределенных системах может быть организована на различных уровнях - от клиентского ПО и транспортных протоколов до защиты серверов БД.

Рис. 2. Основные уровни архитектуры распределенного приложения

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

Архитектура распределенных приложений

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

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

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

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

· хранение данных (уровень данных). Это уровень серверов баз данных. Здесь расположены сами серверы, базы данных, средства доступа к данным, различные вспомогательные инструменты.

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

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

Рис. 3. Распределение бизнес-логики по уровням распределенного приложения

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

Таким образом, можно выделить четыре основных уровня распределенной архитектуры (см. рис. 2):

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

· правила бизнес-логики (уровень обработки данных);

· управление данными (уровень управления данными);

· хранение данных (уровень хранения данных).

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

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

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

Физическая структура распределенных приложений

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

Распределение бизнес-логики по уровням распределенного приложения

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

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

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

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

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

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

Уровень представления данных

Уровень представления данных - единственный доступный конечному пользователю. Этот уровень моделирует клиентские рабочие места распределенного приложения и соответствующее ПО. Возможности клиентского рабочего места в первую очередь определяются возможностями операционной системы. В зависимости от типа пользовательского интерфейса клиентское ПО делится на две группы: клиенты, использующие возможности ГИП (например, Windows), и Web-клиенты. Но в любом случае клиентское приложение должно обеспечивать выполнение следующих функций:

· получение данных;

· представление данных для просмотра пользователем;

· редактирование данных;

· проверка корректности введенных данных;

· сохранение сделанных изменений;

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

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

Уровень обработки данных

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

· обработка потоков данных в соответствии с бизнес-правилами;

· взаимодействие с уровнем представления данных для получения запросов и возвращения ответов;

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

Чаще всего уровень обработки данных отождествляют с промежуточным ПО распределенного приложения. Такая ситуация в полной мере верна для "идеальной" системы и лишь отчасти - для реальных приложений (см. рис. 3). Что касается последних, то промежуточное ПО для них содержит большую долю правил обработки данных, но часть из них реализована в серверах SQL в виде хранимых процедур или триггеров, а часть включена в состав клиентского ПО.

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

Уровень управления данными

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

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

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

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

Итак, к функциям уровня управления данными относятся:

· управление частями распределенного приложения;

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

· управление потоками данных между клиентами и серверами и между серверами;

· управление нагрузкой;

· реализация системных служб приложения.

Необходимо отметить, что часто уровень управления данными создается на основе готовых решений, поставляемых на рынок программного обеспечения различными производителями. Если разработчики выбрали для своего приложения архитектуру CORBA, то в ее составе имеется брокер объектных запросов (Object Request Broker, ORB), если платформу Windows, - к их услугам разнообразные инструменты: технология COM+ (развитие технологии Microsoft Transaction Server, MTS), технология обработки очередей сообщений MSMQ, технология Microsoft BizTalk и др.

Уровень хранения данных

Уровень хранения данных объединяет серверы SQL и базы данных, используемые приложением. Он обеспечивает решение следующих задач:

· хранение данных в БД и поддержание их в работоспособном состоянии;

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

· реализация части бизнес-логики распределенного приложения;

· управление распределенными базами данных при помощи административного инструментария серверов БД.

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

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

Подключение к базам данных серверов SQL осуществляется в основном при помощи клиентского ПО серверов. Помимо этого дополнительно могут использоваться различные технологии доступа к данным, например ADO (ActiveX Data Objects) или ADO.NET. Но при проектировании системы необходимо учитывать, что функционально промежуточные технологии доступа к данным не относятся к уровню хранения данных.

Расширения базовых уровней

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

Среди прочих можно выделить два наиболее часто применяемых расширения базовых уровней.

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

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

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

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

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