Разработка составных бизнес-сервисов на базе сервис-ориентированной архитектуры (SOA): Часть 1. Разработка для реализации бизнес-сервисов

Интегрируйте имеющиеся бизнес-сервисы, объединяя их в различных сочетаниях. Мы уделим часть нашего внимания тому, как это осуществляется в рамках сервисно-компонентной архитектуры (Service Component Architecture).

Хавьер Гарсиа, инженер-программист, IBM

Хавьер Гарсиа – инженер-консультант, более 20 лет занимающийся разработкой ПО. Сейчас он работает в отделе планирования и технологий компании SWG и занимается в основном SOA и составными приложениями.



Герман Голдшмидт, старший технический сотрудник, IBM

Доктор Герман Голдшмидт является старшим техническим сотрудником в IBM Software Group. Его работа связана с архитектурой интегрированных платформ и выпуском, настройкой и развёртыванием составных приложений SOA для реализации бизнес-сервисов.



27.06.2007

Введение

Составные приложения обеспечивают возможность объединять имеющиеся сервисы на базе сервис-ориентированной архитектуры (SOA) и/или создавать новые сервисы, которые можно по-разному комбинировать. Ключевыми процессами для составных приложений являются разработка многократно используемых ресурсов ПО и внедрение SOA-сервисов с использованием SCA. Мы разработали демонстрационное составное приложение для банковской сферы, использующее WebSphere Process Server, WebSphere Portal, WebSphere Service Registry and Repository, WebSphere Enterprise Bus, WebSphere Portlet Factory и WebSphere Application Server, а также соответствующие инструменты разработки. Выбранные сценарии служат примерами реализации различных функций, необходимых для разработки эффективных составных приложений. Сначала мы рассмотрим преимущества составных приложений и трудности их разработки, на примере сценариев, разработанных нами в качестве иллюстраций. В заключение мы рассмотрим технические характеристики продуктов IBM и возможности их использования для разработки составных приложений.

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

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

Что такое составные приложения?

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

Рисунок 1. Составное приложение для предоставления банковского займа
Составное приложение для предоставления банковского займа

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

В этом контексте, сервисно-компонентная архитектура (SCA) представляет собой сервис-ориентированную компонентную модель. Она предоставляет абстракцию, которая охватывает компоненты спецификации EJB, не использующие информацию о состоянии в сессии, Web-сервисы, объекты Plain Old Java Objects (POJOs), бизнес-процессы, описанные на языке WS-BPEL (WS-Business Process Execution Language), компоненты доступа к базам данных, компоненты доступа к информационной системе предприятия (Enterprise Information System, EIS), а также другие реализации сервисов, как видно из рисунка 2 (см. ниже). SCA разделяет бизнес-логику и логику инфраструктуры, чтобы разработчики приложения могли сконцентрироваться на коммерческой задаче.

Рисунок 2. Виды реализации SCA
Виды реализации SCA

Точки изменчивости

Точки изменчивости (points of variability) - это участки, на которых реализованы решения, вероятность внесения последующих изменений в которые высока, и которые должны легко изолироваться. Компоненты сервиса со встроенными точками изменчивости позволяют пользователям конфигурировать эти сервисы в соответствии с различными требованиями. Для создания конфигурируемых приложений нужно разработать механизмы расширяемости для пользовательского интерфейса, интерфейсов компонентов сервиса, самих компонентов сервиса и для модели данных.

Важно понимать отличия понятия конфигурируемости и настройки. Конфигурируемость дает возможность привести компонент в соответствие с различными требованиями, не меняя основной код (не переписывая его). Конфигурируемость встроена в сервисы (такие объекты, как переключатели, шкалы и бегунки) и предназначена для пользователя приложения. Настройка компонента, напротив, требует разработки дополнительного кода (на языке программирования) для расширения компонента ПО и внесения в него изменений, чтобы адаптировать его к конкретным требованиям.

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

Пользовательский интерфейс (UI)

