Создание бизнес-процесса с помощью инструментов Rational и WebSphere

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

Разбить на страницы
Показывать лекцию целиком

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

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

В лекции 6, "Архитектура решения", рассматривается дизайн решения и разработка архитектуры решения.

5.1 Выбор архитектурных шаблонов

Мы выполним шаги, приведенные на рис. 3.10, чтобы выбрать подходящий архитектурный шаблон для решения по работе с внешними оценщиками. Это весьма длительный процесс. Чтобы помочь вам сориентироваться, мы приводим ниже краткое описание этапов.

  • Шаг 0. Сбор требований.

    На этих предварительных этапах архитектор решения собирает требования, которые были зафиксированы на семинарах в сотрудничестве с бизнес-аналитиком. Максимально используя возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect, архитектор решения начинает создавать элементы решения, такие, как прецеденты использования, роли и компоненты, которые будут применяться в архитектурной модели.

  • Шаг 1. Выбор шаблона бизнес-интеграции.

    На первом этапе мы выбираем, какие виды шаблонов бизнес-интеграции мы будем использовать. Это оказывает существенное влияние на архитектуру решения. Нужна нам интеграция, ориентированная на данные или на процесс? Существует ли связь между пользователями и требованиями? Нужно ли включать в решение приложения партнеров?

  • Шаг 2. Выбор шаблона приложения.

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

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

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

  • Шаг 4. Применение связей с продуктами.

    Наконец, мы применяем к шаблону рабочей системы связи с продуктами (product mappings). При этом создается наша базовая архитектура, которую мы фиксируем, создавая схему размещения в Rational Software Architect. Базовая архитектура имеет несколько областей применения:

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

    Теперь мы можем вернуться к нашей работе. Предварительный этап, назовем его "шаг 0", состоит в сборе всех требований и изучении тех частей, которые нужно интегрировать друг с другом для создания решения для работы с внешними оценщиками.

    5.2 Шаг 0. Сбор требований

    Архитектор решения, совместно с бизнес-аналитиком, на семинарах занимается сбором требований и определением существующего и планируемого процесса изучения страховых претензий (см. раздел 3.2.2, "Области ответственности и разработка по контракту"). Материалы этого семинара в качестве требований использует архитектор системы.

    Хотя мы и не использовали Rational Requisite Pro для регистрации требований и интегрирования их в архитектурную модель в Rational Software Architect, вам все же следует принимать это во внимание. Это особенно полезно, если одной из задач директора по информационным технологиям является отслеживание требований. Инструмент Requisite Pro, если использовать его в сочетании с другими инструментами для управления изменениями, такими, как ClearQuest, дает ответы на следующие вопросы:

  • Какие требования в каком решении реализуются?

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

  • Каково будет влияние удаления какой-то возможности из решения?
  • На другие решения, которые могут зависеть от данного?
  • На дизайн и реализацию решения?
  • Какие части реализации мы теперь можем отбросить?
    •
  • Если менеджер ИТ-инфраструктуры решит изменить план обновлений, какое влияние это окажет на разрабатываемые решения?
  • Какие допущения лежали в основе выбранного плана обновлений?
  • Какие допущения остаются в силе?
  • Как они повлияют на новый план?

    • Мы собрали все требования в презентацию, которая была изучена руководителями-кураторами и другими членами команды. В следующих разделах мы даем общий обзор требований и показываем, как архитектор решений может использовать возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect для получения информации, необходимой для разработки базовой архитектуры для проектирования решения.

    5.2.1 Бизнес-цели

    Полное описание бизнес-целей компании LGI приводится в разделе 1.2, "Бизнес-цели". Ниже дается краткий обзор.

  • Уменьшение затрат на администрирование путем сведения к минимуму ручных операций, связанных с управлением оценкой претензий. Автоматизация управления оценкой претензий.
  • Повышение удобства для клиентов путем уменьшения административных задержек при обработке претензий. Осуществление мониторинга и управления всем процессом обработки претензий, включая задачи, выполняемые внешними оценщиками.
  • Максимальное повышение окупаемости затрат на разработку:
  • минимальное влияние на существующие системы;
  • простота разработки с использованием имеющихся навыков;
  • быстрая идентификация и устранение задержек в бизнес-процессе
    •

    5.2.2 Прецеденты использования, связанные с бизнесом

    При анализе требований, предъявляемых к процессу обработки претензий, было выявлено несколько прецедентов использования (use case). Мы можем применить Rational Software Architect для автоматической генерации визуального представления прецедентов использования, созданных по модели бизнес-процесса, которая была составлена бизнес-аналитиком при помощи WebSphere Business Integration Modeler.

    Иллюстрация приводится на рис 5.1.

    (рис 5.1) Прецеденты использования, связанные с работой с внешними оценщиками

    Прежде чем рассматривать применение Rational Software Architect для создания данной схемы, мы рассмотрим, как Rational Software Architect конструирует прецеденты использования из модели бизнес-процесса.

    Отображение модели бизнес-процесса в прецедентах использования

    Модель бизнес-процесса порождает разнообразные UML2-артефакты. На уровне абстракций каждая задача представлена в виде кооперации (collaboration). В решении для работы с внешними оценщиками есть две задачи, которые мы можем отобразить в виде коопераций в Rational Software Architect (рис 5.2 и рис 5.3):

    (рис 5.3) Кооперация ClaimInvestigation_TOBE(рис 5.2) Кооперация RequestExternalReports

    Специалист по обработке претензий (Claim Handler) – это единственный ресурс-роль, которую бизнес-аналитик использовал в высокоуровневом процессе ClaimInvestigation_TOBE. Автоматизированных задач здесь не было.

    С другой стороны, в процессе RequestExternalReports бизнес-аналитик определил наряду с ручными задачами, выполняемыми ролью Claim Handler, несколько ролей, выполняющих автоматизированные операции. Аналитик рассматривал оценщика (Assessor) как автоматизированную операцию.

    Следовательно, в соответствии с этими кооперациями есть только два прецедента использования, в которых задействуются ручные операции: роль Claim Handler, выполняющая процесс ClaimInvestigation_TOBE, и роль Claim Handler, участвующая в выполнении операции RequestExternalReports.

    Визуализация прецедентов использования в Rational Software Architect

    В Rational Software Architect существует несколько способов визуализации роли Claim Handler с созданием схем, напоминающих схему, показанную на рис 5.1. Мы рассмотрим здесь только два способа.

    Чтобы в Rational Software Architect можно было использовать модель WebSphere Business Integration Modeler, выполните следующие шагиДополнительная информация об интеграции WebSphere Business Integration Modeler и Rational Software Architect приводится в Приложении В, "Вопросы интеграции".

  • Импортируйте проект WebSphere Business Integration Modeler в Rational Software Architect. Используйте либо разработанный вами процесс, либо один из процессов, поставляемых в дополнительных материалах к этому курсу. Поскольку Rational Software Architect применяет рабочее пространство Modeler, вам нужно сделать в проекте, который вы хотите импортировать в Rational Software Architect, доступное рабочее пространство. Затем импортируйте проект ITSOLGI из рабочего пространства Modeler. Предположим, у вас есть рабочее пространство, называемое ExternalAssessors, а внутри него – проект ITSOLGI:

    Выберите пункт меню File (Файл) $$\to$$ Import (Импорт). Импортируйте в рабочее пространство существующий проект ( Existing WBI Modeler 5.1 project ), нажмите Next (Далее), затем Browse (Обзор), перейдите в рабочее пространство WebSphere Business Integration Modeler, выберите проект .\SG24-6636\Modeler\Workspaces\Pre Bpel\ITSOLGI, нажмите OK, затем Finish (Готово).

  • Сделайте двойной щелчок по файлу resources.xmi, чтобы увидеть модель WebSphere Business Integration Modeler:Важно! Никогда не изменяйте и не сохраняйте модель resources.xmi. Этот файл доступен только для чтения. Если вы сохраните версию этого файла как новую модель UML2 (файл .emx) с дополнениями и модификациями, вы потеряете возможность выполнять динамические обновления из WebSphere Business Integration Modeler. Эти инструкции позволяют вам создавать расширения модели и схемы на основе модели WebSphere Business Integration Modeler. Убедитесь, что вы случайно не добавили элементы в файл resources.xmi модели WebSphere Business Integration Modeler. Если в редакторе UML-модели закладка с файлом resources.xmi помечена звездочкой, это значит, что вы случайно внесли в модель изменения, которые вы не сможете сохранить. Для очистки изменений закройте проект WebSphere Business Integration Modeler в Rational Software Architect, нажав правую кнопку мыши и выбрав пункт меню Close (Закрыть). Затем откройте проект заново и устраните проблемы.
  • В качестве первого варианта создания схемы прецедентов использования, просто выполните обзор:
  • в проводнике по моделям (Model Explorer) (см. рис. 5.5) откройте пункт resources.xmi $$\to$$ ITSOLGI $$\to$$ RootProcessModel $$\to$$ Claim $$\to$$ Claim_TOBE.
  • щелкните правой кнопкой мыши по пункту Claim handler $$\to$$ Visualize (Визуализация) $$\to$$ Explore in Browse diagram (Изучить в схеме обзора).
    •
  • Во-вторых, создайте схему прецедентов использования как часть архитектурной модели:
  • Создайте новый проект для хранения архитектуры решения, выбрав пункт меню File (Файл) $$\to$$ New Project (Новый проект) $$\to$$ UML project (UML-проект) $$\to$$ ITSOLGI Architecture.
  • Установите опцию Blank Model template (Пустой шаблон модели) и снимите опцию Create a default diagram in the new model (Создавать схему по умолчанию в новой модели). Нажмите Finish (Готово).
  • Щелкните правой кнопкой мыши по пункту Blank Model (Пустая модель), выберите пункт меню Refactor (Реорганизация) $$\to$$ Rename (Переименовать) и введите имя Claim Investigation.
  • Щелкните правой кнопкой мыши по пункту Claim Investigation, выберите пункт меню Add Diagram (Добавить схему) $$\to$$ Use Case Diagram (Схема прецедентов использования) и введите имя Claim Investigation.
    • К этому моменту окно Model Explorer должно выглядеть так, как показано на рис 5.5.
  • Заполните схему прецедентов использования, чтобы показать связи, которые вам нужно задокументировать:
  • Перетащите роль Claim Handler из пакета Claim_TOBE в редактор пакетов Claim Investigation.
  • Щелкните правой кнопкой мыши по ).(рис 5.4) Отображение взаимосвязей роли Claim Handler
  • Приведите схему в порядок. Хорошей практикой является размещение элемента Claim handler в верхнем левом углу, поскольку естественный способ чтения прецедентов использования сверху вниз и слева направо, начиная от исполнителя роли.
    • (рис 5.5) Проект ITSOLGI в Model Explorer

    Прецеденты использования сами не хранятся в Rational Software Architect. Для управления документами прецедентов использования вы можете применить Rational Requisite Pro.

    Прецедент использования 1. ClaimInvestigation_TOBE

    Роль: Claim handler.

  • Выбор полиса и проверка данных, содержащихся в нем.
  • Ввод первоначальной оценки клиентом стоимости повреждений и генерация резерва на выплату.
  • Проверка истории претензии $$\to$$ Предупреждение $$\to$$ Претензии, превышающие 30000$.
  • Отправка внешнего запроса на подробную оценку повреждения (см. "Прецедент использования 2").
  • Проверка стороннего отчета об оценке.
  • Согласование выплаты с клиентом.
  • Инициирование выплаты или ремонта.
    •

    Прецедент использования 2. RequestExternalReports

    Роль: Claim handler.

  • Исполнитель роли Claim handler подключается к Business Process Manager.
  • Выбор претензии, ожидающей оценки.
  • Инициирование автоматизированного процесса оценки.
  • Выбор подходящего оценщика по почтовому коду и типу машины.
  • Отправка запроса о готовности к работе.
  • Ожидание подтверждения.
  • Выбор оценщика.
  • Запрос на оценку.
  • Ожидание получения отчета об оценке.
  • Возврат отчета об оценке исполнителю роли Claim handler.
    •

    5.2.3 Роли

    За полным описанием всех ролей обращайтесь к разделу 1.4, "Роли". Ниже приводится краткое описание.

  • Роли LGI:
  • Claim handler (Специалист по обработке претензий). Управляет претензиями.
  • Claims Supervisor (Эксперт по претензиям). Имеет право работать с исключительными случаями претензий.
  • Claims Analyst (Аналитик по претензиям). Следит за всем процессом обработки претензий с целью определения экономических параметров.
    •
  • Внешние роли:
  • Assessor (Оценщик) – производит оценку претензии

    • С помощью Model Explorer вы можете создать визуальное представление вовлечения ролей в процесс обработки претензий. Чтобы в Rational Software Architect создать схему, более подробно отображающую роли, создайте в проекте ITSOLGI Architecture схему свободного формата (freeform). Назовите ее Manual Roles и перетащите выбранные роли из модели WebSphere Business Integration Modeler [в Model Explorer выберите пункт ITSOLGI $$\to$$ RootResourceModel $$\to$$ Resources (Ресурсы) $$\to$$ Roles (Роли)]. Для выбора нескольких ролей используйте щелчок мышью при нажатой клави- ше Ctrl, после чего при нажатой левой кнопке мыши перетащите роли на схему, как показано на рис 5.6. На этой схеме показаны не только некоторые из определенных нами ролей, но и список операций, в выполнении которых участвует роль, поскольку бизнес-аналитик определил эти операции. Роли смоделированы функцией интеграции с WebSphere Business Integration Modeler в виде бизнес-сотрудников (Business-Workers). Если вы изучите свойства одной из этих ролей, вы увидите, что они являются стереотипами интерфейсов.

    (рис 5.6) Роли и операции в процессе ClaimInvestigation_TOBE

    Некоторые роли в исходных требованиях не были смоделированы (например Claim Analyst – аналитик претензий) и поэтому здесь отсутствуют. Есть и другие роли, которые применялись для моделирования автоматических задач и которые мы здесь опустили.

    5.2.4 Компоненты

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

    Чтобы создать в модели новые компоненты, выполните следующие шаги:

  • Откройте проект ITSO Architecture и создайте новую схему компонентов Claim Investigation Component Diagram.
  • Перетащите на схему компонентов роли Assessor, Assessor Management, Business Rules Engine и Document Handler.
  • Теперь создайте шесть новых компонентов с именами AssessorManagement, BusinessRulesEngine, AssessorSystem, ClaimsSystem, AssessorAutomation и ClaimsWorkflow. Сделать это можно прямо на схеме, щелкнув правой кнопкой мыши и выбрав пункт меню Add UML (Добавить UML) $$\to$$ Component (Компонент).
  • Соедините каждый интерфейс с соответствующим ему компонентом, создав реализующую взаимосвязь. Наведите курсор мыши на компонент и щелкните по маленькой стрелке, указывающей на прямоугольник. Перетащите его на соответствующий интерфейс и отпустите кнопку мыши. Выберите пункт Create New Implementation (Создать новую реализацию). Соедините компоненты AssessorAutomation и ClaimsWorkflow, как показано на рис 5.7. Мы можем использовать цвета, соответствующие схеме Pattern for e-business, и показать, что компонент Assessor System является частью другой организации.
    •  (рис 5.7) Схема компонентов Claims Investigation

    Когда мы выберем шаблоны Patterns for e-business, как будет описано позже в этой лекции, мы обнаружим, что нам нужно добавить в эту схему еще один компонент.

    Компонент AssessorSystem не является частью LGI, и для него нужен прокси-компонент, который мы назвали proxyAssessorSystem, который будет выполнять функцию посредника между LGI и оценщиками. Мы снабжаем этот новый компонент другим интерфейсом, отличным от того, который используется компонентом Assessor System. Интерфейсы не могут быть одинаковыми, поэтому это не прокси в общепринятом смысле этого слова. Его нельзя сгенерировать автоматически из реального интерфейса компонента AssessorSystem. Например, задача Request Availability запрашивает информацию о готовности у всех подходящих оценщиков, а каждый оценщик получает отдельный запрос о готовности. И конечно, запросы к оценщикам поступают в разные точки назначения с применением разных транспортных протоколов.

    Мы добавляем на схемы компонент proxyAssessorSystem и другую детальную информацию из готовой архитектуры. И все же компонентная архитектура не завершена, пока мы не установим связи для рабочей системы, используя шаблоны для электронного бизнеса, как это описано в разделе 5.5, "Шаг 3. Выбор и объединение шаблонов рабочей системы".

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

    Одним из достоинств Rational Software Architect является то, что он упрощает создание и изменение моделей, которые можно анализировать и критиковать до тех пор, пока не получится картина, с которой будут согласны все члены команды.

    Для завершения компонентной модели мы выполнили следующие шаги:

  • Были добавлены выполняемые вручную ролью Claim handler задачи, которые бы- ли разделены между системами процесса Claims Workflow и Automated Assessor.
  • В компоненты были добавлены предоставляемые и необходимые интерфейсы. Готовая схема компонентной модели показана на рис 5.8.
    •  (рис 5.8) Готовая схема компонентов для ClaimInvestigation_TOBE

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

    Существующие компоненты

    Существующие компоненты при создании нового решения должны изменяться как можно меньше.

    LGI Assessor Management System (Система управления оценщиками LGI)

    Эта система предоставляет информацию о каждом оценщике и о способах взаимодействия оценщиков с LGI.

    Данная система включает следующие операции:

  • Identify Assessor (Идентификация оценщика).

    По типу и почтовому коду области нахождения автомобиля, подлежащего оценке, операция Identify Assessor формирует список потенциальных оценщиков с контактной информацией.

  • Load/Register AssessorЭти операции не были включены в данный сценарий. (Загрузка/регистрация данных об оценщике).
  • Ranking AssessorЭти операции не были включены в данный сценарий. (Ранжирование оценщиков).
  • Record Selected AssessorЭти операции не были включены в данный сценарий. (Запись выбранного оценщика).
    •

    Сохраняет сведения о выбранном оценщике и возвращает данные об идентификаторе претензии и о самом оценщике.

    Claims Workflow (Рабочий поток претензий)

    Это существующий, выполняемый вручную процесс. Интересующей нас подзадачей является процесс изучения претензии. Специалист по обработке претензий (Claim handler) выбирает претензию, с которой он будет работать, получает внешние отчеты и завершает работу, устанавливая для претензии статус "готовность к принятию решения". Процесс изучения претензии содержит следующие операции:

  • Select ReportЭти операции не были включены в данный сценарий. (Выбор отчета).

    Специалист по обработке претензий выбирает претензию из своего списка.

  • RequestExternalReports (Запрос внешних отчетов).

    Теперь это автоматизированный процесс, который вызывает автоматизированный подпроцесс работы с внешними оценщиками и возвращает отчет оценщиков.

  • Update External ReportsЭти операции не были включены в данный сценарий. (Обновление внешних отчетов).

    Специалист по обработке претензий может получать другие внешние отчеты.

  • SetClaimStatusЭти операции не были включены в данный сценарий. (Установка статуса претензии).
    •

    В заключение для претензии устанавливается статус "готовность к принятию решения".

    Document Management System (Система управления документами)

    Система управления документами хранит все отчеты, сгенерированные в процессе работы с претензиями и полисами. Нас интересует только одна операция – Store the assessment report (Сохранение отчета об оценке).

    Новые и измененные компоненты

    Из существующих компонентов WebSphere MQSeries и Web Services Gateway создается корпоративная сервисная шина (enterprise service bus), обеспечивающая на основе служб передачу данных к компонентам решения.

    Новым компонентом является система бизнес-правил (Business Rules Engine, BRE). Мы не акцентируем внимание на способах использования BRE и применяемых в ней технологиях. Целью этого компонента является повышение удобства для пользователя через совершенствование взаимодействия с внешним оценщиком.

    Enterprise Service Bus (Корпоративная сервисная шина)

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

  • ProxyRequestAvailability.

    Данная операция, имея доступ к списку оценщиков и к данным об оценщиках, посылает каждому оценщику запрос о том, готов ли он к выполнению оценки. Запрос должен посылаться при помощи метода, согласованного с оценщиком (e-mail, EDI, Web-служба, страница браузера и т. п.).

  • ProxyRequestAssessment.

    Данная операция, имея доступ к данным о выбранном оценщике и к данным о претензии, посылает запрос об оценке претензии и сохраняет данные о под- тверждении запроса.

  • ProxyAssessorSendReport.

    Получает от оценщика отчет и сохраняет его.

    •

    Business Rules Engine (Система работы с бизнес-правилами)

    Это новый компонент, позволяющий настраивать процесс оценки в зависимости от задач бизнеса. К нему относятся следующие операции:

  • выбор времени оценки на основе типа полиса, имеющегося у клиента;
  • применение бизнес-правил для выбора оценщика из списка оценщиков.
    •

    5.2.5 Организационные и архитектурные ограничения

    За полным описанием целей и ограничений, связанных с ИТ, обращайтесь к разделу 1.3, "Цели и ограничения, связанные с ИТ". Ниже приводится краткое описание.

  • ИТ-политики:
  • Использование открытых стандартов;
  • Поддержка используемых каналов;
  • Создание общей инфраструктуры для LGI и DirectCar;
  • Повторное использование существующих приложений;
  • Установка новой инфраструктуры LGI.
    •
  • Ограничения, связанные с корпоративной инфраструктурой. Новые приложения должны использовать корпоративную LDAP-директорию для определений ролей и назначения их персоналу
  • Возможность выполнять оценку вручную при работе с особыми случаями
  • Поддержка разных систем, используемых оценщиками, включая доступ через браузер, электронную почту, EDI и Web-службы, работающие через HTTP и JMS.

    • 5.2.6 Границы решения

    Существует ряд аспектов решения, которые мы опустили из-за недостатка времени.

  • Моделирование данных.

    Мы упростили в данном решении использование данных. На практике моделирование данных с использованием модели промышленного стандарта, например ACCORD для страховой индустрии, является весьма существенной частью работы бизнес-аналитика и создает много проблем для всей команды проекта.

  • Безопасность.

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

  • Директория.

    Мы не реализовывали в масштабе решения директорию для работы с персоналом.

  • Пользовательский интерфейс.

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

    •

    WebSphere Business Integration Server Foundation не использует общие рабочие списки, и, если не проведена дополнительная работа, специалисту по обработке претензий приходится применять два окна для работы с двумя рабочими списками. Кроме того, специалист должен обеспечивать соответствие этих списков.

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

  • Мы не реализовывали мониторинг бизнес-событий для отслеживания обработки претензии.
  • Мы не реализовывали никаких функций системного управления для размещения и мониторинга.
    •

    Мы ограничили виды соединений с внешними оценщиками только протоколом SOAP/Http:. На практике продукты, используемые в качестве шлюза ESB, должны обрабатывать как минимум доступ через EDI, электронную почту и браузер.

    5.3 Шаг 1. Выбор шаблона бизнес-интеграции

    Теперь, когда архитектор организовал требования и понял природу и границы решения, первым этапом использования подхода Patterns for e-business является выбор шаблона Бизнес-интеграции. Выбор сводится к рассмотрению двух шаблонов:

  • Extended Enterprise (Расширение предприятия). Критериями выбора шаблона Extended Enterprise является следующее:
  • бизнес-процесс необходимо интегрировать с существующими бизнес-системами и данными;
  • бизнес-процессы нужно интегрировать с процессами и данными, существующими в организациях-партнерах.
    •  За дополнительной информацией обращайтесь по адресу: http://www-106.ibm.com/developerworks/patterns/b2bi/info.html
  • Application Integration (Интеграция приложений). Критериями выбора шаблона Application Integration является следующее:
  • бизнес-процесс необходимо интегрировать с существующими бизнес-системами и данными;
  • бизнес-процессы нужно интегрировать с процессами и данными, существующими в организациях-партнерах;
  • для работы бизнеса нужно объединять, организовывать и представлять информацию из различных источников как внутри организации, так и за ее пределами.
    • За дополнительной информацией обращайтесь по адресу http://www-106.ibm.com/developerworks/patterns/application/info.html

    На рис 5.9 и рис 5.10 курсивом в списках обозначены перекрытия между этими шаблонами. Использовать можно оба шаблона. Должны ли мы выбрать первый, второй или оба? Некоторые дополнительные инструкции приводятся на Web-сайте Patterns for e-business. И снова курсивом выделены перекрытия между шаблонами.

    (рис 5.10) Выбор элементов шаблона Extended Entity(рис 5.9) Выбор элементов шаблона Application Integration

    Мы не будем выбирать какой-то из этих шаблонов на этой стадии и продолжим использовать оба, а с перекрытиями разберемся при установлении соответствий для рабочей системы – раздел 5.5, "Шаг 3. Выбор и объединение шаблонов рабочих систем".

    5.4 Шаг 2. Выбор шаблона приложения

    Итак, для детализации у нас есть два шаблона бизнес-интеграции – Extended Enterprise и Application Integration. Шаблон Extended Enterprise будет наиболее полезен при проектировании архитектуры взаимодействий с оценщиками. Шаблон Application Integration будет полезен для интеграции нового решения для работы с внешними оценщиками, существующим рабочим потоком претензий, системой управления оценкой и претензиями.

    5.4.1 Кооперации

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

    Для изображения коопераций существующей и новой системы мы использовали стиль Patterns for e-business (P4EB).

    Воспроизведем на рис 5.11 существующий процесс оценки, который мы уже показывали ранее на рис 2.6.

    (рис 5.11) Ручной запрос отчетов у внешних оценщиков

    При использовании стиля [P4EB], если мы оставим в стороне приложения, лежащие выше системы обработки претензий, существующая система превращается в то, что изображено на рис 5.12.

    (рис 5.12) Кооперация [P4EB] ClaimInvestigation_ASIS

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

    На рис 5.13 показаны шаблоны Extended Enterprise и Application Integration, наложенные на планируемую систему.

    (рис 5.13) Кооперация [P4EB] ClaimInvestigation_TOBE

    Теперь нам нужно выбрать два шаблона приложения: один – для шаблона бизнес-интеграции Extended Enterprise, другой – для шаблона бизнес-интеграции Application Integration.

    5.4.2 Шаблоны приложений для Extended Enterprise

    Основное назначение той части решения, которая связана с шаблоном Extended Enterprise, – это связь с внешними оценщиками. На рис 5.14 показаны факторы бизнеса, на основании которых мы выбрали шаблон приложения Exposed Broker (Внешний брокер). Обратите внимание на столбец, относящийся к этому шаблону, который мы выделили линиями. Шаблон приложения Exposed Broker показан на рис 5.15.

    (рис 5.15) Выбор шаблона приложения Exposed Broker(рис 5.14) Шаблон приложения Exposed Broker

    Основными факторами, определившими выбор шаблона, явились следующие:

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

    Если процитировать информацию с сайта Patterns for e-business, этот шаблон наиболее хорошо соответствует нашим целям. Главный фактор, способствующий выбору данного шаблона приложения, состоит в том, что этот шаблон позволяет одному приложению взаимодействовать с одним или несколькими приложениями партнеров, находящихся за пределами организации. Использование звездообразной архитектуры, а не соединений "точка-точка", позволяет осуществить интеграцию приложений в единую систему при минимальной сложности. Запрос на получение информации может направляться в одну или несколько точек назначения или одновременно во многие точки. Получающееся сообщение-запрос может быть разделено (декомпозиция) на множество сообщений-запросов, а сообщения-ответы могут быть собраны в единое сообщение-ответ с использованием подходящих правил сборки (рекомпозиции).

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

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

    5.4.3 Шаблоны приложений для Application Integration

    Если изучить бизнес-факторы для шаблонов интеграции приложений на рис 5.17, становится ясно, что для поддержки вмешательства человека нам нужно выбрать шаблон Parallel Workflow variation (Вариант с параллельным рабочим потоком) (рис 5.16).

    (рис 5.17) Шаблон интеграции приложений Parallel Workflow variation(рис 5.16) Выбор шаблона Parallel Workflow variation

    Основные критерии для выбора данного шаблона были следующие:

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

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

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

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

    (рис 5.19) [SOA] Application Integration::Parallel Workflow variation::Runtime pattern(рис 5.18) [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). Это должно сделать интеграцию относительно простой.

    5.6 Шаг 4. Применение связей с продуктами

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

    5.6.1 Имеющиеся вложения в системы и продукты

    На рис 2.12 показана вся существующая ИТ-инфраструктура и инструменты, использованные для создания имеющейся системы обработки претензий. Существенными являются следующие аспекты:

  • объединенный поток претензий обрабатывается на WebSphere MQ Workflow, а компания DirectCar имеет систему работы с процессами WebSphere Application Server Enterprise;
  • ESB функционирует на WebSphere MQSeries и WebSphere Business Integration Message Broker, где два существующих соединения Web-служб с внешними поставщиками поддерживаются при помощи Web Services Gateway;
  • клиентская Web-часть и некоторые имеющиеся приложения для работы с претензиями функционируют как EJB на WebSphere Application Server.
    •

    5.6.2 Имеющиеся клиентские навыки и навыки разработки

    В компании LGI имеются довольно хорошие навыки работы с WebSphere MQSeries и WebSphere Application Server. Специалисты компании создавали приложения-Web-службы типа "точка-точка" и EJB-приложения. Они также создавали бизнес-процессы, используя WebSphere Business Integration Modeler 4.3.4 (продукт Holosofx, приобретенный IBM), и выполняли процесс на WebSphere MQ Workflow.

    5.6.3 Выбор, сделанный заказчиком

    Компания LGI желает разрабатывать больше приложений на основе открытых стандартов, таких, как Java 2 Enterprise Edition (J2EE), Web-службы и BPEL. В частности, специалисты компании хотят использовать данный проект для оценки инструментов и системы для разработки, управляемой моделями с применением UML и BPEL. См. раздел 1.3, "Цели и ограничения, связанные с ИТ".

    Выбранная платформа должна подходить к среде заказчика и обеспечивать качество обслуживания, в частности масштабируемость и надежность, чтобы решение могло расти вместе с бизнесом:

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

    5.6.4 Связи с продуктами

    На рис 5.23 дается общий обзор связей с выбранными продуктами.

    (рис 5.23) External Claim Assessor::Product Mapping

    Assessor Systems (Системы работы с оценщиками)

    Мы реализуем одну систему работы с оценщиками как EJB-компонент, работающий на WebSphere Application Server. К области ответственности оценщиков относится:

  • ответ на запрос о доступности;
  • ответ на запрос о выполнении оценки претензии;
  • отправка готового отчета об оценке.
    •

    Business Rules Engine (Система бизнес-правил)

    Система бизнес-правил представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за следующее:

  • за предоставление данных о времени обязательного ответа на претензию;
  • выбор оценщика для обработки претензии из списка доступных оценщиков.
    •

    Assessor Management (Система управления оценщиками)

    Создание списка оценщиков, потенциально способных выполнить оценку, на основе типа автомобиля и местоположения

    Claim System (Система обработки претензий)

    Система управления оценщиками представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за хранение отчета об оценке.

    Assessor Automation (Автоматизация работы с оценщиками)

    Система автоматизации работы с оценщиками представляет собой BPEL-систему, работающую на WebSphere Business Integration Server Foundation. Она отвечает:

  • за получение запроса на оценку претензии от системы управления потоком претензий
  • управление процессом создания отчета;
  • возврат отчета в систему управления потоком претензий.
    •

    Claims Workflow (Система управления потоком претензий)

    Система управления потоком претензий представляет собой FDL-систему, работающую на WebSphere MQ Workflow. Она отвечает:

  • предоставление специалисту по обработке претензий:
  • списка претензий для изучения;
  • списка претензий, прошедших к данному моменту оценку;
    •
  • отправку претензии в процесс Assessor Automation и ожидает окончания оценки.

    • ESB (Корпоративная сервисная шина)

    ESB – это сервисная шина, поддерживающая MQ, SOAP/JMS и SOAP/Http:. Она отвечает за отделение запросов к службам от транспортного протокола и физических адресов конечных точек.

    ESB Gateway (Шлюз ESB)

    Шлюз ESB – это службы, используемые сервисной шиной. Он отвечает:

  • за реализацию соответствующего стиля взаимодействия с каждым из оценщиков (SOAP/http, Web-службы, EDI, браузер и т. д.);
  • распределение запросов среди множества оценщиков;
  • сбор ответов от нескольких брокеров;
  • задание времени ожидания ответов;
  • обработку ответов, пришедших с опозданием.
    •

    Web services Gateway (Шлюз Web-служб)

    Шлюз Web-служб представляет собой демилитаризованную зону (DMZ). Он отвечает:

  • за реализацию функции прокси для адресов Web-служб между Интернетом и интранетом;
  • за ответы на автоматические запросы по предоставлению WSDL-интерфейсов клиентам Web-служб;
  • за обеспечение безопасности связи через Интернет.
    •

    5.7 Базовая архитектура

    На рис 5.24 показана базовая физическая архитектура, которую мы будем использовать в данном сценарии. Размещение моделируется в Rational Software Architect с использованием уже созданной компонентной модели.

    (рис 5.24) Схема размещения Claim Investigation
  • В Model Explorer выберите пункт ITSO Architecture $$\to$$ Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add Diagram (Добавить схему) $$\to$$ New Deployment Diagram (Новая схема размещения).
  • Перетащите компоненты на схему (для краткости опустим оценщиков и шлюз Web-служб), выделите их все и нажмите пункт Name Compartment Style (Стиль с отображением имени), чтобы отображались только имена компонентов, но не их атрибуты. (рис 5.24).
  • Добавьте следующие артефакты ( Artefacts ): хранилище архивов брокера (Broker Archive Repository, BAR), хранилище корпоративных архивов (Enterprise Archive Repository, EAR) и поток FDL (FDL flow), которые будут размещены в системе. Мы также добавим артефакт Supportpac W0AD, который будет использоваться для соединения WebSphere MQ Workflow и WebSphere Business Integration Server Foundation.
  • Добавьте устройства ( Devices ) или среды выполнения ( Execution Environments ), представляющие собой серверы промежуточного программного обеспечения, на которых будут размещаться эти артефакты.
    •

    5.7.1 Чего нет в базовой архитектуре

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

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

    5.8 Заключение

    В этой лекции рассматривались три этапа создания архитектуры системы:

  • Сведение воедино требований, предъявляемых к ИТ-архитектуре в Rational Software Architect. Эти требования поступают из модели процесса, созданной бизнес-аналитиком, из исходных бизнес-целей и ИТ-целей, а также создаются на семинаре по созданию модели бизнес-процесса.
  • Анализ требований для построения базовой архитектуры с помощью подхода Patterns for e-business Integration Design Approach.
  • Возврат в Rational Software Architect для фиксации базовой архитектуры в форме схемы размещения.
    •

    Следующий этап – это изучение деталей процесса и создание архитектуры решения на основе базовой архитектуры, взаимодействий и интерфейсов компонентов.

    Страницы:

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

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

    В лекции 6, "Архитектура решения", рассматривается дизайн решения и разработка архитектуры решения.

    5.1 Выбор архитектурных шаблонов

    Мы выполним шаги, приведенные на рис. 3.10, чтобы выбрать подходящий архитектурный шаблон для решения по работе с внешними оценщиками. Это весьма длительный процесс. Чтобы помочь вам сориентироваться, мы приводим ниже краткое описание этапов.

  • Шаг 0. Сбор требований.

    На этих предварительных этапах архитектор решения собирает требования, которые были зафиксированы на семинарах в сотрудничестве с бизнес-аналитиком. Максимально используя возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect, архитектор решения начинает создавать элементы решения, такие, как прецеденты использования, роли и компоненты, которые будут применяться в архитектурной модели.

  • Шаг 1. Выбор шаблона бизнес-интеграции.

    На первом этапе мы выбираем, какие виды шаблонов бизнес-интеграции мы будем использовать. Это оказывает существенное влияние на архитектуру решения. Нужна нам интеграция, ориентированная на данные или на процесс? Существует ли связь между пользователями и требованиями? Нужно ли включать в решение приложения партнеров?

  • Шаг 2. Выбор шаблона приложения.

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

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

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

  • Шаг 4. Применение связей с продуктами.

    Наконец, мы применяем к шаблону рабочей системы связи с продуктами (product mappings). При этом создается наша базовая архитектура, которую мы фиксируем, создавая схему размещения в Rational Software Architect. Базовая архитектура имеет несколько областей применения:

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

    Теперь мы можем вернуться к нашей работе. Предварительный этап, назовем его "шаг 0", состоит в сборе всех требований и изучении тех частей, которые нужно интегрировать друг с другом для создания решения для работы с внешними оценщиками.

    5.2 Шаг 0. Сбор требований

    Архитектор решения, совместно с бизнес-аналитиком, на семинарах занимается сбором требований и определением существующего и планируемого процесса изучения страховых претензий (см. раздел 3.2.2, "Области ответственности и разработка по контракту"). Материалы этого семинара в качестве требований использует архитектор системы.

    Хотя мы и не использовали Rational Requisite Pro для регистрации требований и интегрирования их в архитектурную модель в Rational Software Architect, вам все же следует принимать это во внимание. Это особенно полезно, если одной из задач директора по информационным технологиям является отслеживание требований. Инструмент Requisite Pro, если использовать его в сочетании с другими инструментами для управления изменениями, такими, как ClearQuest, дает ответы на следующие вопросы:

  • Какие требования в каком решении реализуются?

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

  • Каково будет влияние удаления какой-то возможности из решения?
  • На другие решения, которые могут зависеть от данного?
  • На дизайн и реализацию решения?
  • Какие части реализации мы теперь можем отбросить?
    •
  • Если менеджер ИТ-инфраструктуры решит изменить план обновлений, какое влияние это окажет на разрабатываемые решения?
  • Какие допущения лежали в основе выбранного плана обновлений?
  • Какие допущения остаются в силе?
  • Как они повлияют на новый план?

    • Мы собрали все требования в презентацию, которая была изучена руководителями-кураторами и другими членами команды. В следующих разделах мы даем общий обзор требований и показываем, как архитектор решений может использовать возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect для получения информации, необходимой для разработки базовой архитектуры для проектирования решения.

    5.2.1 Бизнес-цели

    Полное описание бизнес-целей компании LGI приводится в разделе 1.2, "Бизнес-цели". Ниже дается краткий обзор.

  • Уменьшение затрат на администрирование путем сведения к минимуму ручных операций, связанных с управлением оценкой претензий. Автоматизация управления оценкой претензий.
  • Повышение удобства для клиентов путем уменьшения административных задержек при обработке претензий. Осуществление мониторинга и управления всем процессом обработки претензий, включая задачи, выполняемые внешними оценщиками.
  • Максимальное повышение окупаемости затрат на разработку:
  • минимальное влияние на существующие системы;
  • простота разработки с использованием имеющихся навыков;
  • быстрая идентификация и устранение задержек в бизнес-процессе
    •

    5.2.2 Прецеденты использования, связанные с бизнесом

    При анализе требований, предъявляемых к процессу обработки претензий, было выявлено несколько прецедентов использования (use case). Мы можем применить Rational Software Architect для автоматической генерации визуального представления прецедентов использования, созданных по модели бизнес-процесса, которая была составлена бизнес-аналитиком при помощи WebSphere Business Integration Modeler.

    Иллюстрация приводится на рис 5.1.

    (рис 5.1) Прецеденты использования, связанные с работой с внешними оценщиками

    Прежде чем рассматривать применение Rational Software Architect для создания данной схемы, мы рассмотрим, как Rational Software Architect конструирует прецеденты использования из модели бизнес-процесса.

    Отображение модели бизнес-процесса в прецедентах использования

    Модель бизнес-процесса порождает разнообразные UML2-артефакты. На уровне абстракций каждая задача представлена в виде кооперации (collaboration). В решении для работы с внешними оценщиками есть две задачи, которые мы можем отобразить в виде коопераций в Rational Software Architect (рис 5.2 и рис 5.3):

    (рис 5.3) Кооперация ClaimInvestigation_TOBE(рис 5.2) Кооперация RequestExternalReports

    Специалист по обработке претензий (Claim Handler) – это единственный ресурс-роль, которую бизнес-аналитик использовал в высокоуровневом процессе ClaimInvestigation_TOBE. Автоматизированных задач здесь не было.

    С другой стороны, в процессе RequestExternalReports бизнес-аналитик определил наряду с ручными задачами, выполняемыми ролью Claim Handler, несколько ролей, выполняющих автоматизированные операции. Аналитик рассматривал оценщика (Assessor) как автоматизированную операцию.

    Следовательно, в соответствии с этими кооперациями есть только два прецедента использования, в которых задействуются ручные операции: роль Claim Handler, выполняющая процесс ClaimInvestigation_TOBE, и роль Claim Handler, участвующая в выполнении операции RequestExternalReports.

    Визуализация прецедентов использования в Rational Software Architect

    В Rational Software Architect существует несколько способов визуализации роли Claim Handler с созданием схем, напоминающих схему, показанную на рис 5.1. Мы рассмотрим здесь только два способа.

    Чтобы в Rational Software Architect можно было использовать модель WebSphere Business Integration Modeler, выполните следующие шагиДополнительная информация об интеграции WebSphere Business Integration Modeler и Rational Software Architect приводится в Приложении В, "Вопросы интеграции".

  • Импортируйте проект WebSphere Business Integration Modeler в Rational Software Architect. Используйте либо разработанный вами процесс, либо один из процессов, поставляемых в дополнительных материалах к этому курсу. Поскольку Rational Software Architect применяет рабочее пространство Modeler, вам нужно сделать в проекте, который вы хотите импортировать в Rational Software Architect, доступное рабочее пространство. Затем импортируйте проект ITSOLGI из рабочего пространства Modeler. Предположим, у вас есть рабочее пространство, называемое ExternalAssessors, а внутри него – проект ITSOLGI:

    Выберите пункт меню File (Файл) $$\to$$ Import (Импорт). Импортируйте в рабочее пространство существующий проект ( Existing WBI Modeler 5.1 project ), нажмите Next (Далее), затем Browse (Обзор), перейдите в рабочее пространство WebSphere Business Integration Modeler, выберите проект .\SG24-6636\Modeler\Workspaces\Pre Bpel\ITSOLGI, нажмите OK, затем Finish (Готово).

  • Сделайте двойной щелчок по файлу resources.xmi, чтобы увидеть модель WebSphere Business Integration Modeler:Важно! Никогда не изменяйте и не сохраняйте модель resources.xmi. Этот файл доступен только для чтения. Если вы сохраните версию этого файла как новую модель UML2 (файл .emx) с дополнениями и модификациями, вы потеряете возможность выполнять динамические обновления из WebSphere Business Integration Modeler. Эти инструкции позволяют вам создавать расширения модели и схемы на основе модели WebSphere Business Integration Modeler. Убедитесь, что вы случайно не добавили элементы в файл resources.xmi модели WebSphere Business Integration Modeler. Если в редакторе UML-модели закладка с файлом resources.xmi помечена звездочкой, это значит, что вы случайно внесли в модель изменения, которые вы не сможете сохранить. Для очистки изменений закройте проект WebSphere Business Integration Modeler в Rational Software Architect, нажав правую кнопку мыши и выбрав пункт меню Close (Закрыть). Затем откройте проект заново и устраните проблемы.
  • В качестве первого варианта создания схемы прецедентов использования, просто выполните обзор:
  • в проводнике по моделям (Model Explorer) (см. рис. 5.5) откройте пункт resources.xmi $$\to$$ ITSOLGI $$\to$$ RootProcessModel $$\to$$ Claim $$\to$$ Claim_TOBE.
  • щелкните правой кнопкой мыши по пункту Claim handler $$\to$$ Visualize (Визуализация) $$\to$$ Explore in Browse diagram (Изучить в схеме обзора).
    •
  • Во-вторых, создайте схему прецедентов использования как часть архитектурной модели:
  • Создайте новый проект для хранения архитектуры решения, выбрав пункт меню File (Файл) $$\to$$ New Project (Новый проект) $$\to$$ UML project (UML-проект) $$\to$$ ITSOLGI Architecture.
  • Установите опцию Blank Model template (Пустой шаблон модели) и снимите опцию Create a default diagram in the new model (Создавать схему по умолчанию в новой модели). Нажмите Finish (Готово).
  • Щелкните правой кнопкой мыши по пункту Blank Model (Пустая модель), выберите пункт меню Refactor (Реорганизация) $$\to$$ Rename (Переименовать) и введите имя Claim Investigation.
  • Щелкните правой кнопкой мыши по пункту Claim Investigation, выберите пункт меню Add Diagram (Добавить схему) $$\to$$ Use Case Diagram (Схема прецедентов использования) и введите имя Claim Investigation.
    • К этому моменту окно Model Explorer должно выглядеть так, как показано на рис 5.5.
  • Заполните схему прецедентов использования, чтобы показать связи, которые вам нужно задокументировать:
  • Перетащите роль Claim Handler из пакета Claim_TOBE в редактор пакетов Claim Investigation.
  • Щелкните правой кнопкой мыши по ).(рис 5.4) Отображение взаимосвязей роли Claim Handler
  • Приведите схему в порядок. Хорошей практикой является размещение элемента Claim handler в верхнем левом углу, поскольку естественный способ чтения прецедентов использования сверху вниз и слева направо, начиная от исполнителя роли.
    • (рис 5.5) Проект ITSOLGI в Model Explorer

    Прецеденты использования сами не хранятся в Rational Software Architect. Для управления документами прецедентов использования вы можете применить Rational Requisite Pro.

    Прецедент использования 1. ClaimInvestigation_TOBE

    Роль: Claim handler.

  • Выбор полиса и проверка данных, содержащихся в нем.
  • Ввод первоначальной оценки клиентом стоимости повреждений и генерация резерва на выплату.
  • Проверка истории претензии $$\to$$ Предупреждение $$\to$$ Претензии, превышающие 30000$.
  • Отправка внешнего запроса на подробную оценку повреждения (см. "Прецедент использования 2").
  • Проверка стороннего отчета об оценке.
  • Согласование выплаты с клиентом.
  • Инициирование выплаты или ремонта.
    •

    Прецедент использования 2. RequestExternalReports

    Роль: Claim handler.

  • Исполнитель роли Claim handler подключается к Business Process Manager.
  • Выбор претензии, ожидающей оценки.
  • Инициирование автоматизированного процесса оценки.
  • Выбор подходящего оценщика по почтовому коду и типу машины.
  • Отправка запроса о готовности к работе.
  • Ожидание подтверждения.
  • Выбор оценщика.
  • Запрос на оценку.
  • Ожидание получения отчета об оценке.
  • Возврат отчета об оценке исполнителю роли Claim handler.
    •

    5.2.3 Роли

    За полным описанием всех ролей обращайтесь к разделу 1.4, "Роли". Ниже приводится краткое описание.

  • Роли LGI:
  • Claim handler (Специалист по обработке претензий). Управляет претензиями.
  • Claims Supervisor (Эксперт по претензиям). Имеет право работать с исключительными случаями претензий.
  • Claims Analyst (Аналитик по претензиям). Следит за всем процессом обработки претензий с целью определения экономических параметров.
    •
  • Внешние роли:
  • Assessor (Оценщик) – производит оценку претензии

    • С помощью Model Explorer вы можете создать визуальное представление вовлечения ролей в процесс обработки претензий. Чтобы в Rational Software Architect создать схему, более подробно отображающую роли, создайте в проекте ITSOLGI Architecture схему свободного формата (freeform). Назовите ее Manual Roles и перетащите выбранные роли из модели WebSphere Business Integration Modeler [в Model Explorer выберите пункт ITSOLGI $$\to$$ RootResourceModel $$\to$$ Resources (Ресурсы) $$\to$$ Roles (Роли)]. Для выбора нескольких ролей используйте щелчок мышью при нажатой клави- ше Ctrl, после чего при нажатой левой кнопке мыши перетащите роли на схему, как показано на рис 5.6. На этой схеме показаны не только некоторые из определенных нами ролей, но и список операций, в выполнении которых участвует роль, поскольку бизнес-аналитик определил эти операции. Роли смоделированы функцией интеграции с WebSphere Business Integration Modeler в виде бизнес-сотрудников (Business-Workers). Если вы изучите свойства одной из этих ролей, вы увидите, что они являются стереотипами интерфейсов.

    (рис 5.6) Роли и операции в процессе ClaimInvestigation_TOBE

    Некоторые роли в исходных требованиях не были смоделированы (например Claim Analyst – аналитик претензий) и поэтому здесь отсутствуют. Есть и другие роли, которые применялись для моделирования автоматических задач и которые мы здесь опустили.

    5.2.4 Компоненты

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

    Чтобы создать в модели новые компоненты, выполните следующие шаги:

  • Откройте проект ITSO Architecture и создайте новую схему компонентов Claim Investigation Component Diagram.
  • Перетащите на схему компонентов роли Assessor, Assessor Management, Business Rules Engine и Document Handler.
  • Теперь создайте шесть новых компонентов с именами AssessorManagement, BusinessRulesEngine, AssessorSystem, ClaimsSystem, AssessorAutomation и ClaimsWorkflow. Сделать это можно прямо на схеме, щелкнув правой кнопкой мыши и выбрав пункт меню Add UML (Добавить UML) $$\to$$ Component (Компонент).
  • Соедините каждый интерфейс с соответствующим ему компонентом, создав реализующую взаимосвязь. Наведите курсор мыши на компонент и щелкните по маленькой стрелке, указывающей на прямоугольник. Перетащите его на соответствующий интерфейс и отпустите кнопку мыши. Выберите пункт Create New Implementation (Создать новую реализацию). Соедините компоненты AssessorAutomation и ClaimsWorkflow, как показано на рис 5.7. Мы можем использовать цвета, соответствующие схеме Pattern for e-business, и показать, что компонент Assessor System является частью другой организации.
    •  (рис 5.7) Схема компонентов Claims Investigation

    Когда мы выберем шаблоны Patterns for e-business, как будет описано позже в этой лекции, мы обнаружим, что нам нужно добавить в эту схему еще один компонент.

    Компонент AssessorSystem не является частью LGI, и для него нужен прокси-компонент, который мы назвали proxyAssessorSystem, который будет выполнять функцию посредника между LGI и оценщиками. Мы снабжаем этот новый компонент другим интерфейсом, отличным от того, который используется компонентом Assessor System. Интерфейсы не могут быть одинаковыми, поэтому это не прокси в общепринятом смысле этого слова. Его нельзя сгенерировать автоматически из реального интерфейса компонента AssessorSystem. Например, задача Request Availability запрашивает информацию о готовности у всех подходящих оценщиков, а каждый оценщик получает отдельный запрос о готовности. И конечно, запросы к оценщикам поступают в разные точки назначения с применением разных транспортных протоколов.

    Мы добавляем на схемы компонент proxyAssessorSystem и другую детальную информацию из готовой архитектуры. И все же компонентная архитектура не завершена, пока мы не установим связи для рабочей системы, используя шаблоны для электронного бизнеса, как это описано в разделе 5.5, "Шаг 3. Выбор и объединение шаблонов рабочей системы".

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

    Одним из достоинств Rational Software Architect является то, что он упрощает создание и изменение моделей, которые можно анализировать и критиковать до тех пор, пока не получится картина, с которой будут согласны все члены команды.

    Для завершения компонентной модели мы выполнили следующие шаги:

  • Были добавлены выполняемые вручную ролью Claim handler задачи, которые бы- ли разделены между системами процесса Claims Workflow и Automated Assessor.
  • В компоненты были добавлены предоставляемые и необходимые интерфейсы. Готовая схема компонентной модели показана на рис 5.8.
    •  (рис 5.8) Готовая схема компонентов для ClaimInvestigation_TOBE

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

    Существующие компоненты

    Существующие компоненты при создании нового решения должны изменяться как можно меньше.

    LGI Assessor Management System (Система управления оценщиками LGI)

    Эта система предоставляет информацию о каждом оценщике и о способах взаимодействия оценщиков с LGI.

    Данная система включает следующие операции:

  • Identify Assessor (Идентификация оценщика).

    По типу и почтовому коду области нахождения автомобиля, подлежащего оценке, операция Identify Assessor формирует список потенциальных оценщиков с контактной информацией.

  • Load/Register AssessorЭти операции не были включены в данный сценарий. (Загрузка/регистрация данных об оценщике).
  • Ranking AssessorЭти операции не были включены в данный сценарий. (Ранжирование оценщиков).
  • Record Selected AssessorЭти операции не были включены в данный сценарий. (Запись выбранного оценщика).
    •

    Сохраняет сведения о выбранном оценщике и возвращает данные об идентификаторе претензии и о самом оценщике.

    Claims Workflow (Рабочий поток претензий)

    Это существующий, выполняемый вручную процесс. Интересующей нас подзадачей является процесс изучения претензии. Специалист по обработке претензий (Claim handler) выбирает претензию, с которой он будет работать, получает внешние отчеты и завершает работу, устанавливая для претензии статус "готовность к принятию решения". Процесс изучения претензии содержит следующие операции:

  • Select ReportЭти операции не были включены в данный сценарий. (Выбор отчета).

    Специалист по обработке претензий выбирает претензию из своего списка.

  • RequestExternalReports (Запрос внешних отчетов).

    Теперь это автоматизированный процесс, который вызывает автоматизированный подпроцесс работы с внешними оценщиками и возвращает отчет оценщиков.

  • Update External ReportsЭти операции не были включены в данный сценарий. (Обновление внешних отчетов).

    Специалист по обработке претензий может получать другие внешние отчеты.

  • SetClaimStatusЭти операции не были включены в данный сценарий. (Установка статуса претензии).
    •

    В заключение для претензии устанавливается статус "готовность к принятию решения".

    Document Management System (Система управления документами)

    Система управления документами хранит все отчеты, сгенерированные в процессе работы с претензиями и полисами. Нас интересует только одна операция – Store the assessment report (Сохранение отчета об оценке).

    Новые и измененные компоненты

    Из существующих компонентов WebSphere MQSeries и Web Services Gateway создается корпоративная сервисная шина (enterprise service bus), обеспечивающая на основе служб передачу данных к компонентам решения.

    Новым компонентом является система бизнес-правил (Business Rules Engine, BRE). Мы не акцентируем внимание на способах использования BRE и применяемых в ней технологиях. Целью этого компонента является повышение удобства для пользователя через совершенствование взаимодействия с внешним оценщиком.

    Enterprise Service Bus (Корпоративная сервисная шина)

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

  • ProxyRequestAvailability.

    Данная операция, имея доступ к списку оценщиков и к данным об оценщиках, посылает каждому оценщику запрос о том, готов ли он к выполнению оценки. Запрос должен посылаться при помощи метода, согласованного с оценщиком (e-mail, EDI, Web-служба, страница браузера и т. п.).

  • ProxyRequestAssessment.

    Данная операция, имея доступ к данным о выбранном оценщике и к данным о претензии, посылает запрос об оценке претензии и сохраняет данные о под- тверждении запроса.

  • ProxyAssessorSendReport.

    Получает от оценщика отчет и сохраняет его.

    •

    Business Rules Engine (Система работы с бизнес-правилами)

    Это новый компонент, позволяющий настраивать процесс оценки в зависимости от задач бизнеса. К нему относятся следующие операции:

  • выбор времени оценки на основе типа полиса, имеющегося у клиента;
  • применение бизнес-правил для выбора оценщика из списка оценщиков.
    •

    5.2.5 Организационные и архитектурные ограничения

    За полным описанием целей и ограничений, связанных с ИТ, обращайтесь к разделу 1.3, "Цели и ограничения, связанные с ИТ". Ниже приводится краткое описание.

  • ИТ-политики:
  • Использование открытых стандартов;
  • Поддержка используемых каналов;
  • Создание общей инфраструктуры для LGI и DirectCar;
  • Повторное использование существующих приложений;
  • Установка новой инфраструктуры LGI.
    •
  • Ограничения, связанные с корпоративной инфраструктурой. Новые приложения должны использовать корпоративную LDAP-директорию для определений ролей и назначения их персоналу
  • Возможность выполнять оценку вручную при работе с особыми случаями
  • Поддержка разных систем, используемых оценщиками, включая доступ через браузер, электронную почту, EDI и Web-службы, работающие через HTTP и JMS.

    • 5.2.6 Границы решения

    Существует ряд аспектов решения, которые мы опустили из-за недостатка времени.

  • Моделирование данных.

    Мы упростили в данном решении использование данных. На практике моделирование данных с использованием модели промышленного стандарта, например ACCORD для страховой индустрии, является весьма существенной частью работы бизнес-аналитика и создает много проблем для всей команды проекта.

  • Безопасность.

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

  • Директория.

    Мы не реализовывали в масштабе решения директорию для работы с персоналом.

  • Пользовательский интерфейс.

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

    •

    WebSphere Business Integration Server Foundation не использует общие рабочие списки, и, если не проведена дополнительная работа, специалисту по обработке претензий приходится применять два окна для работы с двумя рабочими списками. Кроме того, специалист должен обеспечивать соответствие этих списков.

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

  • Мы не реализовывали мониторинг бизнес-событий для отслеживания обработки претензии.
  • Мы не реализовывали никаких функций системного управления для размещения и мониторинга.
    •

    Мы ограничили виды соединений с внешними оценщиками только протоколом SOAP/Http:. На практике продукты, используемые в качестве шлюза ESB, должны обрабатывать как минимум доступ через EDI, электронную почту и браузер.

    5.3 Шаг 1. Выбор шаблона бизнес-интеграции

    Теперь, когда архитектор организовал требования и понял природу и границы решения, первым этапом использования подхода Patterns for e-business является выбор шаблона Бизнес-интеграции. Выбор сводится к рассмотрению двух шаблонов:

  • Extended Enterprise (Расширение предприятия). Критериями выбора шаблона Extended Enterprise является следующее:
  • бизнес-процесс необходимо интегрировать с существующими бизнес-системами и данными;
  • бизнес-процессы нужно интегрировать с процессами и данными, существующими в организациях-партнерах.
    •  За дополнительной информацией обращайтесь по адресу: http://www-106.ibm.com/developerworks/patterns/b2bi/info.html
  • Application Integration (Интеграция приложений). Критериями выбора шаблона Application Integration является следующее:
  • бизнес-процесс необходимо интегрировать с существующими бизнес-системами и данными;
  • бизнес-процессы нужно интегрировать с процессами и данными, существующими в организациях-партнерах;
  • для работы бизнеса нужно объединять, организовывать и представлять информацию из различных источников как внутри организации, так и за ее пределами.
    • За дополнительной информацией обращайтесь по адресу http://www-106.ibm.com/developerworks/patterns/application/info.html

    На рис 5.9 и рис 5.10 курсивом в списках обозначены перекрытия между этими шаблонами. Использовать можно оба шаблона. Должны ли мы выбрать первый, второй или оба? Некоторые дополнительные инструкции приводятся на Web-сайте Patterns for e-business. И снова курсивом выделены перекрытия между шаблонами.

    (рис 5.10) Выбор элементов шаблона Extended Entity(рис 5.9) Выбор элементов шаблона Application Integration

    Мы не будем выбирать какой-то из этих шаблонов на этой стадии и продолжим использовать оба, а с перекрытиями разберемся при установлении соответствий для рабочей системы – раздел 5.5, "Шаг 3. Выбор и объединение шаблонов рабочих систем".

    5.4 Шаг 2. Выбор шаблона приложения

    Итак, для детализации у нас есть два шаблона бизнес-интеграции – Extended Enterprise и Application Integration. Шаблон Extended Enterprise будет наиболее полезен при проектировании архитектуры взаимодействий с оценщиками. Шаблон Application Integration будет полезен для интеграции нового решения для работы с внешними оценщиками, существующим рабочим потоком претензий, системой управления оценкой и претензиями.

    5.4.1 Кооперации

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

    Для изображения коопераций существующей и новой системы мы использовали стиль Patterns for e-business (P4EB).

    Воспроизведем на рис 5.11 существующий процесс оценки, который мы уже показывали ранее на рис 2.6.

    (рис 5.11) Ручной запрос отчетов у внешних оценщиков

    При использовании стиля [P4EB], если мы оставим в стороне приложения, лежащие выше системы обработки претензий, существующая система превращается в то, что изображено на рис 5.12.

    (рис 5.12) Кооперация [P4EB] ClaimInvestigation_ASIS

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

    На рис 5.13 показаны шаблоны Extended Enterprise и Application Integration, наложенные на планируемую систему.

    (рис 5.13) Кооперация [P4EB] ClaimInvestigation_TOBE

    Теперь нам нужно выбрать два шаблона приложения: один – для шаблона бизнес-интеграции Extended Enterprise, другой – для шаблона бизнес-интеграции Application Integration.

    5.4.2 Шаблоны приложений для Extended Enterprise

    Основное назначение той части решения, которая связана с шаблоном Extended Enterprise, – это связь с внешними оценщиками. На рис 5.14 показаны факторы бизнеса, на основании которых мы выбрали шаблон приложения Exposed Broker (Внешний брокер). Обратите внимание на столбец, относящийся к этому шаблону, который мы выделили линиями. Шаблон приложения Exposed Broker показан на рис 5.15.

    (рис 5.15) Выбор шаблона приложения Exposed Broker(рис 5.14) Шаблон приложения Exposed Broker

    Основными факторами, определившими выбор шаблона, явились следующие:

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

    Если процитировать информацию с сайта Patterns for e-business, этот шаблон наиболее хорошо соответствует нашим целям. Главный фактор, способствующий выбору данного шаблона приложения, состоит в том, что этот шаблон позволяет одному приложению взаимодействовать с одним или несколькими приложениями партнеров, находящихся за пределами организации. Использование звездообразной архитектуры, а не соединений "точка-точка", позволяет осуществить интеграцию приложений в единую систему при минимальной сложности. Запрос на получение информации может направляться в одну или несколько точек назначения или одновременно во многие точки. Получающееся сообщение-запрос может быть разделено (декомпозиция) на множество сообщений-запросов, а сообщения-ответы могут быть собраны в единое сообщение-ответ с использованием подходящих правил сборки (рекомпозиции).

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

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

    5.4.3 Шаблоны приложений для Application Integration

    Если изучить бизнес-факторы для шаблонов интеграции приложений на рис 5.17, становится ясно, что для поддержки вмешательства человека нам нужно выбрать шаблон Parallel Workflow variation (Вариант с параллельным рабочим потоком) (рис 5.16).

    (рис 5.17) Шаблон интеграции приложений Parallel Workflow variation(рис 5.16) Выбор шаблона Parallel Workflow variation

    Основные критерии для выбора данного шаблона были следующие:

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

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

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

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

    (рис 5.19) [SOA] Application Integration::Parallel Workflow variation::Runtime pattern(рис 5.18) [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). Это должно сделать интеграцию относительно простой.

    5.6 Шаг 4. Применение связей с продуктами

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

    5.6.1 Имеющиеся вложения в системы и продукты

    На рис 2.12 показана вся существующая ИТ-инфраструктура и инструменты, использованные для создания имеющейся системы обработки претензий. Существенными являются следующие аспекты:

  • объединенный поток претензий обрабатывается на WebSphere MQ Workflow, а компания DirectCar имеет систему работы с процессами WebSphere Application Server Enterprise;
  • ESB функционирует на WebSphere MQSeries и WebSphere Business Integration Message Broker, где два существующих соединения Web-служб с внешними поставщиками поддерживаются при помощи Web Services Gateway;
  • клиентская Web-часть и некоторые имеющиеся приложения для работы с претензиями функционируют как EJB на WebSphere Application Server.
    •

    5.6.2 Имеющиеся клиентские навыки и навыки разработки

    В компании LGI имеются довольно хорошие навыки работы с WebSphere MQSeries и WebSphere Application Server. Специалисты компании создавали приложения-Web-службы типа "точка-точка" и EJB-приложения. Они также создавали бизнес-процессы, используя WebSphere Business Integration Modeler 4.3.4 (продукт Holosofx, приобретенный IBM), и выполняли процесс на WebSphere MQ Workflow.

    5.6.3 Выбор, сделанный заказчиком

    Компания LGI желает разрабатывать больше приложений на основе открытых стандартов, таких, как Java 2 Enterprise Edition (J2EE), Web-службы и BPEL. В частности, специалисты компании хотят использовать данный проект для оценки инструментов и системы для разработки, управляемой моделями с применением UML и BPEL. См. раздел 1.3, "Цели и ограничения, связанные с ИТ".

    Выбранная платформа должна подходить к среде заказчика и обеспечивать качество обслуживания, в частности масштабируемость и надежность, чтобы решение могло расти вместе с бизнесом:

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

    5.6.4 Связи с продуктами

    На рис 5.23 дается общий обзор связей с выбранными продуктами.

    (рис 5.23) External Claim Assessor::Product Mapping

    Assessor Systems (Системы работы с оценщиками)

    Мы реализуем одну систему работы с оценщиками как EJB-компонент, работающий на WebSphere Application Server. К области ответственности оценщиков относится:

  • ответ на запрос о доступности;
  • ответ на запрос о выполнении оценки претензии;
  • отправка готового отчета об оценке.
    •

    Business Rules Engine (Система бизнес-правил)

    Система бизнес-правил представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за следующее:

  • за предоставление данных о времени обязательного ответа на претензию;
  • выбор оценщика для обработки претензии из списка доступных оценщиков.
    •

    Assessor Management (Система управления оценщиками)

    Создание списка оценщиков, потенциально способных выполнить оценку, на основе типа автомобиля и местоположения

    Claim System (Система обработки претензий)

    Система управления оценщиками представляет собой EJB-компонент, работающий на WebSphere Application Server и отвечающий за хранение отчета об оценке.

    Assessor Automation (Автоматизация работы с оценщиками)

    Система автоматизации работы с оценщиками представляет собой BPEL-систему, работающую на WebSphere Business Integration Server Foundation. Она отвечает:

  • за получение запроса на оценку претензии от системы управления потоком претензий
  • управление процессом создания отчета;
  • возврат отчета в систему управления потоком претензий.
    •

    Claims Workflow (Система управления потоком претензий)

    Система управления потоком претензий представляет собой FDL-систему, работающую на WebSphere MQ Workflow. Она отвечает:

  • предоставление специалисту по обработке претензий:
  • списка претензий для изучения;
  • списка претензий, прошедших к данному моменту оценку;
    •
  • отправку претензии в процесс Assessor Automation и ожидает окончания оценки.

    • ESB (Корпоративная сервисная шина)

    ESB – это сервисная шина, поддерживающая MQ, SOAP/JMS и SOAP/Http:. Она отвечает за отделение запросов к службам от транспортного протокола и физических адресов конечных точек.

    ESB Gateway (Шлюз ESB)

    Шлюз ESB – это службы, используемые сервисной шиной. Он отвечает:

  • за реализацию соответствующего стиля взаимодействия с каждым из оценщиков (SOAP/http, Web-службы, EDI, браузер и т. д.);
  • распределение запросов среди множества оценщиков;
  • сбор ответов от нескольких брокеров;
  • задание времени ожидания ответов;
  • обработку ответов, пришедших с опозданием.
    •

    Web services Gateway (Шлюз Web-служб)

    Шлюз Web-служб представляет собой демилитаризованную зону (DMZ). Он отвечает:

  • за реализацию функции прокси для адресов Web-служб между Интернетом и интранетом;
  • за ответы на автоматические запросы по предоставлению WSDL-интерфейсов клиентам Web-служб;
  • за обеспечение безопасности связи через Интернет.
    •

    5.7 Базовая архитектура

    На рис 5.24 показана базовая физическая архитектура, которую мы будем использовать в данном сценарии. Размещение моделируется в Rational Software Architect с использованием уже созданной компонентной модели.

    (рис 5.24) Схема размещения Claim Investigation
  • В Model Explorer выберите пункт ITSO Architecture $$\to$$ Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add Diagram (Добавить схему) $$\to$$ New Deployment Diagram (Новая схема размещения).
  • Перетащите компоненты на схему (для краткости опустим оценщиков и шлюз Web-служб), выделите их все и нажмите пункт Name Compartment Style (Стиль с отображением имени), чтобы отображались только имена компонентов, но не их атрибуты. (рис 5.24).
  • Добавьте следующие артефакты ( Artefacts ): хранилище архивов брокера (Broker Archive Repository, BAR), хранилище корпоративных архивов (Enterprise Archive Repository, EAR) и поток FDL (FDL flow), которые будут размещены в системе. Мы также добавим артефакт Supportpac W0AD, который будет использоваться для соединения WebSphere MQ Workflow и WebSphere Business Integration Server Foundation.
  • Добавьте устройства ( Devices ) или среды выполнения ( Execution Environments ), представляющие собой серверы промежуточного программного обеспечения, на которых будут размещаться эти артефакты.
    •

    5.7.1 Чего нет в базовой архитектуре

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

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

    5.8 Заключение

    В этой лекции рассматривались три этапа создания архитектуры системы:

  • Сведение воедино требований, предъявляемых к ИТ-архитектуре в Rational Software Architect. Эти требования поступают из модели процесса, созданной бизнес-аналитиком, из исходных бизнес-целей и ИТ-целей, а также создаются на семинаре по созданию модели бизнес-процесса.
  • Анализ требований для построения базовой архитектуры с помощью подхода Patterns for e-business Integration Design Approach.
  • Возврат в Rational Software Architect для фиксации базовой архитектуры в форме схемы размещения.
    •

    Следующий этап – это изучение деталей процесса и создание архитектуры решения на основе базовой архитектуры, взаимодействий и интерфейсов компонентов.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^