автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.06, диссертация на тему:Метод построения архитектуры систем интеграции распределенных приложений в АСУ на железнодорожном транспорте

I к

¡иг

1 "Л''. ; .

"На"правах рукописи

<

КАСАТКИН АЛЕКСАНДР ВЛАДИМИРОВИЧ

МЕТОД ПОСТРОЕНИЯ АРХИТЕКТУРЫ СИСТЕМ ИНТЕГРАЦИИ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ В АСУ НА ЖЕЛЕЗНОДОРОЖНОМ

ТРАНСПОРТЕ

Специальность 05.13.06 - Автоматизация и управление технологическими процессами и производствами (транспорт).

Автореферат диссертации на соискание ученой степени кандидата технических наук

Са нкт-Петербург 2003

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

Научный руководитель:

доктор технических наук,

профессор Яковлев Валентин Васильевич

Официальные оппоненты:

доктор технических наук,

профессор Лецкий Эдуард Константинович,

кандидат технических наук,

доцент Чухонин Владимир Михайлович

Ведущее предприятие: ФГУП "Гипротранссигналсвязь"

Защита состоится 29.12.2003 в 13.00 на заседании диссертационного совета Д.218.008.02 при Петербургском государственном университете путей сообщений по адресу: 190031, Санкт-Петербург, Московский пр., 9, ауд. 7-320.

С диссертацией можно ознакомиться в библиотеке университета.

Автореферат разослан ноября 2003 года.

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

Ученый секретарь диссертационного совега,

кандидат технических наук, доцент В.Б.Культин

2.00?

-А

Общая характеристика работы

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

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

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

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

предприятий также имеют проблемы передачи та|'гнп,Т1г""Г'",Лй инф^рмпп""

РОС. НАЦИОНАЛЬНАЯ [ между распределенными приложениями. БИБЛИОТЕКА

СИ

5 оэ

ДБЛИОТЕКА I

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

В связи с этим все больше возрастает актуальность решения следующих

задач:

- Анализ основных проблем, возникающих в процессе объединения в единую систему разрозненных автоматизированных систем (АСУТП, АСУП и пр.);

- Создание методики для оценки параметров взаимодействия между системами и приложениями;

- Исследование возможности использования промышленных средств интеграции для транспортных предприятий;

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

Исходной основой диссертации являются теоретические и прикладные исследования, связанные с вопросами интеграции программных приложений и автоматизированных систем (АСУП, АСУТП) на транспорте.

Цель диссертации: разработка архитектуры для интеграции приложений и АСУ, создание методики по выбору параметров архитектуры применительно к транспортным предприятиям.

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

Научная новизна работы заключается в следующем:

• Создана формализованная модель для оценки качества взаимодействия приложений и АСУ на транспорте

• Разработана методика определения основных параметров

.......архитектуры для интеграции приложений и АСУ

• Создана базовая архитектура для интеграции приложений в транспортном комплексе.

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

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

Апробация работы. Основные положения диссертационной работы докладывались и обсуждались на:

- Международных научно-практических конференциях "Инфотранс-1999" и "Инфотранс-2002"

- Конференциях "Неделя науки" (Санкт-Петербург, 2002 г.)

- Семинарах корпорации ЮМ (1999 - 2002 гг.)

Публикации. Материалы диссертации опубликованы в 5 печатных работах.

Структура и объем диссертации. Диссертация состоит из введения, четырех частей и заключения. В приложении содержится список использованных источников. Общий объем работы 143 страницы, 27 иллюстраций, 5 таблиц.

Содержание работы

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

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

Интеграция программных приложений и АСУ как правило необходима в следующих случаях:

- При внедрении на предприятии новых информационных систем;

- При объединении предприятий, в том числе предприятий транспортного комплекса;

- В процессе создании единого информационного пространства предприятия, включающего в себя различные АСУ.

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

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

Цжатмим I I Приложение 2 I | Приложение 1

Ж

Интеграционны инфраструктур»

I Приложение I I I Приложение 2 1 I Прияоженне 3 I

I Приложение 1 I I Приложение 2 Пражские }