Точки изменчивости в пользовательском интерфейсе позволяют пользователю менять вид и функции UI вместе с его семантическим контентом (полями данных) посредством конфигурирования. Примеры конфигурирования точек изменчивости в пользовательском интерфейсе:

  1. Оформление Web-сайта логотипами и баннерами клиента. Предположим, что существуют два банка, банк А и банк Б. У каждого из них есть свои логотипы или торговые марки и они хотели бы, чтобы это было отражено на их Web-сайтах.
  2. Изменение надписей и текста, применяющихся в пользовательском интерфейсе, для удобства сотрудников и клиентов. Например, в одном банке может использоваться выражение Привилегированный счет как надпись для поля ввода данных, а в другом – Бонусный счет..
  3. Изменение полей ввода данных, открытых пользователю. В одном банке клиенту может быть разрешено ввести дополнительный номер сотового телефона, в то время как в другом такая возможность отсутствует.
  4. Изменение конечных точек (endpoints) SOA-сервисов, запускаемых пользователем. Сервис проверки кредитоспособности, например, может варьироваться в зависимости от страны пребывания, таким образом, создание изолируемой конечной точки позволяет конфигурировать сервис.

Бизнес-процесс

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

Чтобы выполнить это требование, реализации составных приложений должны обладать возможностью отключать дополнительные действия в бизнес-процессе. WebSphere Process Server предоставляет механизм для создания точек изменчивости, которые позволяют конфигурировать бизнес-процессы, не переделывая их. Это легко осуществимо в рамках бизнес-процесса BPEL: прежде, чем совершать действие, нужно найти бизнес-правило, которое доставит булево выражение, указывающее, включено ли данное действие. В примере, представленном в предыдущем абзаце, мы имели бы дело с «правилом получения подарка», которое могло быть активировано администратором и в итоге включало или выключало бы соответствующее действие "отправить подарок" в бизнес-процессе.

Уровень данных

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

Один из возможных способов обеспечения этой функции – хранить атрибуты данных в файле XML, находящемся в базе данных. Хранение атрибутов данных в XML позволяет создать очень гибкую систему, из которой атрибуты можно удалять или добавлять в нее без нарушения логической структуры данных. Это возможно, поскольку этот XML-документ хранится в одном атрибуте базы данных (функция DB2® V9), следовательно, логическая структура данных не меняется.

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

Роли

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

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

Рисунок 3. Роли администратора провайдера банковских услуг
Роли администратора провайдера банковских услуг

Администраторы банка

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

Конечные пользователи банковских сервисов

Конечные пользователи банковских сервисов делятся на 3 основные категории: сотрудники банка, бизнес-партнеры и непосредственные клиенты банков. Это показано на рисунке 4. Наличие деловых партнеров усложняет конфигурацию системы, поскольку некоторые банковские услуги фактически предоставляются другим провайдером. В сфере банковского дела обработкой данных по ипотеке может заниматься ипотечный провайдер. Таким образом, ипотечный провайдер становится бизнес-партнером банка, и возникает необходимость в соответствующих агентах (actors).

Рисунок 4. Конечные пользователи банковских сервисов
Конечные пользователи банковских сервисов

Варианты использования (Use Cases)

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

Рисунок 5. Функциональные области применения
Функциональные области применения

Администрирование провайдера банковских услуг

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

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

Варианты использования приложения администратором банка

Администраторы банка могут конфигурировать бизнес-процессы, например, процесс выдачи кредита, добавлять администраторов, новых пользователей (массивами), а также создавать для банка оригинальную торговую марку. Это показано на рисунке 7. Торговая марка обеспечивает уникальность впечатлений от использования Web-сайта данного банка.

Рисунок 7. Варианты использования приложения администратором банка
Варианты использования приложения администратором банка

Варианты использования приложения служащими банка

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

Рисунок 8. Варианты использования приложения служащими банка
Варианты использования приложения служащими банка

Варианты использования сервисов банка клиентами

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

Рисунок 9. Варианты использования сервисов банка клиентами
Варианты использования сервисов банка клиентами

Топологические диаграммы

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

