Компания IBM
Опубликован: 14.08.2008 | Доступ: свободный | Студентов: 1090 / 150 | Оценка: 4.75 / 3.75 | Длительность: 27:55:00
Лекция 5:

Моделирование. Архитектура системы

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >

5.5 Шаг 3. Выбор и объединение шаблонов рабочих систем

В данном разделе мы опишем шаблоны рабочих систем для двух выбранных нами шаблонов приложений, объединим их и установим соответствия между компонентами приложений и компонентами рабочей системы.

ИТ-стратегия подталкивает нас к использованию подхода с открытыми стандартами, и мы решили внедрить рабочую систему на основе сервисно-ориентированной архитектуры (Service Oriented Architect, SOA). Для обоих шаблонов – и для Exposed Broker, и для Parallel Workflow – существует вариант рабочей системы SOA, как это показано на рис. 5.18 и рис. 5.19.

[SOA] Application Integration::Parallel Workflow variation::Runtime pattern

увеличить изображение
Рис. 5.18. [SOA] Application Integration::Parallel Workflow variation::Runtime pattern
[SOA] Extended Enterprise::Exposed Broker::Runtime pattern

увеличить изображение
Рис. 5.19. [SOA] Extended Enterprise::Exposed Broker::Runtime pattern

5.5.1 Предложение 1. Шаблон интеграции, ориентированный на брокер

В нашем первом предложении по архитектуре эти два шаблона рабочей системы объединены с помощью брокера (посредника), который соединяет компоненты. Это показано на рис. 5.20. Чтобы избежать путаницы, мы изобразили на этих схемах только одного оценщика (Assessor) и одного специалиста по обработке претензий (Claim handler). Конечно, оценщиков и специалистов по обработке на самом деле много.

Комбинация шаблонов интеграции приложений на основе брокера

увеличить изображение
Рис. 5.20. Комбинация шаблонов интеграции приложений на основе брокера

Мы разместили новую систему автоматизации работы с оценщиками на новой системе работы с процессами и свели к минимуму изменения, вносимые в существующую систему обработки претензий (Claims Workflow). Все необходимые нам службы работают в среде сервера приложений. Службы, которые управляют оценщиками (компонент Assessor Proxy), располагаются на шлюзе ESB, и все компоненты соединены общей сервисной шиной, которая связывает воедино два интеграционных шаблона.

Эта архитектура имеет ряд преимуществ, которые следует учесть при рассмотрении имеющихся в распоряжении компании LGI инфраструктуры и навыков:

  • Специалисты компании LGI знакомы с реализацией шины сообщений и имеют навыки, позволяющие превратить шину сообщений в сервисную шину.
  • Соединение всех служб через ESB привлекательно с точки зрения удобства управления, руководства и возможностей многократного использования. ESB – это ресурс, охватывающий все предприятие. Соединение служб напрямую с теми приложениями, которым эти службы первоначально понадобились, может привести к дублированиям и утрате контроля.
  • Технология, используемая для реализации центра ESB (WebSphere Business Integration Message Broker), доказала свою эффективность в решении проблем интеграции при соединении отличных друг от друга компонентов. Такие проблемы, как несовместимые протоколы, разные уровни структуры прикладных данных и т. п., могут быть преодолены путем создания потоков сообщений или посреднических потоков в брокере.
  • Свободный стиль связей, реализуемый в ESB, доказал свою полезность при устранении зависимостей между командами разработки.

Данное решение опровергает критику со стороны тех, кого волнует объем дополнительной работы, требующейся для реализации маршрутизации от системы работы с процессом Assessor Automation через шину ESB к подключенным к ней службам, а затем обратно - к Assessor Automation. Если шина ESB компании LGI будет работать главным образом через WebSphere Business Integration Message Broker, то для установления соединений не окажется общего инструмента. Если же использовать модель с прямыми соединениями между системой работы с процессом Assessor Automation и теми ее службами, которые работают как EJB-компоненты, то инструмент WebSphere Studio Application Development Integration Edition сгенерирует соединения и реализует систему работы с процессом.

5.5.2 Предложение 2. Шаблон интеграции, ориентированный на процесс

Мы изменили шаблон рабочей системы на тот, который показан на рис. 5.21, в котором используются прямые соединения "точка-точка" с системой работы с процессами.

Parallel Process application pattern::Runtime pattern

увеличить изображение
Рис. 5.21. Parallel Process application pattern::Runtime pattern

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

Комбинация шаблонов интеграции приложений на основе процесса

увеличить изображение
Рис. 5.22. Комбинация шаблонов интеграции приложений на основе процесса

Оба подхода имеют свои преимущества и недостатки. На наш выбор существенно повлияют практические соображения, такие, как имеющиеся навыки, имеющаяся ИТ-инфраструктура и количество необходимых изменений при использовании каждого подхода. Как уже говорилось, существенное влияние на выбор у нас оказал инструментарий создания решения, который подвел нас к выбору решения, ориентированного на процесс. Еще одним фактором стал вспомогательный пакет для соединения сервера WebSphere MQ Workflow, работающего с потоком претензий, с сервером WebSphere Business Integration Server Foundation, на котором будет работать система автоматизации работы с внешними оценщиками (Assessor Automation). Это должно сделать интеграцию относительно простой.

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Надежда Белякова
Надежда Белякова
Россия
Pavel Pelevin
Pavel Pelevin
Украина, Одесса