интеграция на уровне корпоративных приложений eai enterprise application integration подразумевает
СОДЕРЖАНИЕ
Обзор
Улучшение связи
Однако количество подключений внутри организаций не растет пропорционально квадрату количества очков. В общем, количество подключений к любой точке не зависит от количества других точек в организации ( мысленный эксперимент : если в вашу организацию добавляется дополнительная точка, знаете ли вы об этом? очков есть?). Есть небольшое количество «точек сбора», к которым это неприменимо, но для управления ими не требуются шаблоны EAI.
EAI может также увеличить связь между системами и, следовательно, увеличить накладные расходы и затраты на управление.
EAI можно использовать для разных целей:
Узоры
В этом разделе описаны общие шаблоны проектирования для реализации EAI, включая шаблоны интеграции, доступа и времени жизни. Это абстрактные шаблоны, которые можно реализовать разными способами. Существует множество других шаблонов, обычно используемых в отрасли, от абстрактных шаблонов проектирования высокого уровня до узкоспециализированных шаблонов реализации.
Шаблоны интеграции
Системы EAI реализуют два шаблона:
Посредничество (внутрикорпоративное общение) Здесь система EAI действует как посредник или посредник между несколькими приложениями. Каждый раз, когда в приложении происходит интересное событие (например, создается новая информация или завершается новая транзакция), модуль интеграции в системе EAI получает уведомление. Затем модуль распространяет изменения в другие соответствующие приложения. Федерация (межсетевое взаимодействие) В этом случае система EAI действует как всеобъемлющий фасад для нескольких приложений. Все вызовы событий из «внешнего мира» в любое из приложений передаются системой EAI. Система EAI настроена так, чтобы предоставлять внешнему миру только релевантную информацию и интерфейсы базовых приложений, и выполняет все взаимодействия с базовыми приложениями от имени запрашивающей стороны.
Оба шаблона часто используются одновременно. Одна и та же система EAI может поддерживать синхронизацию нескольких приложений (посредничество), одновременно обслуживая запросы от внешних пользователей к этим приложениям (федерация).
Шаблоны доступа
Образцы жизни
Операция интеграции может быть кратковременной (например, синхронизация данных между двумя приложениями может быть завершена в течение секунды) или долгоживущей (например, один из этапов может включать взаимодействие системы EAI с приложением рабочего процесса, выполняемым человеком, для утверждения. кредита, на выполнение которого уходит часы или дни).
Топологии
Технологии
При реализации каждого из компонентов системы EAI используется несколько технологий:
Коммуникационные архитектуры
В настоящее время существует множество вариантов взглядов на то, что составляет лучшую инфраструктуру, компонентную модель и структуру стандартов для интеграции корпоративных приложений. Похоже, существует консенсус в отношении того, что для современной архитектуры интеграции корпоративных приложений необходимы четыре компонента:
Подводные камни реализации
В 2003 году сообщалось, что 70% всех проектов EAI терпят неудачу. Большинство этих сбоев происходит не из-за самого программного обеспечения или технических трудностей, а из-за проблем с управлением. Европейский председатель интеграционного консорциума Стив Крэггс обрисовал семь основных ловушек, с которыми сталкиваются компании, использующие системы EAI, и объяснил решения этих проблем.
В этих областях могут возникнуть другие потенциальные проблемы:
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, ожидается стабильный рост поступлений от реализации программного обеспечения, которое предназначено для решения интеграционных задач.
Журнал ВРМ World
К счастью, сейчас есть три технологии, которые могут помочь в этом. Автор статьи именует их «три ‘И'» (или три «Е» в английском варианте). Это интеграция корпоративных приложений (enterprise application integration, сокр. EAI), интеграция корпоративной информации (enterprise information integration, сокр. EII) и программное обеспечение для извлечения, преобразования и загрузки данных (extract, transform and load, сокр. ETL).
Рис.1. Интеграционный ландшафт сегодня
Далее необходимо рассмотреть место этих технологий в уже существующей архитектуре. На рис. 2 показано, как каждая из них может быть использована наилучшим образом. Технология EAI интегрирует транзакции двух или более приложений, технология ETL интегрирует данные операционных систем и компонентов поддержки принятия решений, а технология EII осуществляет виртуальную интеграцию данных из различных источников.
Рис. 2. Место технологий EAI, EII и ETL в уже существующей архитектуре
Технология ETL оказывается наиболее полезной в тех случаях, когда необходимо создать Хранилище данных, содержащее хорошо документированные и надежные данные для исторического анализа, например, для анализа временных рядов или многомерных запросов. Эта технология также используется для интеграции ключевых справочных данных. Технология ETL незаменима для таких задач, как удаление дублирующихся данных, осуществление процессов проверки качества данных и т.п. Эти инструменты также используются для создания отдельных витрин данных, обслуживающих конкретный отдел или бизнес-процесс или предназначенных для каких-либо долгосрочных целей. Инструменты ETL дают пользователю возможность запустить повторяющиеся процессы для большей слаженности действий и возможности их многократного использования. Такие процессы включают создание точных технических метаданных, поддерживающих общую целостность среды business intelligence (BI).
Кроме понимания того, когда необходимо использовать эти технологии, нужно также знать и проблемы, которые им присущи. Во-первых, внедрение этих технологий требует от IT-персонала глубокого понимания тех требований, которые предъявляются к данным для принятия как тактических, так и стратегических решений. Применительно к технологии ETL это означает, что необходимые данные извлекаются, преобразуются и загружаются в виде, пригодном для использования непосредственно аналитиками или EII-сервером. В случае EII-технологии, способы представления данных должны удовлетворять отчетным требованиям аналитиков, т.е. данные должны быть пригодны для использования в аналитических отчетах. Во всех случаях понимание источников данных и требований, предъявляемых к данным, является необходимым шагом при внедрении этих технологий и безусловно оправдывает то время, которое приходится тратить, чтобы достичь этого понимания.
Кроме того, необходимо понимать, что внедрение этих инструментов в уже сложившуюся архитектуру требует от бизнес- и IT-персонала разработки такой стратегии управления данными и приложениями, которая будет постоянно поддерживать этот процесс в активном состоянии. Обязательной составляющей такой стратегии должно быть осознание того, что повышается важность механизмов архивирования, а также того, что с самого начала должны быть созданы контрольные журналы. Это необходимо для обеспечения слаженности и надежности интегрированных данных и приложений.
И наконец, очень важен постоянный мониторинг производительности и эффективности этих технологий в условиях конкретной инфраструктуры. Их производительность в значительной степени будет зависеть от скорости архивирования данных, размеров и детальности данных, а также от эффективности функционирования системы в условиях полной нагрузки. При определении производительности также следует оценить влияние, которые эти инструменты могут оказывать на операционные приложения и системы. Поэтому необходим постоянный мониторинг и этого влияния.
СОДЕРЖАНИЕ
Обзор
Улучшение связи
Однако количество подключений внутри организаций не растет пропорционально квадрату количества очков. В общем, количество подключений к любой точке не зависит от количества других точек в организации ( мысленный эксперимент : если в вашу организацию добавляется дополнительная точка, знаете ли вы об этом? очков есть?). Есть небольшое количество «точек сбора», к которым это неприменимо, но для управления ими не требуются шаблоны EAI.
EAI может также увеличить связь между системами и, следовательно, увеличить накладные расходы и затраты на управление.
EAI можно использовать для разных целей:
Узоры
В этом разделе описаны общие шаблоны проектирования для реализации EAI, включая шаблоны интеграции, доступа и времени жизни. Это абстрактные шаблоны, которые можно реализовать разными способами. Существует множество других шаблонов, обычно используемых в отрасли, от абстрактных шаблонов проектирования высокого уровня до узкоспециализированных шаблонов реализации.
Шаблоны интеграции
Системы EAI реализуют два шаблона:
Посредничество (внутрикорпоративное общение) Здесь система EAI действует как посредник или посредник между несколькими приложениями. Каждый раз, когда в приложении происходит интересное событие (например, создается новая информация или завершается новая транзакция), модуль интеграции в системе EAI получает уведомление. Затем модуль распространяет изменения в другие соответствующие приложения. Федерация (межсетевое взаимодействие) В этом случае система EAI действует как всеобъемлющий фасад для нескольких приложений. Все вызовы событий из «внешнего мира» в любое из приложений передаются системой EAI. Система EAI настроена так, чтобы предоставлять внешнему миру только релевантную информацию и интерфейсы базовых приложений, и выполняет все взаимодействия с базовыми приложениями от имени запрашивающей стороны.
Оба шаблона часто используются одновременно. Одна и та же система EAI может поддерживать синхронизацию нескольких приложений (посредничество), одновременно обслуживая запросы от внешних пользователей к этим приложениям (федерация).
Шаблоны доступа
Образцы жизни
Операция интеграции может быть кратковременной (например, синхронизация данных между двумя приложениями может быть завершена в течение секунды) или долгоживущей (например, один из этапов может включать взаимодействие системы EAI с приложением рабочего процесса, выполняемым человеком, для утверждения. кредита, на выполнение которого уходит часы или дни).
Топологии
Технологии
При реализации каждого из компонентов системы EAI используется несколько технологий:
Коммуникационные архитектуры
В настоящее время существует множество вариантов взглядов на то, что составляет лучшую инфраструктуру, компонентную модель и структуру стандартов для интеграции корпоративных приложений. Похоже, существует консенсус в отношении того, что для современной архитектуры интеграции корпоративных приложений необходимы четыре компонента:
Подводные камни реализации
В 2003 году сообщалось, что 70% всех проектов EAI терпят неудачу. Большинство этих сбоев происходит не из-за самого программного обеспечения или технических трудностей, а из-за проблем с управлением. Европейский председатель интеграционного консорциума Стив Крэггс обрисовал семь основных ловушек, с которыми сталкиваются компании, использующие системы EAI, и объяснил решения этих проблем.
В этих областях могут возникнуть другие потенциальные проблемы:
Устраняют несовместимость информационных, управленческих и транзакционных систем, используемых контрагентами в цепочке поставок, а это одна из главных проблем, осложняющих внедрение и последующую эксплуатацию SCM-решений.
Интеграция приложений: история подходов
Проблема интеграции разнообразных приложений восходит к самым истокам ИТ, возможно, она возникла в тот момент, когда в каком-то вычислительном центре впервые было установлено второе приложение.
В общем, под интеграцией приложений понимается процесс налаживания взаимосвязей между независимыми технологическими островками, существующими внутри организации. Поскольку изначально не предполагалось, что приложения должны будут работать друг с другом, это не так-то просто. Поиск решения этой проблемы продолжается уже давно.
Первоначально идея интеграции развивалась по двум направлениям.
1. Частная интеграция. Это традиционный и наиболее распространенный в прошлом подход к интеграции систем, заключающийся в создании специализированных интерфейсов к приложениям для каждой отдельной ситуации. Проблема в том, что в результате частной интеграции возникает путаница из связующих звеньев интеграции приложений, что, в конечном счете, заводит ее в тупик.
Допустим, сотрудникам вашей торговой организации нужен доступ к клиентской базе данных и к документации на продукцию. Довольно скоро вы понимаете, что если интегрировать эти две услуги с помощью технологии help desk, то вы получите базу для новой специализированной услуги. Так и происходит. Однако по мере того, как интегрируются все новые и новые системы, количество необходимых частных интерфейсов увеличивается пропорционально квадрату числа использующихся приложений. С увеличением числа новых интерфейсов осуществление интеграции для создания новых приложений становится все сложнее. Частная интеграция требует больших объемов программирования, отнимает много времени, приводит к огромным структурным сложностям, а проведение изменений отнимает много сил и средств. Фактически частная интеграция приводит к созданию еще одной независимой информационной системы и увеличивает стоимость внедрения каждого нового приложения.
Проблема интеграции усугубляется тем, что многие традиционные критичные приложения слишком хрупки, чтобы их модифицировать.
2. Интеграция на уровне пользовательских интерфейсов. Идея достаточно оригинальна: приложения могут взаимодействовать так же, как их используют люди, а именно через пользовательский интерфейс. Это что-то типа входа через парадную дверь, вместо того, чтобы лезть через окно, как это делают традиционные EAI-средства. Простейшая форма такой интеграции под названием screen scraping уже более десяти лет используется для расширения возможностей мэйнфрейм-приложений. Расшифровывая символьные дисплеи, связанные со многими старыми приложениями, инструменты «соскабливания экрана» предлагают быстрый и порой весьма надежный интерфейс для доступа к системам, которые в противном случае были бы полностью закрытыми.
Это быстрая интеграция, однако такой подход предлагает доступ к интегрированным системам «только для чтения». Кроме того, этот подход сильно ограничен, так как для остальных (не веб) приложений имитация пользователя в качестве парадигмы интеграции представляется более сложным делом. Для этого требуются программы, способные воспринимать вызовы GUI, соотнося их с объектами приложений и представляя в качестве программируемых средств управления в режиме близком к режиму реального времени.
Тем не менее исследования в данной области не прекращаются. Так, молодая компания Anysoft провела серьезные исследования и разработки в этом направлении. Ее решение позволяет интегрировать практически любые приложения через презентационный слой, не вызывая агрессивных помех в работе друг друга и не используя комплексной инфраструктуры. Хотя подобное решение не может так же хорошо масштабироваться как решения middleware, описанный подход обещает стать еще одним экономичным методом работы в области интеграции. Это весьма своевременно, учитывая, что многие компании заняты сейчас поиском способов интеграции без привлечения огромных средств.
Хотя ранние подходы решают непосредственные бизнес-проблемы, они отнюдь не всегда оптимальны и часто приводят к созданию негибких независимых приложений, в результате чего увеличивается стоимость и время разработки будущих интеграционных модулей. В лучшем случае ранние подходы представляют собой промежуточный мост для перехода к более гибким, масштабируемым и надежным решениям по интеграции приложений.
Интеграция на уровне данных
Чуть позже появился подход хранилищ данных (datawarehouses), который в последнее время стал базовым. Он подразумевает поддержку данных в специальных хранилищах независимо от бизнес-логики, их породившей. Доступ к хранилищам могут получать различные приложения. Например, база данных по сотрудникам может служить общим фундаментом для нескольких HR-приложений, таких, как распределение премий и пособий, планировщик направления сотрудников на тренинги и отслеживание эффективности работы. Интеграция приложений по такой схеме подразумевает составление запросов и проведение обновлений по общей, хорошо документированной модели данных. Во многом благодаря успеху продуктов, созданных на основе реляционных баз данных и сопутствующих стандартов (таких, как SQL и ODBC) интеграция на уровне данных продолжает господствовать в качестве способа оптимизации взаимосвязей между различными системами.
Однако данные в хранилищах могут вызвать некоторые проблемы. Во-первых, они подразумевают использование общей модели данных для всего набора приложений, что препятствует разработчикам и ограничивает гибкость. Даже в четко определенной области, например в HR, приложения самообслуживания, предназначенные для сотрудников, и инструменты поддержки принятия решений, нацеленные на менеджеров, скорее всего будут использовать различные модели данных. Кроме того, интеграция на уровне данных сама по себе не предлагает средств для связи с традиционными приложениями. Иногда слои данных таких систем хорошо представлены и документированы, однако чаще для связи с ними требуются специальные коннекторы, что влечет за собой дополнительные расходы, организацию внесения изменений и «привязку» к поставщику. Кроме того, компоненты приложений не всегда хорошо взаимодействуют в реальном времени, что является критически важным требованием сегодняшних стратегических бизнес-приложений.
Интеграция на уровне корпоративных приложений
EAI осуществляет интеграцию на функциональном уровне, а не только на уровне пользовательских интерфейсов или данных. В результате новые интегрированные приложения могут осуществлять функции как «считывания» так и «записи», т. е. поддерживать полноценные транзакции со всеми интегрированными системами.
Веб-услуги скорее всего используются неоправданно часто. Вероятно, лишь в 20% интеграционных проектов необходима интеграция сервисного уровня. В остальных случаях происходит лишь обмен данными.
Вместо специализированных интерфейсов между отдельными программами EAI полагается на связующую среду с возможностью многократного использования, которая играет роль универсального программного ядра, соединяющего все приложения. Эта интеграционная структура может многократно использоваться для быстрого создания новых приложений. Таким образом, интеграторы приложений должны создать только один интерфейс для связи со структурой интеграции приложений, вместо того чтобы создавать все новые интерфейсы для связи с каждым новым приложением. Полученную в результате систему легче поддерживать и расширять. Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений, при этом скудные ресурсы развития можно направить на важные бизнес-задачи, а не воссоздавать заново уже существующие функции. Интеграционные среды такого рода получили название middleware (промежуточное ПО или инфраструктурное ПО). Учитывая, что бизнес-логика, как правило, расположена на средних ярусах распределенной архитектуры, термин middleware хорошо описывает суть процессов.
Многие аналитики придерживаются мнения, что интеграция данных долго не уступит своих позиций в качестве решения корпоративного класса.
Кроме того, поскольку традиционные и пакетные приложения выполняют различные функции, EAI интегрирует их, не внося каких-либо модификаций, что гарантирует отсутствие ошибок в критически важных приложениях.
Недостатком этого подхода является сложность. Реальные EAI-проекты, как правило, оказываются дорогостоящими и длительными и требуют значительных экспертных знаний.
Важнейшее отличие веб-услуг от более ранних EAI-проектов заключается в следующем. Веб-услуги предоставляют стандартизированные способы работы с интеграцией, а EAI-технологии всегда зависели от одного-двух поставщиков или разрабатывались для конкретных продуктов. Другими словами, может существовать EAI-интерфейс, связывающий пакет PeopleSoft по работе с персоналом с системой SAP R/3, однако он не сможет подключить к SAP другие пакеты по работе с персоналом. С другой стороны, веб-услуги основаны на стандартах, поддерживаемых консорциумом World Wide Web (W3C). Кроме того, в то время как веб-услуги с самого начала разрабатывались для использования в распределенных средах, EAI-технологии далеко не всегда предназначались для этого.
Несмотря на обилие методов и технологий, достижения ИТ-компаний, разрабатывающих критические решения для интеграции систем, весьма плачевны. Вот статистика:
• 85% проектов по программной разработке не доводятся до конца;
• 58% крупных системных проектов не укладываются в бюджет;
• 63% выбиваются из графика;
• 58% компаний сообщают, что успешных их проектов у них менее 50%.
Помимо проблем, осложнявших жизнь интеграторам приложений в прошлом, новому поколению приходится сталкиваться с дополнительными сложностями. На разработку таких приложений сейчас отводится еще меньше времени. Большие сроки, которые традиционно отпускались на разработку новых приложений, неприемлемы в сегодняшних обстоятельствах. Попытки изменить традиционные инфраструктуры или приложения, построенные на них, к сожалению, отнимают много времени, невероятно сложны и чреваты ошибками.
Проблемы безопасности сегодня также стоят гораздо острее, чем в прошлом. Модная сегодня веб-поддержка бизнес-процессов зачастую означает, что теперь критические приложения открыты новым опасностям. После интеграции в новое приложение четко контролируемая и надежно защищенная среда становится подвержена тем же опасностям, что и настольный компьютер, работающий в смешанных сетях. Многие из этих приложений станут уязвимыми для атак хакеров. Защита таких интегрированных систем осложняется тем, что каждая система имеет собственную архитектуру безопасности. Разнородность системы увеличивает вероятность выявления уязвимых точек, что усугубляет проблемы безопасности.
Традиционные подходы EAI часто оказываются более конкретными, сильносвязанными решениями, а веб-услуги представляют обобщенный слабосвязанный подход. Примерно такой же баланс существует и в других аспектах системного дизайна.
Найти сотрудников, обладающих опытом работы с интеграционными инструментами, сегодня весьма непросто. Успех проекта непосредственно зависит от того, располагаете ли вы необходимыми навыками в нужный момент времени. Потеря ключевого персонала, как правило, представляет собой значительный риск. Малые знания и опыт команды в области технологий интеграции ведут к нарушению графика реализации проекта. Неопытный персонал может разработать систему, которая не отвечает вашим требованиям. Недостаток персонала, обладающего экспертными знаниями по технологиям интеграции и методам построения интеграционных решений, представляет собой серьезную угрозу.
Традиционные EAI-технологии или веб-услуги?
Чарльз Голдфарб, создатель XML-технологии и соавтор «Руководства по XML», говорит, что в общем и целом веб-услуги и традиционные EAI-технологии являются различными точками единой интеграционной среды. Он поясняет, что подходы EAI часто оказываются более конкретными, сильносвязанными решениями, а веб-услуги представляют обобщенный слабосвязанный подход к проблемам интеграции. Это примерно такой же баланс, как и в других аспектах системного дизайна.
Заказчикам следует осторожно относится к рекламным лозунгам поставщиков, так как оптимальный подход зависит от конкретной ситуации. Если вы работаете с большими объемами и ваши цели четко определены, то, возможно, вам имеет смысл оптимизировать рабочий цикл, создав сильносвязанное специализированное решение, считает Голдфарб. Однако если вам нужна гибкость «в мире, где каждый день и каждый час может изменить то, что вы делаете, и те, с кем вы это делаете», то подход использования веб-услуг может оказаться более ценным.
Дата добавления: 2015-02-10 ; просмотров: 41 ; Нарушение авторских прав