Принципы создания системы обработки информации в масштабе предприятия
История развития компьютерной техники (и соответственно программного обеспечения) началась с обособленных, автономных систем. Ученые и инженеры были озабочены созданием первых ЭВМ и в основном ломали головы над тем, как заставить работать эти скопища электронных ламп. Однако такое положение вещей сохранялось недолго - идея объединения вычислительных мощностей была вполне очевидной и витала в воздухе, насыщенном гулом металлических шкафов первых 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.
В крупных холдингах работают десятки тысяч пользователей в дочерних компаниях. В каждой организации налажены свои внутренние бизнес-процессы: согласование документов, выдача поручений и т.д. При этом некоторые процессы выходят за пределы одной компании и затрагивают сотрудников другой. Например, руководитель головного офиса выдает поручение в дочернюю организацию, или сотрудник дочерней отправляет договор на согласование с юристами головной компании. Это требует создания сложной архитектуры с использованием нескольких систем.
Кроме того, в пределах одной компании используется множество систем для решения разных задач: ERP-система для учетных операций, отдельные инсталляции ЕСМ-систем для организационно-распорядительной документации, для проектно-сметной документации и т.д.
Обеспечить взаимодействие разных систем как внутри холдинга, так и на уровне одной организации, поможет система DIRECTUM.
DIRECTUM предоставляет удобные инструменты для построения управляемой распределенной архитектуры организации и решения следующих задач:
- организация сквозных бизнес-процессов и синхронизация данных между несколькими системами одной компании и в холдинге;
- обеспечение доступа к данным разных инсталляций ECM-систем. Например, выполнить поиск документа по нескольким специализированным системам: с финансовой документацией, с проектно-сметной документацией и пр.
- администрирование множества систем и сервисов из единой точки управления и создание комфортной IT-инфраструктуры;
- удобное распространение разработки в распределенные продуктивные системы.
Компоненты управляемой распределенной архитектуры
Механизмы межсистемного взаимодействия (DCI)
Механизмы DCI используются для организации сквозных бизнес-процессов и синхронизации данных между разными системами внутри одной или нескольких организаций (холдинга).
Решение соединяет существующие в компаниях локальные бизнес-процессы в единый сквозной процесс. Сотрудники и их руководители работают с уже знакомым интерфейсом задач, документов и справочников. При этом действия сотрудников прозрачны на каждом этапе: они могут видеть текст переписки со смежной компанией, посмотреть состояние согласования документа с головной организацией и пр.
К DCI можно подключать разные инсталляции DIRECTUM и другие классы систем (ERP, CRM и пр.). Как правило, инсталляции делятся по направлениям бизнеса, с учетом территориального или юридического размещения организаций и других факторов.
Вместе с DCI поставляются компоненты разработки с подробным описанием и примерами кода, благодаря которым разработчик может создать алгоритм под бизнес-процессы своей организации.
Механизмы DCI позволяют передавать большие объемы данных и выдерживают пиковые нагрузки. Кроме того, они обеспечивают отказоустойчивость при сбое связи и защиту передаваемых данных.
Федеративный поиск
С помощью федеративного поиска можно найти нужные задачи или документы сразу во всех отдельных системах DIRECTUM. Например, запустить поиск одновременно по рабочей системе и по системе с архивными документами.
Федеративный поиск позволяет:
- посмотреть через веб-клиент ход согласования исходящего документа в дочерней организации;
- найти договоры, заключенные с контрагентом во всех дочерних организациях, например, для подготовки переговоров. При этом можно перейти к задачам, в которые вложены договоры;
- проверить статус исполнения поручения, отправленного из головной организации в дочернюю, или документы и задачи, созданные по нему;
- найти документы одновременно в нескольких системах с разной специализацией, например, с организационно-распорядительными документами и с договорами;
- найти первичные учетные документы для аудита или сверки с контрагентом сразу в рабочей системе и в системе с архивом документов;
- обменяться ссылками на результаты поиска с коллегами.
Администратор может изменять стандартные поиски, добавлять новые, а также настраивать, какие системы будут видны пользователю.
Центр администрирования служб DIRECTUM
Система DIRECTUM решает множество разных задач: взаимодействие сотрудников, хранение документов и др. Это возможно благодаря надежной работе ее служб. А в крупных компаниях выделяют целые инсталляции системы DIRECTUM со своим набором служб под конкретную задачу, например, под хранение архивных документов. Инсталляции и службы разворачивают на нескольких серверах. Эту инфраструктуру необходимо администрировать.
Центр администрирования служб DIRECTUM — это единая точка входа администратора для конфигурирования, мониторинга и управления службами и системами DIRECTUM. Центр представляет собой сайт с инструментами управления сервером сеансов, службой Workflow, службой обработки событий, службой файловых хранилищ , службами ввода и преобразования , федеративным поиском и веб-справкой.
Удобная визуальная настройка удаленных систем и служб упрощает работу администратора. Ему не нужно заходить на каждый сервер и вручную вносить изменения в конфигурационные файлы.
Службы останавливаются и включаются в один клик. Состояние служб моментально отображается на экране.
Список настроек можно пополнять и фильтровать. По умолчанию сайт отображает только основные настройки. При этом для всех настроек можно посмотреть подсказки с рекомендациями по заполнению.
Система DIRECTUM эффективно организует работу распределенных организаций и обеспечивает пользователям прозрачный обмен документами, задачами и записями справочников.
Каждый компонент управляемой распределенной архитектуры можно использовать отдельно, но в совокупности они принесут вашей организации больший бизнес-эффект.
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 может выполнять различные функции, начиная от мониторинга и управления удалёнными объектами и заканчивая высокоуровневыми сервисами, такими как бизнес-аналитика или, например, управление инцидентами.
Все серверы цифрового предприятия подключены друг к другу через распределённую инфраструктуру. Серверы нижнего уровня предоставляют доступ к части контекстов единой модели данных серверам верхнего уровня, позволяя создать ситуационный центр для целого предприятия.
Такой тип систем является более сложным с точки зрения организации системы. Суть распределенной системы заключается в том, чтобы хранить локальные копии важных данных .
Схематически такую архитектуру можно представить, как показано на рис. 5.6.
Рис. 5.6. Архитектура распределенных систем
Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и архитектуры системы, является обеспечение возможности персональной ответственности за сохранность данных. Так как данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, при использовании средств шифрования и личных аппаратных ключей исключается доступ к данным посторонних, в том числе и IT администраторов.
Такая архитектура системы также позволяет организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений, можно распределить между соседними АРМами благодаря тому, что они, как правило, обладают одной информацией в своих БД и, таким образом, добиться максимальной производительности системы.
Распределенные системы с репликацией
Данными между различными рабочими станциями и централизованным хранилищем данных, передаются репликацией (рис. 5.7). При вводе информации на рабочих станциях – данные также записываются в локальную базу данных, а лишь затем синхронизируются.
Рис. 5.7. Архитектура распределенных систем с репликацией
Распределенные системы с элементами удаленного исполнения
Существуют определенные особенности, которые невозможно качественно реализовать на обычной распределенной системе репликативного типа. К этим особенностям можно отнести :
использование данных из сущностей, которые хранятся на удаленном сервере (узле);
использование данных из сущностей, хранящихся на разных серверах (узлах) частично;
использование обособленного функционала, на выделенном сервере (узле).
У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рис. 5.8).
Рис. 5.8. Архитектура распределенных систем с удаленным исполнением
В настоящее время все разрабатываемые в коммерческих целях ИС имеют распределенную архитектуру, которая подразумевает использование глобальных и/или локальных сетей.
Исторически первыми получила широкое распространение файл-серверная архитектура, поскольку ее логика проста и перевести на такую архитектуру уже находящиеся в эксплуатации ИС –проще всего. Затем она была трансформирована в архитектуру сервер-клиент, которую можно трактовать как ее логическое продолжение. Современные системы, используемые в глобальной сети INTERNET в основном относятся к архитектуре распределенных объектов (см. Рис. III ‑15 )
ИС можно представить состоящую из следующих составных частей (Рис. III‑16)
III.03.2. a Файл-серверные приложения.
Это исторически первая распределенная архитектура (Рис. III‑17). Организуется она предельно просто: на сервере находятся только данные, а все остальное относится к клиентской машине. Поскольку локальные сети достаточно дешевы, и в силу того, что при такой архитектуре прикладное ПО автономно, такая архитектура достаточно часто используется и сейчас. Можно сказать, что это вариант клиент-серверной архитектуры, при которой на сервере находятся только файлы данных. Разные персональные компьютеры взаимодействуют только по средствам общего хранилища данных, поэтому программы, написанные в расчете на один компьютер проще всего адаптировать под такую архитектуру.
Плюсы:
Плюсы файл-серверной архитектуры:
Простота организации;
Не противоречит необходимым требованиям к БД к поддержанию целостности и надежности.
Перегрузка сети;
Непредсказуемость реакции на запрос.
Эти недостатки объясняются тем, что любой запрос к БД приводит к перекачке по сети к значительным объемам информации. Например, для выборки из таблиц одной или нескольких строк перекачивается вся таблица на клиентскую машину и уже там СУБД производит выборку. Значительный сетевой трафик особенно чреват при организации удаленного доступа к БД.
III.03.2. b Клиент-серверные приложения.
В данном случае имеет место распределение обязанностей между сервером и клиентом. В зависимости от того, как они разделены различают толстого и тонкого клиента .
В модели «тонкий клиент” вся работа приложения и управление данными выполняются на сервере. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты компьютеры или рабочие станции. Сетевые устройства запускают Internet-броузер и пользовательский интерфейс, реализованный внутри системы.
Главный недостаток модели тонкого клиента - большая загруженность сервера и сети. Все вычисления выполняются а сервере, а это может привести к значительному сетевое трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, но она практически не используется в модель/тонкого клиента банка
Напротив, модель толстого клиента использует вычислительную мощность локальных машин: само приложение помещаются на клиентский компьютер. Примером архитектуры такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер -центральным компьютером, обслуживающим базу данных по расчетам с клиентами
III.03.2. c Двух- и трехуровневые архитектура клиент-сервер.
Все рассмотренные выше архитектуры являются двухуровневыми. В них различается уровень клиента и уровень сервера. Строго говоря, ИС состоит из трех логических уровней:
· Уровень пользователя;
· Уровень приложения:
· Уровень данных.
Поэтому в двухуровневой модели, где задействованы только два уровня, возникает проблема с масштабируемостью и производительностью, если выбрана модель тонкий клиент, либо проблемы связанные с управлением системы, если взята модель толстый клиент. Избежать этих проблем можно, если применять модель, состоящую из трех уровней, где два из них сервера(Рис. III‑21).
| Сервер данных |
Фактически сервер приложения и сервер данных могут располагаться на одной машине, но выполнять функции друг друга они не могут. Трехуровневая модель хороша тем, что в ней логически разделены выполнение приложения и управление данными.
Таблица III‑5 Применение разных типов архитектур
| Архитектура | Приложение |
| Двухуровневая тонкий клиент | 1 Наследуемые системы, в которых не целесообразно разделять выполнение приложения и управление данными. 2 Приложения с интенсивными вычислениями, но малыми объемами управления данными. 3 Приложения с большими объемами данных, но малым количеством вычислений. |
| Двухуровневый толстый клиент | 1 Приложения, где пользователю требуется интенсивная обработка данных, то есть визуализация данных. 2 Приложения с относительно постоянным набором функций пользователя, применяемых к среде с хорошо отлаженным системным управлением. |
| Трехуровневый сервер-клиент | 1 Большие приложения с сотами и тысячами клиентов 2 Приложения, в которых часто меняются и данные и методы их обработки. 3 Приложения, в которых выполняются интеграции данных из многих источников. |
Такая модель подходит многим типам приложений, но ограничивает разработчиков ИС, которые должна решать, где предоставить сервисы, обеспечивать поддержку масштабируемости, разрабатывать средства для подключения новых клиентов.
III.03.2. d Архитектура распределенных объектов.
Более общий подход обеспечивает архитектура распределенных объектов, основными компонентами которой являются объекты. Они предоставляют набор услуг через свои интерфейсы. Другие объекты посылают запросы, при этом не делается различий между клиентом и сервером. Объекты могут располагаться на разных компьютерах в сети и взаимодействовать по средствам промежуточного ПО, по аналогии системной шины, которая позволяет подключать различные устройства и поддерживать взаимодействие между аппаратными устройствами.
| … |
| Диспетчер драйвер ODBC |
| Драйвер 1 |
| Драйвер К |
| БД 1 |
| БД К |
| Работа с SQL |
| … |
Архитектура ODBC включает компоненты:
1. Приложение (например, ИС). Оно выполняет задачи: запрашивает соединение с источником данных, посылает SQL – запросы к источнику данных, описывает область хранения и формат для SQL – запросов, обрабатывает ошибки и оповещает о них пользователя, осуществляет фиксацию или откат транзакций, запрашивает соединение с источником данных.
2. Диспетчер устройств. Он загружает драйвера по требованию приложений, предлагает единый интерфейс всем приложениям, причем интерфейс администратора ODBC одинаков и независим то того, с какой СУБД приложение будет взаимодействовать. Диспетчер драйверов, поставляемый Microsoft, является динамически загружаемой библиотекой DLL.
3. Драйвер зависит от СУБД. Драйвер ODBC – это динамическая библиотека DLL, которая реализует функции ODBC и взаимодействует с источником данных. Драйвер – это программа, которая обрабатывает запрос какой-то функции специфично для СУБД (может модифицировать запросы в соответствии с СУБД) и возвращает результат приложению. Каждая СУБД, поддерживающая технологию ODBC, должна предоставить разработчикам приложений драйвер для этой СУБД.
4. Источник данных содержит управляющую информацию, задаваемую пользователем, информацию об источнике данных и используется для доступа к конкретной СУБД. При этом используются средства ОС и сетевой платформы.
Эта модель предполагает много аспектов, для представления которых на языке UML используется как минимум 5 диаграмм см. пп. 2.04.2- 2.04.5.
Рассмотрим аспект управления. Модель управления дополняет структурные модели.
Каким бы образом не была описана структура системы, она состоит из набора структурных единиц (функций или объектов). Чтобы они функционировали как единое целое, ими надо управлять, а информация по управлению отсутствует в статических диаграммах. В моделях управления проектируется поток управления между системами.
Можно выделить два основных типа управления в программных системах.
1. Централизованное управление.
2. Управление, основанное на событиях.
Централизованное управление может быть:
· Иерархическим - по принципу «вызов-возврат» (именно так чаще всего работает учебные программы)
· Модель диспетчера , которая применяется для параллельных систем.
В модели диспетчера предполагается, что один из компонентов системы – диспетчер. Он управляет как запуском, так и завершением систем и координацией остальных процессов системы. Процессы могут работать параллельно друг другу. Под процессом понимается программа, подсистема или процедура, которая работает на данный момент. Эта модель может применяться также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от каких-то переменных состояния (через оператор case ).
Управление событиями предполагает отсутствие какой-либо подпрограммы ответственной за управление. Управление осуществляется внешними событиями: нажатие клавиши мыши, нажатие клавиатуры, изменения показания датчиков, изменения показания таймера ит.д. Каждое внешнее событие кодируется и помещается в очередь событий. Если реакция на событие в очереди предусмотрена, то вызывается та процедура (подпрограмма), которая и осуществляет реакцию на это событие. События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы.
Примером такого управления является организация приложений в ОС Windows.
Все описанные ранее структурной модели можно реализовать с помощью централизованного управления или управления, основанного на событиях.
Пользовательский интерфейс
При разработки модели интерфейса следует учитывать не только задачи проектируемого ПО, но и особенности мозга, связанные с восприятием информации.
III.03.4. a Психофизические особенности человека, связанные с восприятием и обработкой информации.
Часть мозга, которую условно можно назвать процессором восприятия, постоянно, без участия сознания, перерабатывает поступающую информацию, сравнивает ее с прошлым опытом и помещает ее в хранилище.
Когда зрительный образ привлекает наше внимание, тогда интересующая нас информация поступает краткосрочную память. Если же наше внимание не было привлечено, то информация в хранилище пропадает, замещаясь следующими порциями.
В каждый момент времени фокус внимания может фиксироваться в одной точке, поэтому если возникает необходимость одновременного отслеживания нескольких ситуаций, то фокус перемещается с одного отслеживаемого объекта на другой. При этом внимание рассредоточивается, и какие-то детали могут быть упущены. Существенно и то, что восприятие во многом основано на мотивации.
При смене кадра мозг на некоторое время блокируется: он осваивает новую картинку, выделяя наиболее существенные детали. Это значит, что если необходима быстрая реакция пользователя, то резко менять картинки не стоит.
Краткосрочная память - самое узкое место в системе обработки информации человека. Ее емкость равна 7±2 несвязанных объекта. Невостребованная информация хранится в ней не более 30 секунд. Чтобы не забыть какую-нибудь важную для нас информацию, мы обычно повторяем ее про себя, обновляя информацию в краткосрочной памяти. Таким образом, при проектировании интерфейсов следует иметь в виду, что подавляющему большинству сложно, например, запомнить и ввести на другом экране числа, содержащие более пяти цифр.
Несмотря на то, что емкость и время хранения долгосрочной памяти неограниченны, доступ к информации весьма непрост. Механизм извлечения информации из долгосрочной памяти имеет ассоциативный характер. Для улучшения запоминания информации ее привязывают тем данным, которые память уже хранит и позволяет легко получить. Поскольку доступ к долгосрочной памяти затруднен, целесообразно рассчитывать не на то, что пользователь вспомнит информацию, а на то, что пользователь узнает ее.
III.03.4. b Основные критерии оценки интерфейсов
Многочисленные опросы и обследования, проводимые ведущими фирмами по разработке программного обеспечения, показали, что пользователи ценят в интерфейсе:
1)простоту освоения и запоминания - конкретно оценивают время освоения и продолжительность сохранения информации и памяти;
2)скорость достижения результатов при использовании системы, которая определяется количеством вводимых или выбираемых мышью команд и настроек;
3)субъективную удовлетворенность при эксплуатации системы (удобство работы, утомляемость и т. д.).
Причем для пользователей-профессионалов, постоянно работающих с одним и тем же пакетом, на первое место достаточно быстро выходят второй и третий критерии, а для пользователей-непрофессионалов, работающих с программным обеспечением периодически и выполняющих сравнительно несложные задачи - первый и третий.
С этой точки зрения на сегодняшний день наилучшими характеристиками для пользователей-профессионалов обладают интерфейсы со свободной навигацией, а для пользователей-непрофессионалов - интерфейсы прямого манипулирования. Давно замечено, что при выполнении операции копирования файлов при прочих равных условиях большинство профессионалов используют оболочки типа Far, а непрофессионалы - «перетаскивание объектов» Windows.
III.03.4. c Типы интерфейсов пользователя
Различают следующие типы пользовательских интерфейсов:
Примитивные
Со свободной навигацией
Прямого манипулирования.
Интерфейс примитивный
Примитивным называется интерфейс, который организует взаимодействие с пользователем и используется в консольном режиме. Единственное отклонение от последовательного процесса, который обеспечивается данными, заключается в организации цикла для обработки нескольких наборов данных.
Интерфейс Меню.
В отличие от примитивного интерфейса, позволяет пользователю выбирать операцию из специального списка, выводимого ему программой. Эти интерфейсы предполагают реализацию множества сценариев работы, последовательность действий в которых определяется пользователями. Древовидная организация меню предполагает, что поиск пункта более чем двух уровневого меню оказывается довольно сложной задачей.
