Разработка платформы интеграции уровня предприятия для авиационного предприятия на базе сервис-ориенированной архитектуры Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК004.75, 004.624

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

© 2012 С.В. Липатова

Ульяновский государственный университет

Поступила в редакцию 05.10.2012

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

ВВЕДЕНИЕ

Бурное развитие IT-отрасли привело к тому, что на предприятиях накопится большой объем программ, используемых для решения разнообразных производственных задач, работающих на разнородных аппаратных, программных платформах, по разным протоколам. Поэтому используют интеграцию. Интеграция - мера вынужденная, весьма затратная, и было бы правильным постараться ее избежать [11]. Это можно сделать, если сами разработчики приложений выполнят ее на этапе создания наборов приложений, но унаследованные приложения необходимо интегрировать. Интеграция приложений и интеграционные платформы постепенно становятся существенной статьей ИТ-бюджета.

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

ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ПЛАТФОРМЫ ИНТЕГРАЦИИ

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

Липатова Светлана Валерьевна, доцент кафедры ТТС, кандидат технических наук. E-mail: dassegel@mail.ru

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

Этапы разработки интеграционной платформы можно представить в виде последовательности действий (рис. 1).

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

На этапе постановки задачи для интеграционной платформы кроме традиционных работ требуется: выбрать подход к интеграции систем; определить перечень интегрируемых функциональных систем (список интегрируемых программных продуктов будет формироваться на этапе моделирования).

При разработке интегрированных информационных систем значительный акцент делается на моделировании, особенно на моделировании бизнес-процессов. Активное использование MDA (Model-Driven Architecture), UML (Unified Model Language), BMP (Business Process Modeling), включение в среды моделирования средств генерации кода и создание моделей на базе кода, подключение средств моделирования к IDE (Integrated Development Environment) - все это указывает на то, что классические этапы анализа и проектирования все больше замешаются моделированием.

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

Информационная система

Подготовка

Планирование

Анализ

Проектирование

Реализация

Тестирование

Развертывание

Сопровождение

Интеграционная платформа

Подготовка

Планирование

Моделирование

Реализация

Тестирование

Развертывание

Сопровождение

Развитие платформы

Рис. 1. Соотношение этапов классического [8] жизненного цикла разработки ИС

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

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

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

Рассмотрим подробнее перечисленные работы по созданию интеграционной платформы.

ВЫБОР ПОДХОДА К ИНТЕГРАЦИИ

На сегодняшний момент технологий интеграции можно разделить по нескольким подходам (см. табл. 1), каждый из которых имеет свои границы применения.

Примерное разделение технологий (с учетом их ограничений) представлено на рис. 2 в виде алгоритма выбора подхода к интеграции.

Перечисленные технологии и подходы взаимосвязаны, например распространение данных может строиться на ЗОЛ, технология ЕЗБ является развитием идей ЕЛ1 в ЗОЛ, гибридный подход может опираться на несколько подходов, а в реальном проекте интеграции разные сегменты могут поддерживать разные подходы (при внедрении ЕЗБ сегмент с брокером интеграции для отдельного отдела может рассматриваться как одна точка подключения к шине).

Число 5 для ограничения применимости архитектуры «каждый с каждым» выбрано из следующих соображений (если доступ ко всем ПП или большей части унифицирован, то эта цифра может быть и больше). Количество возможных связей между системами можно вычислить с помощью формулы Ы(Ы-1)/2. Если интегрируется три системы, то и количество связей между ними тоже равно трем. В таком случае интег-

рация по принципу «каждый с каждым» оправдана. Если же систем 10, то количество связей равно 45-ти, а это - уже довольно значительная величина [14].

Среди этих технологий ЕЗБ и ЗОЛ (некоторые исследователи включают ЕЗБ в ЗОЛ) являются наиболее популярными и обсуждаемыми технологиями интеграции, с ними сегодня связываются повышенные ожидания, т.к.. с одной стороны, методология ЕЛ1 достигла своей зрелости, а с другой — развеялась иллюзия покрыть всю деятельность организации одной суперсистемой. Важную роль сыграла также маркетинговая активность крупных поставщиков, направленная на продвижение новых сервисных платформ интеграции, таких как ЕЗБ [2].