Нятг •раццпмная инфрветрукпцрш

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

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

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

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

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

Необходимость обеспечения масштабируемости.

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

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

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

Реализация интеграционной инфраструктуры на основе синхронных способов обмена информацией (ЯР С, КМ1) позволяет обеспечить гарантированность доставки информации, но не может применяться с случае

ненадежных каналов передачи информации, которые распространены в транспортных системах.

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

' Возможно также и построение интеграционной инфраструктуры на базе технологии очередей сообщений и соответствующего программного обеспечения (MOM - Message Oriented Middleware). Наряду с положительными моментами (гарантированность доставки, сокращение требований, предъявляемых к клиентскому программному обеспечению), разработка интеграционной инфраструктуры на базе MOM имеет и отрицательные стороны - в частности, невозможность обеспечения без определенных доработок функций, связанных с управлением системой передачи информации.

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

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

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

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

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

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

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

Схематично место СПТИ в информационной инфраструктуре предприятия транспортной отрасли иллюстрировано на Рис. 2.

Рис. 2 Место СПТИ в информационной инфраструктуре

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

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

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

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

В настоящее время актуальной является проблема создания существенно распределенных АСУТП с использованием существующих на предприятии каналов передачи информации. Применение СПТИ при решении данной проблемы практически устраняет влияние распределенности.

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

Наиболее распространенными критическими ситуациями являются:

- невозможность в течение длительного времени организовать доставку информации адресату;

- неактивность того или иного приложения в случае функционирования последнего в режиме регламента;

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

Определение

набора критических параметров

Мониторинг системы

Проведение корректирующих действий

Рис. 3 Алгоритм работы оператора с критическими ситуация"»

Для формализации процесса выбора наиболее подходящей С1ТГИ из ряда возможных необходимо определить понятие качества взаимодействия приложений и привнесенного качества СПТИ.

на Рис. 3.

нет

Возникновение

критической

ситуации

При рассмотрении упрощенной модели взаимодействия приложений (Рис. 4) можно ввести понятие качества взаимодействия приложений без учета влияния СПТИ.

Рис. 4 Упрощенная модель взаимодействия: два приложения

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

Качество интеграции

