MDD

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

Уровень сложности: простой

IBM developerWorks, IBM developerWorks, IBM

05.2007

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

Эта глава основывается на сценарии, описанном в гл. 2, «Общий обзор сценария». В этой главе представлен общий обзор процесса, используемого для моделирования служб сервисной шины предприятия (Enterprise Service Bus, ESB) и для генерации соответствующих артефактов. Процесс касается следующих элементов:

• архитектуры ESB;
• контрактов на поведение;
• шаблонов интеграции.

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

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

7.1 Связь с планом проекта

Если мы соотнесем эту главу со структурой проекта, определенной на рис. 4-1, то в ней мы будем говорить больше о проекте разработки инструментария для MDD, чем о промежуточном программном обеспечении или проекте бизнес-приложения. В разд. 7.9, «Использование каркаса», мы рассматриваем некоторые аспекты применения каркаса, но совершенно не углубляемся в проект разработки бизнес-приложения.

В разд. 7.2 («Общий обзор проектирования шаблонов») - 7.7( «Дополнение исходной модели шаблонами служб») рассматриваются первые три шага разработки инструментов MDD, показанной в разд. 4-3, «Планирование MDD-проекта». На рассматриваемом примере показано, как анализируются бизнес-проблемы, как определяется архитектура решения и как выбираются шаблоны, определяющие модель дизайна.

В разд. 7.8, «Трансформации RSA»,описанытрансформации.Вэтомразделепоказан», описаны трансформации. В этом разделе показан более простой подход, чем тот, который приведен на рис. 4-3- Цепочка инструментов, показанная на рис. 4-3, предполагает, что существует две трансформации: одна - от модели дизайна к компонентам, независимым от среды исполнения, а другая - от компонентов, независимых от среды исполнения, к компонентам, зависимым от нее. Этот случай является более общим, но в примере, который используется в этой книге, предполагается, что определена одна среда исполнения и переход осуществляется от модели дизайна прямо к компонентам среды исполнения.

В начало

7.2 Общий обзор проектирования шаблонов

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

На самом высшем уровне мы можем создать в RSA категории шаблонов, которые определяют:

• архитектуру ESB (1), описывающую структуру ESB (архитектура рассматривается в разд. 7.3, «Архитектурные шаблоны»);
• контракты на поведение (2), описывающие взаимодействие служб (например, запрос или обновление) (об этом рассказывается в разд. 7.4, «Контракты на поведение»);
• шаблоны интеграции, описывающие, как выполняются взаимодействия для каждого контракта на поведение (3) (см. разд. 7.5, «Интеграционные шаблоны»).

В данном примере мы создадим в Rational Software Architect (RSA) шаблоны кооперации ESB, которые генерируют модель кооперации ESB (4) (см. разд. 7.6, «Применение шаблона для создания высокоуровневой модели»).

Шаблоны кооперации ESB в RSA содержат по одному шаблону из каждой категории (1), (2) и (3), изображенной на рис. 7-1. Не все комбинации этих шаблонов являются допустимыми. Следовательно, мы будем реализовывать в RSA шаблон для каждой допустимой комбинации шаблонов этих трех категорий.

Повторное использование

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

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

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

В начало

7.3 Архитектурные шаблоны

Один из абстрактных высокоуровневых шаблонов определяется архитектурой ESB. Данная реализация ESB представляет всю интеграционную функциональность в виде служб. Для обозначения такого архитектурного стиля мы используем термин сервисно-ориентированная интеграция (SOI).

На верхнем уровне архитектура такой ESB определяет следующие элементы шаблона:

• тип службы;
• ограничения интерфейса;
• шаблоны допустимых вызовов;
• архитектурные ограничения.

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

• требования к проверке;
• требования к авторизации;
• требования к трансформации;
• отчет об ошибках;
• сбор контрольной информации.

Типы служб

В ESB разрешается использовать следующие типы служб:

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

Ограничения интерфейса

