Точка интеграции что это
О классификации кода
О, коде
Когда я пишу код, мне нравится отдавать себе отчёт о том, что именно я делаю.
Например, код, который пишется за одну ночь для демы завтра утром сильно отличается от кода, который станет основным API системы.
В этом посте я бы хотел рассказать о разных типах кода и дать несколько советов, которые помогают мне и ночью перед демой, и при дизайне больших API.
Код «для себя»
Это код, который решает одну задачу один раз в жизни. Это может быть, например, решением «задачки на смекалку», или вызовом какой-нибудь сложной функции, чтобы посмотреть, «как работает», или скриптом, избавляющемся от каждой третьей точки в файле, или «Hello, world!» на новом языке.
Поскольку время жизни таких программ не больше пары дней, писать их очень просто: не надо волноваться о читабельности, комментариях, проверке входных данных, юнит-тестах и т. п.
Этот код никогда не должен появляться в системе управления версиями. Более того, я предпочитаю не показывать этот код другим разработчикам.
Код прототипа
Это код, который должен реализовать минимальную функциональность какой-нибудь новой фичи. Это может быть практически всем, чем угодно: и пробной интеграцией с другим продуктом, и принципиально новой функциональностью, и новой фичей существующего продукта. Зачастую реализацию прототипа надо закончить в короткие сроки.
Написать хороший прототип в срок довольно сложно. Я выработал следующие правила разработки такого кода: во-первых, код должен быть читаемым. Осмысленные имена переменных, классов и функций, стандарты кодирования и т. п. Во-вторых, комментарии должны быть хотя бы возле наиболее сложных участков. В-третьих, если сроки поджимают, то можно обойтись только самыми основными юнит-тестами и практически не заботиться о проверке выходных данных. Всё это можно добавить, когда прототип станет полновесной частью системы.
Есть ещё одно важное правило. Если для работы прототипа необходимо поменять старый код, изменение должно иметь комментарий. Хотя изменение может быть очевидно в момент написания прототипа, через несколько месяцев будет очень сложно понять, что же хотелось сделать. Особенно если прототип пришлось выкинуть.
Основной код
Это код самой системы. То, что релизится, то что тестирует QA, то, что видят пользователи.
Про то, как создавать этот код пишут книжки. Моя любимая – книга МакКоннела Code Complete.
Я не буду останавливаться на общих правилах создания основного кода. Однако, я бы хотел выделить четыре категории основного кода.
Это та часть компонента, которой будут пользоваться остальные. Мне очень нравится, когда каждый член команы разработчиков создаёт свой компонент и предоставляет остальным API для использования.
Понятно, что все методы и классы API должны иметь самую лучшую документацию, самые дотошные проверки данных, самые читабельные юнит-тесты.
Ну и, конечно, сам API должен должен быть удобным в использовании. Рекомендую презентацию Блоха How to Design a Good API and Why it Matters.
Точка интеграции
Точки интеграции должны обладать неплохой документацией (может, не такой дотошной как API). Более того, должно быть понятно, как именно интегрировать свою часть компонента. Иногда помогает пример.
Мне кажется, что очень важно выделять точки интеграции в отдельные классы (или файлы). Во-первых, этот код довольно часто меняется, во-вторых в нём всегда много ошибок, в-третьих при дальнейшей разработке все конфликты (в смысле системы управления версиями) возникают именно в этих точках.
Более того, если вашему коллеге потребовалось изменить какую-либо часть компонента вне точки интеграции, то скорее всего что-то не так архитектурой (компонент слишком сильно связан внутри себя).
Точка роста
Это часть компонента, которая наверняка будет пополняться новыми фичами. Например, это код, который создаёт контекстное меню. По мере роста системы контекстное меню будет, скорее всего, увеличиваться. Другой пример: системы доставки контента. Хотя изначально может поддерживаться лишь одна, скорее всего в будущем нужно будет добавить ещё несколько.
Ясно, что для таких точек используются шаблоны factory method и abstract factory.
На первый взгляд эти части кода мало отличаются от точек интеграции. Однако, если интеграцию внутри компонента обычно проводят один раз те два человека, которые части писали, расширять компонент могут неоднократно разные люди. Поэтому я стараюсь относиться к точкам роста скорее как к API: дотошная документация, проверки входных данных, обилие примеров.
Я специально выделил точки роста в отдельную категорию. Очень важно понять рано, что данный кусочек кода является точкой роста. Если этот момент пропустить, то каждое следующее дополнение будет добавлять новые хаки. Если в класса (или файле) больше 2000 строчек, то это, скорее всего, запущенная точка расширения.
Более того, именно в этих точках зачастую появляются зависимости от других компонентов. Это ещё один аргумент в пользу выделения точек роста в отдельный класс (или файл).
Остальной код
А это всё остальное. Про этот тип кода написано много статей. Я стараюсь писать этот код так, чтобы через полгода мне было приятно его читать.
Заключение
Мне кажется, что очень важно отдавать себе отчёт о том, какой именно код сейчас пишешь. Это и ускоряет процесс разработки, и делает код лучше.
Какие ещё типы кода стоит выделить? Может, стоит добавить какие-нибудь советы?
Представление модели предметной области (МПО) и точек интеграции
Как известно, описание архитектуры состоит из множества представлений, для соответствующих точек зрения, интересов и заинтересованных сторон.
В этой статье я расскажу о способе создания представления (диаграммы) модели предметной области (МПО), дополненное связями с точками интеграции, на базе которых построена функциональность системы: хранимыми процедурами, функциями и веб-сервисами. Таким образом, данное представление хорошо подойдёт проектам с большим количество точек интеграций и поможет разработчикам и аналитикам быстрее ориентироваться в проекте, порой даже не заходя в код.
Разработка такого представления велась для оптимизации разработки интернет банка. Характерной особенностью подобных систем, является то, что они являются прослойкой над множеством внутренних банковских систем, предоставляющих множество точек интеграции для интернет банка. Поэтому данное представление может быть востребовано в интернет банках и других фронт системах в высокотехнологичных компаниях, использующих множество внутренних интегрированных систем.
Возможности, которые даёт такое представление:
Представление сущности МПО
Представление строится на основе диаграммы классов. Для отображения сущности МПО используется класс. Сама сущность МПО представляет из себя абстракцию, которой может не существовать в реализации в описанном виде.
Аттрибуты сущности МПО содержат перечень основных полей, при этом они могут содержать не все используемые в коде поля, так как их может быть достаточно много и в этом нет смысла.
Название аттрибута задаётся в наиболее удобной для понимания форме. В случае с атрибутами чаще всего было проще использовать то название, которое указано в коде.
Методы бизнес-модели содержат все возможные действия, над данной моделью. Это могут быть CRUD и какие либо ещё возможные методы. Выделение метода зачастую ориентируется на точку интеграции, которая используется в данном методе. Есть смысл так же выносить производные методы, для понимания предметной области.
Название метода в бизнес-модели указывается в свободной форме, таким образом, чтобы по названию можно было понять его суть. Зачастую проще использовать русскоязычные имена. Например, метод получения списка банковских карт, будет иметь названия ПолучитьСписокКартПоКлиенту.
Точки интеграции — это могут быть хранимые процедуры, функции или веб-сервисы. Описываются по формату %схема/веб-сервис%: хп/хф/метод веб сервиса. Стрелкой соединяются с соответствующим методом.
Рисунок 1. МПО на примере одной сущности
Пример того, как описывается одна сущность МПО — изображён на Рисунке 1.
Представление МПО
Итоговое представление МПО может выглядеть примерно как на рисунке. В примере я привёл значительно упрощённую модель. В реальной модели было в 10-15 раз больше сущностей с значительно большим количеством методов и точек интеграции. Однако даже с большими размерами МПО было достаточно просто ориентироваться. Свою роль сыграли возможностям Enterprise Architect и Visual Paradigm, однако в первую очередь помог логический поиск Функциональность->Сущность->Метод->Точка интеграции
Рисунок 2. Пример полного представления МПО.
На рисунке 2 изображён пример полного представления МПО. По этому рисунку уже можно сложить мнение о том, какая функциональность реализована в приложении.
Как представление МПО + точки интеграции может упростить разработку
Для наглядности я приложил диаграмму компонентов (Рисунок 3), распределённых по приложениям инфраструктуры проекта:
Рисунок 3. Диаграмма компонентов.
Допустим, что у нас стоит задача модифицировать функциональность открытия счёта и мы не знакомы с кодом проекта. В такой задаче может прийтись исследовать стэк вызова, а учитывая, что в каждом приложении существует свой набор компонентов, стэк вызова при клике на кнопку «Открыть счёт» может состоять из 8 уровней:
1 — ReactUI
2 — RestApiController
3 — AccountCachedController
4 — AccountServiceWrapper
5 — MainOnlineBackendServiceImplementation
6 — AccountServiceWrapper
7 — OnlineBankLogicServiceImplementation
8 — sheme1: sp_createAccount
Анализ сверху-вниз при помощи отладчика в такой ситуации может занять значительное время, так как на каждом слое, метод может содержать множество строк и ещё вложенные методы, которые будут либо возвращать обратно либо вести к другим точкам интеграции. Поэтому чтобы найти точку интеграции (а именно она выполняет действие), нужно будет прошарить отладчиком почти все строки стэка вызова.
В случае, если мы используем диаграмму МПО, то по соответствующему действию можно получить название хранимой функции, а через неё, с помощью глобального поиска по проекту, найти нужный участок кода и поставить на ней точку останова. Дальше остаётся только вызвать эту точку и идти по стэку вызова снизу-вверх, что значительно проще.
Допустим, что у нас стала возникать ошибка при выполнении какого-либо действия. Для проектов с множеством интеграций частой причиной ошибок является ошибки внешних систем, например было выполнено обновление хранимой процедуры, отключение/недоступность веб-сервиса. На уровне пользователя такие ошибки совсем не очевидны и возникает ощущение, что проблема конкретно в системе, с которой работает пользователь. Чтобы локализовать ошибку чаще всего необходимо проанализировать стэк вызова.
В случае, если мы используем диаграмму МПО, то по действию, с которым происходит ошибка мы находим точку интеграции, ставим на неё точку останова и делаем вызов.
Если точку не поймали, то проблема лежит до вызова.
Если точку поймали, делаем вызов и смотрим прошёл ли вызов без ошибок. Очень часто на этом этапе находятся все ответы.
Если точку поймали и действие выполнилось, тогда идём по стэку снизу-вверх, пока не найдём ошибку.
Это две типовые распространённые задачи, при которых требуется находить точки интеграции.
Другое множество, где диаграмма была полезна — это различные вопросы:
Вы исследуете систему и вам необходимо накапливать информацию о всех понятиях и функционале системы. Диаграмма помогает это выполнять в достаточно лаконичном виде. В дальнейшем такая декомпозиция/композиция позволяет спроектировать архитектурные слои.
Энсис Технологии
«Интеграция приложений для поддержки целостных бизнес-процессов»
Олег Хомутов
Интеграционный проект, направленный на поддержку «сквозных» бизнес-процессов, по своей значимости оказывается одним из наиболее критичных для бизнеса компании. В идеальном варианте интеграционный проект может обеспечить ряд преимуществ.
Требуется тщательная подготовка
Затем встанет вопрос получения данных из одних систем и размещения их в других. Обычно в компании есть разные системы, как от известных вендоров с хорошими возможностями интеграции, так и заказные программные системы. Во втором случае интеграционных интерфейсов может и не быть, или они могут быть самыми минимальными. В самом пессимистичном варианте нужно будет провести «обратное проектирование» бизнес-логики приложения чтобы, к примеру, по имеющимся в базе данным восстановить данные, нужные для интеграции. Имея достаточные возможности для интеграции (к примеру, интеграционный фреймворк системы MS Dynamics AX 4.0), нужно будет только реализовать несколько стандартных интеграционных методов. В большинстве случаев объем работ лежит между этими крайностями.
Оценив потребности получения и обработки данных можно переходить к оценке трудозатрат. Если стоит задача синхронизации данных между однопользовательской бухгалтерской системой и написанной на заказ складской системой, реализованной на СУБД уровня MS Access, то этот объем работ вполне может быть реализован одним средним по квалификации программистом по принципу «точка-точка» через выгрузку-загрузку файлов с нужными данными. Если же поставлена задача интеграции нескольких промышленных и заказных программных систем с большими объемами данных при синхронизации и десятками сложных бизнес-процессов, то здесь нужна команда высококвалифицированных специалистов.
Зная набор интегрируемых систем, наборы данных и бизнес-процессы для интеграции, примерные объемы данных и учитывая перспективы развития ИТ-систем компании, можно приступить к выбору реализации интеграционного проекта. В большинстве случаев, выбор делается между методами «точка-точка» и «интеграционная шина». Иногда применяется решение с выделенным интеграционным хранилищем данных, например БД с интеграционными таблицами. В этом случае каждая система интегрируются с этими таблицами, даже не подозревая о существовании других систем. Такое решение используется редко, в основном если компания сама развивает свои ИТ-системы и полностью может контролировать структуру интеграционных таблиц. Но с течением времени такое решение поддерживать всё сложнее и сложнее.
Не редко, даже при интеграции нескольких систем, метода «точка-точка» бывает достаточно. Для примера возьмём управляющую компанию. У неё есть три системы – система электронного документооборота (СЭД), финансовая система MS Dynamics AX и трейдерская система. Бизнес-процессы таковы, что документ, после согласования в СЭД, попадает в трейдерскую систему. Данные о торгах из трейдерской системы раз в сутки попадают в финансовую систему MS Dynamics AX. Новые договора вводятся в финансовую систему MS Dynamics AX и после этого согласуются в СЭД. Бизнес-процессы устоялись, системы и связи между ними стабильны, внедрение новых систем в будущем не планируется. В таких условиях внедрение «интеграционной шины» будет избыточным и не оправданным. И интеграция по типу «точка-точка» будет наилучшим решением.
Как правило, интеграционная логика в таких решениях реализуется или программным кодом в одной из систем (мастер-системе), или же на базе какого-либо готового инструмента (к примеру, с помощью компонента Integration Services СУБД SQL Server корпорации Microsoft).
Несколько примеров из нашей практики. Крупная международная логистическая компания. Нужно было интегрировать наше решение для документооборота DocHouse и внутреннюю систему заказчика для управления заказами. Объем ежедневной синхронизации – примерно 1000 записей. Очевидно, что здесь решение с использованием «интеграционной шины» будет избыточным. Поэтому мы выбрали интеграцию по типу «точка-точка». Были согласованы форматы синхронизируемых данных, написана пара хранимых процедур для MS SQL Server, изменена логика процесса документооборота в DocHouse. Объем работ – примерно две человеко-недели.
Другой пример. Крупная управляющая компания. Есть большая база данных Oracle, куда стекается информация из всех агентских пунктов компании. Внутри работа с клиентами компании ведется с помощью системы MS CRM. Задача – синхронизировать информацию по клиентам и продажам финансовых инструментов между этими системами. Первичный импорт информации – около миллиона записей. Последующая ежедневная синхронизация – примерно сотня тысяч записей. Здесь тоже мы выбрали интеграцию по принципу «точка-точка». Ведь нам нужно было всего лишь забрать данные из одной системы, конвертировать их, и положить в другую систему, ничего более. «Интеграционная шина» была бы здесь очень тяжеловесным и дорогим решением, не раскрывающим полностью её («интеграционной шины») потенциала. Разработка была выполнена с использованием компонента Integration Services СУБД MS SQL Server, хранимых процедур на T-SQL и программного кода на VB.NET. Согласование форматов данных, разработка бизнес-процесса, программирование и тестирование – всё было выполнено за три месяца командой из трех человек.
К сожалению, подход «точка-точка» работает до определенного предела, за которым трудозатраты превышают преимущества. Чем больше систем – тем больше связей между ними, сложнее логика синхронизации. Системы часто общаются по разным протоколам и разными форматами данных. Значит, интегрируемые системы должны знать о всех возможных комбинациях протокол/формат данных. Программный код интеграционного процесса «размазывается» по системам и его становится все сложнее и сложнее исправлять и развивать, что увеличивает затраты на поддержку.
Как понять, что компании нужно переходить от интеграции «точка-точка» к «интеграционной шине»? Точный ответ на этот вопрос зависит от очень многих параметров – ресурсов, как финансовых, так и человеческих, динамики развития ИТ-инфраструктуры, развитием самого бизнеса компании. В качестве отправной точки можно порекомендовать следующие признаки: большое количество ИТ-систем (больше 4х); часто изменяющиеся связи между ними, разные протоколы и форматы данных этих систем; бизнес-процессы, охватывающие несколько систем (больше 2х); большие объемы данных (больше тысячи записей в день по каждой из основных систем); требования к надежности и масштабируемости; необходимость в интеграции информации, то есть предоставление консолидированной отчетности по нескольким системам.
Практический пример. Банк, занимающийся ипотекой. Выданные кредиты учитываются и отслеживаются с помощью CRM системы. Банку необходимо было автоматизировать приём кредитных дел от информационных систем партнёров. Около двух десятков бизнес-процессов, сложные трансформации данных (XML различных содержательных нотаций), взаимодействие с несколькими внутренними системами (CRM, БД, внутренний портал) по различным протоколам (HTTP, Web-Services, SQL, файлы), надежность обработки данных – все эти требования предопределили использование интеграционного решения MS BizTalk Server. Такие возможности как большой набор адаптеров для различных протоколов, выделенные компоненты для трансформации данных позволяли нам быстро подключать к одному и тому же бизнес-процессу различные системы. Основная часть бизнес-процессов была разработана нами за пять месяцев.
Производители связующего ПО по разному трактуют термин «интеграционная шина». В контексте обсуждаемых методов интеграции, на мой взгляд, наиболее удачным будет такое определение: программный сервер, который «выполняет» бизнес-процессы, имеет адаптеры ко всем интегрируемым системам, умеет конвертировать данные, обладает масшабируемостью и надежностью при обработке сообщений, предоставляет инструменты для мониторинга как системных параметров процессов, так и бизнес-показателей интеграционных процессов. Последняя особенность шины является прямым следствием её работы «над» остальными системами. Обрабатывая и консолидируя данные других систем, шина позволяет в режиме реального времени строить отчеты в разрезе поставщиков, товаров, комплектов, то есть, бизнес-показателей интеграционных процессов. Эта возможность особенно ценна для бизнес-пользователей.
Выделенная интеграционная шина имеет несколько преимуществ перед интеграцией «точка-точка». Программный код бизнес-процессов выполняется одной системой, интеграционная шина «понимает» каждую систему и говорит на её языке (комбинации протокол/формат данных). При необходимости, шину можно масшатбировать для увеличения производительности, поддержка транзакционности бизнес-процессов у неё «из коробки». Наличие дополнительных инструментов по мониторингу бизнес-активности делает её привлекательной для бизнес-пользователей.
К сожалению, интеграционная шина имеет и недостатки, которые являются продолжением её преимуществ. Всё интеграционную логику шина содержит в себе. Остановка шины по какой-либо причине ведет к полному параличу всей ИТ-инфраструктуры предприятия. К счастью, это решается кластаризацей всех серверов интеграционной шины, эту возможность поддерживают все вендоры. Так же, для интеграционных проектов характерна большая сложность, и, как следствие, необходимость привлечения грамотного партнёра по внедрению.
Выбор же конкретной реализации интеграционной шины зависит от многих факторов: бюджета проекта, квалификации команды внедрения, систем и их интеграционных интерфейсов, объемов интеграции, перспектив развития ИТ-инфраструктуры компании, ориентации на того или иного вендора.
Как и в любом другом проекте внедрения информационной системы, качественное ТЗ, грамотная архитектура, тестирование решения в конечных системах бизнес-пользователями, разграничение ответственности между командами, сопровождающими системы компании – всё это необходимые условия успешного проекта по интеграции систем предприятия. Не стоит забывать и об итерационности подключения систем к общей шине. Так же важна и согласованность действий между бизнес-пользователями, ведь интеграционная шина связывает несколько приложений, которые эксплуатируются разными департаментами, разными пользователями. Встают вопросы о правах доступа к данным, обеспечение безопасности. Иногда некоторые пользователи по каким-либо причинам не хотят делиться информацией с другими системами.
Некоторые выводы
Таким образом, для успеха интеграционного проекта важны многие факторы: наличие интеграционных интерфейсов у интегрируемых систем, выбор метода интеграции, правильный выбор интеграционной шины, сильное руководство проекта, как техническое, так и на уровне менеджмента компании.
Успешный интеграционный проект может поднять обработку информации на новую высоту, стать важным конкурентным преимуществом. Провал же такого проекта может откатить ИТ-инфраструктуру компании на один шаг назад и отбить всякое желание менеджмента экспериментировать с интеграцией в будущем.
Enterprise application integration
EAI (Enterprise application integration) – интеграционная программная структура, объединяющий различного рода приложения, разработанные независимо друг от друга, так, чтобы они работали как одно целое, прозрачно для пользователя. Данные приложения способны использовать разные технологии и оставаться независимо управляемыми. EAI является технологией, при помощи которой организация достигает централизации и оптимизации интеграции корпоративных приложений, используя, как правило, подходящие формы технологии оперативной доставки информации (push technology), которая управляется внешними событиями (event-driven).
Содержание
Технология EAI становится наиболее функциональной тогда, когда необходимо объединить приложения в реальном времени для автоматизации бизнес-процессов. Также возможно применение EAI в том случае, когда необходимо, чтобы изменения, которые были занесены в одно приложение (обычно это небольшой набор записей), были отражены во всех других. Такая технология прекрасно справляется с задачей закрепления изменений и их переноса в соответствующие приложения или системы.
Назначение
На данном уровне задачей интеграции является объединение функции либо данных одного приложения с другим, с помощью которого обеспечивается интеграция, близкая к реальному времени. Интеграция приложений используется с целью интеграции B2B, введения CRM-систем, которые интегрированы с корпоративными серверными приложениями, web-интеграции и создания web-сайтов, которые поддерживают большую часть бизнес систем. Кроме этого, может возникнуть необходимость проведения особой интеграции, особенно, если требуется интегрировать существующее приложение с устанавливаемым вновь ERP-приложением.
Во время интеграции бизнес-процессов компания обязана определять, осуществлять и управлять процессами обмена корпоративной информацией между разного рода бизнес системами. В связи с этим организация может облегчить операции, уменьшить расходы и улучшить ответы на запросы клиентов. В состав элементов данного процесса входит управление процессами, моделирование процессов и технологический процесс, включающий в себя различные задачи, процедуры, архитектуры, требуемую входную и выходную информацию, а также средства, которые нужны для каждого этапа в бизнес-процессе.
Основные цели интеграции приложений могут быть определены следующим образом:
Такие формулировки как: «обеспечить формирование финансовой отчетности предприятия в срок не более одной недели после окончания финансового периода»; «сократить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, который принимает участие в поддержании в актуальном состоянии справочников и классификаторов с 20 до пяти человек» часто используются для обозначения целей конкретных интеграционных проектов. Тем не менее в итоге все сводится к общим задачам, которые можно сформулировать в еще более обобщенной форме — сократить операционные затраты предприятия или организации. В результате интеграционные замыслы часто оказываются в выгодном положении с позиции объяснения перед людьми, которые принимают решение о финансировании проектов: расчет показателей возврата инвестиций для этих проектов может выглядеть достаточно заманчивым. Обеспечение автоматизированного контроля прохождения базовых бизнес-процессов на предприятии, информационная безопасность при реализации бизнес-процессов достигается по средствам благополучной интеграция корпоративных систем.
Топология EAI
В организации маршрутов взаимодействия интегрируемых систем выделяется два подхода. Во-первых, это прямое согласование интегрированных систем по принципу «каждая с каждой», или «точка-точка». Во-вторых, это связь через центральный узел; данную подобную звезде архитектуру, как правило, называемую «хаб + спицы». Топология определяет логические пути взаимодействия и передачи данных между интегрированными системами и не зависит от физической архитектуры информационной системы.
Точка-точка
Хаб и спицы
Согласованность по принципу «точка-точка» создает в инфраструктуре предприятия чересчур много связей и ставит условием взаимодействие интерфейсов и форматов данных между согласующимися приложениями. Такие отрицательные моменты призвана разрешить архитектура взаимодействия, в которой все приложения непосредственно связаны только с центральным узлом, который решает следующие задачи:
изменение форматов файлов и данных;
Краткая оценка рынка EAI и его перспективы
Основываясь на том, что компании предлагают продукты, в которых реализуется только часть основных задач интеграции, и ни один поставщик пока не поставляет законченного решения можно объяснить нынешнюю неоднородность рынка EAI. Лидерами этого рынка считаются BEA Systems, NEON, CrossWorlds Software, Level 8 Systems, Mercator Software, SeeBeyond, Software AG, TIBCO, IONA Technologies, Vitria Technology и webMethods. Такие компании как PricewaterhouseCoopers, CSC и EDS занимаются интеграцией крупных систем Исходя из прогнозов аналитиков, в ближайшее время рынок услуг в области EAI станет наиболее перспективным и быстро растущей частью рынка IT. По утверждению консалтинговой компании IDC, ожидается стабильный рост поступлений от реализации программного обеспечения, которое предназначено для решения интеграционных задач.