Выбор метода и средства моделирования

Для построения моделей разного уровня существует множество подходов и методов (см. табл. 2).

Бизнес-процессы являются основными моделями (на практике часто используются паттерны проектирования и для конкретной системы строятся модели, учитывающие специфику производства). Для моделирования бизнес-процессов часто в ЗОЛ-проектах используют также БРМЫ (достоинством является совместимость с языком описания бизнес-процессов БРЕЬ, входящего в стек протоколов ЗОЛ). Наиболее популярным моделями являются диаграммы ИМЬ (рис. 3), т.к. они могут использоваться при моделировании на разных уровнях и поддерживаются основными методологиями управления информационными проектами (ИИР, ЛШЗ, ЮОШХ и т.д.).

Модели иМЬ также разделяют на: модель анализа, проектирования и реализации. Модель анализа показывает, как будет реализована система, проектирования - реализация модели анализа, представляющая собой абстракцию модели реализации. Модель реализации представляет собой физическое объединение реали-

Таблица 1. Подходы к интеграции [5].

Подход Описание

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

Интеграция на уровне пользовательских интерфейсов приложения могут использовать друга через пользовательский интерфейс (screenscraping), используется для сравнительно простых Web - приложений

Интеграция на уровне данных Синтаксический [З] Консолидация (интеграция на физическом уровне) -технологии ETL (Extract-Transform-Load) и ECM (Enterprise Content Management) - данные собираются из нескольких первичных систем и интегрируются в одно постоянное место хранения.

Федерализация (интеграция на логическом уровне)- EII (Enterprise Information Integration) - обеспечивает единую виртуальную картину нескольких первичных источников данных.

Распространение - технология EDR Enterprise Data Replication) - подразумевает их копирование из одного места в другое. Этот подход обычно используется для операций реального времени и является событийно управляемым.

Гибридный подход использует несколько технологий.

Семантический [13] Подход основывается на знании и учете природы данных, вместе с данными хранятся метаданные, для описания метаданных могут использоваться онтологии.

Интеграция на уровне корпоративных приложений EAI (Enterprise Application Integration), совместное использование исполняемого кода, а не внутренних данных приложения, программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО.

Интеграция при помощи ^'еЬ-сервисов SOA (Service-oriented architecture), ESB(Enterprise Service Bus), основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным, они могут работать всюду, где можно использовать WWW-технологии.

зации в терминах реализуемых подсистем и элементов реализации (директорий, файлов, данных, исполняемых файлов, исходного кода) [2]. При наличии моделей уровня реализации код часть «interface» может быть сгенерирован CASE-средствами. Поэтому перед началом моделирования необходимо выбрать и CASE-средство.

CASE-средство, используемое для разработки платформы интеграции, должно осуществлять поддержку анализа и проектирования бизнес-процессов, баз данных и программных продуктов. Значит, должно быть выбрано CASE-средство класса как минимум Workbenches или Environments. Дополнительным требованием к CASE-системе является наличие SOA-шаблонов (паттернов).

Из наиболее популярных CASE пакетов, представленных на рынке, данным классам соответствуют продукты фирм IBM семейства Rational, ARIS от IDSScheer, Together от Borland, пакет DeveloperSuite от Oracle, PowerDesigner от Sybase.

МОДЕЛИ ЭЛЕМЕНТОВ ИНТЕГРАЦИОННОЙ ПЛАТФОРМЫ НА БАЗЕ SOA

ДЛЯ ПОДДЕРЖКИ ЖЦ АВИАЦИОННОЙ ТЕХНИКИ

Интеграционная платформа для авиационного предприятия требует поддержки систем инженерных расчетов (CAE), управления данными об изделии (PDM), конструкторского проетиро-вания и моделирования (CAD / CAM), автоматизированного проектирования технологических процессов (CAPP), управления ресурсами (ERP / MRP), взаимодействия с клиентами (CRM), управления поставками (SCM) и другие [7].

