Моделирование SOA: Часть 3. Реализация сервиса

Источник: IBM

В этой статье, третьей из пяти статей данной серии, рассказывается о том, как реализуются Web-сервисы на практике. Сначала разработчик решает, какой компонент будет предлагать сервисы, и какие именно сервисы. Данное решение оказывает заметное влияние на доступность, распределенность, безопасность, объем транзакций и связанность сервиса. После того как решение будет принято, можно определить модель реализации функциональных возможностей каждого сервиса, а, значит, и то, как в действительности будут использоваться запрашиваемые сервисы. Затем вы сможете воспользоваться функцией преобразования UML-SOA из программного пакета IBM Rational Software Architect для создания реализации Web-сервиса, которую можно будет использовать в программе IBM WebSphere Integration Developer для реализации, тестирования и развертывания готового решения.

О данной серии

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

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

В данной статье мы расскажем о разработке реальной модели предоставления сервиса, или, в терминологии унифицированного языка моделирования Unified Modeling Language (UML), его реализации . В процессе разработки реализации сервиса сначала решают, какой компонент будет предлагать сервисы, и какие именно сервисы. Данное решение оказывает заметное влияние на доступность , распределенность, безопасность, объем транзакций и связанность сервиса. После того как решение будет принято, можно определить модель реализации функциональных возможностей каждого сервиса, а значит и то, как в действительности будут использоваться запрашиваемые сервисы.

В следующей статье этой серии, "Моделирование SOA: Часть 4. Компоновка сервиса," мы расскажем о том, как можно комбинировать сервисы для создания новых сервисов. В последней статье серии, "Часть 5. Реализация сервиса", мы воспользуемся функцией преобразования UML-SOA из пакета IBM® Rational® Software Architect для создания реализации Web-сервиса, которую можно будет использовать непосредственно в IBM WebSphere Integration Developer для реализации, тестирования и развертывания готового решения.

Контекст статьи

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

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

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

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

В этой статье мы не будем подробно анализировать все эти вопросы, вы найдете их полное описание в документации к методу сервис-ориентированного моделирования и архитектуры IBM® Service Oriented Modeling and Architecture (SOMA) . В этой статье мы предполагаем, что ИТ-архитекторы уже приняли какое-то решение по поводу того, какие поставщики будут предоставлять сервисы, и какие это будут сервисы, поэтому мы можем сосредоточиться на том, как создать модели этих поставщиков и собрать из них решение для потребителя.

Как и в остальных статьях серии, мы будем использовать инструменты IBM Rational and 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 показан контракт о требованиях к бизнес-сервисам, которым должно удовлетворять наше решение.

Рисунок 1. Контракт о требованиях к сервису

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

На рисунке 2 показаны спецификации сервисов, которые были идентифицированы как необходимые для выполнения требований. По сути, мы создаем (приобретаем, повторно используем, адаптируем) сервисы, которые способны выполнять роли в описанном контракте о требованиях к бизнес-сервисам.

Рисунок 2. Топология сервиса

На рисунке 3 показана законченная спецификация сервиса Scheduling. Эта спецификация сервиса представляет собой простой интерфейс, потому что в ней нет ни одного интересующего нас протокола для использования сервисов планирования.

Рисунок 3. Спецификация сервиса планирования Scheduling

На рисунке 4 показана спецификация сервиса доставки ShippingService.

Рисунок 4. Спецификация сервиса ShippingService

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

На рисунке 5 показана спецификация сервиса InvoicingService.

Рисунок 5. Спецификация сервиса инвойсинга InvoicingService.

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

На рисунке 6 показана спецификация сервиса приобретения Purchasing:

Рисунок 6. Спецификация сервиса приобретения Purchasing.

Сервис Purchasing представляет собой функциональную возможность, которая была определена в исходном бизнес-процессе Обработка заказов на приобретение. Это сервис, идентифицированный и разработанный для реализации данного бизнес-процесса. Поскольку с данной спецификацией не ассоциировано ни одного протокола сервиса, мы еще раз создадим ее модель с использованием стереотипизированного интерфейса.

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

Реализация сервиса

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

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

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

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

Инвойсинг

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

Мы начнем разработку поставщика сервиса с создания системного прецедента, определяющего требования к нему, и компонента <<serviceProvider>> с именем Invoicer, который будет реализовать этот прецедент. Компонент Invoicer будет размещаться в пакете credit, который импортирует пакет CRM (пакет управления взаимоотношениями с клиентами) , чтобы использовать общие определения данных сервиса (сообщения). На рисунке 7 показано, что мы имеем на данный момент.

Рисунок 7. Первоначальная модель поставщика сервиса Invoicer

Поставщик сервиса Invoicer будет предоставлять сервис InvoicingService. Для создания модели мы добавляем к модели Invoicer порт <<service>> , имеющий тип спецификации сервиса InvoiceService . Все сервисы типизированы в спецификации сервиса, которая определяет, какие функциональные возможности предоставляются и запрашиваются, а также протокол, необходимый для его использования. На рисунке 8 показан поставщик Invoicer после добавления сервиса инвойсинга.

