Интеграция корпоративных приложений

Использование программного обеспечения для интеграции

Интеграция корпоративных приложений ( EAI ) — это использование принципов архитектуры программного обеспечения и компьютерных систем для интеграции набора корпоративных компьютерных приложений . ^[1]

Обзор

Интеграция корпоративных приложений — это интеграционная структура, состоящая из набора технологий и служб, которые формируют промежуточное программное обеспечение или «средовую структуру», обеспечивающую интеграцию систем и приложений на предприятии. ^[1]

Многие типы бизнес-программного обеспечения, такие как приложения для управления цепочками поставок , системы ERP , приложения CRM для управления клиентами, приложения для бизнес-аналитики , системы расчета заработной платы и кадровых ресурсов, как правило, не могут взаимодействовать друг с другом для обмена данными или бизнес-правилами. По этой причине такие приложения иногда называют островами автоматизации или информационными хранилищами . Такое отсутствие коммуникации приводит к неэффективности, когда идентичные данные хранятся в нескольких местах, или простые процессы не могут быть автоматизированы. ^{[ необходима цитата ]}

Интеграция корпоративных приложений — это процесс связывания таких приложений в рамках одной организации с целью максимально упростить и автоматизировать бизнес-процессы, избегая при этом необходимости вносить радикальные изменения в существующие приложения или структуры данных. Приложения могут быть связаны либо на бэкэнде через API , либо (редко) на фронтэнде ( GUI ). ^{[ необходима цитата ]}

По словам исследовательской компании Gartner : «[EAI] — это неограниченный обмен данными и бизнес-процессами между любыми подключенными приложениями или источниками данных на предприятии». ^[2]

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

Улучшение связи

Если интеграция применяется без следования структурированному подходу EAI, соединения точка-точка растут по всей организации. Зависимости добавляются на импровизированной основе, что приводит к сложной структуре, которую трудно поддерживать. Это обычно называют спагетти, намек на программный эквивалент спагетти-кода .

Например, количество соединений, необходимых для полностью сетчатых соединений точка-точка с n точками, определяется как (см. биномиальный коэффициент ). Таким образом, для полной интеграции десяти приложений точка-точка необходимы соединения точка-точка, следующие квадратичной модели роста . ${\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}}$ ${\displaystyle {\tfrac {10\times 9}{2}}=45}$

Однако количество соединений внутри организаций не обязательно растет пропорционально квадрату количества точек. В общем, количество соединений с любой точкой ограничено только количеством других точек в организации, но может быть существенно меньше в принципе. EAI также может увеличить связанность между системами и, следовательно, увеличить накладные расходы и затраты на управление. ^{[ необходима цитата ]}

EAI не просто занимается обменом данными между приложениями, но также фокусируется на обмене как бизнес-данными, так и бизнес-процессами. Аналитик промежуточного ПО, работающий с EAI, часто смотрит на систему систем . ^{[ необходима цитата ]}

Цели

EAI можно использовать для разных целей: ^{[ необходима ссылка ]}

• Интеграция данных : обеспечивает согласованность информации в нескольких системах. Это также известно как интеграция корпоративной информации (EII).
• Независимость от поставщика: извлекает бизнес-политики или правила из приложений и внедряет их в систему EAI, так что даже если одно из бизнес-приложений заменяется приложением другого поставщика, бизнес-правила не придется внедрять повторно.
• Общий фасад: система EAI может выступать в качестве интерфейса для кластера приложений, предоставляя единый согласованный интерфейс доступа к этим приложениям и избавляя пользователей от необходимости изучать различные программные пакеты.

Узоры

В этом разделе описываются общие шаблоны проектирования для внедрения EAI, включая шаблоны интеграции, доступа и жизненного цикла. Это абстрактные шаблоны, которые могут быть реализованы многими различными способами. Существует много других шаблонов, обычно используемых в отрасли, от высокоуровневых абстрактных шаблонов проектирования до весьма специфических шаблонов внедрения. ^[3]

Модели интеграции

Системы EAI реализуют две модели: ^[4]

Медиация (внутрикорпоративная коммуникация)

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

Федерация (межсетевое взаимодействие)

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

Оба шаблона часто используются одновременно. Одна и та же система EAI может поддерживать синхронизацию нескольких приложений (медиация), одновременно обслуживая запросы от внешних пользователей к этим приложениям (федерация). ^{[ необходима цитата ]}

Модели доступа

EAI поддерживает как асинхронные (запустил и забыл), так и синхронные шаблоны доступа, первый типичен для случая посредничества, а второй — для случая федерации. ^{[ необходима ссылка ]}

Модели жизни

Операция интеграции может быть кратковременной (например, синхронизация данных между двумя приложениями может быть завершена в течение секунды) или длительной (например, один из шагов может включать взаимодействие системы EAI с приложением человеческого рабочего процесса для одобрения кредита, на что уходят часы или дни). ^{[ необходима цитата ]}