Исходя их алгоритма выбора подхода к интеграции, подходящими для такой системы являются уровня данных или приложений. Технология SOA является рекомендуемой ведущими производителями интеграционных решений, поэтому рассмотрим интеграцию данных и приложений на базе SOA. Для виртуализации единого хранилища используют единую модель данных (для этого используют XML). Для интегра-

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

Рис. 2. Алгоритм выбора подхода к интеграции *ПП- программный продукт

ции на уровне приложений используют ЕЗБ (рис. 4).

При использовании ЗОЛ на уровне данных рассматривают варианты федерализации или распространения данных (при консолидации создается единое физическое хранилище данных, дополняемое по необходимости витринами данных, к которым приложения и обращаются или непосредственно к хранилищу). Для передачи данных может вводится дополнительная информационная магистраль (рис. 4), т.е. появ-

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

При гибридизации подходов (из-за производственной необходимости и наличия унаследованных интеграционных решений) архитектуры интеграции могут видоизменяться и использовать другие технологии.

Любой проект в области ЗОЛ - это, по сути, проект модернизации всей информационной

Рис. 3. Диаграммы ИМЬ.

Рис. 4. а) Классическая схема использования Е8Б б)Совместное использование сервисной шиныи шины данных [12]

Таблица 2. Методы моделирования [5, 10]

Уровень

Методы

Год

Описание

Предприятие

ZachmanFramework

1987

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

Архитектура федеральной организации ранее архитектуры федеральной организации (FEAF)

2002 (1999)

(FEA), структура

Включать следующие пункты:

Точка зрения, с которой будут рассматриваться

архитектуры предприятия (модель сегмента, которая

вкратце будет рассмотрена ниже)

Набор эталонных моделей, описывающих различные

точки зрения на архитектуру предприятия (пять

перечисленных выше моделей)

Процесс создания архитектуры предприятия

Процесс перехода от старой парадигмы (до создания

архитектуры предприятия) к новой (после создания

архитектуры предприятия)

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

The Open Group Architecture Framework (TOGAF)

2003

Архитектура предприятия подразделяется на четыре категории:

Архитектура бизнеса — описывает процессы, используемые для достижения бизнес-целей Архитектура приложений — описывает структуру конкретных приложений и их взаимодействие друг с другом

Архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ни м

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

Методология Gartner

2005

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

Окончание таблицы 2

Бизнес -процессы UML (activity diagram) 1996 Диаграмма активности универсального языка моделирования, описывает последовательности активностей (действий).

BusinessProcessModel(BPM) 2005 Процессная модель описывает бизнес-процессы компании в стандарте WFD. Применяется для описания бизнес-процессов нижнего уровня.

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

Event-driven Process Chain (EPC) 90-е цепочка процессов, управляемая событиями Процессная модель аналог классического стандарта WFD. Применяется для описания бизнес-процессов нижнего уровня.

Службы UML (activity, sequence diagrams) 1996 основан на объектно-ориентированном подходе к проектированию, т.е. основное внимание при его использовании уделяется объектам и их поведению в системе, а не данным, которые они обрабатывают.

Блок -схема 50-е Графическое представление алгоритма

Компоненты UML (Component diagram) 1996 статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Средства IDE Средства сред разработки для описания компонентов

Объекты UML(class, object diagrams) 1996 описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов и объектов

Средства IDE Средства сред разработки для описания объектов и классов.

системы компании, а не ее отдельных элементов. Фактически проект SOA - это задача обобществления полезного для бизнеса компании прикладного ПО, представленного в унифицированном виде (программные компоненты, обеспечивающие те или иные бизнес-сервисы) [6].

Для решения этой задачи необходимо иметь формализованное представление о бизнесе компании, например в виде некоторых моделей. Поэтому анализ ресурсов предприятия и проектирование платформы можно объединить в один этап моделирование. Для SOA-систем выделяют несколько уровней абстракции (уровней моделей, рис. 5).

Модели SOA переводят разработку на более высокий уровень абстракции, что позволяет сосредоточиться на бизнес-сервисах. Модели позволяют абстрагироваться от деталей реализации и сосредоточиться на тех проблемах, от которых зависят архитектурные решения [1].

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