Рисунок 8. Добавление сервиса InvoicingService к поставщику сервиса Invoicer

По типу сервиса мы можем определить, что он предоставляет интерфейс Invoicing и запрашивает интерфейс InvoiceProcessing. Кроме того, по типу сервиса мы можем сделать вывод, что должен сделать потребитель при подключении к сервису, чтобы использовать этот сервис, и что поставщик Invoicer (или любой другой поставщик) должен сделать, чтобы его реализовать. Любое использование и реализация сервиса должны быть согласованы со спецификацией сервиса и его протоколом.

Порт <<service>> (порт инвойсинга) также может определять возможные привязки, предоставляемые компонентом Invoicer для использования в сочетании с другими компонентами. Остальные допустимые принципы привязки, например "RMI over IIOP" (Remote Method Invocation over Internet Inter-ORB Protocol, Удаленный вызов метода через протокол интернета Inter-ORB) или "SOAP over HTTP", также могут оказывать значительный эффект на производительность, доступность и безопасность сервиса. Следовательно, эти вопросы должны быть решены на этапе разработки сервиса, несмотря на то, что они могут быть платформенно-специфичными. Как минимум, проект решения должен решать вопрос о том, будет ли подключение к сервису локальным и/или удаленным.

Поставщик Invoicer предоставляет интерфейс Invoicing, имеющий две операции:

initiatePriceCalculation;
completePriceCalculation.

Поставщик Invoicer должен предоставить проект реализации или метод для каждой из этих операций сервиса. Этот метод, кроме того, должен вызывать операцию processInvoice интерфейса InvoiceProcessing после завершения вычисления стоимости. На рисунке 9 изображена схема компонента Invoicer, который является владельцем двух поведений, имена которых совпадают с именами предоставляемых операций.
Рисунок 9. Реализации сервиса Invoicer

Деятельность completePriceCalculation представляет собой метод для операции Invoicing::completePriceCalculation сервиса. Он использует нечеткое правило для вычисления итоговой стоимости, а затем вызывает операцию InvoiceProcessing::processInvoice на порту инвойсинга. (Целевой входной точкой операции processInvoice служит порт инвойсинга.) Обратите внимание на то, что это согласуется с протоколом инвойсинга по определению спецификации сервиса InvoicingService.

Нечеткое поведение initiatePriceCalculation представляет собой метод для операции сервиса initiatePricesCalculation. Эта операция реализуется при помощи Java-™кода, записанного в теле нечеткого поведения.

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

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

Компонент Productions предоставляет интерфейс Scheduling через порт планирования, см. рисунок 10. Порт <<service>> определяет возможные стили привязки, доступные на этом порту.

Рисунок 10. Поставщик сервиса Productions

Методы операции сервиса - это поведения requestProductionsScheduling и sendShippingSchedule. Детали этих реализаций не показаны на диаграмме; они могут быть реализованы разработчиком с использованием более подходящих, платформенно-независимых языков программирования.

Доставка

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

На рисунке 11 показано, что сервис Shipper предоставляет интерфейс доставки в соответствии с определением спецификации сервиса ShippingService.

Рисунок 11. Поставщик сервиса Shipper

Комплементация типов

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

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

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

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

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

Для примера рассмотрим интерфейс сервиса InvoicingService. На рисунке 12 показана комплементарная реализация сервиса InvoicingService с именем ~InvoicingService.

Рисунок 12. ~InvoicingService, комплементарная реализация сервиса InvoicingService

Здесь используется то же соглашение о назначении имен, что и для основной спецификации сервиса, за исключением того, что имя начинается с символа ~ (символ тильды). Можно использовать любое соглашение о назначении имен, но выбранное соглашение следует использовать последовательно, чтобы облегчить узнаваемость взаимосвязи между этими типами. ~InvoicingService имеет такие же внутреннюю структуру и поведения, что и InvoidingService. Эта реализация просто использует интерфейсы, предоставляемые сервисом InvoicingService, и реализует запрашиваемые интерфейсы.

В будущих версиях расширения IBM Software Service Profile for UML планируется ввести понятие порта требования для различения требований от разных функциональных возможностей. Затем порт требования может использовать тот же тип, что и порт сервиса, тем самым устраняется необходимость определения комплементарных типов. Порт требования указывает на то, что функциональные возможности сервиса используются, тогда как порт сервиса указывает на то, что они предоставляются.

Что дальше

На этом мы закончили идентификацию, создание спецификации и реализацию проекта сервисов, потребителей и поставщиков, необходимых для решения бизнес-задач. В результате мы получили технологически-нейтральную модель архитектурного решения сервиса. Но мы еще не создали модель потребителя сервиса, которая может собрать вместе сервисы, предоставляемые поставщиками Invoicer, Productions и Shipper, и использовать их для обработки заказов на приобретение. В следующей статье серии, "Моделирование SOA: Часть 4. Компоновка сервиса," рассказывается о том, как собрать и соединить эти поставщики сервисов и о том, как координировать их взаимодействия для того, чтобы создать комплексное решение, удовлетворяющее бизнес-требованиям.

Ссылки по теме