• Фасады интеграционной службы должны поддерживать одиночные операции.
• Интерфейсы Document Web Services должны иметь литеральный стиль.
• Все внешние взаимодействия должны быть полностью определены на языке Web Services Description Language (WSDL).

Шаблоны допустимых вызовов

Этот шаблон вводит архитектурные ограничения, состоящие в том, что все запросы и ответы, идущие между ESB и внешними приложениями, должны проходить только через службы фасадов и их возвратные службы. Прямой доступ к интеграционным службам и службам-утилитам не допускается. Этим обеспечивается соответствие архитектурным принципам на границе, а также отсутствие необходимости в проверке данных внутренними интеграционными службами и службами-утилитами. Фасады также обеспечивают преобразование данных в формат Enterprise Canonical Data Format (ECDF) перед вызовом внутренних служб.

К дополнительным ограничениям шаблонов допустимых вызовов относятся следующие:

• Службу-утилиту (US) может вызвать любая ESB-служба.
• Фасады интеграционных служб (ISF) являются клиентами только одной интеграционной службы (IS).
• Ответы по асинхронному шаблону возвращаются в возвратную службу (callback, СВ), а не самому клиенту.
• Интеграционные службы могут обращаться к фасадам поставщиков (provider facade, PF) напрямую или вызывать другие интеграционные службы, которые, в свою очередь, вызывают одну или несколько служб-фасадов поставщика.
• Фасады поставщика могут вызывать только одного внешнего поставщика. Если при получении данных возникает необходимость в оркестровке, выполняется несколько запросов, но фасад поставщика должен обращаться только к одной функции.

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

В начало

7.4 Контракты на поведение

Мы кратко описывали контракты на поведение в гл. 2, «Общий обзор сценария». В этой главе мы рассмотрим контракты на поведение для данного ESB-сценария.

Шаблоны контрактов на поведение определяют стили взаимодействий и особенности служб. Мы предлагаем для нашего примера с ESB пять базовых шаблонов:

• синхронный запрос информации с ограниченным временем ожидания;
• синхронное обновление с подтверждением/уведомлением об ошибке и ограниченным временем ожидания;
• асинхронный запрос информации;
• обновление с асинхронным ответом/уведомлением об ошибке;
• асинхронное одностороннее обновление с управляемой обработкой ошибок.

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

Эти контракты на поведение не реализуются напрямую как шаблоны RSA,нооб, но объединяются при генерации шаблонов первого уровня, реализуемых в RSA,собщимшаб, с общим шаблоном архитектуры ESB, измененным в соответствии с конкретными интеграционными функциями.

Пример, используемый в этой книге, основывается на синхронных запросах на обновление, и данный контракт на поведение подробно описывается в разд. 7.4.1, «Контракт на поведение для синхронных обновлений».

7.4.1 Контракт на поведение для синхронных обновлений

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

Мы используем этот шаблон, поскольку наиболее типичным для Web-служб является синхронный протокол HTTP. Хотя этот протокол по своей природе ненадежен, что делает его малоподходящим для обновлений из-за возможного появления неопределенных состояний, он все же широко применяется. Ответственность за выход из неопределенного состояния определяется в требованиях, и вспомогательным средством здесь является ведение журнала.

Применение

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

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

7.4.2 Общие требования к синхронному обновлению

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

Если мы рассмотрим весь сквозной шаблон, то мы увидим, что он состоит из трех частей:

• Исходный отправитель запроса. Это приложение-клиент, отправляющее запрос.
• Посредники. Это ESB-службы.
• Оконечный поставщик. Это приложение или приложения-поставщики.

Требования, которые предъявляются к каждому из этих элементов, описываются в следующих подразделах.

Требования к отправителю запроса

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

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

Единственными отправителями запросов в нашем сценарии являются клиентские приложения. Контракт на поведение делает именно эти приложения, а не ESB, ответственными за восстановление после ошибок и истечения срока ожидания.

Требования к посредникам

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

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

Требования к поставщику

• Немедленно возвратить сообщение об ошибке, если запрос недопустим или не прошел авторизацию.
• Обработать запрос.
• Возвратить результат.
• Дополнительно записать результат в журнал в соответствии с конфигурацией.

