В четырех предыдущих статьях серии (см. врезку "Другие статьи серии" вверху слева) мы использовали бизнес-анализ для идентификации значимых для бизнеса сервисов ("Моделирование SOA. Часть 1. Идентификация сервиса"), необходимых для решения бизнес-задач и достижения бизнес-целей. Затем мы создали спецификации сервисов и использовали протоколы ("Моделирование SOA. Часть 2. Создание спецификации сервиса"), необходимые для решения ИТ-задач. Затем мы создали проектные модели предоставления и использования сервисов ("Моделирование SOA. Часть 3. Реализация сервиса," "Моделирование SOA. Часть 4. Компоновка сервиса"). В результате мы получили технологически-нейтральную, но законченную модель архитектурно смоделированного решения сервиса. В данной, заключительной, статье серии мы поговорим о практическом создании реализации, согласованной с архитектурными и проектными решениями, документированными в модели сервиса. Мы сгенерируем реализацию для конкретной платформы, воспользовавшись принципом управляемой моделями разработки и функцией преобразования UML-SOA из программного пакета IBM Rational Software Architect для создания Web-сервиса из SOA-модели.
В предыдущих статьях мы создали законченную модель SOA-решения, удовлетворяющую бизнес-требованиям. Следовательно, нам известно, каким требованиям удовлетворяет архитектура решения и что необходимо будет изменить, если эти требования изменятся.
Чтобы осуществить развертывание и запустить Web-сервис, необходимо создать практическую реализацию, которая согласуется с архитектурными и проектными решениями, документированными в модели. Мы моли бы создать такое решение вручную, воспользовавшись в качестве направляющей схемы моделью решения. Но чтобы обеспечить корректную реализацию архитектурного решения, потребовалось бы много времени и высокая квалификация разработчика; при этом работа была бы утомительной и мы вряд ли смогли бы избежать ошибок. Безусловно, создать решение вручную можно, и модель была бы весьма полезна в качестве направляющей схемы решения. Но наличие законченной, формальной, верифицированной модели дает нам возможность использовать принцип управляемой моделями разработки (model-driven development, MDD), чтобы создать один или более скелетов решения из модели, а затем закончить решение, написав детализированный код в платформенно-специфичной среде программирования. Именно об этом мы поговорим в данной статье. Мы воспользуемся функцией преобразования UML-SOA из программного пакета IBM® Rational® Software Architect для создания решения Web-сервиса, которое можно будет непосредственно использовать в IBM® WebSphere® Integration Developer для реализации, тестирования и развертывания готового решения.
Как и в остальных статьях серии, мы будем использовать инструменты IBM Rational и IBM WebSphere для создания артефактов решения и привязки их друг к другу, чтобы можно было проверить соответствие решения требованиям и более эффективно управлять изменениями. В таблице 1 перечислены все процессы , которые мы будем использовать при разработке примера, а также инструменты, которые будут использоваться для создания артефактов.
Таблица 1. Роли, задачи и инструменты процесса разработки
| Роль | Задача | Инструменты |
|---|---|---|
| Бизнес-исполнитель | Формулирование бизнес-задач и целей | IBM® Rational® RequisitePro® |
| Бизнес-аналитик | Анализ бизнес-требований | IBM® WebSphere® Business Modeler |
| Разработчик архитектуры программного обеспечения | Разработка архитектуры решения | IBM Rational Software Architect |
| Разработчик Web-сервисов | Реализация решения | IBM® Rational® Application Developer и IBM WebSphere Integration Developer |
Давайте начнем с пересмотра сервисов и участников сервисов, созданных в предыдущих статьях.
Пересмотр спецификации сервисов, требований и анализ использования.
На рисунке 1 показаны спецификации сервисов, которые были идентифицированы как необходимые для выполнения бизнес-требований. Это те сервисы, которые могут выполнять роли в контракте о бизнес-требованиях к сервису.
На рисунке 2 показана модель данных сервиса. Это модель информации, которой обмениваются потребители и поставщики сервиса; она используется для определения параметров операций сервиса.
Рисунок 2. Модель данных сервиса
Сервис планирования Scheduling
На рисунке 3 показана законченная спецификация сервиса Scheduling.
Рисунок 3. Спецификация сервиса планирования Scheduling
Эта спецификация сервиса представляет собой простой интерфейс, потому что в ней нет ни одного интересующего нас протокола, необходимого для использования сервисов планирования. На рисунке 4 изображена схема поставщика, который предоставляет сервис Scheduling.
Рисунок 4. Поставщик сервиса Productions
Практические реализации поведений requestProductionScheduling и sendShippingSchedule (соответственно, деятельности и непрозрачного поведения) подробно не показаны на диаграмме, но в модели они определены.
На рисунке 5 показана спецификация сервиса доставки ShippingService.
Рисунок 5. Спецификация сервиса ShippingService
Спецификация этого сервиса немного сложнее, потому что она моделирует взаимодействие между оператором доставки и оператором заказов в форме простого взаимодействия в стиле обратного вызова. На рисунке 6 изображена схема поставщика, который предоставляет сервис ShippingService.
Рисунок 6. Поставщик сервиса Shipper
Непрозрачное поведение requestShipping, являющееся методом для предоставляемой операции requestShipping, вызывает processSchedule на порту доставки в определенной точке данной реализации. Потребители, подключающиеся к этому порту, должны предоставить реализацию данной операции, которая могла бы дать ответ на запрос.
На рисунке 7 показана спецификация сервиса InvoicingService.
Рисунок 7. Спецификация сервиса InvoicingService.
Данный протокол также является чуть более сложным. Он задает определенный порядок использования функциональных возможностей сервиса. Предполагается, что потребитель и поставщик будут следовать этому протоколу. В данном случае одна из деятельностей используется для определения протокола сервиса.
На рисунке 8 показана схема поставщика сервиса, предоставляющего сервис InvoicingService и методы, предоставляющие функциональные возможности сервиса.
Рисунок 8. Реализации сервиса Invoicer 
И наконец, на рисунке 9 показана спецификация сервиса приобретения Purchasing:
Рисунок 9. Спецификация сервиса приобретения Purchasing.
Интерфейс этого сервиса представляет собой функциональную возможность, определенную в исходном бизнес-процессе "Обработка заказов на приобретение". Он также представляет сервис, идентифицированный и разработанный на основе данного бизнес-процесса.
На рисунке 10 показана схема поставщика сервиса, предоставляющего сервис Purchasing, а также сервисы, которые он запрашивает для обеспечения своей функциональности.
Рисунок 10. Поставщик сервиса OrderProcessor.
На рисунке 11 показан метод для операции сервиса processPurchaseOrder , использующий UML-деятельность.
Рисунок 11. Реализация операции сервиса processPurchaseOrder
Данная диаграмма очень похожа на диаграмму IBM WebSphere Business Modeler для этого же поведения. В данном процессе операции сервиса InvoiceProcessing и ScheduleProcessing реализуются через операции регистрации событий Accept Event processInvoice и processSchedule. Обратите внимание на то, что соответствующие операции в интерфейсах обозначены как операции <<trigger>>, это отражает их способность отвечать на действия AcceptCallActions (аналогично приемкам и AcceptEventActions, где триггером является событие SignalEvent). Ключевое слово <<trigger>> не поддерживается унифицированным языком моделирования версии 2.0 (Unified Modeling Language 2, UML 2); оно используется только для того, чтобы сделать понятнее реализацию операций. Обратите внимание на то, что эти операции не будут приняты до тех пор, пока выполняется деятельность processPurchaseOrder и пока поток управления не выполнит две операции Accept Call. Это говорит о том, что данная реализация операции способна определить получение ответов на другие операции.
Передовые методы моделирования сервисов
Моделирование с использованием UML 2 способствует лучшему пониманию систем, лежащих в основе реализации, что позволит нам абстрагироваться от посторонних деталей. Моделирование ни в коем случае не является панацеей, а для создания и понимания качественных диаграмм моделей по-прежнему необходимы специальные знания. Это естественное следствие необходимости поддерживать весьма общую модель вычислительной среды, которую можно использовать в широком диапазоне прикладных предметных областей и уровней абстракции; помимо этого моделирование представляет семантические схемы нескольких платформенно-специфичных моделей исполнения. Кроме того, возможно, придется ограничить типы операций или стилей в моделировании деятельностей, чтобы обеспечить эффективное преобразование таких моделей в целевую платформу выполнения.
В нашем случае целевой платформой является технология Web-сервисов и модель программирования IBM SOA, поддерживаемая средой WebSphere Integration Developer. Она включает бизнес-объекты (XSD), интерфейсы (WSDL), сборки модулей (SCDL, предшественник SCA от IBM), процессы (BPEL), SCDL (бизнес-формы конечных автоматов) и Java™компоненты. Чтобы обеспечить поддержку преобразований UML-моделей для конкретной платформы Web-сервисов, нам придется использовать некоторые передовые методы моделирования сервисов. То есть сначала нам нужно настроить UML для моделирования архитектуры SOA-решения, а затем придется использовать определенный стиль моделирования, чтобы нашу модель можно было транслировать в Web- сервисы.
Обычно настройка UML осуществляется при помощи профилей. Профиль определяет несколько стереотипных классов, способных дополнить один или более метаклассов UML дополнительными свойствами или ассоциациями. Чтобы эти дополнения стали доступными, мы применяем профили к UML-модели. Как правило, эти профили в управляемой моделями архитектуре используются с двумя целями:
- Первое, и самое распространенное использование профилей - это настройка абстракций, поддержку которых планируется обеспечить. В данном случае мы применили профиль программирования сервисов IBM Software Services к модели "Обработка заказов на приобретение", чтобы дополнить UML средствами поддержки моделирования сервисов. Многие из стереотипов данного профиля просто делают более прозрачным использование метаклассов UML в SOA-решении и ограничение использования возможностей UML; это позволяет гарантировать, что SOA-модели будут отражать принципы архитектуры SOA. Например, стереотип
<<serviceConsumer>>используется для того, чтобы указать UML-компонент, моделирующий пользователя сервисов, который сам по себе никаких сервисов многократного использования не предоставляет. Такой компонент может представлять бизнес-процесс, не предполагающий многократного использования. Пример ограничения: профиль Software Services требует, чтобы все интерфейсы, реализуемые или используемые компонентом<<serviceProvider>>обрабатывались не напрямую, а через порты сервиса. Это делается для того, чтобы уменьшить связанность между подключившимися пользователями и поставщиками за счет создания взаимозависимостей с портом сервиса, а не с компонентом в целом. В дальнейшем при изменении какого-либо интерфейса проверку на влияние этого изменения необходимо будет провести только для данного порта, а не для всех объектов, подключенных к этому компоненту;
- Еще одно назначение профилей в управляемой моделями архитектуре (MDA) - это поддержка платформенно-специфичной разметки. Такие разметки состоят из дополнительных стереотипов и свойств, которые "размечают" модель информацией, необходимой для перевода модели на конкретную платформу. Например, для некоторого UML-пакета при переводе в контейнер Web-сервиса может потребоваться наличие унифицированного идентификатора ресурса Uniform Resource Identifier (URI).
В некоторых ситуациях эти две цели сочетаются. Например, расширение для поддержки моделирования реляционных данных для UML состоит из одного профиля, который одновременно дополняет UML средствами моделирования данных ERA (реляционные атрибуты сущности) и предоставляет разметку, необходимую для перевода моделей предметных областей UML в логические модели данных IBM® Rational® Data Architect (модели LDM). Профиль IBM Software Services предоставляет эту сдвоенную роль для моделей, которые преобразуются в Web- сервисы.
В остальных случаях один профиль может использоваться для поддержки моделирования, а другой - для поддержки преобразования. Для примера рассмотрим случай моделирования SOA-решений, которые предполагается реализовать в среде Java™ 2 Platform, Enterprise Edition (J2EE). Последнюю задачу можно выполнить, применив профиль Software Services и профиль преобразования Enterprise Java™ Beans (EJB) к одной и той же модели. Стереотипы профиля Software Services будут применены к элементам модели для поддержки моделирования сервисов, тогда как стереотипы профиля преобразования EJB будут применены к элементам модели - для проведения преобразования UML-EJB программного пакета Rational Software Architect в процессе генерации кода реализации. Безусловно, эту же SOA-модель можно преобразовать в Web -сервисы при помощи инструмента преобразования UML-SOA из пакета Rational Software Architect. Преобразование UML-SOA сгенерирует Web-сервисы, отключив разметку профиля Software Service. Это инструмент проигнорирует разметку для преобразования EJB.
В следующем разделе описываются некоторые передовые методы для SOA-моделей, которые предполагается транслировать в Web-сервисы, а именно в Web- сервисы, реализованные в модели программирования IBM® SOA и поддерживаемые инструментом WebSphere Integration Developer.
Параметры операции сервиса должны иметь либо один из примитивных типов, либо тип данных <<message>>. Разработчики моделей не должны делать никаких допущений о размещении данных, семантике call-by-value (вызов по значению) или call-by-reference (вызов по ссылке), или о каких-либо неявных функциях управления параллелизмом. Предположим, что наша реализация сервиса работает с недокументальной копией данных, которые можно передавать и/или преобразовывать из исходного источника этих данных. Этим достигается минимальная связанность между пользователями и поставщиками сервиса.
По определению профиля IBM Software Services, компонент поставщика сервисов должен реализовать или использовать интерфейсы не непосредственно, а через порты сервиса. Благодаря этому обеспечивается оптимальная разъединенность между потребителями и поставщиками сервиса, подключенными к этому компоненту.
Реальный поставщик сервиса моделирует методы своих операций сервиса посредством указания поведения для каждой операции.
Примечание
Реальный поставщик сервиса - это компонент, который нельзя отнести ни к абстрактным компонентам, ни к компонентам <<specification>> .
Допускается использование любого поведения, но если целевой платформой модели является платформа Web-сервисов, удобнее использовать деятельность, которая легко может быть транслирована в BPEL WebSphere. Модель деятельности, показанная на рисунке 11, является собственным поведением компонента поставщика сервиса Order Processor , который является методом для операции processPurchaseOrder. В отношении этой деятельности необходимо объяснить некоторые моменты :
- Сигнатура поведения метода должна соответствовать его операции в спецификации;
- Точки входов и выходов операции должны следовать в определенном порядке, от правого нижнего угла содержащей их операции по часовой стрелке до правого нижнего угла. Этот порядок точек присоединения соответствует порядку параметров вызываемой операции, в котором целевая входная точка является первой точкой присоединения, а тип операции (если указан) является последней выходной точкой присоединения, которая соответствует возвращаемому результату. Целевая входная точка обозначает объект назначения, которому передается запрос операции (например, классификатор, являющийся владельцем операции);
- Типы входной и выходной точек присоединения обычно не заданы, потому что могут быть получены из соответствующих параметров;
- Эта деятельность не использует потоки объектов для облегчения создания диаграммы. Вместо этого имена входных и выходных точек присоединения операций маркируются именами параметров, переменных или структурных функций в контекстном классификаторе (классе, являющемся владельцем деятельности) в области действия. UML 2 поддерживает оба варианта, поэтому использование любого из них - это вопрос предпочтения разработчика модели;
- Узлы параметров деятельности (в левом и правом углах деятельности) не используются. Вместо этого параметры деятельности (которые должны соответствовать параметрам своей операции согласно спецификации) при необходимости ссылаются непосредственно на входные и выходные точки присоединения. Узлы параметров деятельности используются в том случае, если используются потоки объектов;
- Секции деятельности могут изображать порты сервиса или элементы компонента, в котором содержится деятельность. Через эти элементы производятся все вызовы и регистрируются все события. В этом случае секции не именуются, поскольку изображаемые ими свойства предоставляют достаточную информацию для идентификации секции;
- Целевые входные точки присоединения действия вызова операции указывать не нужно. В качестве альтернативы секции деятельности могут изображать порты сервиса, на которых инициируются вызовы в этих секциях. В UML 2 такие секции называются экземплярами секций <<instance>> и имеют хорошо очерченную семантику. Допускается указывать целевые входные точки присоединения, но это может оказаться избыточным;
- Точка присоединения
returnInformationдействия Accept Call обрабатывается так же, как целевая входная точка действия операции вызова. Она также является портом, изображаемым секцией деятельности, и точкой взаимодействия, через которую регистрируется вызов;
- Выражения присваивания показаны при помощи непрозрачных действий, в которых имя действия содержит выражение присваивания, ссылающееся на переменные, параметры и структурные функции в области действия. Операторы
lvalueиrvalueв выражении присваивания разделяются символами:=("двоеточие" + "знак равенства");
- Защитными выражениями для объекта и потоков объектов называются булевы выражения Java или XPath , ссылающиеся на переменные, параметры и структурные функции в области действия деятельности:
- На данные в потоке объектов ссылаются по имени потока;
- Тип данных в потоке объектов определяется по его источнику.
Эти соглашения используются для того, чтобы упростить моделирование деятельностей и диаграммы деятельностей и лучше сопоставить их с кодом BPEL, который будет сгенерирован на их основе.
Преобразования требуют использования конфигурационных файлов.
Настройка конфигурации преобразований
Для настройки преобразования необходимо выбрать из меню команды File > New > Other > Transform Configuration (рисунок 12).
Рисунок 12. Создание конфигурации преобразования
Для этого примера мы воспользуемся преобразованием UML-SOA, как показано на рисунке 13.
Рисунок 13. Выбор преобразования UML-SOA 
Настройка конфигурации большинства преобразований состоит из трех основных этапов:
- Выбора исходных элементов преобразования;
- Выбора (либо создания, а потом уже выбора) целевых элементов;
- Настройки свойств преобразования.
Допустимые исходные элементы определяются конкретным преобразованием, которое вы выбрали. Как правило, рекомендуется выполнять преобразование всей модели, а не ее отдельных частей. Этим гарантируется, что модели, представляющие собой отдельные версии ресурсов, будут считаться единицами компиляции по отношению к преобразованию модели. Такая ситуация упрощает управление моделями и обработку зависимостей преобразованием благодаря обеспечению соответствия изменений в ресурсах в рабочей области изменениям постановщика и преобразования, которые необходимо обработать для того, чтобы гарантировать синхронизацию извлекаемых артефактов с соответствующими исходными элементами. Например, не рекомендуется выбрать отдельный метод в Java -классе и скомпилировать только этот метод, а затем вставить его в байт коды для остального класса. Было бы невозможно управлять таким процессом в быстро изменяющейся среде, и это потребовало бы, чтобы вы, а не компоновщики и компиляторы, были осведомлены обо всех взаимозависимостях, компиляцию которых необходимо выполнить после того, как произошли изменения.
В данном примере модель "Обработка заказов на приобретение" является источником, а мы создаем новый простой проект Eclipse в качестве целевого объекта. В этом проекте мы разместим все элементы модели (рисунок 14).
Рисунок 14. Настройка конфигурации источника и цели преобразования
Параметры конфигурации преобразования представляют собой настройки преобразования, которые обычно не подходят для разметки в модели. Они, как правило, управляют общими настройками, а не настройками, которые применяются к отдельным элементам модели. Преобразование UML-SOA имеет всего несколько настроек, показанных на рисунке 15.
Рисунок 15. Настройка конфигурации свойств преобразования
Если установить для свойства "Process UML elements without stereotypes" значение True, то это будет означать, что использование профиля IBM Software Services фактически будет необязательным. Типы данных, компоненты и деятельности будут преобразованы в решение Web-сервиса, не требуя применения стереотипов <<message>>, <<service>> или <<serviceProvider>> ; возможно, что эти стереотипы не будут применены к конкретным элементам модели, которым не нужны их дополнительные свойства.
На этом конфигурация преобразования модели PurchaseOrderProcess в решение Web-сервиса, которое будет размещено в проекте PurchaseOrderProcessWorkspace, закончена.
Выполнение преобразования PurchaseOrderProcess2WebServices не отличается сложностью:
- Выберите конфигурационный файл преобразования PurchaseOrderProcess2WebServices.tc, созданный в предыдущем разделе;
- В раскрывающемся меню выберите команды Transform > UML-to-SOA.
Выбранное преобразование выполняется с заданными настройками конфигурации, при этом исходная модель преобразуется в артефакты Web-сервисов, а результаты преобразования размещаются в проекте PurchaseOrderProcessWorkspace.
Совет:
Если в модель будут внесены изменения, то вам потребуется выполнить это преобразование еще раз.
Результаты преобразования показаны на рисунке 16 в представлении Modeling обозревателя проектов Project Explorer.
Рисунок 16. Результаты преобразования 
При настройке конфигурации преобразования UML-SOA необходимо указать целевой проект, в котором будут размещены все получаемые артефакты. Этот проект представляет собой простой проект Eclipse, который содержит либо проекты библиотек WebSphere Integration Developer, либо проекты модулей, как говорилось в предыдущем разделе.
- Проекты библиотек содержат бизнес-объекты, интерфейсы и элементы экспорта модулей, которые совместно используются другими проектами;
- Проекты модулей содержат реализации модулей для каждого компонента поставщика сервисов в UML-модели сервиса.
Эти проекты можно импортировать в рабочую область WebSphere Integration Developer. Можно также в качестве рабочей области использовать целевой проект, состоящий из всех проектов, сгенерированных из набора преобразований UML-SOA связанных SOA-моделей.
- Просто запустите инструмент WebSphere Integration Developer и выберите целевую папку в качестве рабочей области;
- Затем импортируйте все проекты из этой папки в выбранную рабочую область.
Совет:
Возможно, будет полезно отключить функцию автоматической компоновки Automatic Build до тех пор, пока не будут импортированы все проекты, это позволит ускорить импорт.
Каждая модель в выбранном при настройке конфигурации источнике транслируется в библиотеку WebSphere Integration Developer с именем, совпадающим с именем модели. Эта библиотека содержит XSD-элементы для каждого класса и типа данных исходной модели, а также определение WSDL для каждого UML-интерфейса. Библиотеки определяют бизнес-объекты и интерфейсы, используемые всеми модулями WebSphere, сгенерированными из компонентов выбранного в настройках преобразования источника.
На рисунке 17 показаны импортированные сгенерированные проекты библиотек и модулей в среде WebSphere Integration Developer; библиотека PurchaseOrderProcess развернута, чтобы в панели отображались бизнес-объекты и интерфейсы. Обратите внимание на то, что папки и пространство имен в WebSphere прямо соответствуют структуре пакета в UML-модели сервиса. Благодаря этому достигается согласованное управление пространством имен и поддержка многократного использования во всех ресурсах и инструментах.
Рисунок 17. Библиотека ProcessPurchaseOrder, ее бизнес-объекты и интерфейсы
Давайте внимательнее рассмотрим бизнес-объекты и интерфейсы и сравним их с исходными UML-элементами. На рисунке 18 при помощи редактора WebSphere Integration Developer Business Object editor с открытым бизнес-объектом PurchaseOrder показаны XSD-элементы, сгенерированные из показанной на рисунке 2 модели данных сервиса. Как мы видим, XSD-элементы точно соответствуют их исходным типам данных <<message>>. Нажмите и отпустите левую кнопку мыши на рисунке, чтобы просмотреть сгенерированный источник.
Рисунок 18. XSD-элементы, сгенерированные из модели данных сервиса 
Каждый UML-интерфейс преобразуется в portType WSDL. Код WSDL, сгенерированный для интерфейса Invoicing на рисунке 7, показан на рисунке 19. Нажмите и отпустите левую кнопку мыши на этом рисунке, чтобы просмотреть сгенерированный исходный код WSDL. И в этом случае код WSDL очень похож на UML-интерфейс.
Рисунок 19. Сгенерированный для интерфейса Invoicing код WSDL
Каждый поставщик сервисов в UML-модели сервисов преобразуется в модуль WebSphere Integration Developer. До настоящего времени не существует стандарта на сборку поставщиков и пользователей (потребителей) сервисов. Следовательно, WebSphere Integration Developer версии 6.0.2 использует фирменную раннюю версию компонентной архитектуры сервисов, Service Component Architecture (SCA). Сборки модулей представляют собой документированные файлы компонентов, в которых используется язык описания компонентов сервисов Service Component Description Language (SCDL), язык XML-документов для SCA. Несколько компаний объединили свои усилия для разработки стандарта SCA путем совместной работы этих компаний. См. дополнительную информацию на Web-сайте Open SOA.
Преобразование UML-SOA создает модули WebSphere Integration Developer для каждого компонента поставщика сервисов, чтобы максимизировать многократное использование этих компонентов. Модули SCA невозможно собрать из других модулей. Однако они могут импортировать сервисы из других модулей и использовать их опосредованно. Следовательно, соединения между поставщиками и потребителями сервисов в UML реализуются как привязки между элементами импорта и экспорта модуля в WebSphere Integration Developer. Для примера рассмотрим поставщик сервиса Invoicer, изображенный на рисунке 8.
На рисунке 20 показана схема соответствующей сборки модуля WebSphere Integration Developer . Для каждого порта сервиса созданы элементы импорта и экспорта модуля. SCA не может обеспечить поддержку предоставляемых и запрашиваемых интерфейсов для одной и той же точки взаимодействия, следовательно, для портов сервиса, которые предоставляют и запрашивают интерфейсы, будут созданы отдельные элементы экспорта и импорта. Сервис invoicingExport экспортирует предоставляемый интерфейс Invoicing, тогда как invoicingImport импортирует запрашиваемый интерфейс InvoiceProcessing на порту сервиса Invoicing поставщика сервиса Invoicer.
Рисунок 20. Сборка модуля Invoicer
Обратите внимание на имя модуля. Модуль представляет собой проект Eclipse, но поскольку модель является элементом многократного использования, она должна разрешать коллизии имен, как любой другой элемент многократного использования. По соглашению, которое используется преобразованием UML-SOA, создаваемые модули получают имена на основе полного уточненного имени компонента поставщика сервисов, по определению пакета, в который он входит. Вследствие этого имена получаются очень длинными, что может вызвать проблемы с исполнением на платформе Windows из-за ограничений на длину URL. Длинные имена модулей можно легко преобразовать в более короткие имена, поскольку конфликты имен корректно разрешаются в контексте многократного использования.
Из компонента Productions мы получили еще одну сборку модуля, которая изображена на рисунке 21. Этот модуль не имеет элемента импорта, поскольку данный порт сервиса не запрашивает ни одного интерфейса.
Рисунок 21. Сборка модуля Production
Оба этих модуля используют процессы BPEL для практической реализации сервисов, предоставляемых соответствующими им компонентами поставщиков сервисов. О том, как это происходит, подробно рассказывается в следующем разделе.
На рисунке 22 изображена сборка модуля, созданного для компонента OrderProcessor ранее, на рисунке 10.
Рисунок 22. Сборка модуля OrderProcessor
Поставщик сервисов OrderProcessor предоставляет сервис Purchasing и имеет требования для сервисов Invoicing, Sheduling и Shipping. Каналы сервиса, которые связывают компоненты поставщиков и потребителей на рисунке 10, реализуются как элементы импорта в модуле OrderProcessor , привязанные к элементам экспорта соответствующих поставщиков сервисов. Это делает возможным эффективное многократное использование модулей в WebSphere Integration Developer и сохраняет UML-модели сервисов независимо от эволюции SCA. Когда SCA будет стандартизирована, то в UML-модели сервисов не придется вносить изменения; достаточно будет обновить преобразования.
UML-деятельности и BPEL-процессы
Каждая функциональная возможность (операция), предоставляемая поставщиком сервиса, должна быть каким-либо образом реализована. Реализации разрабатываются в UML с использованием либо поведения метода для каждой операции, либо действия Accept Call в каком-либо другом поведении. Последний метод обеспечивает дополнительное разделение пользователей и поставщиков, позволяя поставщику определять момент, в который он хочет и может ответить на запрос, а не заставляя его отвечать немедленно, как только операция будет вызвана пользователем сервиса.
SCA в WebSphere Integration Developer использует другой подход. Каждый элемент экспорта должен быть связан с каким-либо компонентом в сборке, предоставляющей реализацию для операций в данном интерфейсе. Каждый компонент в SCA имеет свой тип реализации:
- Human Task (задача, выполняемая оператором-человеком);
- Java;
- Process (процесс);
- Rules Group (группа правил);
- State Machine (конечный автомат).
Поставщик сервисов OrderProcessor, изображенный на рисунках 10 и 22, предоставляет одну функциональную возможность для обработки заказов на приобретение через свой сервис Purchasing. Реализацией этой операции в UML-модели была деятельность. Преобразование UML-SOA создает из этой деятельности процесс BPEL, а затем использует его в качестве реализации экспортируемой операции.
Рисунок 23. Реализация компонента процесса OrderProcessor
Обратите внимание на то, что диаграмма процесса BPEL на рисунке 23 очень похожа на диаграмму деятельности, показанную на рисунке 11. Подробную информацию о преобразовании UML-деятельности в BPEL-процесс можно найти в разделе Help программного пакета Rational Software Architect.
Отделение интерфейса от реализации
Как уже говорилось ранее, WebSphere Integration Developer SCA реализует предоставляемые функциональные возможности посредством подключения элементов экспорта, которые предоставляют интерфейсы компоненту, реализующему предоставляемые операции. Поскольку компонент характеризуется типом реализации, все операции, предоставляемые всеми интерфейсами данного элемента экспорта, должны быть реализованы одним и тем же способом. Это связывает тип реализации со всеми интерфейсами элемента экспорта. (Элемент экспорта может быть подключен и реализован только одним компонентом .) Если разработчик желает изменить тип реализации конкретной операции (например, с задачи, выполняемой человеком ("human task"), на автоматизированный сервис, реализованный на Java), то исходный код всех интерфейсов необходимо будет перестроить, чтобы другие элементы экспорта можно было подключить к компонентам других типов реализации. Это, в свою очередь, потребует изменения всех пользователей таких интерфейсов. Такая связанность проекта интерфейса с типом реализации может препятствовать динамичности бизнеса, для поддержки которой и планировалась разработка SOA-решения.
UML не имеет такой связанности спецификации и реализации. Каждая предоставляемая операция в UML может иметь поведение метода, являющееся деятельностью, взаимодействием, конечным автоматом или непрозрачным поведением (кодом). Разработчик модели проектирует реализацию каждой операции независимо. Это может привести к ситуации (см. рисунок 4), в которой один и тот же компонент поставщика сервисов использует разные типы поведения для разных операций, предоставляемых через один и тот же интерфейс. Нам нужен какой-либо способ для трансляции поставщиков сервиса в Web-сервисы.
При этом необходимо учитывать еще один фактор. В UML создаются экземпляры компонентов, а не поведений, которыми они владеют. Следовательно, идентификатор и жизненный цикл экземпляра одинаковы для всех поведений одного компонента. Кроме того, компонент устанавливает контекст области деятельности для всех поведений, которыми он владеет, тем самым позволяя этим поведениям совместно использовать доступ к информации о состоянии компонентов (свойствам и портам). Следовательно, осуществляя трансляцию в Web-сервисы, мы должны иметь элемент, который будет управлять идентификатором, жизненным циклом и общим состоянием, иначе мы не сможем реализовать семантические схемы UML. Именно здесь нам поможет язык исполнения бизнес-процессов Business Process Execution Language (BPEL) (см. дополнительную информацию о BPEL в разделе Ресурсы).
Вместо того, чтобы создавать отдельный компонент SCA, реализующий каждое поведение поставщика сервисов в сборке модуля, мы создадим один процесс BPEL, который будет соответствовать самому компоненту. Обратите внимание на то, что имя процесса BPEL на рисунке 23 - OrderProcessor, то есть такое же, как у поставщика сервиса OrderProcessor, а не processPurchaseOrder, как у предоставляемой операции.
Давайте внимательно рассмотрим рисунок 4, чтобы понять, каким образом компонент Productions транслируется в Web- сервисы WebSphere Integration Developer. Обратите внимание, что проект реализации для requestProductionScheduling использует деятельность (Activity) (детали реализации не показаны), а sendShippingSchedule использует непрозрачное поведение (OpaqueBehavior) с реализацией, представленной в виде Java-кода. Сборка модуля для этого поставщика сервиса показана на рисунке 21, а компонент Productions Process - на рисунке 24.
Рисунок 24. Реализация поставщика сервиса Productions
Для компонента поставщика сервисов Productions создается процесс BPEL. Свойство identity поставщика сервисов используется для определения корреляции для всех деятельностей Invoke, Receive и Reply в этом процессе. Каждая предоставляемая компонентом операция реализуется каким-либо фрагментом этого процесса. Сначала процесс выбирает элемент, который будет использоваться для передачи каждого запроса операции. Затем для каждой операции создается область действия, чтобы предоставить место для переменных, определяемых в UML -поведении. Впоследствии область действия будет содержать результат трансляции поведения. Если поведение являлось деятельностью UML, то область действия будет содержать код BPEL, сгенерированный из этой деятельности. Если поведение имело тип "непрозрачное поведение" (OpaqueBehavior) на языке Java, то тело поведения копируется в фрагменты деятельности на Java в области действия. Если поведение имело тип "неопределенное поведение" (OpaqueBehavior) на языке HTML или Java™Server Pages (JSP), то в область действия добавляется деятельность Human Task.
Благодаря этому достигается разделение интерфейсов и их реализаций. Например, если разработчик модели решит изменить реализацию операции сервиса с "human task" на автоматизированный Java-сервис, то нужно будет изменить только элемент "human task" в области действия этой операции. Клиенты не узнают об изменении реализации до тех пор, пока не заметят, что сервис функционирует быстрее и им не нужно делать столько работы, как раньше.
В общем, понятно, что речь идет о чем-то сложном и запутанном; но ситуация, скорее всего, изменится после стандартизации SCA. Однако разъединение, разделение интересов, многократное использование и динамичность решений являются основополагающими характеристиками SOA, хотя получить их не всегда просто.
Завершение работы над решением
Инструмент преобразования UML-SOA не генерирует законченного решения (пока). Причина заключается в том, что работа по вставке деталей реализации в модели была бы сложнее, чем действия по размещению их в платформенно-специфичных артефактах при помощи редакторов, предназначенных для этой цели. Кроме того, в деятельностях UML 2 имеется ряд функций, которые пока невозможно транслировать в BPEL. Они будут добавлены в будущих версиях. Подробная информация о том, какие функции поддерживаются конкретными версиями, доступна в разделе Help программного пакета Rational Software Architect.
Обычно WebSphere Integration Developer приходится выполнять некоторые или все из следующих деятельностей процесса разработки.
- Добавление Java-кода для непрозрачного поведения, если этот код не был предоставлен в модели. Даже в том случае, если Java-код имеется в теле непрозрачного поведения, в нем могут быть ошибки, поскольку Content Assist и компиляция Java не интегрированы (пока) с функциями моделирования в Rational Software Architect;
- Добавление корреляций для бизнес-процессов. Корреляция определяет информацию, необходимую для идентификации экземпляров компонента, она до сих пор не поддерживается инструментом преобразования UML-SOA. Введение поддержки корреляции планируется в одной из следующих версий;
- Создание пользовательского интерфейса (UI) для задач, выполняемых оператором-человеком (human task). Разработчик UML-модели может включить код JSP или HTML в тело непрозрачного поведения. Но как и Java-код, этот код может быть неполным или содержать ошибки. Чтобы закончить создание пользовательского интерфейса (UI) приложения, разработчику интеграции нужно будет использовать редактор Human Task editor, редактор страниц Page Designer, портал или другие инструменты для создания законченных " human tasks", которые будут удобными в применении и отличаться хорошим дизайном;
- Настройка конфигурации модели мониторинга. На данный момент инструмент преобразования UML-SOA не может предоставить никакой информации для мониторинга, позволяющей оценить ключевые показатели эффективности (KPI), но их можно смоделировать как ограничения для сервисов и поставщиков сервисов. Разработчик интеграции может использовать инструмент Monitor Model Editor в WebSphere Integration Developer для того, чтобы выбрать, какие данные нужно собирать для обновлений имитаций, а также в качестве бизнес-показателей и параметров.
На этом мы заканчиваем серию статей, посвященную моделированию сервисов в Rational Software Architect с использованием профиля IBM Software Services (см. врезку Другие статьи серии вверху слева). В первой статье, "Моделирование SOA. Часть 1. Идентификация сервиса", рассказывалось о том, как использовать модели бизнес-процессов и кооперации сервисов для того, чтобы определить контракт о требованиях, описывающий, как необходимо согласовать и оркестровать набор сервисов для решения некоторых задач. Контракты сервисов часто используются для того, чтобы определить, что необходимо выполнить для достижения бизнес-целей. Далее, при идентификации сервисов, которые представляют собой реальные бизнес-ценности, могут оказаться полезными кооперации сервисов.
В статье "Моделирование SOA. Часть 2. Спецификация сервисов" мы показали, как моделировать детали спецификации с точки зрения поставщика. В спецификации сервиса указывается информация, необходимая потенциальному потребителю для того, чтобы определить, можно ли применить данный сервис для решения своих задач, и если можно, то как его использовать на практике. Кроме того, спецификация сервиса определяет, что должен сделать поставщик для реализации сервиса.
В следующих статьях, "Моделирование SOA. Часть 3. Реализация сервиса" и "Моделирование SOA. Часть 4. Компоновка сервисов" рассказывалось о том, как создаются проекты и модели компонентов, предоставляющие или запрашивающие сервисы, и как реализуются операции сервисов. В этих статьях также описывалось, как поставщики сервисов указывают выполняемые ими контракты, что позволяет снова связать поставщики сервиса с задачами, целями, процессами и требованиями бизнеса.
В последней статье описывалась реализация сервисов на платформе Web-сервисов, поддерживаемой IBM WebSphere Integration Developer при помощи инструмента преобразования IBM UML-SOA. Среда WebSphere Integration Developer поддерживает модель программирования SOA , которая согласуется с проектами идентификации, спецификации и реализации, документированными в Rational Software Architect. При помощи WebSphere Integration Developer можно завершить программирование сервисов, а затем сгенерировать интерфейс пользователя для выполнения задач оператором-человеком, выполнить тестирование и развертывание SOA-решения.