“ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ” N 6, 2011 |
НЕКОТОРЫЕ
ПРИКЛАДНЫЕ ВОПРОСЫ РЕАЛИЗАЦИИ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ
В
СПЕЦИАЛИЗИРОВАННЫХ АСУ
В. А. Балыбердин1, Р. П. Быстров2, О. А. Степанов1
1ЦНИИ МО РФ
1Институт радиотехники и электроники им. В.А. Котельникова РАН
Получена 14 июня 2011 г.
Аннотация. Рассматриваются вопросы использования концепции сервис-ориентированной архитектуры при построении перспективных АСУ специального назначения. Показано, что для эффективного функционирования таких АСУ необходимо обеспечить компромисс между полномасштабной реализацией общих принципов СОА и частной реализацией отдельных вопросов построения и организации функционирования АСУ. Для отработки соответствующих решений необходимо создание соответствующего формального аппарата, обеспечивающего исследование и рациональное использование потенциальных возможностей СОА для существенного улучшения функциональных характеристик создаваемых систем и комплексов автоматизированного управления.
Ключевые слова: АСУ специального назначения, информационно-вычислительные процессы, сервис-ориентированная архитектура (СОА), функциональные характеристики АСУ.
Abstract. The work is devoted to analyses of some applied problems mainly in performance area related to SOA-based special automatic systems (SAS). It is revealed that a compromise between a full scale SOA implementation and special automatic system peculiarities is needed. To settle the problem one must have formal tools. Such tools should ensure good using of SOA potential capabilities to increase the SAS performance characteristics as much as possible.
Keywords: automatic systems performance characteristics, computation and communication processes, special automatic systems, service-oriented architecture (SOA).
В настоящее время при создании больших информационных систем различного назначения получает большое распространение концепция сервис-ориентированной архитектуры (СОА). Функционирование систем с такой архитектурой обеспечивается базовыми и прикладными сервисами, которые могут храниться и выполняться на различных ЭВМ, входящих в информационно-вычислительную сеть, обеспечивая формирование адаптивной распределённой вычислительной среды. Концепция СОА заявлена в качестве перспективной архитектуры также ведущими разработчиками ряда отечественных АСУ.
1. Концепция сервис-ориентированной архитектуры.
В соответствии с определением OASIS (Организация по распространению открытых стандартов структурированной информации) сервис-ориентированная архитектура — это парадигма организации и использования распределенных информационных ресурсов, таких как приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть конечный пользователь или другое приложение [1].
В качестве более простого и понятного можно предложить следующее определение.
Сервис-ориентированная архитектура (СОА) – это современный модульный подход к созданию распределённых АС, основанный на использовании сервисов, т.е. программных и информационных модулей, интегрируемых посредством набора стандартизованных интерфейсов и протоколов в единую систему в соответствии с потребностями функционального назначения.
Отдельные программы (модули) и элементы информации могут быть распределены по разным узлам сети и используются как независимые слабо связанные сервисы, доступ к которым стандартизован.
Основная идея, заложенная в концепции СОА, заключается в стремлении обеспечить построение АС в виде «сборочного процесса из стандартных комплектующих» по аналогии с производством промышленных изделий. Практическая реализация этой идеи обеспечивает значительное сокращение сроков и удешевление процессов создания и модернизации АС. Вместе с тем, при внедрении СОА при разработке ряда специальных АСУ необходимо учитывать особенности построения и функционирования систем управления специального назначения.
На рис. 1 представлена общая схема информационных взаимодействий при реализации СОА.
Рис. 1. Общая схема СОА.
Здесь представлены также основные стандарты, используемые при реализации этой схемы. Поясним их сущность.
XML (eXtensible Markup Language — расширяемый язык разметки) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки [1,2,3].
SOAP (Simple Object Access Protocol) - это достаточно простой, основанный на XML-механизме, протокол доступа к объектам в сети. Он обеспечивает создание структурированных пакетов данных для обмена между объектами. В свою очередь SOAP использует НТТР и другие протоколы Интернета.
WSDL (Web Services Description Language, язык описания Web-сервисов) – язык описания программных интерфейсов сервисов, также основанный на XML. Существующие сервисы описываются в WSDL-документах, часто называемых контрактами. Контракты составляет провайдер сервиса. Чтобы потребители могли найти нужный сервис, провайдер регистрирует его с помощью спецификаций UDDI в реестре сервисов. В архитектуре СOA такие UDDI-реестры играют роль посредника.
UDDI (Universal Description, Discovery and Integration - универсальный стандарт описания, обнаружения и интеграции) - это стандарт на базе XML, позволяющий создавать реестры, в которых провайдеры регистрируют свою контактную информацию, предлагаемые сервисы и техническую информацию о них.
Классическая схеме функционарования системы на базе СОА заключается в следующем.
В результате появления некоторого события формируется информационное сообщение или событие, которое публикуется в реальном времени в информационной среде АСУ (в реестре сервисов). При этом информация о публикуемом событии располагается в ЭВМ источника информации. В результате публикации событие становится доступным другим абонентам АСУ. При этом рассылается уведомление о событии всем абонентам-подписчикам, которые могут получить требуемую информацию.
Построенная на базе указанных стандартов система не зависит от технологий и программно-технических платформ, использующихся для реализации сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов реестр сервисов выполняет функции посредника. Провайдер размещает информацию о своих сервисах в реестре. Это даёт возможность потребителю в любой момент найти необходимый ему сервис. Такой способ общения обеспечивает основное качество СOA — слабую связанность. Благодаря этому, сервисы обретают мобильность, т.е. способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями. При этом потребители сервисов не должны принимать во внимание возможное перераспределение ресурсов, вызванное техническими, либо иными потребностями.
Введение процедуры связывания позволяет отложить момент конечной сборки связей на время исполнения, а не на время разработки программы, что характерно для традиционного подхода. При таком подходе любые изменения в услуге провайдера, не затрагивающие существо сервиса, могут легко осуществляться в динамике работы системы. Это важно для обеспечения корректировки и модернизации приложений.
Сервис-ориентированная архитектура предлагает разработчикам совершенно иной подход к многократному использованию приложений. При этом подходе обеспечивается создание более сложных сервисов из сервисов низкого уровня, причём отдельные сервисы могут быть распределены в сети и даже могут принадлежать различным владельцам.
Таким образом, СOA позволяет одновременно удовлетворить кажущиеся несовместимыми потребности во взаимодействии и в адаптивности, не требуя при этом кардинальных изменений в образе деятельности каждой из взаимодействующих сторон.
2. Основные достоинства и недостатки сервис-ориентированной
архитектуры
В качестве основных достоинств использования СОА можно отметить следующие [1,2,3].
1. Сокращение времени на разработку больших АС и повышение производительности труда разработчиков программного обеспечения (ПО). Это достигается за счёт возможности и простоты многократного использования сервисов в системе, иными словами – за счёт «промышленной сборки» приложений из «стандартных программных комплектующих».
2. Более быстрая и менее затратная интеграция новых и корректировка существующих приложений при развитии и модернизации системы. Этот аспект является очень важных для больших АСУ, которые в процессе функционирования могут неоднократно подвергаться модернизации в связи с изменившимися требованиями.
Вместе с тем, использование СОА имеет ряд недостатков, к основным из которых можно отнести следующие [1,2,3].
1. При использовании в СОА языковых возможностей XML в качестве базового средства взаимодействия в системе размер передаваемых документов существенно больше бинарного представления соответствующей информации (примерно в 10 раз) и значительно больше, чем в альтернативных текстовых форматах, особенно – в форматах данных, оптимизированных для конкретного применения АСУ. Это особенно важно учитывать при использовании в АСУ радиоканалов невысокого быстродействия.
2. XML-документ содержит метаданные. При передаче между абонентами большого числа документов одного типа передача этих метаданных не имеет смысла, хотя они будут содержаться в каждом экземпляре.
3. Иерархическая модель данных, предлагаемая XML, ограничена по сравнению с реляционной и сетевой моделями. Существует множество объектов, для описания которых естественными являются другие модели, и отображение таких объектов в XML может быть не вполне адекватным.
4. Высокая степень универсализации и унификации технических решений, заложенная в СОА, не в полной мере учитывает специфику уникальных систем управления, к каким относятся специализированные АСУ.
Рассмотрим последнее обстоятельство подробнее.
3. Анализ СОА в плане соответствия базовым требованиям к АСУ
С учётом изложенного целесообразно произвести анализ особенностей СОА в рамках основных требований, предъявляемых к АСУ. В качестве таких требований будем рассматривать [5]:
устойчивость управления, т.е. способность органа управления эффективно выполнять свои функции в реальной обстановке;
оперативность управления, т.е. способность руководства решать задачи управления в режиме времени, обеспечивающем своевременное влияние на управляемые объекты;
качество отработки решений – т.е. степень оптимальности (правильности, точности и т.д.) решений, отрабатываемых должностными лицами органов управления посредством АСУ.
Отличительной особенностью многих специализированных АСУ как сложных информационных систем является их функционирование в условиях различного рода деструктивных воздействий. Такие воздействия, в конечном счёте, выражаются в выходе из строя одного или нескольких узлов (объектов) системы. При этом в соответствии с оперативными требованиями АСУ должна обеспечивать выполнение наиболее важных функций управления даже при выходе из строя значительного числа узлов. Рассмотрим указанные аспекты функционирования АСУ в плане использования идеологии СОА.
Обратимся вначале к характеристике устойчивости управления. Обеспечение устойчивого управления в условиях деструктивных внешних воздействий осуществляется за счёт резервирования технических и программных средств и информационного обеспечения. В первом приближении различают два основных подхода к реализации резервирования: структурный и функциональный.
При структурном резервировании осуществляется полное дублирование технических и программных средств некоторого узла, включая базу данных. Такой подход отличается значительной избыточностью средств автоматизации и не всегда приемлем по соображениям практического характера.
Функциональное резервирование обеспечивается за счёт дублирования программного и информационного обеспечения в рамках основной функциональной системы. При этом дублирование осуществляется таким образом, чтобы наиболее важные функции системы сохранялись даже при выходе из строя нескольких узлов. Подобный подход позволяет обеспечить устойчивое управление без излишних затрат на средства автоматизации.
Рассмотрим вопросы реализации требований устойчивости управления в рамках СОА.
Прежде всего, отметим, что тезис СОА об однократном размещении сервисов в системе, приемлемый для корпоративных стационарных информационных систем и широко пропагандируемый в литературе, в отношении многих специализорованных АСУ не вполне корректен. Выход из строя узла, в котором размещается важный и часто используемый сервис, может во многом осложнить выполнение функций управления в системе. Следовательно, резервирование сервисов, хотя бы наиболее важных, должно быть обеспечено в АСУ. Форма такого резервирования может иметь различные варианты исполнения. Наиболее простым в реализации представляется подход, связанный с использованием нескольких имён для одного сервиса с размещением его копий в разных узлах.
Далее встаёт вопрос о размещении в системе реестра сервисов. Если он размещается централизованно в некотором узле, то прекращение функционирования этого узла (например, в результате некоторого внешнего воздействия) может парализовать работу АСУ в целом. Поэтому при реализации требований обеспечения устойчивого функционирования АСУ неизбежно встанет вопрос о резервировании реестра сервисов. Такое резервирование может быть, например, выполнено в варианте «горячего резерва» так, чтобы в случае выхода из строя основного узла реестра сервисов автоматически включался резервный.
В целом же можно отметить, что вопросы обеспечения устойчивого управления в специализированной АСУ при реализации концепции СОА требуют отдельного и достаточно детального исследования.
Оперативность управления выражается временными характеристиками процессов управления, в том числе - решения основных управленческих. Решение таких задач связано с использованием некоторой исходной информации. В первом приближении исходную информацию можно разделить на два больших класса:
-динамическая информация, включающая сведения о положении и состоянии управляемых объектов, а также о состоянии внешней среды, наличии деструктивных воздействий и др.;
-условно-постоянная информация, включающая различного рода характеристики объектов, нормативные данные и т.п.
При решении многих расчётных задач, в состав которых входят оптимизационные процедуры, требуется просмотр практически всего объёма динамической информации и значительного объёма условно-постоянных данных. Поэтому время выполнения таких задач, а следовательно - оперативность отработки соответствующих управленческих решений, зависит от того, как распределена информация в АСУ. Если за каждым элементом данных процедура обращается в систему с запросом на XML, то вполне очевидно, что оперативность решения задачи не будет удовлетворительной. Особенно, если система построена на радиоканалах относительно невысокого быстродействия.
С учётом специфики функционирования специализированной АСУ, по-видимому, возможен компромисс между общим подходом СОА и частным решением отдельных вопросов организации информационно-вычислительных работ (ИВР). Так, например, при существующих параметрах запоминающих устройств ЭВМ вполне возможно дублирование необходимых условно-постоянных данных и некоторых программных средств в тех узлах системы, где часто возникает потребность в их использовании. Причем оформление соответствующих элементов информации может быть осуществлено в соответствии с требованиями СОА и XML. Это также упростит выполнение требований устойчивости системы.
Обратимся теперь к рассмотрению фактора качества автоматизированного управления. Качество управления зависит от того, насколько качественно оказывается поддержка должностным лицам органов управления при отработке управленческих решений.
Для оценки качества управления посредством АСУ часто используют степень оптимальности принимаемых решений (разрабатываемых планов). В некоторых случаях такая оценка может быть построена достаточно просто. Например, в случаях, когда оптимизационная задача решается некоторым приближённым методом. В этой ситуации используемый метод может быть оценен apriori путем сравнения в эксперименте результатов, полученных используемым методом и теоретически строгим методом.
В общем же случае непосредственная оценка качества отрабатываемых в АСУ решений весьма затруднительна. И такую оценку осуществляют косвенным путём, например, по степени автоматизации рутинных и творческих функций управления.
Отметим, что автоматизация рутинных функций управления позволяет сократить затраты времени должностных лиц на выполнение этих функций, освободив тем самым дополнительное время для творческой деятельности. В конечном счёте, это способствует повышению качества отрабатываемых решений.
Автоматизация творческих функций управления способствует повышению качества решений за счёт использования математических методов оптимизации, ранее накопленного опыта квалифицированных специалистов (при использовании экспертных систем поддержки решений) и т.д.
Однако в любом случае отработка сложных решений по управлению объектами в автоматизированном режиме требует использования всей имеющейся на соответствующий момент релевантной информации как динамической, так и условно-постоянной. Поэтому вопросы рациональной организации информационно-вычислительных процессов в распределённой системе пунктов и объектов управления, функционирующих в рамках идеологии СОА, приобретают важное значение как с точки зрения устойчивости управления и оперативности отработки решений, так и с точки зрения качества принимаемых решений. Решение этих вопросов требует использования аппарата математического моделирования процессов функционирования распределённых систем обработки данных (СРОД).
Многие существующие методы моделирования СРОД, как правило, требуют слишком детального описания моделируемой системы и, соответственно, - задания значительного объёма исходных данных, которые не всегда возможно получить на практике. Однако в последние годы появились наработки, где удалось достичь разумного компромисса между строгостью учёта основных особенностей моделируемой системы и объёмом исходных данных для осуществления необходимых расчётов [5,6].
Дополнительные сложности возникают при рассмотрении требования оперативности функционирования системы управления. Здесь необходимо учитывать два основных аспектах проблемы:
-увеличение объёма передаваемых информационных сообщений в системе за счёт использования в СОА стандартизованных языковых средств (XML и средства на его основе);
-увеличение трафика в системе за счёт введения центрального элемента – реестра сервисов и процедур связывания абонентов.
Увеличение количества сообщений в системе при использовании СОА связано с тем, что введение посредника неизбежно приводит к появлению дополнительных «служебных» сообщений. И хотя длина таких сообщений невелика, однако их количество может быть значительным, особенно при больших списках оповещения.
Учёт влияния указанных факторов на оперативность функционирования АСУ неизбежно приводит к необходимости поиска новых решений при построении системы связи в АСУ.
Таким образом, реализация классической схемы организации ИВП при СОА вступает в противоречие с общими требованиями, характерными для многих специализированных АСУ. Жёсткое следование этой схеме не обеспечивает безусловное выполнение таких основополагающих требований, как устойчивость автоматизированного управления, оперативность отработки решений по управлению и др.
В этом свете возникает актуальная проблема исследования вопросов адаптации СОА к требованиям АСУ. Иными словами, необходимо исследовать, каким образом можно обеспечить выполнение основных требований АСУ и в то же время сохранить те преимущества, прежде всего в плане упрощения модернизации и развития АСУ, которыми обладает СОА.
4. Возможные пути адаптации СОА к требованиям АСУ
Обеспечение устойчивости и оперативности функционирования АСУ
Прежде всего необходимо отметить, что в системе целесообразно реализовать горячее резервирование реестра сервисов. Это связано с той ролью диспетчера, которая отведена реестру. В простейшем случае схема функционирования реестра сервисов может быть такой. Пусть в одном из узлов АСУ (узел 1) ведётся основная копия реестра. Резервная копия пусть, например, размещается в узле 2. Абоненты системы постоянно работают с основной копией. В случае же выхода из строя узла 1 функции основной копии передаются узлу 2. При этом одновременно формируется новая копия реестра сервисов, размещаемая, например, в узле 3. Подобная схема может быть распространена и на более сложные ситуации, обусловленные поражением нескольких узлов системы управления.
Отметим, что в рассмотренной схеме ведения реестра сервисов роль узла, отвечающего в каждый конкретный момент времени за основную копию реестра, гораздо шире, чем это заложено в общей схеме СОА. В самом деле, из логики функционирования АСУ вытекает, что этот узел должен отслеживать состояние объектов в системе и вносить необходимые изменения в реестр при выходе отдельных объектов из строя. Иными словами, функции реестра сервисов как системного диспетчера (администратора) в АСУ должны быть расширены. Конкретные алгоритмы такого диспетчирования (как и возможные другие схемы функционирования реестра сервисов) должны быть исследованы и рассмотрены отдельно.
Обратимся теперь к вопросам формирования и размещения в системе базы данных (БД). В состав БД АСУ входит вся информация, необходимая для отработки необходимых управленческих решений, как динамическая, так и условно-постоянная. Для обеспечения устойчивого управления необходимо дублирование БД. Организация дублирования информации в системе существенным образом связана и с оперативностью её функционирования. Здесь следует учитывать два основных процесса:
- корректировка динамической информации;
- её использование для решения задач управления.
Оперативность реализации первого из них тем выше, чем меньше копий необходимо корректировать. Оперативность второго, наоборот, тем выше, чем больше копий имеется в системе. Последнее обстоятельство обусловлено тем, что при наличии необходимой копии информации в узле отсутствует потребность в её запрашивании из вне.
Компромисс между этими процессами достигается путём построения сбалансированного варианта организации ИВП в системе на основе решения соответствующих задач оптимизации.
Таким образом, вопросы рациональной организации функционирования АСУ на базе СОА требуют тщательного количественного анализа и поиска наиболее рациональных вариантов построения информационного взаимодействия в системе.
Организация информационного взаимодействия в рамках СОА
Принятая в СОА трёхзвенная организация информационного взаимодействия, когда любые обращения типа потребитель-поставщик реализуются через посредника (реестр сервисов), ориентирована на большие корпоративные системы, в которых невозможно предусмотреть заранее все потребности в информационном взаимодействии абонентов, как текущих, так и перспективных. Что касается рассматриваемых специализированных АСУ, то здесь большое значение имеет установление устойчивых взаимосвязей между узлами. Это означает, что нет необходимости обращаться к реестру сервисов «за каждым чихом», а однажды установленное соединение (с помощью реестра сервисов) может поддерживаться самостоятельно нужное время.
Будем различать два основных режима функционирования АСУ:
-начальная настройка (инициализация) системы на текущее состояние системы управления, функциональной системы и текущей обстановки;
-оперативный режим, т.е. режим функционирования системы в реальных условиях обстановки.
В режиме начальной настройки формируется начальное состояние БД (основная копия и резервные), реестр сервисов (основная копия и резервные) и осуществляется связывание основных процессов в соответствии с идеологией СОА. Последний момент является крайне важным в плане рационального построения ИВП в АСУ. Поскольку рассматриваемая система является специализированной АСУ, в которой процессы информационного взаимообмена в достаточной степени регламентированы, то «опробование» основных взаимосвязей в системе возможно осуществить заранее. Это позволяет установить необходимое связывание абонентов заранее, что позволяет исключить частые обращения к посреднику – реестру сервисов.
Иными словами, начальное состояние системы может быть сформировано на основе реализации классической для СОА схемы взаимодействий. При этом в качестве событий могут выступать моменты инициализации процедур заполнения БД, ввода картографической информации, решения расчётных задач и т.д. При этом необходимо учитывать целесообразность связывания запросов к конкретной информации из узлов, где хранятся резервные копии этой информации собственно к таким копиям, а не к основной копии.
При функционировании системы в оперативном режиме существенным образом используется информация, полученная в режиме настройки. В самом деле, если осуществлено связывание объектов по какому-то виду взаимодействия, то очевидно, что такое связывание следует сохранять и для последующих взаимодействий.
В оперативном режиме функционирования АСУ осуществляется реализация режима управления в соответствии с предназначением АСУ. При этом имеется ряд особых моментов, обусловленных спецификой АСУ как специализированной системы. Остановимся на некоторых из них, представляющихся наиболее важными.
Прежде всего, заметим, что выход из строя отдельных узлов системы не должен существенно нарушать её функционирование. Особенно это касается реестра сервисов как главного диспетчера системы. При выходе из строя узла с основной копией реестра должны быть реализованы процедуры перевода резервной копии реестра в основную и формирования новой резервной копии. Аналогичные процедуры должны быть реализованы и в отношении ситуаций, связанных с выходом из строя узла с основной копией БД.
При этом отслеживание работоспособности узлов должно осуществляться автоматически из узла-реестра, а факт выхода из строя этого узла должен отслеживаться из узла-копии реестра. Соответствующие оповещения абонентов также должны осуществляться автоматически.
Отдельный вопрос представляет реализация корректировки связывания при выходе из строя узла-провайдера. Здесь возможны, по-видимому, разные варианты. Например, такой. Узел-потребитель сервиса при обращении к узлу-провайдеру получает отказ по связи. После этого потребитель обращается к реестру сервисов за получением нового адреса провайдера и осуществляет новое связывание.
Аналогичным образом может отслеживаться факт выхода из строя узла-реестра сервисов. При отказе по связи обращения к этому узлу возможно осуществить обращение к резервной копии реестра.
Заключение
Таким образом, предварительный анализ показывает, что эффективное функционирование систем на базе СОА, включая обеспечение устойчивости и оперативности управления и высокого качества отработки решений по управлению объектами посредством АСУ, требует грамотного учёта возможностей и ограничений СОА при построении информационно-вычислительных процессов в АСУ. При этом необходимо обеспечить компромисс между полномасштабной реализацией общих принципов СОА и частной реализацией отдельных вопросов построения и организации функционирования АСУ.
Для отработки соответствующих решений необходимо создание соответствующего формального аппарата, обеспечивающего адекватное описание и количественное исследование процессов функционирования и взаимодействия элементов СОА. Создание и применение такого аппарата в процессе разработки перспективных АСУ позволит обеспечить рациональное использование потенциальных возможностей СОА для существенного улучшения функциональных характеристик создаваемых систем и комплексов автоматизированного управления
Отметим, что решение вопросов рационального построения ИВП в системе на базе СОА может осуществляться без учёта трёхзвенной архитектуры системы. В самом деле, исходя из особенностей информационного взаимодействия в АСУ, можно получить статистику потоков (и временных оценок) взаимодействий. На основе этой информации осуществляется решение оптимизационных задач по распределению информации в системе. Далее вводятся реестры сервисов и строится схема СОА с соответствующим резервированием реестров. Резервирование сервисов также определяется в процессе решения задач оптимизации.
В целом можно утверждать, что сетецентрическая информационная система, построенная на базе сервис-ориентированной архитектуры, - это, по сути дела, система с распределённой обработкой данных (СРОД), обладающая достаточно быстродействующими средствами передачи и обработки данных и обеспечивающая доведение автоматизированных взаимодействий до того уровня объектов, который необходим с точки зрения достижения поставленных целей и реализации заданных задач системы.
В этой связи те наработки по построению аппарата моделирования и оптимизации СРОД, которые были получены ранее [5,6], могут быть использованы для оптимизации АСУВ на базе СОА с учётом, естественно, имеющейся специфики соответствующих архитектурных решений.
Литература
1. Сервис-ориентированная архитектура. //www.citforum.ru/internet/webservice/soa/
2. Хамид Д. и др. XML – базовый курс - М.,- С.Пб.-Киев, 2009.
3. Бин Дж. XML для проектировщиков. Повторное использование и интеграция. – М.: ИД КУДИЦ ОБРАЗ, 2004. – 256 с.
4. Месарович М., Мако Д., Такахара И. Теория иерархических многоуровневых систем. – М.: Мир, 1973. – 344с.
5. Балыбердин В.А., Пенкин О.М., Полунин А.И. Проблемные вопросы создания и внедрения новых информационных технологий в автоматизированных системах военного назначения. – М.: СВТП РИА – 2001.
6. Балыбердин В.А., Белевцев А.М., Степанов О.А. Оптимизация информационных процессов в автоматизированных системах с распределённой обработкой данных. – М.: Технология – 2002.