На рис. 7-7 показано взаимодействие между фасадом поставщика ESB и серверной службой-поставщиком.

В начало

7.5 Шаблоны интеграции

Базовый шаблон ESB изменяется в соответствии с типом оркестровки, выполняемой интеграционной службой. Мы называем это шаблонами интеграции (рис. 7-8).

Не всегда бывает возможным указать полный набор шаблонов, охватывающих все возможное поведение интеграционных служб. Если следовать знакомой схеме 80/20, то желательно определить набор шаблонов, в которые можно вносить дополнения по мере появления новых требований, и не тратить слишком много сил на достижение полного охвата к конкретному моменту времени.

Шаблоны на этом уровне соответствуют интеграционным шаблонам приложения для электронного бизнеса. Первый набор интеграционных шаблонов для ESB в данном сценарии будет следующий:

• Запрос на получение информации из одного источника. При желании можно перенаправить запрос на альтернативную службу-поставщика.
• Выполнение обновления в одном источнике. При желании запрос можно перенаправить на альтернативную службу-поставщик или в указанные файлы.
• Запрос на получение информации из нескольких источников. Чтобы получить один результат, нужно объединить данные.
• Распространение обновления на несколько источников на основе содержимого сообщения.
• Последовательность вызовов нескольких интеграционных служб или поставщиков (через фасад поставщика):
• каждый этап определяется результатом предыдущего вызова;
• окончательный ответ комбинируется изо всех ответов.
• Публикация и управление подпиской.
• Обработка файлов:
• обработка каждой записи;
• рассылка проверенных и трансформированных записей источникам на основе маршрутизации, зависящей от содержания.
• Объединение и разделение записей, полученных из разных источников.

В начало

7.6 Применение шаблона для создания высокоуровневой модели

Четвертый шаг в процессе применения шаблонов, которые показаны на рис. 7-1, - это объединение шаблонов кооперации для создания RSA-моделей кооперации нужных нам служб (см. рис. 7-9).

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

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

7.6.1 Шаблон

При выборе высокоуровневых RSA-шаблонов ESB мы можем сделать следующие допущения:

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

RSA-шаблон ESB, выбранный для нашего примера, показан на рис. 7-10 (КПЗ = контракт на поведение, 3). В этом шаблоне показана комбинация базовых шаблонов служб, используемых в ESB, и контракт на поведение - синхронное обновление.

7.6.2 Модель

Когда выбранный RSA-шаблон ESB применяется к кооперации, создается модель кооперации служб. В этой модели используются диаграммы классов и стереотипы из профиля UML 2/0 для программных служб. За подробностями обращайтесь по адресу http://www.ibm.com/developerworks/rational/library/05/419_soa/

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

Фасад интеграционной службы

• Служба.
• Клиент службы (делает запрос к одной интеграционной службе).
• Поставщик службы (обрабатывает запросы от внешнего поставщика).
• Связь «один к одному» (1:1) с интеграционной службой.
• Наложено ограничение - выполнение контракта КПЗ, если играет роль клиента.
• Наложено ограничение - выполнения контракта КПЗ, если играет роль поставщика.
• Наложено ограничение - связь только с клиентами и поставщиками, поддерживающими контракт КПЗ.

Интеграционная служба

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

Фасад поставщика

• Служба.
• Клиент службы (делает запрос к одной интеграционной службе).
• Поставщик службы (обрабатывает запросы от внешнего клиента).
• Связь с внешним клиентом по схеме «один к одному».
• Наложено ограничение - выполнение контракта КПЗ, если играет роль клиента.
• Наложено ограничение - выполнение контракта КПЗ, если играет роль поставщика.
• Наложено ограничение - связь только с клиентами и поставщиками, поддерживающими контракт КПЗ.

Внешний клиент

Внешний клиент включен в модель для генерации тестовых заглушек:

• клиент службы;
• связь по схеме «один к одному» с фасадом интеграционной службы;
• ограничения не используются.

