Содержание к диссертации
Введение
1. Актуальность проблемы. требования, предъявляемые к процессу передачи информации в КИС 8
1.1. Современные корпоративные информационные системы (КИС) и задача обмена информацией 8
1.2. Интеграция приложений и интеграционная инфраструктура 10
1.3. Классификация проблем, препятствующих интеграции приложений 12
1.3.1. Разнородность приложений 12
1.3.2. Проблема разнородности приложений в применении к инф ормационным системам транспортного комплекса 14
1.3.3. Распределенность приложений 16
1.3.4. Проблема распределенности приложений/АСУ в применении к информационным системам транспортного комплекса 17
1.3.5. Гетерогенность среды 19
1.3.6. Проблема гетерогенности среды в применении к информационным системах транспортного комплекса. 19
1.3.7. Обеспечение масштабируемости 20
1.3.8. Защита информации 21
1.3.9. Проблема защиты информации в применении к информационным системах транспортного комплекса 22
1.4. Возможные подходы к созданию интеграционной инфраструктуры 23
1.4.1. Использование протокола передачи файлов 23
1.4.2. Синхронные способы обмена информацией 28
1.4.3. Использование суррогатной интеграционной инфраструктуры 30
1.4.4. Использование MOM для создания интеграционной инфраструктуры 34
1.5. Выбор способа построения интеграционной инфраструктуры 35
2. Формализация задачи передачи технологической информации и интеграции приложений в КИС 36
2.1. Ограничение набора задач 36
2.2. Понятие технологической информации и системы передачи технологической информации 37
2.3. Основные требования, предъявляемые к системе передачи технологической информации 39
2.4. Краткое резюме: основные проблемы создания интеграционной инфраструктуры в случае обмена технологической информацией 44
2.5. Управление системой передачи технологической информацией 45
2.6. Формализация задачи управления системой передачи технологической информацией .48
2.6.1. Понятие качества взаимодействия. Случай двух приложений 48
2.6.2. Поведение СПТИв случае возникновения критических ситуаций 53
2.7. Выбор типа и параметров спти 54
2.8. Случай большого количества приложений 56
2.9. Заключение 57
3. Интеграционная архитектура для передачи технологической информации и интеграции приложений в кис транспортного комплекса 59
3.1. Необходимость создания базовой архитектуры для спти в транспортном комплексе 59
3.2. Message oriented middleware (mom)-основные характеристики 61
3.3. Области применения mom 65
3.4. Свойства спти на базе mom 67
3.5. Предлагаемая архитектура для интеграции приложений и передачи информации 70
3.6. Клиентские компоненты СПТИ 73
3.7. Обеспечение гарантированности доставки информации между клиентской частью и сервером СПТИ 74
3.8. Управление топологией 76
3.9. Интерфейс для интеграции 77
3.10. Средства администрирования 79
3.10.1. Функциональность модуля администрирования 82
3.10.2. Функциональность модуля мониторинга 84
3.10.3. Функциональность модуля генерации отчетов 86
3.10.4. Функциональность модуля протоколирования на рабочих местах 87
3.11. Другие дополнительные функции СПТИ 88
3.11.1. Преобразование форматов. 88
3.11.2. Управление последовательностью действий 92
3.12. Связь методики построения спти и спти на базе mom 93
3.13. Заключение 95
4. Примеры применения систем передачи технологической информации в задачах транспортного комплекса 99
4.1. Доставка информации в распределенной системе транспортного комплекса 100
4.1.1. Использование формализованной методики построения СПТИ. 102
4.1.2. Реализация системы доставки информации в распределенной среде 104
4.2. Реализация системы интеграции приложений с возможностью гарантированной доставки информации 109
4.2.1. Применение системы передачи технологической информации в задаче "Паспорт вагонов " 112
4.2.2. Серверная часть системы 113
4.2.3. Система администрирования и мониторинга 116
4.2.4. Клиентская часть системы 120
4.2.5. Клиентская часть для передачи файлов и сообщений 121
4.2.6. Клиент для передачи файлов, работающий под управлением MS DOS 121
4.2.7. Клиент для передачи файлов и сообщений, реализуемый, как встраиваемая компонента... 124
4.3. Реализация системы обмена файлами в рамках октябрьской железной дороги 124
4.4.1. Задачи системы 127
4.4.2. Общая архитектура системы 128
Заключение 133
Список использованной литературы 139
- Проблема распределенности приложений/АСУ в применении к информационным системам транспортного комплекса
- Основные требования, предъявляемые к системе передачи технологической информации
- Функциональность модуля администрирования
- Реализация системы интеграции приложений с возможностью гарантированной доставки информации
Введение к работе
Современный уровень развития информационных технологий и вычислительной техники характеризуется проникновением ИТ во все области жизнедеятельности. Кроме того, стремительное снижение стоимости информационных систем с одной стороны, а также увеличение конкуренции в промышленности с другой, привели к необходимости использования информационных технологий для всех задач промышленного производства. В частности, в последнее время автоматизации подвергаются промышленные процессы, критичные для функционирования предприятия. Таким образом, речь уже не идет об автоматизации отдельных вспомогательных задач, таких как работа с документами, но о задачах, связанных с управлением производством, контролем за опасными процессами и пр.
Необходимо отметить, что особую значимость задачи автоматизации приобретают в тех случаях, когда речь идет о больших объемах информации, сложных в управлении системах, в том числе АСУ, и необходимости минимизации влияния человеческого фактора. К таким системам можно отнести системы управления предприятием, информационные системы, обеспечивающие функционирование транспортных систем, комплексов, системы управления энергокомплексами, системы АСУП и АСУТП.
При этом информационные системы, которые обеспечивают управление транспортными комплексами, являются критичными не только для бизнеса, но и для жизнеобеспечения населения. Это приводит к еще большим требованиям с точки зрения надежности и управляемости, включая вопросы гарантированности доставки необходимой информации. Отсутствие гарантированности ведет к непредвиденным последствиям, так как потеря информации может привести к возникновению чрезвычайных и критических для безопасности ситуаций.
Повсеместная автоматизация бизнес-процессов, кроме того, ведет и к возникновению такого явления, как "лоскутная автоматизация" [1] — ситуации, при которой создание единой информационной системы предприятия или холдинга практически невозможно. Возможны два выхода из такой ситуации — построение информационной системы "с нуля" и создание и использование технологий, позволяющих осуществлять интеграцию разнородных приложений/АСУ в единое информационное пространство.
Наряду с этим, особую важность для информационных систем транспортного комплекса приобретают задачи, связанные с интеграцией существующих и вновь вводимых в эксплуатацию информационных систем. Это связано с непрерывностью работы информационных систем в транспортном комплексе и отсутствием возможности единовременного обновления компонентов информационной системы.
Задача интеграции приложений и АСУ является особенно актуальной особенно в последние десятилетия. По прогнозам [2], рынок этих услуг вырастет в течение ближайших лет более чем на 200 процентов. Вместе с тем, наличие различных подходов к решению задачи интеграции, а также отсутствие формализованных методов их сравнения приводит к ситуации, в которой решение задачи интеграции приложений является затрудненным.
В [3] показано, что задача передачи информации между приложениями и интеграции приложений могут решаться сходным образом. Как показано выше, обе задачи являются чрезвычайно актуальными для крупных корпоративных информационных систем (КИС). Тем не менее, отсутствие методик для решения задачи гарантированной доставки информации и интеграции приложений и АСУ в специфических областях (в частности, при создании информационных систем в транспортных комплексах) приводит к сложности создания таких систем.
Данная работа посвящена анализу проблемы интеграции разнородных приложений и гарантированной доставки информации в крупных КИС транспортного комплекса, созданию методик построения таких систем, а также разработке архитектуры, решающей данные задачи.
В первой главе приведен анализ актуальности задачи гарантированной доставки информации и интеграции приложений в крупных КИС. Рассмотрена взаимосвязь этих задач, а также приведены примеры использования различных технологий доставки информации (сообщений), в том числе и для решения задачи интеграции приложений/АСУ.
Кроме того, в первой главе приведена классификация проблем, препятствующих интеграции приложений/АСУ, проанализирована степень важности этих проблем, а также возможные способы их решения.
Кратко описано возможное использование различных технологий для решения проблемы гарантированной доставки и интеграции. Проанализировано современное состояние проблемы, указаны достоинства и недостатки каждой технологии, описаны возможные применения для различных случаев. Сделан вывод о необходимости создания единого подхода для построения крупных КИС с точки зрения удовлетворения требованиям гарантированности доставки информации и возможной интеграции приложений. Описана постановка задачи, решаемой в данной работе.
Во второй главе обсуждается сужение круга решаемых задач для комплекса проблем, связанных с передачей определенного типа информации - технологической информации. Введен ряд определений, в том числе и определение понятия технологической информации, описаны базовые требования к системе передачи информации в этом случае. Кроме того, описаны требования к управляющим воздействиям на систему передачи технологической информации.
Во второй главе также произведена формализация задачи создания системы передачи технологической информации и интеграции приложений. Введено понятие качества взаимодействия двух приложений, показано каким образом архитектура и параметры системы передачи информации между приложениями могут влиять на качество взаимодействия двух приложений, определена методика выбора архитектуры и параметров системы передачи технологической информации. Рассмотрено расширение понятия качества взаимодействия на случай взаимодействия нескольких приложений. Введено понятие интеграционной архитектуры как архитектуры, решающей задачу интеграции приложений и надежной передачи информации. Показана необходимость разработки такой архитектуры для КИС транспортных комплексов.
Третья глава посвящена описанию непосредственно интеграционной архитектуры. Подробно описаны основные задач, которые должна решать интеграционная архитектура, описаны возможные пути ее построения на базе различных технологий.
Выявлены основные причины выбора MOM в качестве основы для передачи технологической информации в крупных корпоративных информационных системах. Описаны основные характеристики используемых MOM, а также комплекс необходимых доработок для создания полноценной интеграционной архитектуры. Структурированы основные элементы интеграционной архитектуры, особое внимание уделяется системе администрирования и мониторинга. Приведен обзор необходимых для управления транспортной системой функций.
В четвертой главе описаны основные возможности применения интеграционной архитектуры при создании информационных систем в транспортном комплексе. Они иллюстрированы описанием ряда практических примеров использования интеграционной инфраструктуры с примерами внедрений на предприятиях транспортной отрасли.
Проблема распределенности приложений/АСУ в применении к информационным системам транспортного комплекса
Основной задачей транспорта является перемещение грузов и пассажиров в удаленные точки. В связи с этим, распределенность информационной системы транспортного комплекса является естественной и системной проблемой.
Рассматривая виды транспорта и, соответственно, виды информационных систем, можно выделить следующие параметры, характеризующие различные виды транспорта. - Протяженность маршрутов перевозки грузов/пассажиров, характерные для данного вид транспорта - Необходимость сбора информации о передвижении по пути следования единиц транспорта - Информационная доступность отдельных участков транспортной системы - характеризует возможность получения информации о состоянии транспортной системы и единиц транспорта не только в конечно/начальной точках, но и между ними. - Объем собираемой информации о перемещении грузов/пассажиров - Автономность единиц транспорта - характеризует возможность установления постоянного канала связи для получения информации о состоянии единиц транспорта
С точки зрения интеграции приложений несомненный интерес представляет не только распределенность, но и совокупность других параметров, обуславливающих сложность процесса передачи информации и интеграции приложений. Табл. 1 показывает, что, в частности, задача передачи информации наиболее тяжело решается на железнодорожном транспорте в силу необходимости сбора информации по ходу движения поезда как с подвижного состава, так и с датчиков путевого оборудования.
Вместе с тем, железнодорожный транспорт отличается от других видов транспорта наличием единой сети передачи данных, позволяющей получить информационный доступ практически к любой точке маршрута железнодорожного транспорта. Такой доступ, однако, характеризуется нестабильностью и возможностью временного отсутствия связи. Напротив, авиатранспорт характеризуется, как правило, невозможностью доступа к транспортному объекту в процессе передвижения, а также отсутствием единой сет передачи информации. Такие особенности различных транспортных систем должны приниматься во внимание при решении задач интеграции приложений и передачи информации.
Гетерогенность среды, в которой работают АСУ, как правило, обусловлена следующими факторами: наличием унаследованных систем или различной спецификой использования приложений (в ряде случаев встречаются оба фактора). В первом случае в вычислительной системе присутствуют отдельные элементы, "унаследованные" от замененных систем - или такие системы полностью. Классическим примером такой ситуации является необходимость интеграции с устаревшими моделями mainfram oB в случаях, когда отказ от них по тем или иным причинам невозможен (причины могут варьироваться от технических до организационных).
Во втором случае гетерогенность среды является следствием разнообразия решаемых задач. Например, достаточно распространенной является ситуация, когда для хранения информации в АСУ используются элементы вычислительной системы под управлением OS/390, для доступа к ней клиентских приложений - UNIX, а сами клиентские рабочие места функционируют под управлением Windows-подобных операционных систем. Задача интеграции гетерогенных элементов в общем случае нетривиальна из-за разности используемых программно-аппаратных платформ. Наличие стандартных средств интеграции может решить задачу лишь в том случае, если все программные элементы системы разрабатываются (или, по крайней мере, проектируются) в одно и то же время.
Одной из причина наличия гетерогенной среды в АСУ транспортного комплекса является большой размер последних, а также совокупность причин, связанных с различным назначением отдельных информационных систем. Кроме того, решающее значение в транспортной отрасли стали приобретать так называемые интермодальные комплексы [11], объединяющие в себе целый ряд транспортных подсистем. Одной из ключевых задач при создании интермодальных комплексов является обеспечение интеграции разрозненных информационных систем в единое целое [12]. Как правило, АСУ различных видов транспорта построены с использованием различных технологий, вследствие чего проблема гетерогенности лишь усугубляется.
Масштабируемость предлагаемого для интеграции решения также является одной из основных задач, стоящих перед разработчиками. Это происходит вследствие двух причин. Во-первых, как правило, в результате разработки таких систем создается целая инфраструктура для интеграции. На первых этапах разработки данной инфраструктуры принимается во внимание лишь ограниченное количество приложений, которые будут использовать данную инфраструктуру. На следующих этапах количество приложений расширяется. Кроме того, при разработке необходимо учитывать возможность работы в данной инфраструктуре приложений, которые будут созданы в будущем. Таким образом, при проектировании интеграционной инфраструктуры необходимо руководствоваться соображениями масштабируемости, принимая во внимание возможное отсутствие точной информации о количестве и типах приложений, которые будут ее использовать.
Кроме того, относительная дороговизна и масштабность проектов по интеграции в организационном плане не позволяет осуществлять изменение инфраструктуры интеграции хотя бы раз в несколько лет. В этой связи при разработке необходимо учитывать расширение номенклатуры и количества приложений.
Основные требования, предъявляемые к системе передачи технологической информации
Предложенные выше ограничения, связанные с типом информации, безусловно, видоизменяют набор проблем, возникающих при создании интеграционной инфраструктуры. Эти изменения рассмотрены ниже в данном разделе. Вместе с тем необходимо отметить, что СПТИ впоследствии должна быть использована не только для интеграции приложений, работающих с технологической информацией, но и для других приложений. Такой подход позволяет на первом этапе создать СПТИ как инфраструктуру, провести интеграцию приложений, работающих с технологической информацией, после чего использовать инфраструктуру для других приложений. Кроме того, именно интеграция приложений, работающих с технологической информацией, является наиболее актуальной информацией при решении общей задачи интеграции.
Проблема разнородности при рассмотрении СПТИ видоизменяется следующим образом. Разнородность с точки зрения типа обрабатываемой информации может не приниматься во внимание вследствие однородности обрабатываемой информации. Тем не менее, задачи, решаемые приложениями, входящими в состав СПТИ, являются различными, в силу чего проблема разнородности с точки зрения решаемых задач не теряет своей актуальности. Неактуальной в случае СПТИ является проблема разнородности с точки зрения методики создания приложений, так как сокращение набора задач обуславливает и существенное уменьшение количества методик, применяемых в процессе создания приложений.
Проблема распределенности также не снимается с рассмотрения в случае СПТИ. Напротив, помимо распределенности, можно выделить еще две подпроблемы: проблема плохого качества связи и проблема гарантированности доставки информации.
Качество средств передачи данных в случае СПТИ, как правило, ниже, чем при интеграции приложений, непосредственно используемых пользователями. Данный факт обусловлен как объективными (невозможность обеспечения высокого качества каналов передачи информации в условиях технологического процесса), так и субъективными факторами (низкий приоритет данной задачи в глазах ИТ-менеджеров).
Таким образом, при разработке СПТИ необходимо принимать во внимание качество и разнообразие типов средств передачи данных. Последний фактор, с одной стороны, усложняет задачу, но, с другой стороны, позволяет осуществить выбор оптимального на данный момент времени способа передачи информации.
Гарантированность доставки информации оказывается одним из важнейших требований к СПТИ. Это связано со спецификой функционирования СПТИ. В соответствии с данным выше определением, СПТИ функционирует в автоматическом или полуавтоматическом режиме, вследствие чего влияние человека на функционирование сведено к невозможен. Вследствие этого представляются возможными два варианта решения проблемы. В первом варианте приложения СПТИ реализуют алгоритм проверки факта доставки информации и обработки данного события. Реализация подобных алгоритмов является достаточно трудоемкой, а проверка факта доставки информации не всегда возможна. Второй вариант заключается в реализации свойства гарантированности доставки на уровне самой СПТИ. Отметим, что в этом случае для контроля доставки может быть использована служебная информация СПТИ, недоступная приложениям, вследствие чего возможности алгоритмов существенно возрастают. Алгоритмы же работы самих приложений при наличии у СПТИ свойства гарантированности доставки существенно упрощаются, а надежность конечных приложений, соответственно, повышается. Гарантированность доставки ведет не только к количественному выигрышу с точки зрения сложности реализации системы, но и принципиально повышает ее качество, позволяя использовать СПТИ в различных областях человеческой деятельности. В частности, наличие свойства гарантированности позволяет использовать СПТИ в системах, обеспечивающих управление сложными и критическими технологическими процессами. Такие системы в абсолютном большинстве требуют гарантированности доставки, так как потеря информации может привести к срыву технологического процесса с непредсказуемыми последствиями.
Вопросы построения АСУТП с малой степенью распределенности (в пределах одной производственной площадки предприятия) изучены достаточно хорошо, а разработка таких систем при наличии достаточно качественной среды передачи информации (например, ЛВС) не является неразрешимой проблемой. Вместе с тем, как отмечалось ранее, тенденция к объединению (укрупнению) предприятий и увеличение количества филиалов (площадок) приводит к необходимости разработки существенно распределенной АСУ ТП. При этом качество средств передачи не всегда является высоким. Применение СПТИ при решении данной проблемы практически устраняет влияние распределенности (при обеспечении гарантированности доставки информации), а сама задача сводится к разработке АСУ ТП большого размера. Таким образом, наличие свойства гарантированности доставки информации в СПТИ является одним из определяющих и существенно расширяет возможности применения СПТИ.
Как уже отмечалось выше, одним из требований при разработке интеграционной инфраструктуры является учет фактора распределенности функционирующих приложений. Одним из типов распределенности является географическая распределенность. Принимая во внимабние масштабы современных информационных систем, нередкой является ситуация, при которой в единую корпоративную информационную систему входят приложения, физически функционирующие в отдаленных друг от друга географических регионах. В ряде случаев (в случае финансовых систем, систем управления производством) такие приложения функционируют в соответствии с определенным регламентом, например, по расписанию. В силу разности часовых поясов возможна ситуация, когда в момент обмена информацией одно из приложений является неактивным по тем или иным причинам (иллюстрацией такой ситуации являются финансовые приложения). СПТИ должна принимать во внимание такую возможность и предоставлять возможность для создания минимизации последствий в этом случае.
Функциональность модуля администрирования
Приложения СПТИ существенно отличаются друг от друга функциональностью, временем создания, используемыми технологиями разработки. Вследствие этого, как правило, отличаются друг от друга и форматы передаваемых сообщений. Надежность приложения обратно пропорциональна сложности реализованного алгоритма, вследствие чего реализация преобразования форматов в каждом отдельном приложении, как правило, приводит к снижению надежности работы системы. Кроме того, в этой ситуации необходимо изменение уже существующих приложений при интеграции в СПТИ нового приложения, что представляет собой организационную проблему.
В связи с изложенным выше представляется целесообразным реализация так называемого сервера преобразования форматов.
Сервер преобразования форматов является компонентой серверной части СПТИ и предназначен для преобразования сообщений в различные форматы. Необходимость такого преобразования связана с наличием большого количества сообщений, одинаковых по семантике, но отличающихся по синтаксису.
Сервер преобразования форматов осуществляет преобразование сообщений, поступающих в очереди, в соответствии с ранее определенными правилами. Правила определяются администратором системы с помощью системы администрирования (модуль администрирования интегратора) и хранятся в базе данных сервера преобразования форматов. Пример формата таблицы БД сервера, относящейся к хранению правил, применяемых для преобразования форматов, приведен на Рис. 18. Поле "Имя очереди" предназначено для указания очередей, к которым применяется данное правило. Количество очередей неограниченно. Поле "Условие" представляет собой условие (булевый набор функций для полей сообщения), при выполнении которого преобразование применяется к данному сообщению. Поле "Формат" описывает непосредственно правило преобразования сообщения в новый формат и содержит ссылку на таблицу, содержащую набор форматов.
Заполнение и модификация базы данных сервер преобразования форматов производится с помощью модуля администрирования сервера, входящего в состав системы администрирования СПТИ. Данный модуль предоставляет удобный графический интерфейс для редактирования БД сервер преобразования форматов.
Основные функции интегратора и БД каталога приведены ниже: Хранение информации о правилах преобразования сообщений Хранение информации о форматах сообщений Наличие интерфейса для редактирования БД каталога внешними приложениями (модулем администрирования Workflow системы администрирования - см. ниже) Выполнение преобразований сообщений в форматы, указанные в правилах преобразования Отслеживание поступления в очереди серверов очередей сообщений, удовлетворяющих условиям, указанным в правилах преобразования. Реализованная функциональность сервера преобразования форматов оказывает существенное влияние на возможность использования СПТИ в различных приложениях, влияя на качественную составляющую качества взаимодействия. Администрирование сервера преобразования форматов производится с помощью специального модуля. С помощью данного модуля администратор получает возможность редактирования двух основных таблиц сервера преобразования форматов, хранящихся в соответствующей БД сервера. Первая таблица содержит набор правил преобразования сообщений. Фактически, она содержит информацию о типах сообщений, исходном и конечном форматах. В зависимости от правила преобразования, конечный формат сообщения может значительно отличаться от исходного (например, в сообщение могут быть добавлены новые поля, изменено содержание полей и т.д.). Правила преобразования форматов определяют только типы сообщений, к которым они могут быть применены, не указывая конкретные условия, при которых преобразование будет осуществлено. В отличие от БД правил, в базе данных времени исполнения (см. Рис. 19) содержится информация о том, к каким очередям и сообщениям могут быть применены правила преобразования. В БД времени исполнения хранится информация о периоде применимости правил, очередях и типах очередей для применения и т.д. Администратор имеет возможность с помощью удобного графического интерфейса редактировать содержимое этой БД. Основными функциями модуля управления сервером преобразования форматов являются: Обеспечение интерфейса администратора с БД сервера преобразования форматов Обеспечение взаимодействия с сервером преобразования форматов и сервером технологической почты Предоставление администратору удобного интерфейса по редактированию БД правил преобразования и БД времени исполнения Предоставление информации, находящейся в БД времени исполнения, в распоряжение сервера преобразования форматов и сервера технологической почты Возможность импорта существующих правил преобразования в БД сервера преобразования форматов других подразделений
Другим расширением функциональности СПТИ является внесение в систему возможности заранее определять последовательность обработки сообщений, а также набор действий, осуществляемых при возникновении тех или иных условий. Функциональность предназначенного для этого сервера управления процессами (СУП) кратко описана ниже.
Сервер управления процессами является частью компонентом серверной части СПТИ и предназначен для решения задач, обеспечивающих полную или частичную координацию выполнения производственных операций (заданий, работ, функций), составляющих структурированные бизнес-процессы предприятия.
Сервер управления процессами обеспечивает хранение созданных администратором сценариев работы пользователей и осуществляет их рассылку на клиентские места и контроль выполнения заданий. Создание сценариев работы производится с помощью модуля соответствующего модуля администрирования, входящего в состав системы администрирования. Сценарии работы пользовательских приложений хранятся в хранилище сервера управления процессами и в необходимые моменты времени рассылаются на места пользователей. При получении сценария работы приложение осуществляет выполнение предписанного сценария. При этом на серверную часть могут отсылаться квитанции о выполнении тех или иных заданий сценария. Таким образом, основными функциями сервера управления процессами являются:
Реализация системы интеграции приложений с возможностью гарантированной доставки информации
В данном разделе приведено описание реализации СПТИ для интеграции разнородных приложений с обеспечением гарантированности доставки информации на примере информационной системы, разработанной для Петербургского Метрополитена.
Петербургский метрополитен является крупным предприятием с большим количеством удаленных площадок и многообразием приложений. Ряд приложений осуществляет обмен технологической информацией, в частности, связанной с процессом ремонта и обслуживания вагонного парка.
Одной из наиболее актуальных информационных задач Петербургского Метрополитена, связанных с передачей информации, является задача "Паспорт вагонов". Работа метрополитена по ремонту вагонов с информационной точки зрения заключается в обмене информацией о наличии запчастей между различными депо, а также в поддержании в актуальном состоянии информации о текущем состоянии вагона с точки зрения номенклатуры составных частей - так называемого паспорта вагона. Для обеспечения нормального функционирования задачи "Паспорт вагонов" необходимо обеспечить доставку информации в гарантированном режиме между различными приложениями, функционирующими в различных подразделениях Петербургского Метрополитена.
В задаче "Паспорт вагонов" под технологической информацией понимается весь набор сообщений, передаваемых в системе между депо в рамках информационного обмена между распределенными приложениями системы. Преимущественно, под пересылаемыми сообщениями в задаче "Паспорта вагонов" понимаются: ? паспорта на оборудование, перемещаемое между различными депо; ? классификаторы, обеспечивающие одинаковую структуру баз данных в различных депо; ? планы на модернизацию оборудования; ? планы, связанные с диспетчеризацией заявок на обслуживание; Помимо внедрения СПТИ в систему "Паспорт вагонов" существует необходимость разработки программного обеспечения, позволяющего обеспечить файловый обмен между приложениями, работающими под управлением операционной системы MS DOS. С этой целью предполагается разработка специальных ехе-модулей, которые решают задачу информационного обмена, и вызываются непосредственно из соответствующих пользовательских приложений. Данный способ решения задачи, с одной стороны, предоставляет гибкий механизм информационного обмена между существующими приложениями, а с другой стороны - не требует существенного изменения самих приложений. Еще одной задачей, решаемой в рамках разработки системы передачи технологической информации, является предоставление удобного механизма разработки распределенных систем, обмен информацией в которых осуществляется путем пересылки файлов и сообщений. Пользуясь предоставленным механизмом, возможно существенно сократить ресурсы, затрачиваемые на разработку, за счет того, что при разработке новых приложений и АСУ основное внимание затрачивается на реализацию их бизнес-логики, в то время как задача информационного обмена решается простым вызовом методов соответствующей компоненты. До внедрения СПТИ в качестве средства доставки информации в Петербургском Метрополитене использовалась система NGM. Основным недостатком существовавшего механизма передачи технологической информации с использованием NGM являлось отсутствие гарантии доставки сообщений. Если в сети передачи данных или программном комплексе происходил сбой во время передачи сообщения, то на обслуживающем сервере записывалось только сообщение об отказе. Оператор системы должен был сам просматривать базу отказов и вручную возобновлять передачу. В период интенсивного трафика сообщений накапливалось большое количество не переданной информации, на обработку которой затрачивалось значительное время. В результате, оперативная информация теряла свою актуальность, а процесс передачи -надёжность. Использование формализованной методики позволяет на первом шаге определить необходимость использования MOM в качестве основы для СПТИ вследствие ориентированности процесса обмена информацией на приложения и необходимости обеспечения гарантированности доставки информации. Требование q6 = 1 - необходимость обеспечения гетерогенности системы с точки зрения используемых программно-аппаратных комплексов выявляет необходимость использования многоплатформенного MOM - IBM MQSeries. Требования, связанные с необходимостью интеграции в будущем в систему новых приложений и АСУ, приводят к необходимости разработки специализированных программных приложений, в соответствии с требованиями, приведенными в разделе 3.9. Требования к системе администрирования и мониторинга наряду с необходимостью получения информации о возникновении критических ситуаций, включают в себя требования к возможности изменения приоритетности сообщений оператором системы. Клиентские приложения задачи "Паспорта вагонов" формируют сообщения, которые средствами разработанного в Петербургском Метрополитене API помещаются на Novell Netware Server. Разрабатываемый Исполнителем клиент СПТИ сканирует соответствующую директорию на Novell Netware Server и осуществляет пересылку сообщений на серверную часть системы передачи технологической информации, которая обеспечивает гарантированную доставку сообщений до клиента-адресата. Последний, в свою очередь, размещает доставленное сообщение в соответствующей директории на Novell Netware Server. Механизм доставки сообщения до соответствующего АРМ а задачи "Паспорт вагонов" реализуется возможностями API, разработанного в Петербургском Метрополитене. В связи с тем, что в задаче "Паспорт вагонов" формат отправляемого сообщения отличается от формата получаемого, разрабатываемая серверная часть системы должна обеспечивать указанное преобразование форматов. Гибкая система администрирования и мониторинга, позволяет осуществлять изменение параметров и контроль функционирования всей системы в целом.