Топологии

Существует две основные топологии: hub-and-spoke и bus . Каждая из них имеет свои преимущества и недостатки. В модели hub-and-spoke система EAI находится в центре (концентраторе) и взаимодействует с приложениями через спицы. В модели bus система EAI является шиной (или реализована как резидентный модуль в уже существующей шине сообщений или промежуточном программном обеспечении, ориентированном на сообщения ). ^{[ необходима цитата ]}

Большинство крупных предприятий используют зонированные сети для создания многоуровневой защиты от сетевых угроз. Например, предприятие обычно имеет зону обработки кредитных карт (совместимую с PCI), зону, не соответствующую PCI, зону данных, зону DMZ для проксирования доступа внешних пользователей и зону IWZ для проксирования доступа внутренних пользователей. Приложения должны интегрироваться в нескольких зонах. Модель Hub and Spread будет работать лучше в этом случае. ^{[ необходима цитата ]}

Технологии

При реализации каждого из компонентов системы EAI используется несколько технологий: ^{[ необходима ссылка ]}

Автобус/хаб

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

Возможность подключения приложений

Шина/концентратор подключается к приложениям через набор адаптеров (также называемых соединителями ). Это программы, которые знают, как взаимодействовать с базовым бизнес-приложением. Адаптер выполняет одностороннюю связь (однонаправленную), выполняя запросы от концентратора к приложению и уведомляя концентратор, когда в приложении происходит событие, представляющее интерес (вставлена ​​новая запись, завершена транзакция и т. д.). Адаптеры могут быть специфичными для приложения (например, построенными на основе клиентских библиотек поставщика приложения) или специфичными для класса приложений (например, могут взаимодействовать с любым приложением через стандартный протокол связи, такой как SOAP , SMTP или Action Message Format (AMF)). Адаптер может находиться в том же пространстве процессов, что и шина/концентратор, или выполняться в удаленном месте и взаимодействовать с концентратором/шиной через стандартные отраслевые протоколы, такие как очереди сообщений, веб-службы, или даже использовать собственный протокол. В мире Java такие стандарты, как JCA, позволяют создавать адаптеры в нейтральной по отношению к поставщику манере.

Формат данных и преобразование

Чтобы избежать необходимости каждого адаптера преобразовывать данные в форматы всех других приложений или из них, системы EAI обычно предусматривают независимый от приложения (или общий) формат данных. Система EAI обычно также предоставляет услугу преобразования данных, чтобы помочь преобразовать между форматами, специфичными для приложения, и общими форматами. Это делается в два этапа: адаптер преобразует информацию из формата приложения в общий формат шины. Затем к этому применяются семантические преобразования (преобразование почтовых индексов в названия городов, разделение/объединение объектов из одного приложения в объекты в других приложениях и т. д.).

Интеграционные модули

Система EAI может участвовать в нескольких параллельных операциях интеграции в любой момент времени, причем каждый тип интеграции обрабатывается отдельным модулем интеграции. Модули интеграции подписываются на события определенных типов и обрабатывают уведомления, которые они получают при возникновении этих событий. Эти модули могут быть реализованы разными способами: в системах EAI на основе Java это могут быть веб-приложения или EJB или даже POJO , которые соответствуют спецификациям системы EAI.

Поддержка транзакций

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

Архитектуры коммуникаций

В настоящее время существует множество мнений о том, что составляет лучшую инфраструктуру, модель компонентов и структуру стандартов для интеграции корпоративных приложений. Кажется, существует консенсус, что четыре компонента являются существенными для современной архитектуры интеграции корпоративных приложений: ^{[ необходима цитата ]}

1. Централизованный брокер, который управляет безопасностью, доступом и коммуникацией. Это может быть достигнуто посредством серверов интеграции (например, School Interoperability Framework (SIF) Zone Integration Servers) или посредством аналогичного программного обеспечения, например, модели корпоративной сервисной шины (ESB), которая действует как менеджер служб.
2. Независимая модель данных, основанная на стандартной структуре данных, также известная как каноническая модель данных . Похоже, что XML и использование таблиц стилей XML стали фактическим , а в некоторых случаях и юридическим стандартом для этого единого делового языка.
3. Модель коннектора или агента, в которой каждый поставщик, приложение или интерфейс может создать единый компонент, который может взаимодействовать с этим приложением на собственном языке и взаимодействовать с централизованным брокером.
4. Системная модель, которая определяет API, поток данных и правила взаимодействия с системой таким образом, чтобы можно было создавать компоненты для взаимодействия с ней стандартизированным образом.

