Из Википедии, свободной энциклопедии
Перейти к навигацииПерейти к поиску

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

Обзор

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

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

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

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

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

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

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

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

Однако количество подключений внутри организаций не увеличивается пропорционально квадрату количества баллов. В общем, количество подключений к любой точке не зависит от количества других точек в организации ( мысленный эксперимент : если к вашей организации добавляется дополнительная точка, знаете ли вы об этом? очков есть?). Есть небольшое количество «точек сбора», к которым это неприменимо, но для управления ими не требуются шаблоны EAI.

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 или Action Message Format.(AMF)). Адаптер может находиться в том же пространстве процессов, что и шина / концентратор, или выполняться в удаленном месте и взаимодействовать с концентратором / шиной через стандартные отраслевые протоколы, такие как очереди сообщений, веб-службы, или даже использовать собственный протокол. В мире Java стандарты, такие как JCA, позволяют создавать адаптеры независимо от производителя.
Формат данных и преобразование
Чтобы каждому адаптеру не приходилось преобразовывать данные в / из форматов любых других приложений, системы EAI обычно предусматривают независимый от приложения (или общий) формат данных. Система EAI обычно предоставляет услугу преобразования данных, чтобы помочь преобразовать форматы, специфичные для приложения, и общие. Это выполняется в два этапа: адаптер преобразует информацию из формата приложения в общий формат шины. Затем к нему применяются семантические преобразования (преобразование почтовых индексов в названия городов, разделение / объединение объектов из одного приложения в объекты в других приложениях и т. Д.).
Модули интеграции
Система EAI может участвовать в нескольких параллельных операциях интеграции в любой момент времени, причем каждый тип интеграции обрабатывается отдельным модулем интеграции. Модули интеграции подписываются на события определенных типов и обрабатывают уведомления, которые они получают, когда эти события происходят. Эти модули могут быть реализованы по - разному: на Java систем на основе EAI, это может быть веб - приложение или EJBs или даже POJOs , которые соответствуют спецификации системы EAI в.
Сопровождение сделок
При использовании для интеграции процессов система EAI также обеспечивает согласованность транзакций между приложениями, выполняя все операции интеграции во всех приложениях в рамках одной всеобъемлющей распределенной транзакции (с использованием протоколов двухфазной фиксации или компенсационных транзакций ).

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

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

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

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

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

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

В 2003 году сообщалось, что 70% всех проектов EAI терпят неудачу. Большинство этих сбоев происходит не из-за самого программного обеспечения или технических трудностей, а из-за проблем с управлением. Европейский председатель интеграционного консорциума Стив Крэггс обрисовал семь основных ловушек, предпринимаемых компаниями, использующими системы 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). Интеграция корпоративных приложений . Эддисон-Уэсли Профессионал. ISBN 978-0-201-61583-8.
  2. ^ В своем отчете для AIIM International от апреля 2001 г. «Корпоративные приложения: внедрение технологий электронного бизнеса и документирования, 2000–2001 гг .: всемирное отраслевое исследование» Gartner определяет EAI как «неограниченный обмен данными и бизнес-процессами между любыми подключенными приложениями и источники данных на предприятии ". Гейбл, Джули (март – апрель 2002 г.). «Интеграция корпоративных приложений» (PDF) . Журнал управления информацией . Проверено 22 января 2008 .
  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. ^ Тротта, Джан (2003-12-15). «Танцы вокруг EAI« Медвежьи ловушки » » . Проверено 27 июня 2006 .
  6. ^ Тойванен, Антти (2013-10-25). «Как избежать ловушек интеграционных центров компетенций» . Архивировано из оригинала на 2017-07-30 . Проверено 26 октября 2013 .