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

Enterprise application integration

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

Обзор

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

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

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

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

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

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

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

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

Однако количество подключений внутри организаций не растет пропорционально квадрату количества очков. Как правило, количество подключений к любой точке не зависит от количества других точек в организации (Мысленный эксперимент: если в вашу организацию добавляется дополнительный балл, знаете ли вы об этом? Увеличивает ли это количество подключений к другим не связанным точкам?). Есть небольшое количество «точек сбора», к которым это неприменимо, но для управления ими не требуются шаблоны 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 используется несколько технологий:^{[нужна цитата]}

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

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

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

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

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

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

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

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

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

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

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

Navigation