Андрей Колесов

Архитектура интеграции приложений от Oracle

Источник: журнал BYTE/ Россия ( www.bytemag.ru ) №6 (116), июнь 2008, http://www.bytemag.ru/articles/detail.php?ID=12169&phrase_id=77465

Рис. 1. Эволюция предприятия.

Рис. 2. Структура и состав Oracle Application Integration Architecture.

Рис. 3. Общая схема реализации пакетов Process Integration Pack.

Рис. 4. Интеграция приложения и бизнес-процессов с помощью Enterprise Business Objects.

Корпорация Oracle, сформулировав принципиальный подход к использованию бизнес-приложений в рамках SOA — концепцию Application Integration Architecture, выпустила в конце прошлого года два пакета интеграционного ПО для ее реализации.

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

Весной прошлого года корпорация Oracle ( www.oracle.ru ) также представила на прошедшей в Москве конференции SOA Architect Forum 2007 свою SOA-платформу, состоящую из продуктов семейства Oracle Fusion Middleware (OFM). Имея в виду, что Oracle входит в число крупных разработчиков приложений (к которым в данном случае можно отнести не только ее ERP- и CRM-решения, но и СУБД, и Business Intelligence Suite), на том мероприятии представителям компании тоже был задан вопрос: готова ли Oracle выступить в роли поставщика функциональных сервисов? Прозвучавший ответ был достаточно уклончивым и сводился к будущим планам.

Однако уже летом 2007 г. Oracle сформулировала свой принципиальный подход к возможному использованию бизнес-приложений в рамках SOA, представив концепцию Application Integration Architecture (AIA). А в конце прошлого года в качестве практического шага к реализации этих идей корпорация выпустила два набора компонентов: Oracle AIA Process Integration Packs — готовые модули интеграции приложений, позволяющие автоматизировать обмен данными и управление транзакциями, и Oracle Application Integration Architecture Foundation Pack — инструментарий и среда интеграции, предоставляющие заказчикам средства быстрой разработки собственных интеграционных проектов и подключения к системам заказчиков любых внешних приложений.

Первая презентация концепции AIA и программных пакетов в России состоялась в середине апреля в Мос кве на очередной ежегодной конференции Oracle AppsForum.

Предпосылки и ключевые идеи

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

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

Oracle выделяет три основные причины увеличения разрыва между требованиями бизнеса и способностями ИТ-отдела успевать за ними.

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

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

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

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

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

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

Структура и компоненты AIA

AIA представляет собой иерархическую структуру (рис. 2), включающую несколько слоев:

• процессы на базе лучших методик, построенные с помощью отраслевых эталонных моделей;
• пакеты Process Integration Pack (PIP) — готовые интегрированные приложения Oracle, позволяющие оперативно и без рисков развертывать бизнес-процессы (например, Siebel CRM to Oracle E-Business Suite);
• пакеты Foundation Pack (FP), обеспечивающие создание специализированных бизнес-процессов для любых приложений при помощи готовых, независимых от приложений определений объектов и сервисов;
• Oracle Fusion Middleware — интеграционная платформа на базе открытых стандартов.

Бизнес-процессы создаются на основе отраслевых эталонных моделей, которые отвечают разным уровням детализации.

Уровень 0 . Отрасль — концептуальное представление процессов, задокументированных в отрасли, с очень высокой степенью их абстракции. Например, процесс «Распоряжение о выдаче наличных» тут будет показан одним блоком.

Уровень 1 . Бизнес-процесс — концептуальное описание основного бизнес-процесса с высокой степенью его абстракции, без деталей реализации. Здесь процесс «Распоряжение о выдаче наличных» будет показан в виде нескольких последовательных шагов: поступление запроса, выполнение запроса и выдача денег.

Уровень 2 . Детальный бизнес-процесс — разбиение процесса на логические компоненты. Здесь также имеет место достаточно абстрактное представление, без деталей реализации, но могут быть установлены концептуальные требования к анализу и внедрению. Например, на этом уровне можно уточнить вопросы цены для проверки возможности оплаты счета.

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

Пакеты PIP представляют собой готовую программную реализацию третьего, нижнего уровня эталонной модели в виде интеграционных решений, объединяющих различные бизнес-приложения (рис. 3). В них используется общая модель объектов, что обеспечивает способность пакетов к расширению и модернизации, а также виртуальный набор приложений со значительно более богатой функциональностью. Уже весной 2008 г. Oracle сформировала большой набор пакетов PIP, реализующих как универсальные, так и специализированные интегрированные бизнес-процессы. В частности, выпущены следующие отраслевые версии.

• Телеком: «Управление абонентами и их счетами», «Управление выручкой», «От заказа до подключения».
• Розница: «Оптимизация поставок», «Управление лояльностью покупателей», «Управление заказами, полученными по разным каналам».
• Потребительская продукция: «Акции по продвижению продукции», «Оптимизация продвижения продукции», «Управление спросом».
• Электроника: «От заказа до оплаты», «От запроса до предложения», «Согласование цены».
• Финансы: «Создание счетов в банковской системе», «Консолидация учета финансовых институтов», «Многоканальная поддержка клиентов».

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

Эталонная архитектура SOA — проверенная, надежная и масштабируемая. Она включает заранее определенные шаблоны разработки, лучшие практики безопасности и аудита, рекомендации по обработке транзакций, а также библиотеку справочной документации.

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

Портфель SOA — библиотека готовых независимых от приложений корпоративных объектов/бизнес-сервисов (Enterprise Business Objects and Services, EBO и EBS), которые можно расширять и модернизировать.

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

Технологическим ядром AIA Foundation Pack служит слой Enterprise Business Objects (EBS — это реализация EBO в виде Web-сервиса), через которые происходит взаимодействие бизнес-процессов и приложений (рис. 4). Эти объекты реализованы в виде XSD-файлов. Встроенный набор EBO обеспечивает доступ к функционалу бизнес-приложений Oracle; кроме того, пользователь может создавать свои собственные объекты. При использовании EBO все программные сообщения конвертируются в общую модель данных. При этом приложению нужно знать только две модели данных — свою собственную и каноническую.

Фундамент для будущего

Как уже было сказано, в настоящее время конкретная реализация AIA включает два набора компонентов: Oracle AIA Process Integration Packs — готовые модули интеграции приложений и Oracle Application Integration Architecture Foundation Pack — инструментарий и среда интеграции. Однако нужно подчеркнуть, что AIA — это не только программные продукты, но и общий технологический подход, который позволяет заказчикам получить доступ к функциональности бизнес-приложений Oracle и других поставщиков с использованием идеологии SOA и платформы ПО связующего слоя Fusion Middleware.