(ЗА1А2

^""-♦•Количественные характеристики

@Л\А2 ~ (0-11/12 И 'й*\лгая* } (О

Определение <Зд|а2 в соответствии с (1) позволяет учитывать две основные характеристики систем передачи технологической информации -удобство интеграции приложений и свойства обмена информацией между приложениями. Далее можно определить "качественную составляющую"

= 0.1} (2), причем q•1 в (2) являются характеристиками, показывающими наличие или отсутствием того или иного свойства, необходимого для решения задачи интеграции приложений. В частности, Я| - возможность использования в случае разнородных приложений, я2 - поддержка свойства гарантированное™ доставки, qз- поддержка свойства интеграции новых приложений, наличие свойства масштабируемости, поддержка механизмов защиты информации и разграничения прав доступа, я^-поддержка гетерогенных приложений и т.д. В свою очередь "количественная" составляющая

(3)

Где ЫеТ- максимальное время доставки информации, Ь2 -максимальный процент потерянных сообщений, ЬЗ - периодичность обмена информацией, Ь4 - время блокировки А1 на время передачи/приема информации, Ь5 - время блокировки А2 на время передачи/приема информации. Список данных параметров является расширяемым и индивидуален для каждой задаче. Выше приведены лишь наиболее распространенные параметры.

Как и в случае с дИЫ2 „ отдельные элементы характеризуют качество взаимодействия приложений без использования вспомогательных средств (СПТИ).

Таким образом <2ЛШ = {{<?1, дЗ...}, {61, Ь2, ¿3...} } является

характеристикой взаимодействия приложений А1 и А2.

Необходимо отметить, что предложенное в (1), (2) и (3) выражение для качества взаимодействия А1 и А2 никак не учитывает влияния СПТИ. Для учета его влияния будем рассматривать £ спти, вычисляемое в соответствии с (4).

Оспти = {Оспти М.1 Оспти есхИ.

(2спт ,„, определяется тем же набором параметров, что и ()лш и характеризует собственные свойства СПТИ с точки зрения качества интеграции. Набор параметров, определяющих бспя „с), , существенно уменьшается по сравнению с £Э,М2 , что связано с отсутствием таких параметров, как периодичность обмена информацией и время блокировки приложений. 0СЛ7Й „с)1 таким образом характеризуется значением ЫеТ -временем доставки сообщений и Ь2 - процентом потерянных сообщений.

Качество взаимодействия приложений с учетом СПТИ, определяется в соответствии с (5).

6,11 ( П7И А2 = Qлlл2 °0(ПТИ

(5)

При этом суперпозиция "качественных" составляющих Q представляет собой логическое сложение соответствующих q;.

0м am, лг = 4' Qoi a, V h Саго (6)

"Количественные" составляющие вычисляются в соответствии с (7):

^QaH IITttAi mill (£>] J bf Qciini ^

b,,, ) П).

2 C/41 amiAl 4 2QAIAi* 2 Qctmt ' V '/»

QA | cant AI ^Qaiai

при ЭТОМ bt QMamtl ~ 0, если q1Qcmi =1,ддя/ = 2,4,5

Как видно из (6) и (7), наличие СПТИ и его характеристики могут существенно изменять характеристики взаимодействия. Таким образом, грамотно выбранная и спроектированная СПТИ может улучшить характеристики взаимодействия приложений по сравнению с первоначальными. Для выбора наиболее подходящей из возможных должно быть задано эталонное значение QAIA2. Минимальное расхождение между QAIA2 и QAU2 и будет являться критерием отбора СПТИ и параметров СПТИ. Отметим, что, как правило, перед проектированием СПТИ устанавливаются в основном эталонные значения QAU2 ^ , в то время как QMA2 „ определяются самим проектировщиком на стадии создания СПТИ.

Качество взаимодействия является функцией времени. Интеграционная составляющая качества взаимодействия QM А2 м не зависит от времени, то есть Q*\n mi * /С), где t - время (по крайней мере, такое утверждение справедливо для абсолютного большинства случаев). Таким образом, временную зависимость имеет лишь QM лг и Qcnm. Явной зависимости от времени не

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

лишь на оговоренный промежуток времени (например, допускается отсутствие связи не более чем в течение N секунд). Изменение формулы для (¡мл1 с учетом фактора времени приведено в (8).

йлм ={{<?!. 92. <73...}, 01, 62, И...} } |Де,м2

Шш» ))

Операция "вычитания" в (8) проводится по элементам <2ЛШ. Таким образом, окончательно формализованная задача проектирования СПТИ для двух взаимодействующих приложений сводится к построению СПТИ,

Ялыг » а Д6.М2 (К**, ДЛЯ V/.

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

С методологической точки зрения процесс проектирования СПТИ и системы администрирования заключается в итеративном процессе анализа и синтеза с учетом наложенных на систему ограничений. На первом этапе анализируется лишь качественная составляющая взаимодействия @АЫг ,„, . В большинстве случаев после анализа q¡ оказывается возможным принять решение о выборе наиболее подходящей с этой точки зрения СПТИ.

Второй этап выбора СПТИ начинается с анализа количественных характеристик ()МА1 аЛ и набора Ад, определенного на первом этапе. Основной задачей данного этапа является настройка параметров СПТИ с целью полного удовлетворения заданным условиям. Набор параметров СПТИ, изменяемых на данном этапе, существенно зависит от типа СПТИ.

удовлетворяющей следующим условиям: <2,

А\ СПТИ Л2

минимально отличается от

На третьем этапе выбора СПТИ принимаются во внимание оставшиеся неоптимизированными параметры и набор требований &(). Основной задачей данного этапа является проектирование системы администрирования, максимально удовлетворяющей требованиям, предъявляемым к системе в целом. Блок-схема алгоритма выбора СПТИ проиллюстрирована на Рис. 5. На третьем этапе данного алгоритма производятся следующие действия:

• Выбор набора критических ситуаций на основании Д0.

• Выбор отслеживаемых параметров на основании набора критических ситуаций.

• Определение возможных действий администратора при возникновении критической ситуации.

Тип спти,

Л?

Настройки выбранной СПТИ, Д?'

Параметры системы администрирования

<2.

Л\Л2 ¡т.

0-Л\Л 2 ехсИ, > Л?

0л1А2 ехск

Дб.д»

Рис. 5 Иллюстрация алгоритма выбора типа и параметров СПТИ Формализованная методика выбора типа и параметров СПТИ в случае большого количества приложения аналогична рассмотренной выше, но вместо скалярных выражений для качества взаимодействия рассматривается матрица взаимодействия и матрица требований (9), (10).

о йлш Ялиь •

= о О QA2A} .

