Наличие большого ассортимента аббревиатур (ESB, WSM и т.п.), сочетаемых в разных контекстах с SOA, свидетельствует о разнообразии решений, а следовательно, и мнений. Это неудивительно: SOA не навязывает методов интеграции, а лишь декларирует представление компонентов систем в виде сервисов, характеризуемых строго обозначенной границей, публично известным интерфейсом и автономным поведением.

Модель SOA оставляет открытым вопрос о том, как сообщения попадают к сервису от потребителя. Такую гибкость некоторые считают недостатком, утверждая, что SOA не является целостной, готовой к применению архитектурой. Не вдаваясь в детали, отметим, что для рассмотрения самого процесса доставки сообщений можно применять другую модель – архитектуру, управляемую событиями (event-driven architecture, EDA).

Windows-программисты сталкиваются с EDA постоянно. Архитектура этой операционной системы предполагает наличие унифицированных точек входа в приложения, реализованных в виде так называемых «циклов сообщений» (message loops), которые представляют собой не что иное, как ожидающие поступления сообщений обработчики. Получив управление, эти обработчики могут инициировать потоки других сообщений, которые будут направлены в соответствующие приложения или подсистемы.

Предмет рассмотрения EDA – механика доставки сообщений (т.е. событий, облаченных в конкретную форму). Маршруты следования сообщений могут быть жестко определены каналами взаимодействия в клиент-серверном стиле, но чаще встречаются случаи гибко настраиваемой под изменения среды логики маршрутизации. Так, она может быть основана на современном механизме оркестровки или маршрутизации на базе контента (content-based routing, CBR) каждого из сообщений. Главное, что SOA не ограничивает рамок связанности систем. Именно поэтому часто говорят, что модель SOA – «слабо связанная». Благодаря этому взаимодействие с сервисами может быть как прямым, так и опосредованным, выполняемым при помощи всевозможных программных средств промежуточного слоя. К ним традиционно относятся интеграционные брокеры (enterprise application integration, EAI) и очереди сообщений (message-oriented middleware, MOM)

Подобное разделение интеграционного программного обеспечения и соответствующих подходов хорошо иллюстрирует разницу в акцентах SOA и EDA. Производители брокеров склонны видеть в своих продуктах платформы для агрегации сервисов различных систем, предназначенные для построения композитных приложений. Одной из характеристик SOA является возможность агрегации сервисов для создания новых, и в этом отношении брокеры могут быть подходящей платформой. Модель работы очередей базируется на обратном принципе: системы-адресаты подписываются на получение сообщений, в то время как их публикатор не знает не только фактических получателей своего сообщения, но даже их числа. Если из брокеров информацию «вытягивают» клиенты (стиль взаимодействия pull), то с очередями сообщений ситуация иная – в них публикуют (push).

Семантика обращения к сервису инкапсулирует одну из множества операций, предусмотренных интерфейсом сервиса, в то время как обработчик получаемого очередью сообщения не имеет явного формализуемого интерфейса. Обработчик получает от диспетчера очереди ту же семантику события, которую передал очереди публикатор. Как правило, это разные вариации операции «доставить». Тем самым очереди относятся к однородным интерфейсам, таким как HTTP (операции GET, POST, PUT, DELETE) и SQL (операции SELECT, UPDATE, INSERT, DELETE), в которых разработчик приложения не имеет возможности варьировать операции.

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

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

Новые технологии интеграции

Корпоративная архитектура определяет стили взаимодействия в корпоративной сети, но лишь ими разница в подходах не ограничивается. Напротив, событийная основа MOM и брокерная архитектура EAI за годы их совместного существования стали встречаться в одних и тех же продуктах. Но даже это не помогало ИТ-департаментам поспевать за бурно развивающимся бизнесом, требующим все большей скорости непрерывной обработки ожидаемых потоков событий и адаптации к изменениям структуры бизнес-процессов. Это и дало толчок развитию нового поколения технологий, которые унифицируют архитектурные стили EDA и SOA в рамках общего пространства решений, включающих в себя различные стили инфраструктурного (серверы приложений, брокеры, очереди) и прикладного (ERP, CRM и т.п.) программного обеспечения.

К первому поколению Web-сервисов относят во многом успешные инициативы, преследовавшие целью открытие существующих систем для внешнего взаимодействия. Новое поколение Web-сервисов основано на обмене документами, осмысленно спроектированных интерфейсах взаимодействия и многочисленных расширениях базового протокола SOAP. В этой «инкарнации» Web-сервисы обещают стать самой распространенной технологией реализации как сервис-ориентированных, так и управляемых сообщениями систем, хотя ни те ни другие не привязаны именно к ней. Шаблоны обмена сообщениями (message exchange pattern, MEP) протокола SOAP предусматривают передачу сообщений как в одностороннем порядке, так и в режиме «запрос-ответ», что является хорошим началом, но не дает достаточно семантики для управления взаимодействиями на уровне инфраструктуры.

