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

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

Обзор

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

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

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

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

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

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

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

Например, количество соединений, необходимое для создания полностью связанных двухточечных соединений с $n$ точками, определяется выражением ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ (см. биномиальный коэффициент ). Таким образом, чтобы десять приложений были полностью интегрированы в режиме «точка-точка», ${\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 с приложением рабочего процесса, выполняемым человеком, для утверждения. кредита, на погашение которого уходят часы или дни). ^{[ нужна ссылка ]}

Топологии

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

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

Технологии

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

Автобус/пересадочный узел: Обычно это реализуется путем расширения стандартных продуктов промежуточного программного обеспечения ( сервер приложений , шина сообщений) или реализуется как отдельная программа (т. е. не использует никакого промежуточного программного обеспечения), действующая как собственное промежуточное программное обеспечение.
Возможность подключения приложений: Шина/концентратор подключается к приложениям через набор адаптеров (также называемых разъемами ). Это программы, которые знают, как взаимодействовать с базовым бизнес-приложением. Адаптер осуществляет одностороннюю связь (однонаправленную), выполняя запросы от хаба к приложению и уведомляя хаб, когда в приложении происходит интересующее событие (вставлена новая запись, завершена транзакция и т. д.). Адаптеры могут быть специфичными для приложения (например, построенными на основе клиентских библиотек поставщика приложения) или специфичными для класса приложений (например, могут взаимодействовать с любым приложением через стандартный протокол связи, такой как SOAP , SMTP или формат сообщения действия (AMF). )). Адаптер может находиться в том же технологическом пространстве, что и шина/концентратор, или выполняться в удаленном месте и взаимодействовать с концентратором/шиной через стандартные протоколы, такие как очереди сообщений, веб-службы, или даже использовать собственный протокол. В мире Java такие стандарты, как JCA, позволяют создавать адаптеры независимо от поставщика.
Формат данных и преобразование: Чтобы избежать необходимости конвертировать данные в форматы любого другого приложения каждому адаптеру или из него, системы EAI обычно предусматривают независимый от приложения (или общий) формат данных. Система EAI обычно также предоставляет услугу преобразования данных, помогающую конвертировать форматы, специфичные для конкретного приложения, в распространенные форматы. Это делается в два этапа: адаптер преобразует информацию из формата приложения в общий формат шины. Затем к этому применяются семантические преобразования (преобразование почтовых индексов в названия городов, разбиение/объединение объектов из одного приложения в объекты в других приложениях и так далее).
Модули интеграции: Система EAI может участвовать в нескольких одновременных операциях интеграции в любой момент времени, причем каждый тип интеграции обрабатывается отдельным модулем интеграции. Модули интеграции подписываются на события определенных типов и обрабатывают уведомления, которые они получают при возникновении этих событий. Эти модули могут быть реализованы по-разному: в Java системах EAI на основе это могут быть веб-приложения , EJB или даже POJO , соответствующие спецификациям системы EAI.
Поддержка транзакций: При использовании для интеграции процессов система EAI также обеспечивает согласованность транзакций между приложениями, выполняя все операции интеграции во всех приложениях в одной всеобъемлющей распределенной транзакции (с использованием протоколов двухфазной фиксации или компенсирующих транзакций ).

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

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

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

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

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

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

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

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

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

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

См. также

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

Ссылки

^ Перейти обратно: ^а ^б Линтикум, Дэвид С. (2000). Интеграция корпоративных приложений . Аддисон-Уэсли Профессионал. ISBN 978-0-201-61583-8 .
^ В своем отчете для AIIM International за апрель 2001 г. «Корпоративные приложения: внедрение электронного бизнеса и технологий обработки документов, 2000–2001: всемирное отраслевое исследование» Gartner определяет EAI как «неограниченное совместное использование данных и бизнес-процессов между любыми подключенными приложениями и источники данных на предприятии».
Гейбл, Джули (март – апрель 2002 г.). «Интеграция корпоративных приложений» (PDF) . Журнал информационного менеджмента . Проверено 22 января 2008 г.
^ Хохпе, Грегор; Вульф, Бобби (2015). «Обзор шаблонов обмена сообщениями» . Enterpriseintergationpatterns.com и Addison-Wesley . Проверено 19 мая 2016 г.
^ MSquare Systems (21 мая 2014 г.). «Виды ЭАИ». Архивировано 21 мая 2014 г. по адресу https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai . MSquare Systems Получено 28 мая 2014 г. с http://www.msquaresystems.com/enterprise-application-2/eai .
^ Тротта, Джиан (15 декабря 2003 г.). «Танцы вокруг «медвежьих капканов» ЭАИ » . Проверено 27 июня 2006 г.
^ Тойванен, Антти (25 октября 2013 г.). «Как избежать ловушек интеграционных центров компетенции» . Архивировано из оригинала 30 июля 2017 г. Проверено 26 октября 2013 г.

[Enterprise_Application_Integration-1] Перейти обратно: ^а ^б Линтикум, Дэвид С. (2000). Интеграция корпоративных приложений . Аддисон-Уэсли Профессионал. ISBN 978-0-201-61583-8 .

[2] В своем отчете для AIIM International за апрель 2001 г. «Корпоративные приложения: внедрение электронного бизнеса и технологий обработки документов, 2000–2001: всемирное отраслевое исследование» Gartner определяет EAI как «неограниченное совместное использование данных и бизнес-процессов между любыми подключенными приложениями и источники данных на предприятии».
Гейбл, Джули (март – апрель 2002 г.). «Интеграция корпоративных приложений» (PDF) . Журнал информационного менеджмента . Проверено 22 января 2008 г.

[Enterprise_Integration_Patterns-3] Хохпе, Грегор; Вульф, Бобби (2015). «Обзор шаблонов обмена сообщениями» . Enterpriseintergationpatterns.com и Addison-Wesley . Проверено 19 мая 2016 г.

[4] MSquare Systems (21 мая 2014 г.). «Виды ЭАИ». Архивировано 21 мая 2014 г. по адресу https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai . MSquare Systems Получено 28 мая 2014 г. с http://www.msquaresystems.com/enterprise-application-2/eai .

[5] Тротта, Джиан (15 декабря 2003 г.). «Танцы вокруг «медвежьих капканов» ЭАИ » . Проверено 27 июня 2006 г.

[6] Тойванен, Антти (25 октября 2013 г.). «Как избежать ловушек интеграционных центров компетенции» . Архивировано из оригинала 30 июля 2017 г. Проверено 26 октября 2013 г.

[1]

[2]

[3]

[4]

[5]

[6]