Внешний поставщик

Внешний поставщик включен в модель для генерации тестовых заглушек и для определения интерфейса внешнего поставщика:

• Поставщик службы
• Связь по схеме один-к-одному с фасадом поставщика
• Ограничения не используются

Способы создания моделей

Модель, показанная на рис. 7-11, является отправной точкой для дальнейшего конфигурирования. Модель - это часть инструментария, и ее можно создавать одним из двух способов:

• выбрать из набора моделей, созданных в соответствии с высокоуровневыми шаблонами, и скопировать выбранную модель;
• реализовать шаблон RSA, который можно применить к кооперации, и создать модель, которая связывает компоненты служб в кооперации.

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

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

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

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

В данном примере шаблоны обеспечивают применение (или повторное использование) к модели только одного высокоуровневого шаблона.

В начало

7.7 Детализация первоначальной модели шаблонами служб

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

К этому моменту модель должна содержать информацию в соответствии с выбранным архитектурным стилем, т. е. SOI и подробной архитектурой ESB. Стандартный профиль UML 2.0 для программных служб не содержит необходимых стереотипов, и поэтому определяется новый профиль (SOI Example Profile).

Данный профиль содержит стереотипы для решения следующих задач:

• Идентификация всех возможных действий в диаграммах деятельности для ESB-служб. Каждый тип операции имеет свой собственный стереотип.
• Хранение атрибутов, определяющих поведение службы. Например, операция по трансформации имеет атрибут transformationID, который определяет трансформацию, которую должна применить служба трансформации.
• Идентификация параметров, в соответствии с которыми будет осуществляться генерация службы. Например, стереотип «Optional» имеет атрибут булева типа «generate», который определяет, будет ли эта операция использоваться при генерации службы. Стереотип «Generate» имеет атрибут булева типа, который определяет, является ли данная служба генерируемой, или же это ссылка на существующую службу.
• Идентификация параметров, определяющих и направляющих поведение службы в целом. Например, стереотип <<Integration service Facade>> определяет версию службы и используемый уровень журналирования.

Примечание. Наиболее важная информация о службе - определение ее интерфейсов - хранится в профиле UML 2.0 для программных служб.

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

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

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

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

7.7.1 Шаблоны служб: диаграммы деятельности

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

Функции служб-фасадов (и их возвратные функции, если применяются асинхронные шаблоны) предназначены:

• для обеспечения выполнения архитектурных ограничений на границах ESB;
• обработки взаимодействий между ESB и внешними приложениями, а также между ESB-службами

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

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

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

Во многих случаях шаблон интеграции подразумевает переменное число соединений между службами и переменное число шагов, что позволяет создать RSA-шаблон, который можно применять однократно или многократно, для создания либо обновления диаграммы активности. Это вполне работоспособная альтернатива созданию набора диаграмм деятельности. Интеграционные службы, используемые в нашем примере, были перечислены в разд. 7.5, «Шаблоны интеграции». В этой главе подробно рассматривается только одна из них - синхронное обновление в одном источнике.

Фасад интеграционной службы

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

В нашем примере поддерживается синхронное обновление, и шаблон для фасада интеграционной службы показан на рис. 7-14- Соответствующая диаграмма активности этого фасада приведена на рис. 7-15.

Фасад поставщика

Фасад поставщика находится между интеграционной службой ESB и внешним поставщиком. Если служба-поставщик генерируется по модели, как в нашем сценарии, то диаграмму деятельности нужно прикрепить к компоненту службы в исходной модели. Шаблон фасада поставщика, используемый в нашем примере, показан на рис. 7-16, вместе с соответствующей диаграммой активности, показанной на рис. 7-17.

В описанных выше шаблонах и моделях учитывались контракты на поведение, архитектура ESB и выполняемая интеграционная функция. Однако есть еще один важный фактор, который нужно учесть в ESB. Это обработка специальных требований, предъявляемых к интерфейсам конкретных внешних приложений.

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

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

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

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

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

7.7.2 Интеграционные службы