Такие организации, как OASIS, W3C и WS-I, предпринимают активные действия для совершенствования поддержки управляемых событиями приложений. Этому способствует расширяемость SOAP, которая обеспечивается композиционными свойствами протокола. Подобно дополнительным маркировкам типа «не кантовать», на SOAP-конверты можно «наклеивать» своеобразные электронные инструкции, управляющие доставкой и обработкой сообщений. Например, так можно запросить определенные каналы и требуемый уровень надежности доставки.

Благодаря этому механизму спецификации WS* (в частности, WS-Addressing, WS-Eventing, WS-Notification, WS-ReliableMessaging и WS-Security) в совокупности c WSDL 2.0 позволяют полностью реализовать функциональность современных средств промежуточного слоя, ориентированных на сообщения, без использования нестандартных протоколов. Это было подмечено разработчиками интеграционных средств, и в традиционных МОМ-решениях был реализован как минимум базовый вариант SOAP 1.1; многие пошли и дальше.

Обретение альтернативного транспорта позволило производителям заявить о транспортной независимости их продуктов. Они, как правило, представлены на рынке в новом сегменте корпоративных сервисных шин (enterprise service bus, ESB). Нетрудно связать появление ESB с разгоревшейся вскоре после этого дискуссией о полноценности SOA и преимуществах EDA. Дихотомия основана на превалирующей среди разработчиков ESB точке зрения о доминирующей роли EDA в корпоративных архитектурах, что нетрудно обюяснить их коммерческими интересами. Сняв «сервисную» оболочку, под ней можно найти давно известные шины сообщений от тех же производителей. Не случайно разработчики ESB в последнее время занимаются добавлением брокерных элементов в свои платформы.

В качестве естественного способа обретения сервис-ориентированных возможностей в стиле брокера многие разработчики используют язык выполнения бизнес-процессов BPEL (Business Process Execution Language). Увлечение BPEL уже привело к проникновению этой технологии в ESB, EAI и даже в портальные решения. BPEL описывает XML-нотацию, позволяющую представить абстрактную модель бизнес-процесса (явные информационные потоки, связывающие системы) и соответствующий этой модели алгоритм. Последний может быть представлен в виде исполняемого Web-сервиса, имеющего описание интерфейса на языке WSDL, который тесно связан с BPEL.

Вызов операций сервиса, реализованного при помощи BPEL, приводит в действие последовательность шагов, которые исполняются контейнером BPEL в соответствии с формальным описанием логики процесса. Среди таких шагов наиболее интересны синхронные и асинхронные обращения к другим сервисам. Используя их, экземпляр процесса взаимодействует с внешними системами. Он обюединяет их в единый поток, управляемый соответствующими правилами маршрутизации и преобразования сообщений. Таким образом, BPEL – «язык программирования SOA» – предлагает стандартную альтернативу собственным языкам интеграции устаревающих брокеров EAI.

Классическая демонстрация возможностей BPEL основана на процессе заказа туристической путевки, включающем в себя бронирование авиабилетов, номера в гостинице и оплату. Сложность заключается в оптимизирующих ограничениях, определяющих необходимость минимизации суммарной стоимости поездки. Эти ограничения распространяются на стоимость билетов и мест в гостиницах, которая может варьироваться, а сами билеты (места) на определенные дни – даже оказаться полностью распроданными. Только после определения оптимальных дат путешествия и успешного бронирования процесс производит оплату по кредитной карте, а если это невозможно, отменяет бронь и извещает об ошибке. Локальная память, ветвление, циклы и обработка исключений позволяют полностью автоматизировать процесс при помощи BPEL.

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

Для поддержки самообслуживания партнеров хорошо подходит реестр сервисов на базе стандарта Universal Description, Discovery and Integration (UDDI). Используя этот подход, авиалинии и гостиницы, с которыми у владельца процесса бронирования установлены деловые отношения, получают от него разрешение на автономную публикацию своих сервисов и управление ими в партнерском реестре сервисов турагента. Клиент этих сервисов, процесс бронирования, при обработке запросов обращается в реестр для обнаружения доступных сервисов, после чего оперирует ими в соответствии с бизнес-логикой.

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

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

Российская действительность