Хотя были изучены другие подходы, такие как подключение на уровне базы данных или пользовательского интерфейса, они не были признаны масштабируемыми или способными к настройке. Отдельные приложения могут публиковать сообщения в централизованном брокере и подписываться на получение определенных сообщений от этого брокера. Каждому приложению требуется только одно подключение к брокеру. Этот подход к центральному управлению может быть чрезвычайно масштабируемым и высоко развиваемым . ^{[ необходима цитата ]}

Интеграция корпоративных приложений связана с технологиями промежуточного программного обеспечения, такими как ориентированное на сообщения промежуточное программное обеспечение ( MOM ), и технологиями представления данных, такими как XML или JSON . Другие технологии EAI включают использование веб-сервисов как части сервисно-ориентированной архитектуры в качестве средства интеграции. Интеграция корпоративных приложений, как правило, ориентирована на данные. В ближайшем будущем она будет включать интеграцию контента и бизнес-процессы . ^{[ требуется цитата ]}

Подводные камни реализации

В 2003 году сообщалось, что 70% всех проектов EAI терпят неудачу. Большинство этих неудач происходят не из-за самого программного обеспечения или технических трудностей, а из-за проблем управления. Председатель Integration Consortium European Стив Крэггс выделил семь основных ловушек, с которыми сталкиваются компании, использующие системы EAI, и объясняет решения этих проблем. ^[5]

1. Постоянные изменения: сама природа EAI динамична и требует динамичных менеджеров проектов для управления их реализацией.
2. Нехватка экспертов в области EAI : EAI требует знания многих вопросов и технических аспектов.
3. Конкурирующие стандарты: В сфере EAI парадокс заключается в том, что сами стандарты EAI не являются универсальными.
4. EAI — это парадигма инструмента: EAI — это не инструмент, а система, и ее следует внедрять как таковую.
5. Создание интерфейсов — это искусство: недостаточно просто спроектировать решение. Решения необходимо согласовывать с пользовательскими отделами, чтобы достичь общего консенсуса по конечному результату. Отсутствие консенсуса по дизайну интерфейсов приводит к чрезмерным усилиям по сопоставлению требований к данным различных систем.
6. Потеря деталей: информация, которая казалась неважной на более раннем этапе, может стать решающей позже.
7. Подотчетность: Поскольку у стольких отделов имеется множество противоречивых требований, должна быть четкая подотчетность за окончательную структуру системы.

Другие потенциальные проблемы могут возникнуть в следующих областях: ^{[ необходима ссылка ]}

• Отсутствие централизованной координации работы EAI. ^[6]
• Новые требования: Реализации EAI должны быть расширяемыми и модульными, чтобы допускать будущие изменения.
• Протекционизм: приложения, данные которых интегрируются, часто принадлежат разным департаментам, у которых есть технические, культурные и политические причины не желать делиться своими данными с другими департаментами.

Смотрите также

• Структура архитектуры предприятия
• Стратегии интеграции корпоративных приложений
• Управление бизнес-семантикой
• Интеграция данных
• Интеграция корпоративной информации
• Интеграция предприятия
• Модели интеграции предприятия
• Автобус корпоративного обслуживания
• Обобщенная корпоративная эталонная архитектура и методология
• Интеграционное устройство
• Центр компетенции по интеграции
• Интеграционная платформа
• Системная интеграция

Инициативы и организации

• Уровень здоровья 7
• Инициатива открытых знаний
• OSS через Java
• Структура взаимодействия школ (SIF)

Ссылки

1. Linthicum, Дэвид С. (2000). Интеграция корпоративных приложений. Addison-Wesley Professional. ISBN 978-0-201-61583-8.
2. В своем отчете для AIIM International за апрель 2001 г. «Корпоративные приложения: внедрение технологий электронного бизнеса и документооборота, 2000–2001 гг.: всемирное отраслевое исследование» Gartner определяет EAI как «неограниченный обмен данными и бизнес-процессами между любыми подключенными приложениями и источниками данных на предприятии». Gable, Julie (март–апрель 2002 г.). «Интеграция корпоративных приложений» (PDF) . Information Management Journal . Получено 22.01.2008 .
   
3. Хохпе, Грегор; Вульф, Бобби (2015). «Обзор шаблонов обмена сообщениями». Enterpriseintergationpatterns.com и Addison-Wesley . Получено 19 мая 2016 г.
4. MSquare Systems (2014-05-21). "Типы EAI". Архивировано 2014-05-21 на https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai. MSquare Systems Получено 2014-05-28 с http://www.msquaresystems.com/enterprise-application-2/eai.
5. Тротта, Джан (15.12.2003). "Танцы вокруг 'медвежьих капканов' EAI" . Получено 27.06.2006 .
6. Тойванен, Антти (2013-10-25). «Избегание ловушек интеграционных центров компетенций». Архивировано из оригинала 2017-07-30 . Получено 2013-10-26 .