Всё о секретах программного обеспечения и онлайновых сервисов
Яндекс.Метрика

Метакомпьютинг в распределенных информационных системах (расширенная версия)

МЕТАКОМПЬЮТИНГ В РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ

А.М. Крупин
ЗАО «КОНТУР Софт»
Россия, 117461, Москва, Севастопольский пр-т, 73-63
E-mail: andrey_krupin@computerra.ru

А.М. Самохин
ЗАО «КОНТУР Софт»
Россия, 117461, Москва, Севастопольский пр-т, 73-63
E-mail: kontur_soft@mtu-net.ru

С.А. Хохлов
ЗАО «КОНТУР Софт»
Россия, 117461, Москва, Севастопольский пр-т, 73-63
E-mail: ks700@mail.ru

Ключевые слова: распределенные системы, задачи управления, PACO ‘2004, метакомпьютинг, бизнес-контроль, архитектура, организация данных

Key words: distributed information systems, control problems, PACO ‘2004, management problems, metacomputing, business-control, architecture, data structure

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

METACOMPUTING IN DISTRIBUTED INFORMATIONAL SYSTEMS / A.M. Krupin («KONTUR Soft» close corporation, 73-63 Sevastopol’ski pr., Moscow 117461, Russia, E-mail: andrey_krupin@computerra.ru), A.M. Samokhin («KONTUR Soft» close corporation, 73-63 Sevastopol’ski pr., Moscow 117461, Russia, E-mail: kontur_soft@mtu-net.ru), S.A. Khokhov («KONTUR Soft» close corporation, 73-63 Sevastopol’ski pr., Moscow 117461, Russia, E-mail: ks700@mail.ru). This paper deals with realization of the distributed calculations by a metacomputing principle in the specialized distributed information control system of the enterprise.

Введение

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

Значительный объем данных, используемых в управлении предприятием, может быть размещен на одном персональном компьютере (сегодня дисковая память рядового компьютера 60 Гбайт — что более чем достаточно для этого), обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый в распределенной системе из множества автоматизированных рабочих мест (АРМ), ничтожен по сравнению с объемом данных, используемых в повседневной работе. Поэтому, если хранить непрерывно используемые данные на компьютерах каждого из АРМов, и организовать обмен между исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик в распределенной системе резко снизится.

Как показывает ряд проведенных исследований и оценочных расчетов, это действительно так, особенно, если обеспечить хранение на АРМах, только тех данных, которые действительно на нем используются. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать  асинхронную  связь, и благодаря этому, создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь. А минимизация  трафика между АРМами системы, сделает вполне доступной стоимость эксплуатации такой системы при значительной удаленности отдельных рабочих мест. Это особенно актуально для информационных систем, используемых  в малом и среднем бизнесе, когда относительно небольшое число АРМов в информационной системе управления предприятием (20–40 шт.), часто территориально распределены на множестве мест фактической эксплуатации  (офис, склады, магазины) группами от 1–2 АРМов, что делает затруднительным, эксплуатацию систем с традиционной клиент-серверной архитектурой, так как, как правило, в этом случае нет гарантированной, устойчивой и скоростной связи  между множеством  мест эксплуатации, но при этом есть общедоступные средства связи — низкоскоростные без гарантии устойчивости.

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

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

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

Требования к современным распределенным информационным системам

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

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

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

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

Остановимся более подробно на каждой из задач.

Организация данных

Данные в системе организованы таким образом, что условной единицей данных, к которым можно разграничить доступ и которые реплицируются в системе, является бизнес-объект. Бизнес-объект — это совокупность данных, определяющая воспринимаемое пользователем понятие, присутствующее в предметной области. Конкретным бизнес-объектом может являться — служащий, продукт, счет-фактура. Такая организация данных позволяет возложить на пользователя решение проблемы распределенных транзакций, то есть разрешать конфликтные ситуации, при одновременном исправлении данных на нескольких АРМах.

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

Объекты могут ссылаться друг на друга. При этом репликация и разграничение доступа в системе ведется с учетом ссылочной структуры объектов.

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

Разграничение доступа

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

Репликация данных

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