Системы ERP, PDM, CAD и т.д. будут являться или поставщиками или потребителями

ю <С

Уровень предприятия

Уровень процесса

Уровень служб

Уровень компонентов

Уровень объектов

а о

ё

о

С

Рис. 5. Уровни абстракции ЗОЛ [2].

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

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

Таблица 3. Минимальный набор функций ESB [9]

Связь Интеграция

- Маршрутизация и адресация сервисов для обеспечения прозрачности размещения; - Функция администрирования для управления адресацией и именованием сервисов; - По меньшей мере одна из форм парадигмы обмена сообщениями (например, запрос/ответ, публикация/подписка и т. п.); - Поддержка по меньшей мере одного транспортного протокола, который является или может стать общедоступным. Поддержка нескольких средств интеграции с поставщиками сервиса, например, коннекторов Java 2, Web-сервисов, асинхронного обмена сообщениями, адаптеров и т. п.

Взаимодействие сервисов

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

поддержка транспортных протоколов

поддержка средств взаимодействуя

••rnXxis"

•< Delude»

маршруТиЭаций

"extend»

преобразование

гарантироБлнндя передоил сообщений1"™1"

«¡псШе» «include»

публикация

использование очередей

подключаемой система

обнаружение

«ПЛЙе» ''"dude-

7f~— привязка

ведение у истца

администрирование

Поставщик Потребитель Администратор

Рис. 6. Диаграмма прецедентов использования для подсистемы интеграций (Е8Б).

Рис. 7. Диаграмма деятельности информационно-аналитической подсистемы *ГТ-главный конструктор; ГТ - главный технолог; ПТО - производство технической оснастки; КД - конструкторская документация; ЭТД - эксплуатационно-техническая документация

«С++ СМк>'

0 Message

в 1 1 е getGodtext ( ) « get&xii ( )

