Описание: Обзор процесса проектирования бизнес-процессов и сервисов, соответствующих ролей и инструментов, а также технологических процессов, полезных для архитекторов программного обеспечения. Подчеркиваются преимущества объединения участников и сервисов в бизнес-процесс или сервис и приводятся примеры, демонстрирующие влияние различных моделей на инструменты, применяемые для создания развертываемых артефактов. Приводятся способы достижения хороших результатов даже с неполными моделями и излагается суть методов моделирования на SoaML, полезных при сборке процессов и сервисов.
Выбирайте шляпы и туфли
По мере роста предприятия и его адаптации к изменениям и технологическим новшествам архитекторам бизнес-процессов приходится постоянно анализировать и оптимизировать существующие решения. Вырабатывая новые стратегии автоматизации сервисов или совершенствования процессов и одновременно отслеживая бизнес-курс и добиваясь максимального повторного использования, архитекторы и разработчики сокращают дистанцию от требований до реализации, постоянно предлагая более эффективные, прослеживаемые, гибкие и полезные решения, поддерживающие интеграцию в бизнес и динамичную среду. С появлением IBM® Business Process Manager версии 7.5 и новых бизнес-ориентированных функций в IBM® Rational® Software Architect версии 8.0.4 разработчики программного обеспечения получили возможность выбирать и интегрировать в свои наборы инструментов новые "шляпы и туфли".
Построение бизнес-решения начинается с анализа текущих бизнес-процессов и поддерживающих их ИТ-сервисов. Затем определяют, какой подход лучше всего подходит для вступления на путь достижения бизнес-целей, выбирая сервис-ориентированную архитектуру или подход управления бизнес-процессами - то есть, продолжая метафору, за какой шляпой тянуться ― SOA или BPM, зная, что в течение жизненного цикла архитектуры и разработки понадобятся обе. Тому, кто носит шляпу архитектора, известны возможности инструментов, практические приемы и инфраструктура бизнес-среды, и он может анализировать недостатки и предложить стратегии проектирования решения. У разработчика богатый выбор туфель - технологий или инструментов - для того, чтобы, соблюдая требования, спроектировать решение и сохранять контроль над ним. Разработчикам может понадобиться хорошая пара туристических ботинок, когда они взбираются в гору, самые красивые туфли, когда они готовы сосредоточиться на пользовательском интерфейсе, или самые быстрые кроссовки, когда важно время выхода на рынок.
На обзорной схеме, представленной на рисунке 1, показаны инструменты, участвующие в обоих подходах, включая моделирование, реализацию, имитацию, внедрение и управление. Моделирование бизнес-процесса или сервиса начинается с Rational Software Architect: с помощью функции Process Designer инструмента Business Process Manager выполняются анализ и оптимизация, за которыми следует программирование заглушек с помощью инструментов преобразования Rational Software Architect и реализация с помощью модуля Integration Designer Business Process Manager. Готовое приложение или сервис развертывается на платформе Business Process Manager Process Server. Серверы и приложения могут храниться в Business Process Manager Process Center. Этот процесс иллюстрируется на рисунке 1.
При подходе SOA бизнес-мотивация и цели двигают проект решения вперед, определяя потребности и возможности, которые являются кандидатами на роль сервисов. Rational Software Architect используется для выявления бизнес-целей в виде примеров использования и определения стратегий их достижения в архитектуре сервисов, состоящей из участников, которые потребляют сервисы и предоставляют их. Отделяя интерфейс от реализации и тем самым улучшая приспособляемость предприятия, SOA позволяет ему стать более универсальным и распределенным, сохраняя возможность использования отдельных компонентов.
Совет:
приступая к проектированию SOA-решения с применением Rational Software Architect, создайте UML-модель с помощью шаблона проектирования сервисов, который снабжен инструкциями по каждому шагу процесса.
Архитекторы BPM сначала моделируют бизнес-процесс, выявляя задействованные ресурсы и инструменты, чтобы понять, где его можно усовершенствовать. Затем решение дорабатывается путем извлечения из таких объединений существующих и требуемых интерфейсов путем преобразования в сервисную модель. После этого структура решения детализируется в иерархии пакетов из участников и сервисов. BPM сближает модель процесса и его реализацию, позволяя создавать более гибкие решения и обеспечить прослеживаемость от исходных требований до обеспечения качества.
Совет:
приступая к разработке решения для управления бизнес-процессами (BPM) с применением Rational Software Architect, создайте проект BPMN с помощью шаблона процесса или шаблона взаимодействующих процессов, если нужно разработать несколько взаимодействующих процессов. Приступая к разработке решения с помощью IBM Business Process Manager Process Designer, создайте новое приложение процесса в Process Center и откройте его в Process Designer. Чтобы экспортировать модель Business Process Modeling Notation 2.0 (BPMN 2.0) в Rational Software Architect, вам понадобится Business Process Manager версии 7.5.1. (Process Designer версии 7.5 позволяет импортировать только модель BPMN 2.0).
При моделировании оба подхода часто переплетаются. Процесс как таковой можно рассматривать в качестве сервиса, и наоборот. Процесс состоит из действий, которые обращаются к сервисам; а каждый сервис можно представить в виде схемы действий или процесса. Используя подход SOA, архитектор может воспользоваться процессами BPMN для описания контрактов на обслуживание в архитектуре сервисов и показать, как участники потребляют и предоставляют услуги, указанные в этих контрактах. Модель BPMN, использующая подход BPM, может содержать ИТ-сервисы. В этом случае архитектор использует SoaML-модель для дальнейшей разработки действий процессов и интерфейсов сервисов. Такой ИТ-сервис все же может потребовать полного или частичного участия человека.
Независимо от подхода, если в решении используется взаимодействие участников, при обоих подходах SOA и BPM проектирование завершается и начинается сборка процесса или сервиса на языке моделирования SOA (SoaML), как указано на рисунке для продукта Rational Software Architect. Примеры, приведенные в этой статье, относятся к задаче сборки участников в SoaML-артефакте.
Сборка решения процесса или сервиса
Возможность собрать участников на стадии моделирования бизнес-ориентированной разработки дает проектировщику больше контроля над тем, каким из игроков назначить ту или иную роль в конкретной реализации. Участники предлагают свои услуги и запрашивают требуемые им услуги через порты. Порты снабжены интерфейсами сервисов, которые описывают доступные операции и их входные и выходные параметры. Все участники собраны на общей структурной схеме, объединяющей отдельных, составных или коллективных участников. Внутренняя структура последних состоит из экземпляров взаимодействующих участников, составляющих свойства коллективного участника.
В составной структуре порты экземпляров участников соединены каналами сервисов, по которым передаются взаимодействие между участниками. Эти экземпляры и каналы сервисов управляют инструментами преобразования UML-SOA в Rational Software Architect для создания артефактов реализации и определяют информацию о привязке при реализации собранного решения.
В другом решении для другого разрабатываемого процесса или сервиса могут использоваться некоторые или все те же участники или новые участники с другими реализациями, которые предоставляют те же интерфейсы для удовлетворения других бизнес-потребностей.
Преимущества сборки с помощью инструментов моделирования
Сборка участников с использованием инструментов моделирования, присутствующих в Rational Software Architect 8.0.4, делает эту задачу важным шагом в разработке процесса или сервиса и дает целый ряд преимуществ, как описано в следующих подразделах.
SOA- и BPM-архитекторы могут преобразовать полную модель сервисов в артефакты реализации и передать их разработчикам-специалистам по интеграции для продолжения жизненного цикла разработки SOA. До выхода Rational Software Architect 8.0.4 задача сборки участников решалась представителями обеих ролей; архитектор мог моделировать связи между собранными участниками, а разработчик-специалист по интеграции ― импортировать их в Integration Designer, вновь связывая части с помощью сведений о связях при каждом импорте. В версии 8.0.4 такое дублирование усилий исключается благодаря усовершенствованиям процесса преобразования.
Теперь Rational Software Architect преобразует собранных участников в процесс или SOA, создавая набор модулей Component Definition Language (SCDL), которые соединены друг с другом посредством сервиса Service Component Architecture (SCA) и импорта и экспорта ссылок, которые устанавливают надлежащие цели SCA-соединений и привязки импорта.
Собранные экземпляры участников представляют собой роли во взаимодействии или решении. В решении каждый экземпляр компонента доступен через порты, а его реализации представлены поведением в определении компонента в соответствии с формулировкой бизнес-целей.
Используя при моделировании процесс Rational Service-Oriented and Architecture (SOMA), решение уточняет бизнес-цели, приближаясь к реализации.
- Сначала сервисы, необходимые для достижения бизнес-целей, определяются с помощью ролей и взаимодействий.
- Затем определяются сервисы посредством интерфейсов и протоколов сервисов.
- Наконец, они реализуются в виде компонентов, портов и каналов сервисов.
На каждом этапе происходит дальнейшее уточнение спецификации.
Там где бизнес-процессы или требования указаны в форме сценариев использования и бизнес-моделей, идентификация сервиса принимает форму уточнения до конкретных ролей и взаимодействий. Те, в свою очередь, уточняются вплоть до контрактов на предоставление услуг и интерфейсов/ролей, а затем до сервисов и элементов поведения.
После всех этапов уточнения до завершения абстрактного определения сервиса или элемента поведения начинается стадия реализации посредством сборки участников. Эта задача сборки позволяет архитектору определить каналы связи между участниками и реализовать роль в процессе взаимодействия. Предоставляемый готовым участником сервис легко прослеживается назад до бизнес-требований или примера использования системы.
Возможность разработать модель сервиса от ее идентификации до сборки участников предоставляет разработчику свободу выбора решения на базе SOA, BPM или и того, и другого. Можно разработать архитектуру сервисов в UML, определяя сервисы, или процесс в BPMN-модели, иллюстрируя выполняемые действия и определяя потенциальные сервисы. В соответствии с этим подходом составной участник может рассматриваться как поставщик сервиса или процесса.
С точки зрения SOA примеры использования реализуются участником, предоставляющим простой интерфейс сервиса, или составным участником, содержащим экземпляры двух или более взаимодействующих участников.
С точки зрения BPM бизнес-процессы также могут быть простыми или составными. Простые реализуются одним участником, олицетворяющим предприятие или подразделение, тогда как составной процесс охватывает несколько подразделений или деловых партнеров.
Специалист по внедрению при рассмотрении компонентов целевой системы использует преимущества и BPM, и SOA. Если простой сервис или процесс можно реализовать посредством модуля Java Enterprise Edition (JEE) или процесса Business Process Execution Language (BPEL), то в составных решениях или процессах могут соединяться разные реализации. Эти реализации не только взаимозаменяемы в соответствии с предпочтениями разработчиков, но и часто заложены в инструментах. Преобразование UML-SOA приводит к BPEL-реализация участника, предоставляющего несколько сервисов, направляя запросы к соответствующим сервисам. Значение сборки UML видно по тому, как она интегрирует, распределяет и собирает нескольких участников, сервисов и технологий, создавая универсальные решения для предприятия.
Как работает преобразование в SOA
Возможность генерировать SCDL с надлежащими привязками элементов импорта из составного участника в модель SoaML при использовании Rational Software Architect 8.0.4 можно продемонстрировать на нескольких примерах, которые показывают, как работает алгоритм преобразования. Правильные преобразования - результат проверки каналов сервиса со стороны составного компонента, которому делегирована реализация предоставляемых сервисов. Для понимания некоторых результатов полезно объяснить, как работает алгоритм.
При преобразовании составного участника Rational Software Architect выполняет алгоритм преобразования, приведенный в листинге 1.
Если это составной участник, найти в его внутренней структуре экземпляры, делегированные его портами.Для каждого делегата экземпляра:Создать модуль SCA с компонентом SCDL и элементом экспорта.Найти все экземпляры участника, соединенные с экземпляром каналами сервиса.Для каждого экземпляра:Создать элемент импорта SCDL в текущем модуле и задать свойства привязки.Проверить тип экземпляра.Если он составной, вызвать преобразования сборки (рекурсивно).В противном случае создать модуль SCA с компонентом и элементом экспорта.
Алгоритм обходит каждого участника по дереву делегирования, проходя по соединениям и создает модули SCA. Рекурсия заканчивается, когда встречается простой участник без внутренней структуры; то есть интерфейсы больше не требуются.
Примеры
Чтобы проиллюстрировать внутреннюю работу преобразования и его ограничения, нужны примеры с объединениями, в которых не менее трех участников. Это должен быть составной участник и, по крайней мере, два участника взаимодействия, происходящего по одному сервисному каналу.
Снимки с экрана демонстрируют модель в Rational Software Architect до применения инструментов преобразования и сгенерированную структуру SCA в Integration Designer после преобразования. В данном случае, если из-за неправильной модели сборки преобразование приводит к странным результатам, пользователю Integration Designer предлагаются методы восстановления, позволяющие работать с этими артефактами.
Три SoaML-конструкции иллюстрируют успешные результаты преобразования смонтированных участников в IBM Integration Designer:
- Simple демонстрирует простейшее взаимодействие: два объединенных участника, один из которых предоставляет делегированный интерфейс;
- Nested демонстрирует вложенных составных участников. Каждый имеет в своем составе делегированный предоставленный интерфейс и двух объединенных участников;
- Double демонстрирует решение с двумя предоставленными интерфейсами. Оно может отражать бизнес-процесс с двумя точками входа или, скорее, SOA-решение, предоставляющее несколько сервисных интерфейсов.
Четвертый пример иллюстрирует текущее ограничение преобразования, связанное с принятием неполных сборок.
- NoDelegate демонстрирует эффект составных участников, но составной участник либо не предоставляет услуг, либо не передает полномочия ни одной из своих частей. Это неполная конструкция, и Rational Software Architect не подает никаких сигналов, так что архитектор передает результат разработчику. В этом примере содержатся методы, которые разработчик может использовать для завершения модели в Integration Designer.
Конечно, возможны и другие проекты. Например, для более сложных взаимодействий может потребоваться больше портов и сервисных каналов между участниками одного и того же процесса; можно представить себе реализацию с большей степенью абстракции, что приведет к более глубоким уровням вложенности, и, конечно, может быть больше участников и, следовательно, больше требуемых сервисов или процессов.
Простое взаимодействие двух участников
В этой модели два участника; первый своими UML-действиями вызывает реакцию второго. Принципы SoaML требуют минимизации сопряжений, поэтому все взаимодействие происходит между портами. Делегируемое соединение связывает внутренние порты с портом того же типа составного участника, тогда как сервисные каналы соединяют порты запросов с сервисными портами внутри структуры составного участника.
Рисунок 3. Сборка с простым взаимодействием
Преобразование UML-SOA в этой модели приводит к созданию модулей и библиотеки SCA. Каждый из модулей com.simple.Part1.Participant и com.simple.Part2.Participant содержит компонент и элемент экспорта. Первый модуль также содержит BPEL-реализацию поведения компонента и элемент импорта, указывающий на необходимые сервисы второго модуля. Элемент импорта имеет свойства привязки к модулю, а имена элементов экспорта указывают на элементы экспорта второго модуля (импорт в com.simple.part1.Participant привязан к экспорту в com.simple.part2.Participant).
Рисунок 4. SCA-компоненты простого взаимодействия
В этой UML-модели три участника: первый обращается ко второму, который, в свою очередь, обращается к третьему. В UML-модели две сборки: A1 и A2. A2 - это вложенная сборка, содержащая второго и третьего участников.
Рисунок 5. Сборка вложенных участников
Результат преобразования демонстрирует процесс рекурсии в алгоритме. Модули соответствуют участникам Participant, Participant2 и Participant3. Хотя в UML-модели пять участников, в результате преобразования создаются только три SCA-модуля. Целью сборки участников является задание свойств привязки для элементов импорта делегированных модулей, как в окне Integration Designer на рисунке 6.
Рисунок 6. SCA-компоненты вложенных сборок
В этой UML-модели два участника. Каждый из них предоставляет интерфейс, и каждый запрашивает другого. Именно здесь архитектор ощущает преимущества признания синергического эффекта от использования подходов BPM и SOA. BPM-архитектор разработал бы процесс, в котором имя составного участника отражало бы тот процесс, о котором говорят участники взаимодействия. Но в данном примере проект следует принципам эффективной сборки, и ко всем предоставленным интерфейсам внутри сборки, которые в противном случае не были бы связаны, добавляется делегируемый соединитель. Это напоминает SOA-решение: вместо одного процесса создается набор интерфейсов. Проектировщик в шляпе SOA выглядит щеголем, а тот, что в шляпе BPM, нервно курит в сторонке. Но не выбрасывайте шляпу BPM ― она облегчит понимание преобразования.
Рисунок 7. Сборка нескольких сервисов
Увеличенный вариант рисунка 7.
После преобразования составного участника UML результирующий модуль SCA содержит SCDL-модуль для каждого участника композиции. Каждый модуль содержит привязку элемента импорта к элементу экспорта другого. Этот результат может вызывать недоумение архитектора SOA, потому что он по-прежнему состоит из двух модулей, по одному на каждый процесс, что соответствует стилю BPM.
Рисунок 8. SCA-компоненты нескольких сервисов
Примечание.
Эти примеры иллюстрируют процессы и предоставляемые сервисы только на уровне интерфейса. Теоретически каждый интерфейс может обеспечить несколько операций. Однако в интерфейсе решения в стиле BPM должен быть только один метод, представляющий процесс, в то время как в SOA участник может реализовать несколько методов, предоставляя их все в одном интерфейсе или в отдельных интерфейсах. Если бы архитектор SOA предпочел видеть в сгенерированной модели SCA один модуль, то он, используя обоих участников, создал бы нового, который предоставляет любое количество сервисов, и поместил всех троих в четвертого составного участника. Затем два первоначально открытых интерфейса он соединил бы каналами сервисов с третьим участником.
Результирующая модель SCA будет иметь оригинальные конструктивные блоки, как в первом примере двойного делегирования, плюс новый модуль, который импортирует то и другое.
Рисунок 10. SCA-компоненты с использованием нескольких сервисов
Увеличенный вариант рисунка 10.
Модель UML собирает участников посредством простого сценария, но без делегирования.
В соответствии с инструкциями шаблона моделирования сервисов, составной участник должен создать делегируемый соединитель для всех предоставленных интерфейсов, которые в противном случае не были бы подключены к запрашиваемому порту. Этот пример показывает, что происходит, если модель не завершена.
Рисунок 11. Сборка без делегирования
Преобразование создает модули конструктивных блоков для каждого участника сборки, а также отдельный составной модуль, но не генерирует надлежащие элементы импорта в собирающем модуле. В результате реализации компонента располагаются в сборке, а не в своих собственных модулях, поэтому такого процесса следует избегать. Лучше оставить компоненты разъединенными. Не помещайте их в сборку до тех пор, пока не будете готовы делегировать сервис конкретной реализации.
Рисунок 12. Неэкспортируемые SCA-компоненты
Если у вас нет доступа к оригинальной модели, чтобы добавить делегирование или удалить участника сборки, существуют другие подходы, позволяющие исправить модуль в Integration Designer.
На данный момент в Rational Software Architect 8.0.4 сгенерированы три модуля:
- com.noDelegate.Part1.Assembly
Содержит два компонента и один элемент экспорта. Связь с элементом экспорта отсутствует, потому что в UML-модели не было делегирования. Один из компонентов имеет реализацию BPEL в своем представлении SCDL, указывая на файлcom/noDelegate/Part1/Participant.bpel, которого в этом модуле не существует. SCDL компонента содержит следующий код:
<implementation xsi:type="process:ProcessImplementation"> <scdl:implementationQualifier xsi:type="scdl:Transaction" value="global"/> <process bpel="com/noDelegate/Part1/Participant.bpel"/> </implementation> |
- com.noDelegate.Part1.Participant
Содержит компонент без реализации в своем SCDL, элемент экспорта с интерфейсом типа com.noDelegate.Part1.ServiceInterface и элемент импорта с интерфейсом типа com.noDelegate.Part2.ServiceInterface2. Однако в привязке не указан целевой модуль/элемент экспорта. В каталоге com/noDelegate/Part1 находится файл BPEL.
- com.noDelegate.Part2.Participant
Содержит компонент и элемент экспорта.
Как и следовало ожидать, преобразование создает набор модулей-конструктивных блоков, но также генерирует модуль для сборки составного участника. Этот модуль пытается собрать имеющиеся конструктивные блоки, а не импортировать ссылки на них. Это приводит к тому, что реализации компонентов в конечном итоге оказываются не в нужном месте.
Нужно решить, хотите ли вы скрыть конструктивные блоки в модуле сборки, выбрав работу с модулем com.noDelegate.Part1.Assembly, или сохранить их, работая с модулями com.noDelegate.Part1.Participant и com.noDelegate.Part2.Participant.
Метод сборки компонентов внутри модуля - это метод сверху вниз, похожий на составление компонента каркаса в UML. Построение каркаса противоречит принципам повторного использования модулей, и это можно делать только в том случае, если части никогда не должны выходить за пределы целого, что устраняет необходимость создания отдельно развертываемых компонентов. Построить объединение с помощью метода снизу вверх ― значит выполнить шаги, которые совершило бы преобразование при правильно построенной UML-модели. Конструктивные блоки остаются неизменными и не входят в монтируемый модуль сборки.
Выполните шаги согласно выбранному методу, чтобы завершить объединение в ID.
Обходной путь методом "сверху вниз"
Модуль сборки, состоящий из связанных внутренних компонентов.
- Переместите BPEL из модуля com.noDelegate.Part1.Participant в модуль com.noDelegate.Part1.Assembly. Можно скопировать всю иерархию папок из представления Navigator. Убедитесь, что файл ParticipantArtifacts.wsdl скопирован в ту же папку, что и BPEL.
- Очистите и восстановите модуль com.noDelegate.Part1.Assembly. Убедитесь, что BPEL расположен правильно, дважды щелкнув на компоненте на схеме сборки. Это приведет к открытию схемы BPEL.
- Исправьте новые ошибки в свойствах компонента, как указывают маркеры ошибок. Снимок с экрана, показанный на рисунке 13, иллюстрирует правильные свойства интерфейса и ссылки.
Рисунок 13. Свойства интерфейса в исправленном компоненте
Рисунок 14. Свойства интерфейса в исправленном компоненте
- Соедините элемент экспорта с предоставленным интерфейсом.
- Удалите следующие модули:
- com.noDelegate.Part1.Participant
- com.noDelegate.Part2.Participant
Оставьте конструктивные блоки - участников взаимодействия - вне сборки и сошлитесь на них с помощью элементов импорта в модуле сборки. В данном примере единственный конструктивный блок ― это необходимый сервис, реализованный в com.noDelegate.Part2.Participant. com.noDelegate.Part1.Participant - это модуль, который импортирует конструктивный блок. Модуль com.noDelegate.Part1.Assembly не нужен.
- Скопируйте тег реализации из компонента первого модуля в компонент второго модуля.
- Удалите первый модуль, com.noDelegate.Part1.Assembly.
- Создайте новый модуль с именем
com.noDelegate.Assembly, к которому присоединены SCA-компонент и элемент экспорта SCA. - Добавьте сведения о привязке к элементу импорта во втором модуле, com.noDelegate.Part1.Participant. Результат будет выглядеть как на рисунке 4 "SCA-компоненты простого объединения" в первом примере.
Теперь составной модуль SCDL готов. Можно продолжить реализацию конструктивных блоков или компонентов сборки. По завершении реализации можно сделать ее развертываемой как Web-сервис, сгенерировав привязку Web-сервиса в элементе экспорта и развернув модуль на сервере процессов.
Принципы моделирования SoaML
Чтобы максимизировать повторное использование и минимизировать сцепление при сборке участников, следуйте рекомендациям из статьи Джима Амсдена "Моделирование с помощью SoaML, часть 4. Создание сервисов"
- Собирайте участников с помощью ссылок на составных участников, перетаскивая их на общую структурную схему для создания экземпляров участников.
- Моделируйте возможности и потребности участников через порты запросов и сервисов, а не посредством прямых связей участника с интерфейсами сервиса.
- Во внутренней структуре составных участников используйте каналы сервисов между портами сервисов и запросов экземпляров участников для завершения реализации сервиса или процесса, представленного составным участником.
- Ведите определения участников и модели сборки как отдельные задачи. Определения компонентов находятся на уровне классов, а сборок ― на уровне экземпляров.
- Для сборки участников используйте участников, а не подсистему, которая ограничивает возможность повторного использования вложенных участников.
- Составной участник должен иметь, по крайней мере, одно делегированное соединение между открытым сервисом и портом экземпляра внутреннего участника. Все оставшиеся неподсоединенными порты на общей структурной схеме следует делегировать портам составного участника.
Заключение
Моделирование сервис-ориентированной архитектуры упрощает разработку процесса или сервиса при совершенствовании или реализации бизнес-процессов. Сборка процессов и сервисов в составе бизнес-решения ― это задача архитектора, которая решается в Rational Software Architect. До появления версии Rational Software Architect 8.0.4 архитектору рекомендовали пропустить этот шаг сборки при моделировании в SoaML и передать задачу разработчику для выполнения связей между участниками после импорта созданных артефактов в ID.
Начиная с версии Rational Software Architect 8.0.4, эффективнее соединить компоненты на стадии моделирования разработки процесса. Это обеспечивает большую гибкость при проектировании, предоставляя инструменты как архитекторам BPM, так и архитекторам SOA. Продукты получаются более универсальными и предоставляют архитекторам и разработчикам возможность более гладкой интеграции с сохранением прослеживаемости проектных решений в продолжение всей эволюции моделирования и реализации сервисов.
В этой статье используются простые модели для демонстрации того, как преобразование UML-SOA создает SCA-модули, компоненты, элементы импорта и экспорта, а также определяет свойства привязки импорта для элементов импорта, сгенерированных из требуемых интерфейсов. Предложены методы завершения сборки SCA в Integration Designer, когда невозможно найти SCDL-реализации и свойства элементов импорта. Даны практические рекомендации по сборке участников с помощью SoaML, извлеченные из статей developerWorks.