При инициализации пользователем сеанса репликации данных, бизнес-объекты из виртуального почтового ящика сохраняются в XML-файл, затем для уменьшения трафика архивируются и, поскольку передача сообщений ведется по открытым каналам, шифруется. На противоположной стороне сообщение расшифровывается, разархивируется, после чего специально настраиваемый робот «Арбитр» решает проблему синхронизации вновь пришедших копий объектов и им соответствующих копий объектов уже присутствующих на АРМе.

«Арбитр» — это алгоритм реализованный на базе двух видов правил — правил, обеспечивающих целостность и непротиворечивость данных в системе, и правил, задаваемых пользователем учитывающих специфику обработки данных на конкретном АРМе. Так как все эти правила описывают алгоритмы синхронизации различных типов бизнес-объктов, то с точки зрения пользователя они понятны, и он в состоянии их редактировать и задавать. В простейшем случае правила пользователя могут не формулироваться и не задаваться, а пользователю просто предоставляется интерфейс подтверждения вставки бизнес-объектов и пользователь сам решает, сохранить старый бизнес-объект или заменить его новым, пришедшим с соседнего АРМа (если он отказывается от пришедшей копии бизнес-объекта, то по правилам, обеспечивающим целостность и не противоречивость, копия соответствующего объекта рассылается другим АРМам, чтобы заменить вновь пришедшею). Так решается проблема распределенных транзакций в системе.

Поддержка актуальности кода АРМов в распределенной системе

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

Реализация предложенной архитектуры в ПО «Бизнес-контроль»

На основе вышеизложенных принципов, была реализована распределенная система ПО «Бизнес-контроль», предназначенная для ведения управленческого учета на предприятии. Распределенная система ПО «Бизнес-контроль» имеет древовидную структуру, отражающую отношения подчиненности на предприятии. АРМы в системе делятся на четыре различных типа. Каждый из них выполняет свои функции.

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

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

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

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

Заключение

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

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

  1. Крупин А.М., Самохин А.М., Чернышев Ю.А. Метакомпьютинг в распределенных информационных системах. // Научная сессия МИФИ. М.: Московский инженерно-физический институт (технический университет), 2004.
  2. Федоров А. Java: архитектура и интерфейсы, http://fort.stup.ac.ru/wmaster/books/language/java/4/Java99-1.htm, 2000.
  3. Галатенко В.А. Информационная безопасность — основы. // СУБД. № 1,
  4. Хенкин В., Навроцкий С. Опознанные летающие объекты. // Открытые системы, 1999.
  5. Цишевский В. Язык и архитектура JAVA. http://ruby.h1.ru/cgi-bin/index.cgi?2,6,1, 2001.
  6. Г. М. Ладыженский. Системы управления базами данных — коротко о главном. // СУБД. № 1-4, 1995.
  7. Рамбо Д. Тенденции в развитии языка UML и разработки ПО. http://www.interface.ru/fset.asp?Url=/rational/umltend.htm.
  8. Яворски Д., Перроун П. Дж. Система безопасности JAVA / SAMS, 2001.
  9. Куцыгин С.А., Дружинин Е.Л., Самохин А.М., Чернышев Ю.А. Разработка XML-сервера. // Научная сессия МИФИ. М.: Московский инженерно-физический институт (технический университет), 2001.
  10. Хохлов С. А., Самохин А.М., Чернышев Ю.А. Система управления доступом к распределенным информационным ресурсам. // Научная сессия МИФИ. М.: Московский инженерно-физический институт (технический университет), 2004.
  11. Хохлов С.А., Чернышев Ю.А. Разработка сервера аутентификации и разграничения доступа (САРД). // Научная сессия МИФИ. М.: Московский инженерно-физический институт (технический университет), 2001.
  12. Кунегин С.В. Технология CORBA. http://kunegin.narod.ru/ref2/corba/index.htm, 2001.
  13. Хитрин С.В. Разработка подсистем разграничения доступа в составе корпоративных информационных систем, http://www.compulog.ru/msdos/compulog/1999/archive/ahtml 1999.
  14. Чернышев Ю.А., Хохлов С.А., Дружинин Е.Л. Система аудита вычислительной сети. // Научная сессия МИФИ. М.: Московский инженерно-физический институт (технический университет), 2002.