• getPaJt ( 1

• getAttJchmerl < 1 о getTVpe ( )

m getPropeiWs ( ) в сои ( )

» MiiîSJflij ( ) « -Ate sape { )

'■■С++ Claw« Э MesiagePlugiii

в treateBodyTvpe ( ) " М^^й oetTvoe ( ) меячвРЦ*^ « Message*^ ( ) • -JMersaj^ftj^ ( )

«С++ ClüS" QHeader

1

- Header • getta ( j « setcal {1

1 « Headei ( )

« 1er f )

■ tody

■ Attachment

1 Fejlt 1 Properties Message

Message

Unsage

•■Ct+ClüS" Q l ullt

о getcode ( ) 6 »(Code ( ) a œtfiejscri ( ) » wtReason ( ) a getCauK ( !

* Fault I )

• -AäirtiJ

■■С++ das-3 propttttet

* getRropatr ( i « ( )

« jepwpertr ( J e reuKwe [ J « иге [ ) « Picpyitles { )

• »AflpefMs ( )

Message

-С++ Class-0 Attachment

■ gei<)

■ PMt IJ

■ remcure i J

■ getNares i )

■ itemAt ( )

щ remonfternAt ( )

■ reobce№emAt [ )

■ addltem ( )

■ addltemAt ( J

• QehJftumedCount ( )

s gettimedut/tt i ) » Attachment ( ] в -AiWirortf {)

1

■ at

Hejtfei

"С++ CI«S" QBorty

» get ( ) « getContwts ( i « »Uli в get О « lemcwe ( )

• teplsce ( ) « map? ; )

# getNames { ]

• Bod* U

* -Sod/i)

«С++ Oass" IJCJ

i"calT)

• C3l()

• Mi)

e wiTo [ ) « getTo ( ) в Wtfrçm [ )

в getfüorn ( ) в setFecfoTo [ ) в getReptyTo ( )

• wtfeticTii [ ) 4 gMFJÜtTO ( ) в îiWelalMTO ( ) в getRetoTo ( ) в copy( )

О selection ( ) в getAçiwi ( ) в mut* ( )

• WÎMesbijelD ( ) в getMeraagelD ( ) л tuStiiig 1 )

• Miftiöum ( )

• v*f[ ) в copy [ ) в

Рис. 8. Фрагмент диаграмма классов

ются из одной подсистемы в другую.

Диаграммой уровня реализации является диаграмма классов. На рис. 8 представлен фрагмент диаграммы для подсистемы интеграций. Классы описывают сообщения, передаваемые через шину (примерами сообщений являются сообщения из диаграммы деятельности).

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

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

Работа выполнена при частичной финансовой поддержке Министерства образования и науки РФ в рамках Государственного контракта № 07.514.11.4131.

СПИСОК ЛИТЕРАТУРЫ

1. Амсден Д. Моделирование SOA: Часть 1. Идентификация сервисов URL: http://www.interface.ru/ home.asp?artId=8416 (дата обращения: 8.07.2012 г.).

2. Биберштейн Н., Боуз С., Джонс К, Фиаммант М, Ша Р Компас в мире сервис-ориентированной архитектуры (SOA): ценность для бизнеса, планирование и план развития предприятия. М. :Кудицресс, 2007. 256 с.

3. Воскобойникова А.А. Разработка архитектуры интеграции нескольких информационных систем // Восточно-Европейский журнал передовых технологий.-2009.- №40. URL:http://masters.donntu.edu.ua/2012/ iii/dmuhovsky/library/ voskoboynikov.htm (дата обращения: 8.07.2012 г.).

4. Ковалев С.М., Ковалев В.М. Современные методологии и стандарты описания бизнес-процессов: преимущества, недостатки и области применения // Справочник экономиста. 2006. №11. URL: http://www.profiz.ru/se/ 11_06/ (дата обращения: 8.07.2012 г.).

5. Кусов А.А. Проблемы интеграции корпоративных информационных систем // Управление экономическими системами: электронный научный журнал. 2011. № 28. С. 103-109.

6. Ладыженский Г. Интеграция: ретроспектива и горизонты // Открытые системы. 2010. № 8. C. 34-36.

7. Назаров В.В. Шабалкин Д.Ю. Основные подходы и требования к построению полиплатформенной интегрированной системы непрерывной информационной поддержки жизненного цикла воздушных судов на основе электронного определения изделия. // Материалы 2-й научно-практической конференции «Опыт и проблемы внедрения систем управления жизненным циклом изделий авиационной техники». Ульяновск, 2011. С.88-104.

8. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения. СПб.: Питер, 2012. 608 с.

9. Робинсон Р. Сценарии и решения использования шины Enterprise Service Bus в сервис-ориентированной архитектуре. Функции Enterprise Service Bus/ http://www.kacit.ru/upload/iblock/e6b/ e6b002c1de718a083054f44fa5c1243c.pdf (дата обращения: 8.09.2012 г.)

10. Сешнс Р. Сравнение четырех ведущих методологий построения архитектуры предприятия. 2007. URL: http://msdn.microsoft.com/ru-ru/library/

ее914379.азрх (дата обращения: 8.07.2012 г.).

11. Хохлов Г. Миражи интеграции // Открытые системы. 2007. № 4. С.74-75.

12. Черняк Л. 80Л и сервисы данных// Открытые системы. -2008. - № 2. - С. 30-34.

13. Черняк Л. Интеграция данных: синтаксис и семантика // Открытые системы. 2009. № 10. С.24-29.

14. ШаппеллД. А. Е8Б - Сервисная Шина Предприятия. СПб.: БХВ-Петербург, 2008. 370 с.

DESIGNING OF ENTERPRISE INTEGRATION PLATFORM FOR A AIRCRAFT PLANT WITH SERVICE-ORIENTED ARCHITECTURE

© 2012 S.V. Lipatova

Ulyanovsk State University

The present paper is devoted to questions of designing enterprise integration system, life cycle of enterprise integration platform, methods of simulation and project's example of enterprise integration system for an aircraft plant. Keywords: application integration, information integration, service-oriented architecture, simulation of systems.

Svetlana Lipatova, Candidate of Technical Science, Associate Professor. E-mail: dassegel@mail.ru