ООО ООО

(10)

В третьей главе освещаются вопросы создания базовой архитектуры СПТИ для предприятий транспортного комплекса.

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

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

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

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

1. Необходимость обеспечения гарантированное™ доставки информации между серверными и клиентскими компонентами.

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

3. Необходимость создания специальных средств для интеграции с производственными приложениями.

Для полноценного удовлетворения нужд транспортного комплекса необходима модификация СПТИ на базе MOM с учетом указанных выше свойств. Архитектура СПТИ на базе MOM с необходимыми доработками проиллюстрирована на Рис. 6.

Ctfitf яриЛ/шмтаымя фпряяят»

Молу ль Модуль Модуль

редшггиро храиеияа работа с

очередамн

форинм

л:

I Систем* администрирования

Модула, гора Мо*>*» оператор* генерации

Уяраыенж тол од от ней

г^Ж""-

Управление tonoaontaH Управление тмояогиеЯ

1 -1 «»

Приложение Приложение

Рис. 6 Архитектура СПТИ на базе MOM с необходимыми доработками

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

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

Клиентские части могут быть разбиты на три основных типа. Основные функции клиентских частей иллюстрированы в Табл. 1.

Табл. 1 Функции клиентских частей

л Тип клиентской Управление Хранение Интерфейс для

« компоненты топологией информации интеграции

« Тип I V

Тип II л/ V

Тип III V л/ л/

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

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

»

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

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

Система администрирования СПТИ включает в себя модуль администрирования, модуль мониторинга, модуль генерации отчетов, модули логгирования и протоколирования в клиентских частях.

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

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

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

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

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

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

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

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

В четвертой главе рассматриваются примеры применения СПТИ для решения задач интерации АСУ и приложений транспортных предприятий. Примеры иллюстрируют следующие основные области применения СПТИ:

- Доставка информации в распределенной системе транспортного комплекса с возможностью оперативного управления ситуацией;

- Интеграция АСУ и приложений с обеспечением гарантированное™ доставки информации и предоставлением интерфейсов для интеграции вновь разрабатываемых приложений;

- Взаимодействие между распределенными приложениями с применением механизмов гарантированной доставки файлов.

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

- Гетерогенность среды получения и обработки информации;

- Гетерогенность каналов передачи данных;

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

- Высокие требования к надежности доставки информации (время доставки не более 2 минут);

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

Применение формализованной методики показывает необходимость применения MOM (системы MSMQ) как основы для СПТИ, а также приводит к следующим параметрам СПТИ: Ы - время передачи информации между приложениями не более 2 мин, Ь2 - вероятность потери сообщения в процессе передачи по причинам, связанными с программным обеспечением, должна быть близка к нулю. Такой набор параметров приводит к необходимости реализации специализированного клиентского программного обеспечения, а также системы мониторинга СПТИ. Архитектура системы приведена на Рис. 7.

Рис. 7 Архитектура СПТИ на Октябрьской железной дороге

К основным функциям системы мониторинга, определенным в результате применения формализованной методики, относятся:

• Информирование оператора о следующих критических ситуациях

о Неактивность приложения в течение более чем N секунд (данный параметр может настраиваться как для группы приложений, так и для конкретного приложения) о Недоставка/неполучение сообщения в течение более чем N секунд

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

• Удаленное изменение параметров передачи информации

• Возможность использования других способов связи при отсутствии соединения.