Рисунок 10. Топологическая диаграмма
Топологическая диаграмма

Сервисы представления (Presentation services)

Сервисы представления выполняются в узле Presentation Services Node, задачей которого является запуск пользовательского интерфейса. В нашем случае WebSphere Portal предоставляет мощную среду выполнения для Web-приложений. На рисунке 11 показаны продукты межплатформенного ПО, необходимые для запуска WebSphere Portal, а на рисунке 12 представлены некоторые готовые программные компоненты для построения порталов (Portlets) нашего демонстрационного банковского приложения.

Рисунок 11. Сервисы представления
Сервисы представления
Рисунок 12. Пользовательский интерфейс Websphere Portal для демонстрационного банковского приложения
Пользовательский интерфейс Websphere Portal для для демонстрационного банковского приложения

Бизнес-сервисы

Бизнес-сервисы запускаются на узле бизнес-сервисов. Это место хранения бизнес-логики. Поскольку в нашем случае механизм вызова основан на сервисно-компонентной архитектуре, мы используем Websphere Process Servise, как показано на рисунке 13.

Рисунок 13. Бизнес-сервисы содержат бизнес-логику приложения
Бизнес-сервисы содержат бизнес-логику приложения

Сервисы уровня предприятия

Сервисы уровня предприятия запускаются на узле сервисов предприятия, который содержит продукты, обеспечивающие сервисы данных, безопасность и другие сервисы инфраструктур, например, системный реестр сервисов. Сервер каталогов Tivoli (Tivoli Directory server) обеспечивает инфраструктуру облегченного протокола доступа к каталогам (Lightweight Directory Access Protocol, LDAP), являющегося основой для управления идентификацией. WebSphere Service Registry and Repository дает возможность провайдерам регистрировать, а клиентам – выбирать сервисы.

Рисунок 14. Сервисы уровня предприятия
Сервисы уровня предприятия

Функции составных приложений для реализации бизнес-сервисов

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

Множественная принадлежность (Multi-tenancy): Множественная принадлежность – это возможность использования составного приложения различными пользователями на базе совместно используемой, общей среды размещения информации.

Динамичность: динамичность можно определить, как способность реагировать на события, происходящие в течение всего времени выполнения приложения, а не только в заранее установленный или фиксированный промежуток времени. Например, в WebSphere Process Server динамичность, главным образом, поддерживается селекторами и бизнес-правилами.

Публикация: Составные приложения могут быть как пользователями, так и провайдерами сервисов, опубликованных в каталоге. Например, реестр и репозиторий WebSphere Service Registry and Repository помогает управлять регистрацией таких сервисов.

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

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

Конфигурируемость: Характеристики приложения можно согласовывать со специфическими потребностями клиента, используя такие элементы, как стандарты бизнеса, бизнес-правила, соглашения об уровне бизнес-сервиса и параметры конфигурации. Например, функция Dynamic Profiles WebSphere Portlet Factory обеспечивает высокую динамическую конфигурируемость пользовательского интерфейса.

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

Измеримость: Составные бизнес-сервисы должны вести замеры своей коммерческой выгоды. Например, бизнес-сервис может использовать инфраструктуру Common Event Infrastructure (CEI) для генерирования событий, которые затем можно будет анализировать и производить численные оценки эффективности бизнеса.

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

Гибкость: Составные бизнес-сервисы должны приспосабливаться к изменениям лежащих в их основе коммерческих и технологических требований. Например, при использовании WebSphere Enterprise Service Bus одно и то же SCA-приложение может поддерживать синхронную и асинхронную связь на базе SOAP/HTTP- и SOAP/JMS-протоколов без изменения кода приложения.

Благодарность

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

Ресурсы

Научиться

Получить продукты и технологии

  • Скачайте пробные версии ПО от IBM и научитесь пользоваться инструментами разработки приложений и межплатформенными продуктами от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=236746
ArticleTitle=Разработка составных бизнес-сервисов на базе сервис-ориентированной архитектуры (SOA): Часть 1. Разработка для реализации бизнес-сервисов
publish-date=06272007