Интеграционная служба, используемая в нашем примере, поддерживает обновление в одном источнике, которое осуществляется путем вызова маршрутизирующей службы с указанием начальной буквы фамилии покупателя (рис. 7-18, 7-19).

В начало

7.8 Трансформация RSA

Последний этап создания каркаса MDD для нашего примера ESB - это создание трансформаций, использующих информацию, содержащуюся в моделях служб для генерации кода и других артефактов (рис. 7-20).

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

• имел четкую структуру;
• соответствовал необходимым стандартам;
• был хорошо инструментирован (well-instrumented);
• хорошо работал;
• максимально использовал промежуточное программное обеспечение, поддерживающее каркас Web-служб (в данном примере).

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

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

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

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

7.8.1 Реализация фасада интеграционной службы

Фасад интеграционной службы сам по себе является Web-службой. Он имеет WSDL-интерфейс и поддерживает одиночные операции со значениями document для style и HTTP для binding (Примечание: Style и binding - элементы описания WSDL-интерфейса). Ожидается, что все клиенты будут посылать запросы, соответствующие этому интерфейсу.

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

Класс реализации

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

Примечание. В более общем случае для обеспечения уникальности имен служб требуется управление правилами именования.

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

Метод принимает один аргумент - тело запроса в виде закодированной строки (альтернативой может быть аргумент типа XMLDocument). Десериализация тела входящего SOAP-запроса в объекты Java представляет собой серьезный удар по производительности, если только это не является необходимым для класса реализации. Однако функции фасада посреднические. Фасад на основе тела сообщения в форме XML выполняет проверку и трансформацию, прежде чем выполнить запрос к следующей службе.

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

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

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

Любые запросы к EJB и классам-утилитам, где необходимо тело сообщения, передаются в виде строк (и снова вариантом может быть XMLDocument).

Проверка

Проверка выполняется путем вызова службы-утилиты при помощи EJB-связывания. Для нашего примера реализована простая служба. Интерфейс принимает тело сообщения как XMLDocument, а соответствующий URL определяет схему, по которой производится проверка. Служба-утилита вызывает Xerces.

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

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

Трансформация

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

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

Поиск адреса

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

Вызов интеграционной службы

Все интеграционные службы в ESB реализованы с использованием связываний EJB, и они принимают один параметр - XMLDocument.

Запись событий в журнал

Для некоторых контрактов на поведение очень важно, чтобы конкретные события при обработке запроса заносились в журнал, чтобы в случае истечения времени ожидания ответа клиента служба поддержки приложения могла увидеть эти события.

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

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

В нашем примере ведение журнала является упрощенным, и данные выводятся на консоль.

7.8.2 Реализация интеграционной службы

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

7.8.3 Реализация фасада поставщика

Служба провайдера в нашем примере разрабатывается в полном соответствии с высокоуровневым дизайном, показанным на рис. 7-21.

Интерфейс Web-служб

Интеграционная служба - это либо вызов Web-службы через JMS (асинхронные или однонаправленные запросы), либо вызов EJB. Служба имеет WSDL-интерфейс и поддерживает одиночные операции.

Класс реализации

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

Примечание. В более общем случае для обеспечения уникальности имен служб требуется дополнительное управление привилами именования.

Метод принимает один аргумент - тело запроса в виде закодированной строки (альтернативой может быть аргумент типа XMLDocument). Десериализация тела входящего SOAP-запроса в объекты Java представляет собой серьезный удар по производительности, если только это не является необходимым для класса реализации. Однако функции фасада - посреднические. Фасад на основе тела сообщения в форме XML выполняет проверку и трансформацию, прежде чем выполнить запрос к следующей службе.

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

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

Любые запросы к EJB и классам-утилитам, где необходимо тело сообщения, передаются в виде строк (и снова вариантом может быть XMLDocument).

Трансформация