Реализация системы интеграции АСУ и приложений возможностью гарантированной доставки информации рассматривается на примере СПТИ для Петербургского метрополитена.

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

21

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

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

- паспорта на оборудование, перемещаемое между различными депо;

- классификаторы, обеспечивающие одинаковую структуру баз данных в различных депо;

- планы на модернизацию оборудования;

- планы, связанные с диспетчеризацией заявок на обслуживание.

На основе формализованной методики были выбраны параметры СПТИ, а также определены основные функции системы администрирования. Архитектура системы приведена на Рис. 8.

Рис. 8 Архитектура системы в СПТИ Петербургского метрополитена

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

1. Гарантированность процесса обмена информацией

2. Интеграция в существующие приложения без нарушения целостности последних

3. информирование администратора о процессе передачи информации.

Решение данной задачи возможно с помощью применения СПТИ как

показано на Рис. 9.

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

Заключение

Основные научные и практические результаты диссертации, выносимые на защиту, состоят в следующем:

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

2. Предлагаемая в работе методика определения качества взаимодействия приложений/АСУ позволяет количественно оценивать параметры взаимодействия и обосновывать выбор тех или иных способов интеграции.

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

( "количественных" характеристик, влияние СПТИ на качество

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

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

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

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

' сократить количество случаев выхода параметров системы за

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

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

Публикации по теме диссертации

1. Касаткин A.B. Системы технологической почты - гарантированная доставка информации и средство для интеграции приложений, BYTE, №5,1999 г., с. 28-34, №6, 1999 г., с. 38-45

2. Касаткин А.В, Реализация систем технологической почты на основе промежуточного ПО (middleware) различных производителей, Readme, №6,1998 г., с. 35-37

3. Касаткин A.B., Проектирование архитектуры для построения систем передачи технологической информации, Неделя науки-2002, СПб, ПГУПС, 2002 г., с. 367-368.

4. Касаткин A.B., "Средства middleware и их классификация", PCWeek/RE, №19,1999 г.

5. Касаткин A.B., Системы передачи технологической информации на железнодорожном транспорте. Возможность применения стандартного программного обеспечения MQSeries, Материалы конференции "Инфотранс-2002"

Подписано к печати &6~ 11.03г. Печ.л.-1.5

Печать офсетная. Бумага для множит, апп. Формат 60x84 1/16

Тираж 100 экз._Заказ № -12,05,_

Тип. ПГУПС

190031, С.-Петербург, Московский пр , 9 26

г I

n'l

I

i-

#20 92 4 goo?-Л

ВВЕДЕНИЕ.

1. АКТУАЛЬНОСТЬ ПРОБЛЕМЫ. ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ПРОЦЕССУ ПЕРЕДАЧИ ИНФОРМАЦИИ В КИС.

1.1. Современные корпоративные информационные системы (КИС) и задача обмена информацией.

1.2. Интеграция приложений и интеграционная инфраструктура.

1.3. Классификация проблем, препятствующих интеграции приложений.

1.3.1. Разнородность приложений.

1.3.2. Проблема разнородности приложений в применении к информационным системам транспортного комплекса.

1.3.3. Распределенность приложений.

1.3.4. Проблема распределенности приложений/АСУ в применении к информационным системам транспортного комплекса.

1.3.5. Гетерогенность среды.

1.3.6. Проблема гетерогенности среды в применении к информационным системах транспортного комплекса.

1.3.7. Обеспечение масштабируемости.

1.3.8. Защита информации.

1.3.9. Проблема защиты информации в применении к информационным системах транспортного комплекса.

1.4. Возможные подходы к созданию интеграционной инфраструктуры.

1.4.1. Использование протокола передачи файлов.

1.4.2. Синхронные способы обмена информацией.

1.4.3. Использование суррогатной интеграционной инфраструктуры.

1.4.4. Использование MOM для создания интеграционной инфраструктуры.

1.5. Выбор способа построения интеграционной инфраструктуры.

2. ФОРМАЛИЗАЦИЯ ЗАДАЧИ ПЕРЕДАЧИ ТЕХНОЛОГИЧЕСКОЙ ИНФОРМАЦИИ И ИНТЕГРАЦИИ ПРИЛОЖЕНИЙ В КИС.

2.1. Ограничение набора задач.

2.2. Понятие технологической информации и системы передачи технологической информации.

2.3. Основные требования, предъявляемые к системе передачи технологической информации

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

2.5. Управление системой передачи технологической информацией.

2.6. Формализация задачи управления системой передачи технологической информацией .48 to 2.6.1. Понятие качества взаимодействия. Случай двух приложений.

2.6.2. Поведение СПТИ в случае возникновения критических ситуаций.

2.7. Выбор типа и параметров СПТИ.

2.8. Случай большого количества приложений.

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

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

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

Повсеместная автоматизация бизнес-процессов, кроме того, ведет и к возникновению такого явления, как "лоскутная автоматизация" [1] — ситуации, при которой создание единой информационной системы предприятия или холдинга практически невозможно. Возможны два выхода из такой ситуации — построение информационной системы "с нуля" и создание и использование технологий, позволяющих осуществлять интеграцию разнородных приложений/АСУ в единое информационное пространство.

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

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

В [3] показано, что задача передачи информации между приложениями и интеграции приложений могут решаться сходным образом. Как показано выше, обе задачи являются чрезвычайно актуальными для крупных корпоративных информационных систем (КИС). Тем не менее, отсутствие методик для решения задачи гарантированной доставки информации и интеграции приложений и АСУ в специфических областях (в частности, при создании информационных систем в транспортных комплексах) приводит к сложности создания таких систем.

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

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

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

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

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

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

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

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

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

Заключение

Интеграция программных приложений и АСУ, как правило, необходима в следующих случаях:

• При внедрении на предприятии новых информационных систем

• При объединении предприятий, в том числе предприятий транспортного комплекса

• В процессе создании единого информационного пространства предприятия.

Задача интеграции приложений/АСУ и передачи информации в распределенных системах тесно связаны и обладают целым рядом общих характеристик.

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

• Разнородность приложений и АСУ

• Распределенность приложений и АСУ

• Гетерогенность среды, в которой функционируют приложения и/или автоматизированные системы

• Необходимость обеспечения масштабируемости.

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

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

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

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

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

Для формализации процесса выбора наиболее подходящей СПТИ в работе определяется понятие качества взаимодействия приложений/АСУ и привнесенного качества СПТИ.

Качество интеграции

Количественные характеристики

Qa\A2 int. = {Ч\,ЧгЯъ-)>где Я, е{0, 1} причем qj в являются характеристиками, показывающими наличие или отсутствием того или иного свойства, необходимого для решения задачи интеграции приложений.

В свою очередь "количественная" составляющая QAXA2exch={b\,b2,b3.},

Где b\ е Т - максимальное время доставки информации, Ь2 — максимальный процент потерянных сообщений, ЬЗ — периодичность обмена информацией, Ь4 — время блокировки А1 на время передачи/приема информации, Ь5 - время блокировки А2 на время передачи/приема информации и т.д.

Для учета влияния СПТИ в работе рассматривается Q спти, вычисляемое в соответствии с

Qcnm = Шелти ы.» Qcnm ecxh. = { {q\, q2, q3.}, {b\, Ь2) }

Качество взаимодействия приложений с учетом СПТИ, определяется в соответствии с выражением

Qa\ СПТИ А2 = Qa\A2 ° Qc-ПТИ

Для выбора наиболее подходящей из возможных должно быть задано эталонное значение QMAZ. Минимальное расхождение между QAiA2 и QAiA2 и будет являться критерием отбора СПТИ и параметров СПТИ.

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

Методика выбора параметров СПТИ иллюстрирована на следующем рисунке.

Этап I

Тип СПТИ, Д<7 Q

А1А2 int.

Настройки выбранной

СПТИ, Aq'

Этап II

Qa\A2 exch. t A q

Этап III

Параметры системы администрирования

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

В качестве примеров применения разработанных методик и архитектуры в работе рассматриваются следующие основные области применения СПТИ:

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

• Интеграция приложений и АСУ с обеспечением гарантированности доставки информации и предоставлением интерфейсов для интеграции вновь разрабатываемых приложений/АС У

• Взаимодействие между распределенными приложениями с применением механизмов гарантированной доставки файлов

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

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

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

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

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

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

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

1. James Fenner, Application integration techniques, http://\vwwxs.ucl^c.uk/staff/W.Emmerich/lectures/3C05-02-03/aswe21-essay.pdf

2. Middleware and Businessware Market Forecast and Analysis Summary, 2001-2005, IDC Research, http://www.idc.com/getdoc.jhtml?containerId=28373

3. Eric Roch, Application Integration Business and Technology Trends, EAI Journal, August 2002, http://www.eaijournal.com/PDF/EAITrendsRoch.pdf

4. The Emerging Digital Economy, April 1998 report of the United States Department of Commerce, http://www.unc.edU/depts/jomc/academics/dri/011/growth.html

5. Касаткин A.B. Системы технологической почты — гарантированная доставка информации и средство для интеграции приложений, BYTE, №5-6, 1999 г., с. 28-34, 38-45

6. Sungchul Hang, Method-Oriented В2В Application Integration, http ://www.to wson .edu/~shong/teaching/cosc643/l

7. David S. Linthicum, Where Enterprise Aplication Integration Fits with Web Services, Softwaremag.com, April 2003, http://www.softwaremag.com/L.cfm?Doc=2003-April/WebServices

8. С.Санблэд, П. Снблэд, Разработка масштабируемых приложений для MS Windows, Москва, Русская редакция, 2002 г.

9. Д.Марка, К.МакГоуэн, Методология структурного анализа и проектирования, http://ooad.asf.ru/standarts/idef/sadt/index.shtml

10. И. Гордиенко, Закон успешной комбинации, http://old.computerra.ru/online/xxi/283

11. Л.Б. Миротин, Т.А. Прокофьева, О.М. Лопаткин, А.Г. Некрасов, Зарубежная практика создания и функционирования транспортныхтерминальных комплексов, Железнодорожный транспорт. 2003. -№7. - С.47-52

12. З.Касаткин А.В., Средства middleware и их классификация, PCWeek/RE, №19, 1999 г.

13. Middleware and Businessware Market Forecast and Analysis Summary, 2001-2005, IDC Research, http://www.idc.com/getdoc.jhtml?containerId=28373

14. Gray Т., Enterprise QoS Survival Guide: 1999 Edition, http://qos.internet2.edu/wg/documents.shtml

15. H. Игнатович, IBM MQSeries: архитектура системы очередей сообщений, "Открытые Системы", #09-10/1999, http://www.citforum.ru/programming/digest/ibmmqs.shtml

16. Ермаков Е.Т., Опыт работ по разработке и внедрению автоматизированных систем для станций, http://pktb.css-mps.ru/publich/005.html

17. Mark F. Creamer, Heterogeneous Computing Comes of Age, Enterprise Systems Journal, http://www.sengi.com/downloads/PDFDOCs/WhitePaper-EnterpriseArticle-EAIMiddleware6-00.pdf

18. Steve Craggs, File transfer for the future. Using modern file transfer solutions as part of an EAI strategy, White Paper, http://www.eaiindustry.org/docs/member%20docs/eai/FileTransferfor theFuture.pdf

19. Hancen, M. Open middleware standards are redefining EAI and B2B intergration, Intelligent EAI, 25.10.2001, http://www.inteligenteai.eom/feature/010810/featll .shtml

20. McVey, S., Cundiff, R., The Essential Supply Chain, TechnologyEvaluation.COM, 25.10.01, http://www.intranetjournal.com/features/supplychain.html

21. Hansen, M., Mamorsky, P. Java Connector Architecture: The feature of EAI, EAI Journal, May 15, 2001.

22. Correia, J., The Global Economic Impact on the Application Integration. and Middleware Markets, Gartner Group, Aug. 8, 2001

23. Pezzini, M., Thompson, J., Ten Golden Rules for Starting Application Integration, Gartner Group, Nov. 20, 2001

24. IBM MQSeries Workflow, Concepts and Architecture, version 3.2, www3.ibm.com/software/integration/mqfamily/library/manualsa/fmcg0/fmcg Omst.htm

25. MQSeries Family White Paper, June 1999, www-3.ibm.com/software/integration/support/supportpacs/individual/supportp acs/mqsecf.pdf

26. Касаткин A.B., Системы передачи технологической информации на железнодорожном транспорте. Возможность применения стандартного программного обеспечения MQSeries, Материалы конференции "Инфотранс-2002"

27. Касаткин А.В, Реализация систем технологической почты на основе промежуточного ПО (middleware) различных производителей, Readme, №6, 1998 г., с. 35-37

28. Касаткин А.В., Архитектура систем передачи технологической информации, Неделя науки-2002, СПб, ПГУПС, 2002 г., с. 367-368

29. D. Linthicum, A Promising And Perhaps Model Standard, www.ebizq.net/topics/scm/features/1471 .html

30. D. Linthicum Middleware Basics: Not As Basic As You Might Think, www.ebizq.net/topics/messagingmiddleware/features/2049.html

31. John Schmidt, Transforming EAI from Art to Science, www.businessintegrationjournal.com/Department.asp ?DepartmentID=5

32. А.А.Орлюк, А.Н.Ефимов, А.Е.Нартов, Электронный документооборот перевозочного процесса, "Автоматика, связь информатика", №11, 2002 г., http://pktb.css-mps.ru/publich/asil l02ed.doc

33. А.А.Орлюк, Г.Н.Баврин Система ДИСПАРК: функциональные возможности и эффективность, "Автоматика, связь информатика", №4, 2002 г., http://pktb.css-mps.ru/publich/asi4020rluk.htm

34. П.А.Козлов, Информатизация и автоматизация управления — приоритетное направление отрасли, "Автоматика, связь информатика", №4, 2000 г., http://pktb.css-mps.ru/publich/asi400Kozlov.htm

35. А.А.Орлюк, А.Н.Крестинин, Проблемы разработки и внедрения автоматизированных систем, "Автоматика, связь информатика", №4, 2000 г., http://pktb.css-mps.ru/publich/asi4000rluk.htm

36. А.А.Орлюк, Создание программных продуктов в условиях МПС, http://pktb.css-mps.ru/publich/001 .html

37. А.В.Крестинин, Перспективы применения электронного обмена данными в грузовых перевозках в международном сообщении, http://pktb.css-mps.ru/publich/004.html

38. Яковлев В.В., Локальные сети персональных ЭВМ, Ч. 1.-СП6: ПГУПС. 1993

39. Д.А. Милованцев, Ю.А. Фонтанов, В.Г. Воронин, Информатизация государственных служб в период построения глобального информационного общества, Электросвязь. 2003. - №7. - С.9-12

40. Н. Игнатович, IBM MQSeries: архитектура системы очередей сообщений, Открытые системы, #09-10/1999, http://www.citforum.ru/programming/digest/ibmmqs.shtml

41. V. Narayan, Application integration environment for messaging/queuing model, Second International Symposium on Autonomous Decentralized Systems (ISADS'95), http://info.computer.org/proceedings/isads/7087/70870169abs.htm

42. Rikard Land, Ivica Crnkovic, Software Systems Integration and Architectural Analysis A Case Study, http://csdl.computer.org/comp/proceedings/icsm/2003/1905/00/ 19050338abs.htm

43. Tommy Joseph, A Messaging-Based Architecture for Enterprise Application Integration, The Proceedings of 15th International Conference on Data Engineering, http://china.computer.org/proceedings/icde/0071/00710062abs.htm

44. Mark Davydov, Getting ERPs on the same page, Intelligent Enterprise, October 2000, http://www.intelligenteф.com/feature/2000/10/davydov0ct20.shtml

45. Apex Technologies, Whitepaper on Enterprise Application Integration Technology, http://www.firstapex.com/content/Pdfs/WP-EAI-l .O.pdf

46. John Williams, Keys to Enterprise Application Integration, The Proceeding of Technology of Object Oriented Languages and Systems (TOOLS),http://china.computer.org/proceedings/tools/0774/07740399.pdf