Недавно в России началась опытная эксплуатация отраслевого решения booklogic, нацеленного на интеграцию отечественных издателей и книжных магазинов. Книжный рынок характеризуется рядом специфических особенностей, в числе которых – широкий ассортимент товарной номенклатуры и большое число контрагентов, а также резкая смена темпов движения отдельных товарных позиций и состава предложений. Эти особенности требуют от участников рынка высокой слаженности действий, которой было сложно добиться из-за крайней разнородности имевшихся средств ИТ-обеспечения и отсутствия инфраструктуры для их непрерывного взаимодействия.

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

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

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

Бизнес-сервисы booklogic оформлены в виде BPEL-процессов, исполняемых на площадке. Поскольку собственного механизма обеспечения возможности постоянного хранения обюектов данных в BPEL не предусмотрено, инфраструктура booklogic дополнена платформой создания «гостевых» сервисов данных для их преобразования и долгосрочного хранения. Когда речь идет о критичных для бизнеса процессах, провайдер сервисов интеграции не может слепо надеяться на успешное выполнение удаленного вызова – тем более в России, где качество каналов связи сильно варьируется.

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

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

Интеграция как услуга

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

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

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

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

Появление первого поколения провайдеров интеграционных сервисов было связано с технологией EDI (Electronic Document Interchange). Тогда эти провайдеры были операторами сетей VAN (Value Added Network), которые обеспечивали доставку коммерческих документов EDI еще без инфраструктуры Internet. Те из них, которые успешно пережили появление Internet, конвертируются в полноценных провайдеров интеграционных сервисов, добавляя в свои решения ряд интеллектуальных функций. Среди наиболее известных операторов VAN, работающих сегодня на рынке интеграции, можно назвать компании GXS, Inovis, ClickCommerce и Sterling Commerce. Они активно пополняют линейки своих предложений, обеспечиваемых в удаленном режиме, другими решениями – как прикладными, так и инфраструктурными.

Очень интересна относительно молодая компания Grand Central Communications, имя которой происходит от названия крупного транспортного узла Нью-Йорка. В этой красивой метафоре Grand Central отводит себе роль «интеграционной кухни» для клиентов, которым для информационного сообщения друг с другом нужен только стандартный «тупик», а не целая инфраструктура «семафоров», «рельсов», «развязок», диспетчеров и администраторов. Стандартами, конечно, являются не ширина шпал и расстояние между рельсами, а XML, SOAP и WSDL. При этом клиенты могут сами управлять логикой взаимодействия с контрагентами, используя пока не завершенную реализацию BPEL.

Даниил Фейгин (feygin@unitspace.com) – вице-президент по технологиям компании UnitSpace (Москва).

Компонентная SOA

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

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

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

Основной архитектурной особенностью системы IFS Applications является компонентный подход к построению ERP-приложения. Принцип сборки из компонентов реализуется на уровне бизнес-решений и на уровне технологической инфраструктуры. Сама система предоставляется пользователям как совокупность автономных интегрированных модулей для поддержки определенных функциональных направлений работы предприятия, а также ключевых бизнес-процессов общего значения (управление эффективностью бизнеса, CRM, SCM, управление качеством, управление проектами, документооборот, бизнес-моделирование). Каждый функциональный модуль, в свою очередь, собирается из обюектов разных уровней технологической платформы – IFS Foundation1.

IFS Foundation1 обеспечивает необходимые средства для проектирования, обюектно-ориентированной разработки, развертывания и администрирования модулей IFS Applications на базе стандартов UML, J2EE и .Net. Разработчики IFS говорят об архитектуре на базе моделей, подразумевая, что при работе над системой основной акцент делается на моделирование: моделирование бизнес-процессов с помощью модуля Business Modeler и UML-моделирование обюектов более низкого уровня, что позволяет сократить время на создание собственно кода. Процессная модель описывает порядок функционирования приложения, в то время как модель на уровне обюектов – его построение. В целом следование компонентному принципу на макро- и микро-уровнях повышает гибкость модернизации как бизнес-логики, так и технологических основ ERP-решения.

Новый технологический фундамент системы IFS Applications 2004 получил название Service Oriented Component Architecture (SOCA). И этот подход вполне соответствует идеологии SOA, не навязывающей новой организации распределенной среды, а предлагающей дополнительный уровень абстракции для представления прикладных компонентов системы как взаимодействующих друг с другом сервисов.

IFS Foundation1 поддерживает трехзвенную архитектуру распределенных систем, без которой невозможна эффективная «компонентизация» бизнес-функций и инфраструктуры. Функциональные бизнес-компоненты системы технологически разбиваются на программные обюекты разных уровней с четко определенными интерфейсами и задачами. Система IFS Applications состоит из более 5 тыс. обюектов, определенных и документированных с помощью UML.

