Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

Книга «Шаблоны интеграции корпоративных приложений»

1.1. Решение задач интеграции с помощью шаблонов проектирования

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

Читать далее >>

1.2. Трудности интеграции

Интеграция корпоративных приложений - весьма непростое занятие. По определению интеграция корпоративных приложений подразумевает обеспечение взаимодействия между множеством программ, выполняющихся под управлением различных платформ и расположенных в различных местах предприятия. Таким образом, фраза простая интеграция является ни чем иным, как оксюмороном. Некоторые разработчики ПО предлагают пакеты...

Читать далее >>

1.3. Роль интеграционных шаблонов проектирования

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

Читать далее >>

1.4. Роль интеграционных шаблонов проектирования. Продолжение.

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

Читать далее >>

1.5. Слабое связывание

Одним из наиболее популярных терминов в области интеграции корпоративных приложений является термин слабое связывание. Дуг Кэй (Doug Куге) посвятил этой вездесущей концепции целую книгу. Преимущества слабого связывания были известны давно, однако ключевое место эта концепция заняла благодаря растущей популярности архитектур на основе Web-служб.Основной принцип слабого...

Читать далее >>

1.6. Пример простой интеграции

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

Читать далее >>

1.7. Пример простой интеграции. Продолжение.

Использование для удаленного взаимодействия протокола TCP/IP устанавливает временную зависимость между общающимися системами. Как известно, протокол TCP/IP является протоколом с установкой соединения. Это означает, что фактической передачи информации между двумя системами предшествует стадия установки соединения (рис. 1.7). При создании TCP-соединения отправитель и получатель данных обмениваются IP-пакетами...

Читать далее >>

1.8. Компоненты слабосвязанного интеграционного решения

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

Читать далее >>

1.9. Пример Приборы и устройства

Рассмотрим пример создания интеграционного решения, основанного на обмене сообщениями. Предположим, что вымышленная компания ''Приборы и устройства'' (ПРУСТ) закупает у производителей два наименования продукции (приборы и устройства) и реализует ее розничным потребителям через Интернет (рис. 1.10). Сформулируем требования, предъявляемые к интеграционному решению (несмотря на...

Читать далее >>

1.10. Размещение заказов

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

Читать далее >>

1.11. Обработка заказов

Обработка заказа предполагает выполнение следующих действий.• Проверка кредитной репутации клиента. Если у клиента остались неоплаченные счета, следует отменить новый заказ.• Проверка наличия товара. Компания не сможет выполнить заказ, если в него будут включены отсутствующие в данный момент на складе товары. • Отправка товара...

Читать далее >>

1.12. Обработка заказов. Продолжение.

Описав основные этапы передачи сообщения, сосредоточимся на функции управления складскими запасами. Как известно, компания ПРУСТ имеет две подобные системы, соответствующие приборам и устройствам. Для корректной маршрутизации запросов о наличии товара на складе применим маршрутизатор на основе содержимого, как показано на рис. 1.15. В зависимости от...

Читать далее >>

1.13. Проверка состояния заказа

Несмотря на объединение систем с помощью каналов сообщений (Message Channel, с. 93), на выполнение заказа может уйти достаточно много времени. К примеру, нужного товара может не оказаться в наличии, в результате чего система управления складскими запасами будет удерживать сообщение о проверке возможности выполнения заказа до...

Читать далее >>

1.14. Проверка состояния заказа. Продолжение.

Итак, новый вариант интеграционного проекта предусматривает размещение сообщений в хранилище сообщений, а также использование последнего при обработке сообщений. Информация, содержащаяся в хранилище сообщений, позволяет определить следующий этап обработки сообщения, устраняя тем самым необходимость соединения компонентов интеграционного решения с помощью фиксированных каналов сообщений. К примеру, если...

Читать далее >>

1.15. Изменение адреса клиента

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

Читать далее >>

1.16. Изменение адреса клиента. Продолжение.

Как отмечалось выше, для преобразования канонического формата сообщений в формат, используемый приложениями, применяются трансляторы сообщений. Отсутствие транслятора сообщений Web-интерфейса объясняется тем, что формат последнего был взят за основу канонической модели данных (Canonical Data Model, с. 367). Это может ограничить гибкость решения, если мы захотим предоставить...

Читать далее >>

1.17. Обновление каталога товаров

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

Читать далее >>

1.18. Тестирование и мониторинг

Мониторинг потока сообщений является неотъемлемой частью процессов функционирования и обслуживания интеграционного решения. Некоторые важные бизнес-метрики, такие как среднее время выполнения заказа, можно узнать с помощью хранилища сообщений (Message Store, с. 565). Однако в процессе функционирования интеграционного решения может возникнуть потребность и в более детальной информации...

Читать далее >>

2.1. Стили интеграции

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

Читать далее >>

2.2. Способы интеграции приложений

Универсального способа интеграции приложений, в одинаковой степени удовлетворяющего всем рассмотренным выше критериям, не существует. Ниже перечислены основные стили интеграции приложений, известные на момент написания этой книги.• Передача файла (File Transfer, с. 80). Взаимодействие между приложениями осуществляется с помощью файлов, в которые помещаются общие данные.• Общая...

Читать далее >>

1
...




Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта