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

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

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

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

увеличить изображение
Рис. 5.18. [SOA] Application Integration::Parallel Workflow variation::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, в котором используются прямые соединения "точка-точка" с системой работы с процессами.

увеличить изображение
Рис. 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). Это должно сделать интеграцию относительно простой.