Презентационный уровень и уровень баз данных в этой архитектуре вполне традиционны и используют технологии порталов и различных пользовательских интерфейсов и реляционных СУБД соответственно. Уровень бизнес-логики реализует функции ERP-системы и потоки работ в рамках бизнес-процессов. Для этого вводятся обюекты нескольких типов:

  • обюекты-сущности (entity object) служат для абстрагирования работы с информацией на уровне бизнес-логики, реализуют выборку и модификацию данных, скрывая детали физической реализации хранения;
  • обюекты действий (activity object) поддерживают транзакционные операции и обеспечивают интерактивное взаимодействие пользователей с системой, доступ к ним осуществляется посредством API;
  • сервисные обюекты (service object) служат для реализации сервис-ориентированных архитектурных принципов, обеспечивают предоставление функциональности и данных как сервисов для других приложений с помощью обмена XML-документами.

Объекты уровня бизнес-логики обеспечивают интеграцию высокоуровневых бизнес-компонентов IFS Applications. Обюекты действий реализуют пользовательский доступ к функциональным модулям системы посредством стандартных интерфейсов различных типов – традиционных рабочих мест под управлением ОС Windows, браузеров и мобильных устройств. Сервисные обюекты вводят новый тип коммуникаций для бизнес-модулей на базе XML и обеспечивают взаимодействие этих компонентов с базовыми коммуникационными сервисами. В IFS Foundation1 реализована единая архитектура интеграции IFS Applications с внешним миром – IFS Connect, обеспечивающая взаимодействие бизнес-процессов предприятия с другими процессами, приложениями и технологиями. IFS Connect предоставляет адаптеры для различных типов интеграции, включая EDI, среды промежуточного слоя, ориентированные на обмен сообщениями, простой импорт/экспорт файлов и др. С переходом к архитектуре SOCA система IFS Connect была дополнена возможностями представления любого сервисного обюекта в IFS Applications в виде Web-cервиса, взаимодействующего с другими сервисами по протоколу SOAP. Все коммуникации системы IFS Applications с внешним миром посредством IFS Connect переводятся на язык XML, при этом IFS Connect может конвертировать XML-сообщения таким образом, чтобы использовать различные типы соединений, например WebSphere MQ для связи с приложением на языке Кобол, реализованным на мэйнфрейме.

Внутренние интеграционные механизмы IFS Foundation1 реализованы с использованием J2EE, а IFS Applications может быть развернута на базе серверов приложений от IBM, BEA Systems, Sun Microsystems и Oracle, включая и решения с открытым кодом Jboss и TomCat. Однако разработчики не хотели ограничивать своих клиентов только этим типом инфраструктурной платформы, поэтому в IFS Applications 2004 существуют специальные подключаемые модули для реализации Web-сервисов для .Net и возможности доступа к компонентам IFS Applications из .Net-приложений.

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

--Наталья Дубова

Приложения и инфраструктуры

Компания SAP предлагает клиентам корпоративную сервисную архитектуру Enterprise Services Architecture. Как и линейка приложений нового поколения mySAP Business Suite (включая mySAP ERP), она основана на решении SAP NetWeaver, ядром которого является поддерживающий Web-сервисы сервер приложений J2EE. Он служит основой для брокера интеграции Exchange Infrastructure (XI), ключевая функция которого – оркестровка Web-сервисов на базе BPEL. Совместно с порталом и другими инфраструктурными элементами NetWeaver, брокер XI используется для создания композитных приложений SAP xApps, интегрирующих функции разных систем в единый бизнес-процесс.

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

Технологией композитных приложений занимается корпорация Oracle. В результате приобретения молодой компании Collaxa она получила доступ к одной из наиболее зрелых реализаций BPEL. Продукт, известный теперь как Oracle BPEL Process Manager, занимает центральное место в «сервис-ориентированном» позиционировании Oracle, а его значение для компании нельзя определить иначе как стратегическое. В линейке продуктов промежуточного уровня версия 10.1.3 этого продукта будет представлена в составе Oracle Application Server 10g (средства исполнения процессов) и JDeveloper (инструменты проектирования процессов). В этом виде BPEL станет также связующим элементом линейки прикладных продуктов Oracle Applications.

Старается не отставать от конкурентов и компания Siebel – один из лидеров в области CRM-приложений. В 2003 году она представила решение Universal Applications Network (UAN), архитектурно близкое к ESB, но имеющее одну интересную особенность, которая характерна для решений интеграции данных. На уровне UAN определяется единое представление обюектов, общее для всех интегрируемых приложений, а затем интеграционный сервер автоматически преобразует данные между различными форматами.

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