В работе рассматриваются вопросы построения объектной распределеннойсистемы моделирования процессов массового обслуживания, в частности,предложена компонентная модель системы и техника организации распределенных вычислений
Component model of distributed objectorientedsimulation software.pdf На сегодняшний день на рынке программного обеспечения существует опре-деленное число систем, предназначенных для моделирования процессов массо-вого обслуживания. Большая часть таких систем ориентирована на решениепрактических задач в конкретной предметной области (транспорт, телекомму-никации и т.п.), к тому же практически все эти системы реализуют определен-ные модели имитационного моделирования, не предусматривая подключениядругих возможных подходов. В качестве примера программы, удачно сочетаю-щей решение практических задач в конкретных областях с возможностью реа-лизации того или иного теоретического подхода, можно привести системуAnyLogic компании XJ Technologies [1]. Пожалуй, это одна из лучших систем всвоем классе. Однако и эта программа обладает рядом недостатков, наиболеесущественным из которых является необходимость использовать для проведе-ния вычислений производственные мощности настольного (клиентского) ком-пьютера. В связи с практическим отсутствием средств, решающих задачи моде-лирования с возможностью распределенных вычислений (в том числе - и посети Интернет), актуальной является задача создания соответствующего про-граммного обеспечения.1. Базовые компоненты системыВ качестве дополнительного требования к разрабатываемой системе былавыдвинута возможность производить независимо от имитационного и матема-тическое моделирование систем массового обслуживания (где это возможно)и представлять сравнительные результаты расчетов на примере конкретных сис-тем.1 Работа выполнена в рамках аналитической ведомственной целевой программы «Развитие научногопотенциала высшей школы (2009 - 2010 годы)», проект № 4761.Компонентная модель распределенной объектно-ориентированной системы 79В качестве базовой парадигмы программирования выбран объектно-ориенти-рованный подход. В процессе разработки была получена компонентная модельсистемы, ее общий вид представлен на рис. 1.«library»АИМ«library»АММ«executable»Калькулятор«executable»Конструктор«file»МодельРис. 1. Модель основных компонентовобъектной распределенной системы моделированияВ качестве отдельного компонента, например в виде инструментальной биб-лиотеки, предлагается выделить алгоритмы имитационного моделирования(АИМ). Данный компонент реализует набор механизмов для построения имита-ционной модели систем массового обслуживания, а также базовые инструментыимитационного моделирования.Для выполнения расчетов, не нуждающихся в имитационном моделировании,расчетов, имеющих аналитические или численные решения, предлагается исполь-зовать компонент, отвечающий за алгоритмы математического моделирования(АММ). Кроме того, совместное использование этих компонентов позволит нетолько провести численные расчеты и выполнить имитационное моделирование, апри необходимости и сравнить полученные результаты.Калькулятор (Calculator) - «ядро» системы, производит чтение и разбор дан-ных, описанных в файле Модель, и обращается к компонентам АИМ (AIM) иАММ (AMM) для выполнения соответствующих расчетов;Модель (Model) - компонент типа «файл», полностью описывающий поста-новку задачи моделирования и все необходимые параметры. Для этого компонен-та выбрана объектная модель внутренней структуры;Конструктор (Constructor) - программа, предоставляющая возможность созда-ния и редактирования моделей в удобном для пользователя виде.Исходя из предполагаемой сложности, а главное длительности выполняемыхвычислений, возникает задача разработки архитектуры, позволяющей использо-вать для работы системы несколько компьютеров одновременно, причем такимобразом, что все участвующие в работе системы компьютеры должны одновре-менно использоваться для выполнения одного текущего задания системы, то естьрасчетов по одной и той же задаче.Для построения системы воспользуемся принципом распределённых вычисле-ний (GRID, MPP[2]). Это частный случай параллельных вычислений, при которомиспользуется большое количество самостоятельных компьютеров, а разделениерасчетов осуществляется путем разбиения основной задачи на ряд подзадач.80 К.Ю. Войтиков, А.Н. Моисеев, П.Н. ТумаевОтсюда следует, что принципиально такая архитектура может использоватьсялишь для тех моделей, имитацию которых можно разбить на независимые частибез потери адекватности имитации.2. Организация распределенных вычисленийВ работе системы должны участвовать три типа узлов: Клиент (Client) - компьютер клиента системы, который составляет для неезадание; Удаленный Калькулятор (Remote Calculator) - узел, использующийся непо-средственно для расчетов; Сервер (Server) - узел, использующийся для приема заданий от Клиентов, иххранения, координации сети Удаленных Калькуляторов, аккумуляцию и синхро-низацию результатов расчетов.Как видно из модели компонентов, представленной на рис. 1, непосредственнов процессе имитации и вычислений обязательно участвуют три ее компонента -Calculator, AIM и AMM. Вдобавок экземпляры компонента Model передаютсякомпоненту Calculator для каждого конкретного задания.Исходя из этого, компоненты основной модели системы будут распределеныпо типам узлов следующим образом (рис. 2).Рис. 2. Диаграмма развертывания компонентов системыНаряду с основными компонентами в системе появляются два новых компо-нента: GRID Client - компонент, агрегирующий в себя компоненты, участвующиев расчетах, и обеспечивающий их связь с Сервером; и GRID Server - компонент,осуществляющий разделение заданий на сегменты, обеспечивающий координа-цию Удаленных Калькуляторов и Клиентов, хранящий задания и результаты ими-таций.Компонентная модель распределенной объектно-ориентированной системы 81Стоит заметить, что узел Клиент не обязательно содержит компонент Конст-руктор. В общем случае достаточно передать компоненту GRID Server файл мо-дели и параметры задания для нее, для чего Конструктор не является необходи-мым. Для передачи этих параметров будет использоваться специальный интер-фейс Сервера, названный Интерфейсом Заданий.Компонент Model фактически присутствует на всех трех узлах системы, таккак создается пользователем на узле Клиент, передается и хранится вместе с зада-нием на узле Сервер, а также передается и обрабатывается на узле УдаленныйКалькулятор.Одним из ключевых свойств такой архитектуры является пассивность компо-нента GRID Server, который, по сути, является хранилищем данных и правил дос-тупа к ним. Таким образом, взаимодействие компонентов системы, находящихсяна узлах Клиент и Удаленный Калькулятор осуществляется через изменение дан-ных, хранящихся в компоненте GRID Server. Так клиент системы создает новоезадание и сохраняет его на Сервере. Множество Удаленных Калькуляторов в оп-ределенные промежутки времени соединяются с Сервером и, если он содержитновые задания, загружают их и начинают процесс имитации, наполняя Сервер ре-зультатами. По окончании моделирования всеми Удаленными Калькуляторами,клиент системы вновь подключается к Серверу и получает необходимые данные орезультатах моделирования.Из этого следует, что компонент GRID Server должен предоставлять два ин-терфейса: Интерфейс Заданий для создания заданий и получения результатов кли-ентом и интерфейс GRID Клиентов для подключения Удаленных Калькуляторов.3. Применение WCF для организации распределенных вычисленийДля связи компонентов системы между узлами была выбрана технологияMicrosoft Windows Communication Foundation (WCF). WCF - это унифицирован-ная модель программирования распределенных приложений на платформеMicrosoft. Она инкорпорирует предшествующие технологии - ASMX, .NETRemoting, DCOM и MSMQ - и предоставляет расширяемый API, отвечающийразнообразным требованиям, которые возникают при создании распределенныхсистем. WCF - это каркас для работы с web-службами на основе XML, которыйсовместим со многими другими технологиями [3]. WCF предоставляет возмож-ность конструировать логику взаимодействия независимо от протоколов, форма-тов и способов передачи данных, позволяет динамически переключаться междуними, а также предоставляет готовые механизмы обеспечения безопасности ис-полнения кода.Рассмотрим более подробно структуру компонентов GRID Server и GRIDClient.Центральным звеном компонента GRID Server является компонент Controller,отвечающий за обработку всех событий внутри компонента и реализующий биз-нес-логику обращения к данным.Как было сказано выше, компонент GRID Server предоставляет два интерфей-са: Интерфейс Заданий и Интерфейс GRID Клиентов. Интерфейс GRID Клиентовреализуется компонентом Service, который является WCF-службой и обеспечива-ет связь компонентов GRID Client и GRID Server вне зависимости от способа фи-зического соединения содержащих их улов и доступных протоколов передачиданных.82 К.Ю. Войтиков, А.Н. Моисеев, П.Н. ТумаевРис. 3. Структура компонентов GRID Server и GRID ClientКомпонент DB является базой данных, хранящей информацию о заданиях сис-темы, результатах проведенных ранее имитаций, а также о существующих GRIDКлиентах.Компонент Model - компонент из основной модели системы. Отдельные эк-земпляры компонента передаются на Сервер Клиентом и привязываются к кон-кретному заданию.Компонент Grid Client Application - центральное звено GRID Клиента. Компо-нент выполняет запросы к WCF-службе Сервера для получения новых заданий иотправки результатов имитации. Инициирует имитацию и выполнение заданийкомпонетном Calculator+AIM+AMM.Компонент LocalDB является локальной базой данных или другой формойхранения данных для локального хранения заданий и результатов между сеансамисвязи с GRID Сервером.Стоит отметить, что гибкость интеграции и разделения компонентов вычисли-тельной системы достигается благодаря применению проектных решений Фасад[4] и Шлюз [5]. Применение этих проектных решений позволяет избавиться отвозможной зависимости систем друг от друга, выделить их в независимые про-граммные модули, что, в свою очередь, способствует повышению степени их по-вторной используемости.ЗаключениеИтак, в работе представлена модель распределенной системы моделированияпроцессов систем массового обслуживания, работоспособность которой в доста-точной степени не зависит от физического размещения компьютеров и пользова-телей, участвующих в работе системы, а также доступных каналов связи междуними. Это делает доступным для привлечения к работе большее количество вы-числительных ресурсов, а саму систему - доступной для большего количестваклиентов.
Войтиков Константин Юрьевич | Анжеро-Судженский филиал Кемеровского государственного университета | кандидат технических наук, доцент кафедры информатики | kost_v@ngs.ru |
Моисеев Александр Николаевич | Томский государственный университет | кандидат технических наук, доцент кафедры математических методов и информационных технологий в экономике | amoiseev@ngs.ru |
Тумаев Павел Николаевич | Анжеро-Судженский филиал Кемеровского государственного университета | программист отдела автоматизации и разработки программного обеспечения | ptumaev@yandex.ru |
Резник С., Крейн Р., Боуэн К. Основы Windows Communication Foundation для .NET Framework 3.5: пер с англ. М.: ДМК Пресс, 2008. 480 с.
Фаулер М. Архитектура корпоративных программных приложений: пер. с англ. М.: Изд. дом «Вильямс», 2004. 544 с.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования: паттерны проектирования. СПб.: Питер, 2001. 366 с.
Топорков В. В. Модели распределенных вычислений. М.: ФИЗМАТЛИТ, 2004. 320 с.
XJ Technologies (Официальный русскоязычный сайт) [Электронный ресурс]. URL: http://www.xjtek.ru