Трансформация ответов из форматов внешних поставщиков в ECDF выполняется путем вызова службы трансформации с EJB-связыванием. Интерфейс принимает два параметра - тело сообщения в форме XMLDocument и используемую трансформацию в виде соответствующего URL. Как и в случае фасадов интеграционных служб, эти трансформации могут включать Java-классы, вызываемые через XSLT

Поиск адреса

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

Вызов внешнего поставщика

Все внешние поставщики вызываются как Web-службы с полностью определенным WSDL-интерфейсом. При вызовах, обращенных за пределы CIB, XML-документы и строки не принимаются.

Запись событий в журнал

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

В начало

7.9 Использование каркаса

Пока в данной главе мы уделяли основное внимание вопросам, с которыми сталкиваются разработчики MDD-каркаса для ESB-служб. Эти задачи решаются в начале проекта и требуют таких важных знаний и навыков, как

• работа с платформами и промежуточным программным обеспечением;
• проектирование программного обеспечения;
• знание предметной области;
• UML-моделирование и работа с технологиями Rational;
• стандарты моделирования.

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

Разработчики служб должны знать следующие концепции:

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

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

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

7.9.1 Представление информации, содержащейся в модели, пользователям

Если мы вернемся к сценарию, описанному в гл. 2, «Общий обзор сценария», то здесь есть головная группа, принимающая решения по внедрению разработки, управляемой моделями, которая сразу ставит вопрос о необходимых навыках перед ГТ-груп-пой подразделения. Проблема состоит не в навыках, которые требуются для ESB-раз-работки, поскольку выработка таких навыков является частью первоначальных вложений, которые должны окупиться экономией средств в нескольких проектах.

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

Предлагаются следующие варианты

• Познакомить с навыками моделирования все IT-группы подразделений и сделать их обязательными для всех поставщиков, которые выполняют интеграционные проекты. Дальнейшая работа идет напрямую в инструментах для моделирования, хотя при этом она ограничена применением шаблонов и трансформаций в точном соответствии с инструкциями по ESB.
• Ограничить требования к навыкам моделирования пониманием моделей, для чего нужно дать пользователям возможность увидеть структуру ESB и представления шаблонов ESB. Взаимодействие с пользователем в данном случае осуществляется через управляемый пользовательский интерфейс; при данном подходе модели видимы для пользователей, создающих службы.
• Снять с пользователей все требования по пониманию методик моделирования и управлять работой при помощи настроенного пользовательского интерфейса, дающего возможность пользователям, генерирующим службы, работать главным образом в той области, где они понимают данные, участвующие в запросах и ответах, а также выполняемые бизнес-операции.
• Определить параметры, необходимые для генерации разных типов служб и разрешить создавать службы без прямого взаимодействия с пользователем. Похоже на шаг назад - к редактированию файлов и определению конфигурационных данных, но это фактически можно делать и в сочетании с другими вариантами. Вы можете комбинировать этот вариант с предыдущими, зафиксировав конфигурационные данные и сгенерировав файл, который будет направлять неинтерактивную генерацию служб с различными вариациями.

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

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

7.9.2 Создание службы

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

1. Понять, какое событие запускает вызов службы
• определить прецедент использования.
2. Определить данные, используемые в службе:
• схема сообщений клиента и поставщиков;
• WSDL-определение службы;
• трансформации.
3. Выбрать интеграционный шаблон и создать модель кооперации, выбрав соответствующий RSA-шаблон.
4. Сконфигурировать отдельные службы через пользовательский интерфейс.
5. Сгенерировать и протестировать каждую службу.

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

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

В начало

7.10 Заключение

В этой главе мы изучили, как применить нашу методологию к синхронному обновлению в соответствии с интеграционным шаблоном обновления одного целевого источника в рамках общей архитектуры ESB. Особое внимание мы уделили анализу сценария и тому, как применяется методология. Это была имитация на бумаге того, что мы хотим обсудить теперь. А обсудить мы хотим встраивание расширений для автоматизации в Rational Software Architect для реализации определенных нами шаблонов.

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

Об авторе

		команда developerWorks работает над созданием полезных материалов для разработчиков

Выскажите мнение об этой странице

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