Опыт первых проектов построения сервисно-ориентированных архитектур (service-oriented architecture,
SOA) показывает, что существующие методологии разработки программного обеспечения (ПО) и нотации, такие
как OOAD (Object-Oriented Analysis and Design, OOAD), Enterprise Architecture (EA) и Business Process
Modelling (BPM) охватывают лишь часть из того, что необходимо для поддержки реализации архитектурных
шаблонов, объединенных в настоящее время под "зонтиком" SOA. Таким образом, возникает потребность в
некотором расширенном междисциплинарном подходе к моделированию сервисов.
В недавнем интервью изданию Info World Гради Буч заявил, что "такие фундаментальные понятия программной
инженерии, как абстракция и разделение сущностей никогда не выйдут из моды", однако он также отметил,
что "имеются реальные возможности в очередной раз повысить уровень абстракции". Предыдущий опыт
показывает, что уровень абстракции должен быть повышен до предметных бизнес-областей, с которыми компания
имеет дело. При этом необходимо принимать во внимание весь корпоративный IT-ландшафт.
Mark Colan в статье "Сервисно-ориентированная архитектура расширяет видение веб-сервисов, Часть 1"
пишет, что SOA являет собой новый архитектурный стиль создания корпоративных приложений следующего
поколения. Несмотря на то, что подход SOA интенсивно способствует укреплению хорошо устоявшихся,
общеархитектурных принципов разработки ПО, такие как сокрытие информации (часто употребляется также
синоним "инкапсуляция" - прим. перев.), модульность и разделение сущностей (часто употребляется также
синоним "декомпозиция" - прим. перев.), он также вводит и некоторые новые понятия, такие, например,
как хореография сервисов, репозитарии сервисов и шаблоны сервисной шины промежуточного ПО (service bus
middleware pattern).
Для качественного построения SOA необходим структурированный подход или метод анализа и проектирования.
Поскольку по результатам выполненных проектов реализации SOA ни один из существующих подходов не
удовлетворил требованиям авторов этой статьи, авторами предлагается скомбинировать различные элементы
устоявшихся практик, таких как OOAD, EA и BPM, дополнив их при необходимости новыми элементами, и тем
самым попытаться сформулировать требуемый подход.
Основные положения концепции SOA и веб-сервисов сформулированы на основе повседневного опыта и
признаны в качестве общепринятого архитектурного стиля разработки современных корпоративных приложений.
В этом контексте, основной вопрос состоит в следующем: что делает хорошие сервисы все более и более
критичными для обеспечения успешной реализации SOA.
Существующие на сегодняшний день методологии моделирования, такие как Object-Oriented Analysis and Design
(OOAD), Enterprise Architecture (EA) и Business Process Modelling (BPM) являются высококлассными
практиками, которые, безусловно, полезны для идентификации и определения нужных абстракций при построении
архитектуры системы. Однако, опыт показывает, что эти практики не оправдывают ожиданий, будучи
примененными по отдельности.
В этой статье мы рассмотрим подходящие для наших целей элементы OOAD, EA и BPM. Мы также попробуем
построить некий гибридный подход, комбинирующий отдельные элементы вышеуказанных методологий, а также
некоторые новые элементы. В результате мы попробуем сформулировать междисциплинарный OOAD-метод,
способствующий успешному развертыванию SOA, который мы будем называть сервисно-ориентированным анализом и
проектированием (Service-Oriented Analysis and Design, SOAD). В этой статье мы делаем лишь первые шаги в
описании данного метода.
В ситуации, когда для бизнеса возможно появление новых возможностей или угроз, архитектурный стиль SOA
способствует построению корпоративных бизнес-решений, обладающих способностью расширять либо изменять
функциональность по требованию. SOA-решения состоят из повторно используемых сервисов, обладающих четко
описанными, широкодоступными и стандартизованными интерфейсами. SOA предоставляет механизм интеграции
существующих унаследованных приложений безотносительно программных платформ и языков программирования,
на которых они реализованы.
Концептуально в SOA существует три основных уровня абстракции:
Опыт первых проектов построения SOA показывает, что существующие методологии разработки ПО и нотации,
такие как OOAD (Object-Oriented Analysis and Design, OOAD), Enterprise Architecture (EA) и Business
Process Modelling (BPM) охватывают лишь часть из того, что необходимо для поддержки парадигмы SOA.
Несмотря на то, что SOA-подход интенсивно способствует укреплению хорошо устоявшихся, общеархитектурных
принципов разработки ПО, такие как инкапсуляция, модульность и декомпозиция, он также вводит и некоторые
новые понятия, такие как хореография сервисов, репозитарии сервисов и шаблоны сервисной шины
промежуточного ПО (service bus middleware pattern), которые требуют пристального внимания в процессе
моделирования.
Рис. 1 иллюстрирует области применения существующих на сегодняшний день подходов к моделированию (EA, BPM и
OOAD). Данный рисунок представляет собой также хорошую отправную точку для дальнейшего обсуждения SOAD.
По горизонтальной оси рисунка представлены фазы жизненного цикла проекта, по вертикальной - различные
уровни абстракций или области знаний, где обычно применяется моделирование.
Рис. 1: Позиционирование BPM, EA и OOAD
Концепция SOA в значительной степени принимается легче, поскольку ее техническая основа хорошо
известна. Например, применение общеархитектурных принципов создания ПО и объектно-ориентированных техник
является общепринятой практикой для любого SOA-проекта. Однако, как уже было сказано, вопрос, наиболее
часто задаваемый начинающими - как следует определять нужные сервисы. Мы упомянули ранее, что OOAD, EA и
BPM не дают удовлетворительного ответа на этот вопрос, будучи примененными изолированно друг от друга.
Методология OOAD, описанная в оригинальных книгах
Буча и Якобсона (выпущенными около десятилетия назад),
являет собой прекрасную отправную точку для разработки SOA. OOAD имеет дело с абстракциями микро-уровня -
классами и экземплярами объектов, хотя применение OOAD-техник и нотации Unified Modeling Language (UML)
на архитектурном уровне было общепринятой практикой на протяжении многих лет. Так как модель вариантов
использования часто создается отдельно для каждой предметной области и, следовательно, для проекта
разработки приложения, часто целостная картина ситуации по всему предприятию оказывается размытой. Кроме
того, по различным причинам модели вариантов использования не всегда бывают синхронизированы с их
BPM-аналогами.
Подходы к построению корпоративных интеграционных приложений, такие как
Treasury Enterprise
Architecture Framework (TEAF), Feature-Oriented Domain Analysis (FODA) и Zachman дают высокоуровневое представление
об архитектуре приложений, однако не описывают методы идентификации необходимых общекорпоративных
абстракций, улучшающих качество свойств повторности использования и жизнеспособности решений.
Такие же BPM-подходы, как, например, BPMI,
дают законченное представление о функциональных единицах
работы, однако, они, как правило, не дают детального описания предметных областей архитектуры и
реализации. Например, до появления таких языков как Business Process Execution Language for Web Services
(BPEL), в BPM-нотациях не существовало описания операционной семантики. Более того, мы видели много
ситуаций, когда процессы моделирования и разработки были вовсе отделены друг от друга.
Наконец, ни одна из существующих дисциплин не описывает того, как существующие приложения могут быть
адаптированы для SOA - везде, как правило, используется принцип построения SOA "сверху вниз".
Существующие системы обычно хранят большое количество критичных данных и бизнес-логики и легко заменить
их нельзя. Следовательно, для этих систем должен применяться также анализ по принципу "снизу вверх" с
целью изучения возможностей их "обертывания" (здесь мы вводим новый русскоязычный термин "обертывание
приложения", означающий облечение приложения в совокупность интерфейсов для интеграции с другими
приложениями без изменения внутренней структуры приложения; в оригинале присутствует термин "wrapping" -
прим. перев.) и рефакторинга. Принимая во внимание наличие существующих приложений, мы приходим к
необходимости построения некоторой компромиссной, сходящейся (в том смысле, что данная методология будет
сочетать как подход "сверху вниз" так и подход "снизу вверх" - прим. перев.) методологии построения SOA.
Учитывая вышесказанное, необходим некий гибридный SOAD-подход к моделированию. Этот подход должен вобрать в себя лучшие элементы OOAD, BPM и EA, при необходимости дополнив их новыми элементами. Рис. 2 иллюстрирует средства SOAD (элементы и техники) описываемого нового подхода.
Рис. 2: SOAD и его составляющие: OOAD, BPM и EA
Вовлечение корпоративных приложений и IT-инфраструктуры предприятия в процесс построения SOA может быть
серьезным начинанием, затрагивающим множество аспектов бизнеса и организационных единиц. Поэтому в
подобных случаях необходимо применять методологии EA и реферрентные архитектуры EA, такие, например,
как The Open Group
Architecture Framework (TOGAF) и Zachman, которые обеспечивают архитектурную
совместимость отдельных решений.
Основываясь на имеющемся опыте можно утверждать, что большинство существующих EA-методологий имеют
ограничения в одной или нескольких предметных областях. Например, если основным предметом рассмотрения
методологии является взаимодействие на макроуровне низкоуровневых блоков, представляющих технические
устройства, то в этом случае не может быть получено ни описание процесса на бизнес-уровне, ни
представление о системе с точки зрения сервисов. Однако, в контексте SOA, подобный образ мышления
необходимо сменить на подход, сконцентрированный на логических блоках, представляющих бизнес-сервисы,
на определении интерфейсов и сервисных соглашений Service Level Agreements (SLA) между сервисами.
Более того, многие реферрентные архитектуры и методологии уровня предприятия являются довольно общими и
не имеют глубокого описания процессов проектирования. Подобные общие архитектуры не дают архитекторам и
разработчикам решений конкретных, тактических советов, следствием чего часто бывает фундаментальный
разрыв между корпоративной архитектурой и архитектурой создаваемых решений.
SOAD должен помочь архитекторам SOA в выработке целостного представления о ландшафте сервисов на
бизнес-уровне. Это то, что не могут дать сегодняшние EA-методологии без улучшений, адаптирующих их для
SOA. Инициатива IBM On Demand Operating Environment (ODOE) является большим шагом в этом направлении.
BPM является фрагментарной дисциплиной, сочетающей в себе множество различных стилей, нотаций и
средств. Например, использование UML обычно простирается от предметной области к BPM-уровню. Другой
часто используемой техникой, как указывается в работе
Baker и Longman, является описание событийно-обусловленных процессных
цепочек, представляющих собой концептуальные потоки процессов. Данная техника использует нотацию,
отличную от UML.
Более того, существует множество вполне адекватных подобных BPM-техникам подходов, которые можно
рассматривать как некие конкурентные преимущества консультационных компаний и вендоров систем класса
Enterprise Resourse Planning (ERP). В качестве примеров можно привести ARIS Implementation Platform®,
Line of Visibility Enterprise Modeling (LOVEMTM) и инициативу
IBM Component Business Modeling (CBM).
Последней тенденцией является определение стандартного пути представления исполняемых потоковых моделей
(например,
Business Process Execution Language for Web Services (BPEL)). BPEL расширяет сферу применения
процессных моделей от фазы анализа до фазы реализации. Подобные исполняемые модели поднимают весь спектр
новых вопросов, таких как:
Объектно-ориентированный анализ является весьма мощным и проверенным подходом, поэтому в SOAD
необходимо использовать техники OO-анализа настолько широко насколько это возможно. Чтобы успешно
применять OO-анализ в SOA-проектах, необходимо проверять одновременно более чем одну систему. При этом
модели вариантов использования будут по-прежнему играть важную роль. Однако, SOAD должен быть
преимущественно процессным, нежели основанным на вариантах использования. Поэтому в SOAD должна
присутствовать сильная связь между BPM и моделированием вариантов использования.
На уровне проектирования цель OO - сделать быстрым и эффективным проектирование, разработку и выполнение
гибких и расширяемых приложений. Объекты являются конструкциями ПО, отражающими поведение реальных
сущностей, моделями которых они служат. Например, объект Customer (Клиент) будет наделен именем,
контактной информацией, а также может иметь один или несколько ассоциированных с ним объектов,
олицетворяющих банковские счета клиента. С точки зрения OO, все является объектами.
Фундаментальными принципами OO являются:
CheckingAccount (Проверить баланс счета)
, SavingsAccount
(Сберегательный счет)
и LoanAccount (Ссудный счет)
. Если попробовать разобраться чуть подробнее (см.
Рис 3), то можно увидеть, что эти классы имеют много общих свойств, таких как, например, баланс счета,
возможность пополнять либо уменьшать баланс счета и так далее.Рис. 3: Пример наследования класса в нотации UML
Вместо того, чтобы дублировать код, который определяет и управляет этими свойствами, можно создать
общий родительский класс Account (Счет)
, который будет иметь баланс счета и сможет обрабатывать
транзакции, связанные с пополнением либо уменьшением счета. Все другие классы будут являться некими
специализированными формами объекта Account
. Например, класс LoanAccount
будет иметь отрицательный
баланс при значениях между нулем и некоторым условленным максимумом, а SavingsAccount
будет иметь
положительный баланс, отражать операцию начисления процентов и т. п.
CheckingAccount
и
соответствующего сообщения credit экземпляру класса SavingsAccount
. Когда экземпляр получает сообщение,
он выполняет соответствующую функцию, называемую методом, которая имеет то же наименование, что и
сообщение.FreeCheckAccount
и CheckingAccount
должны отвечать на сообщение debit ($100), но экземпляр FreeCheckingAccount
баланс должен дебетовать
счет ровно на $100, в то время как экземпляр CheckingAccount
должен дебетовать его баланс на $100 плюс
комиссия за транзакцию.Главная проблема современных ОО-методов проектирования при их использовании в сервисно-ориентированном
подходе - степень детализации их моделей находится на уровне класса, что является слишком низким уровнем
абстракции для моделирования бизнес-сервисов. Сильные ассоциации, такие как наследование, создают сильное
связывание (и, следовательно, сильную зависимость) между взаимодействующими сторонами.
Сервисно-ориентированная парадигма напротив способствует гибкости и возможности быстрого перестроения
систем посредством слабого связывания. В настоящее время в концепции SOA не существует поддержки
кроссплатформенного наследования и четкого представления экземпляра сервиса. Решение данных вопросов
позволило бы избежать многих проблем при реализации вспомогательных операций жизненного цикла сервисов,
подобных удаленному сбору мусора (здесь по-прежнему слово "мусор" следует трактовать как программные
объекты, в которых отпала необходимость - прим. перев.).
Приведенные рассуждения делают затруднительным прямое сравнение объектно-ориентированного подхода с
сервисно-ориентированным. Однако, объектно-ориентированный подход по-прежнему является весьма полезным
при проектировании основных классов и компонентной структуры сервисов. Более того, многие OOAD-техники,
такие как карты Classes, Responsibilities and Collaborations (CRC) например, могут оказаться удобнее при
моделировании сервисов, если их применять на более высоком уровне абстракции. Позднее мы вернемся в нашей
статье к этому вопросу.
Рис. 4 демонстрирует соответствие между уровнями видимости и фокусами объектно-ориентированного,
компонентно-ориентированного и сервисно-ориентированного подходов. Он также показывает, как данные
подходы соотносятся друг с другом в контексте SOA и SOAD.
Рис. 4: Уровни проектирования
Говоря о нотации - Unified Modeling Language (UML), будучи улучшенным несколькими дополнительными
стереотипами и профилями, вполне естественным образом становится ключевым элементом SOAD.
В процессной области Rational Unified Process (RUP) - признанная OOAD-методология поддержки анализа и
проектирования при итеративной разработке ПО, использование UML-моделей высокопродуктивно. Однако, в
основе RUP лежат принципы OOAD, поэтому RUP не так легко приспособить к использованию в ходе
SOA-проектирования. С точки зрения RUP, архитектурой системы является структура ее основных компонент,
взаимодействующих через определенные интерфейсы. Эти компоненты, в свою очередь, состоят из более мелких
компонент и так далее до степени детализации на уровне классов. Архитектура системы в SOA, напротив,
состоит из не имеющих состояния (stateless), полностью инкапсулированных и самодостаточных сервисов,
которые могут быть объединены общим понятием бизнес-сервиса и с высокой степенью точности маппированы в
BPM, как это показано на Рис. 5.
Рис. 5: Иерархия сервисов в SOAD
Данные сервисы формируются из набора совместно функционирующих или оркестрованных сервисов. Это не исключает ОО-подход, принятый в RUP, однако вводит иной уровень абстракции. Данный "супер-уровень" служит для инкапсуляции компонентов, спроектированных в виде артефактов RUP (программных сервисов), внутри формальной кроссуровневой структуры интерфейса.
В этом разделе мы рассмотрим требования, предъявляемые к SOAD, более подробно и попробуем определить его основные понятия и элементы. Нашей целью будет являться инициация дискуссии по вопросам формализации SOAD с целью определения направлений дальнейшей работы.
Для SOAD можно сформулировать следующие требования:
В настоящее время уже можно определить некоторые общие принципы и критерии качества, которые могут послужить основой процесса проектирования при использовании SOAD:
Техники моделирования на бизнес-уровне, исповедующие принцип "сверху вниз", например CBM, могут служить отправной точкой при моделировании в SOA. Но, как уже отмечалось, реализация SOA редко начинается с "чистого листа" - создание SOA-решения почти всегда заключается в интеграции унаследованных систем путем их декомпозиции на сервисы, операции, бизнес-процессы и бизнес-правила (см. также Рис. 6):
Рис. 6: Декомпозиция сервиса
Для идентификации и определения сервисов могут применяться любые OOAD-техники. Важно, однако, использовать и представление о системе более высокого уровня абстракции. Кроме того, поскольку проекты построения SOA-архитектур претендуют на большее, чем быть просто классическим проектом разработки, в ходе их реализации всегда существует необходимость в применении творческого подхода.
BPM и прямой анализ требований посредством интервью с акционерами, а также CBM являются
очевидными и хорошо зарекомендовавшими себя способами идентификации сервисов.
Предыдущий опыт показывает, что вышеуказанные способы следует усовершенствовать непрямыми техниками
анализа. Когда требуется идентифицировать сервисы, необходимо проинтервьировать продакт-менеджеров и
других бизнес-лидеров предприятия. Но, например, как должны быть реализованы планирование платежей и
система биллинга? Необходимо рассмотреть организационную структуру предприятия, которую предполагается
заложить при проектировании системы. Необходимо также принять во внимание все созданные в ходе
не-SOA-проектов модели вариантов использования. Терминология, используемая в маркетинговых презентация,
посвященных проектируемой системе, может является еще одним источником информации для идентификации
сервисов (в частности, можно использовать глаголы; наречия же, используемые в маркетинговых презентация,
в этом смысле дадут не много!).
Декомпозиция предметной области, анализ подсистем, создание целевой модели и другие подобные техники, как было отмечено в Endrei, являются первыми и самыми многообещающими попытками построения метода структуризации процессов SOA или методологии концептуализации сервисов, основанными на ранних работах Levi и Arsanjani. В развитие данной темы также внесла свой вклад работа FODA SEI.
Правильный выбор уровня абстракции является ключевым моментом при моделировании сервисов. Часто можно услышать совет моделировать до уровня крупных блоков. Это некоторое чрезмерное упрощение. Данное утверждение необходимо перефразировать следующим образом: моделировать настолько крупноблочно насколько это возможно, однако без потери важных элементов и обеспечивая непротиворечивость и полноту моделей. При этом при необходимости всегда имеется возможность разработки детальных абстракций сервисов. Поскольку SOA не эквивалентна веб-сервисам и SOAP, для получения доступа к сервисам на различных уровнях абстракции могут использоваться различные протокольные привязки. Другим вариантом является связывание нескольких взаимодействующих сервисов в крупные блоки, служащие одним из вариантов "фасадных" архитектурных шаблонов.
Необходимо определить корпоративные соглашения об обозначениях (пространства имен XML, систему имен Java-пакетов, Интернет-доменов). В этой связи можно рекомендовать следующее: всегда обозначать сервисы существительными, а их операции глаголами. Подобное правило является отличной практикой, введенной еще в ходе применения OOAD.
Кроме осознания необходимости использования при формализации SOAD комбинации OOAD, BPM и EA, существует также несколько важных понятий и аспектов SOAD, которые пока не получили своего смыслового наполнения:
Сервисы имеют различное назначение и могут использоваться различным образом: например, программные
сервисы отличны от бизнес-сервисов (как ранее было показано на Рис. 5). Кроме того, отдельные сервисы
могут быть оркестрованы (собраны) в законченные сервисы более высокого уровня.
Композиция сервисов упрощается исполняемыми моделями (например, выполненными в BPEL) - это то, с чем
не оперируют традиционные средства и методы моделирования.
Сервис имеет синтаксические и семантические характеристики, а также характеристики качества сервиса
(QoS), которые должны учитываться в моделях. В то же время формальные интерфейсные контракты
взаимодействия сервисов представляют собой нечто большее, чем может описать язык Web Services Description
Language (WSDL). В этой связи спецификация
WS-Policy является весьма важной в качестве дополнения к WSDL.
Желательным свойством, наряду с хорошо известным принципом архитектурной трассируемости, является
бизнес-трассируемость (в оригинале - business traceability; traceability, трассируемость - финансовый
термин, означающий возможность отнесения затрат на конкретную операцию или объект затрат - прим. перев.):
должна быть возможность прямой привязки всех возникающих в ходе разработки системы артифактов к языку,
понятному неэксперту предметной области. Это особенно важно для абстракций, напрямую используемых
на бизнес- и сервисном уровне. Закон Сарбейнса-Оксли (SOX) (англ. Sarbanes-Oxley act - закон, согласно
которому компании, акции которых котируются на фондовых биржах, регулируемых Комиссией по ценным бумагам
и биржам, должны вести финансовую отчетность в соответствии с общепринятыми принципами бухгалтерского
учета - прим. перев.) (см. статью Astor) является примером, для реализации которого и может потребоваться
бизнес-трассируемость.
В реальном мире не существует проектов, выполняемых с "чистого листа", поскольку всегда должны
приниматься во внимание унаследованные приложения (термин унаследованные приложения является синонимом
для термина "приложения, существующие в настоящее время"). Поэтому, вместо применения в чистом виде
подходов к проектированию по принципам "сверху вниз" или "снизу вверх", необходимо применение так
называемого сходящегося подхода.
Подход к проектированию по принципу "снизу вверх" может привести к бедности абстракций бизнес-сервисов в
случае, когда при проектировании руководствуются существующей IT-средой, а не имеющимися и будущими
бизнес-нуждами предприятия. С другой стороны, подход "сверху вниз" может породить недостаточные либо
нефункциональные характеристики требований, а также подвергнуть опасности показатели других критериев
качества архитектуры (например, проблемы производительности - ввиду недостатка нормализации (имеется
ввиду терминологическая и понятийная стандартизация предметной области - прим. перев.) модели предметной
области)) наряду с проблемами, ведущими к несогласованности на сервисном или компонентном уровнях.
В любой SOA для синтаксиса вызовов важно наличие формального интерфейсного соглашения. При моделировании предметной области также должны быть решены вопросы семантики (значение параметров и т. д.). Ответы на эти вопросы являются ключевыми при разработке любого B2B-сценария или сценария динамического вызова. Данные сценарии являются краеугольными понятиями концепции SOA, которая привносит гибкость и быстроту адаптации как ответ на новые бизнес-нужды в мире слияний, поглощений, бизнес-реструктуризаций и глобализации.
Данный вопрос относится к области управления знаниями и концепции жизненного цикла сервиса: как
правильно разработать сервисы и сделать их доступными для повторного использования сразу после
концептуализации?
Сервисы необходимо идентифицировать и описывать, имея ввиду один из главных критериев SOA - свойство
повторности использования (и возможность сборки). Если компонент (или сервис) не может быть повторно
использован, он не должен представляться как сервис. Он может быть связан с другим сервисом архитектуры
предприятия, но не будет сервисом в полном смысле этого слова.
Однако, даже если свойство повторности использования закладывается с самого начала, методология
проектирования должна иметь формализованную методологию сборки сервисов. Использование сервиса
несколькими клиентами - основная цель проектирования в SOA (например, при создании реестра сервисов -
UDDI-реестра масштаба предприятия).
Предметной областью данного примера является процесс управления оказанием клиентам компании услуг по
техобслуживанию автомобилей. Мы приводим этот пример для иллюстрации обсуждающихся в этой статье
вопросов, касающихся SOAD.
Наряд на выполнение авторемонтных работ представляет собой соглашение между автосервисной компанией и
клиентом, согласно которому автосервисная компания выполняет ряд плановых или аварийных мероприятий по
техобслуживанию автомобиля клиента, таких как плановое техобслуживание по достижении пробега в 50000
миль, смена тормозных колодок, замена покрышек или масла.
Бизнес-сценарий (показанный на Рис. 7) в этом случае следующий:
Рис. 7: Укрупненное представление примера
Если вы попробуете создать приложение, реализующее вышеописанный сценарий, может получиться набор классов, подобный показанному на Рис. 8.
Рис. 8: Диаграмма классов приложения, реализующего пример
Если приложение, реализующее пример, будет создаваться как OO-приложение, программные объекты должны
содержать все необходимые бизнес-правила и описывать осуществляемые бизнес-процессы.
Однако, у данного подхода существует несколько практических недостатков:
SOAD прекрасно решает данные проблемы. Поскольку согласно данному подходу сервисы группируются по
признаку совместности функционирования, а не наличия свойства инкапсуляции (функционирование плюс
данные), перечень сервисов будет несколько отличаться от модели бизнес-объектов.
Например, вероятно следует объединить Work Order (Наряд на выполнение работ) и Work Order Item (Пункт
наряда на выполнение работ) с Work Order Services (Услуги, оказываемые согласно наряду на выполнение
работ) и создать сервисы Scheduling (Планирование), Catalog (Каталог) и Inventory (Список). Поскольку не
существует экземпляров сервисов, не существует и эквивалента отношений между сервисами. Модель сервисов
для нашего примера показана на Рис. 9.
Рис. 9: Модель сервисов для примера
В отличие от OO-подхода, данная модель не описывает функциональную систему. Она не содержит ни
потоков, ни описаний бизнес-событий или бизнес-правил. В SOA хореография бизнес-процессов определяет
очередность и последовательность во времени выполнения вызовов сервисов.
Концептуально, весь бизнес, начиная с первого контакта с клиентом и заканчивая завершением работ и
оплатой счета, на макро-уровне представляет собой одну логическую единицу работы с продолжительностью
от нескольких дней до нескольких недель. Эта логическая единица работы и генерирует прибыль.
Однако, на практике мы имеем дело с целым спектром деятельностей (например, определение состава работ,
планирование встречи, выбор необходимых запчастей и ресурсов, выполнение работ по техобслуживанию),
которые осуществляются попеременно с относительно продолжительными периодами простоя. В IT-системе не
существует реального процесса, который длился бы больше нескольких минут, при этом состояние
бизнес-процесса характеризуется состоянием данных в базе данных между событиями.
Процессы подобного типа могут быть адекватно описаны с помощью модели перехода состояний (state
transition model) (выполненной, например, в UML). Рис. 10 демонстрирует пример того, как можно
смоделировать бизнес-поток с использованием метода конечных автоматов. Данная иллюстрация является
общим представлением того, как в ходе осуществления бизнес-процесса может меняться состояние наряда на
выполнение работ.
Рис. 10: BPM для примера
Хореография бизнес-процессов фокусируется на транзакциях между состояниями. Отдельные операции
отражают соответствующие изменения состояния.
Рис. 11 показывает пример хореографии бизнес-процесса, охватывающей шаги 1-5 бизнес-сценария, показанного
на Рис. 10 (например, клиент определяет работы, которые необходимо выполнить для его автомобиля и
назначает встречу для выполнения работ).
Рис. 11: Модель бизнес-взаимодействия для примера
В этой статье мы обсудили и обозначили необходимость разработки нового, сходящегося подхода к анализу
и проектированию SOA-систем, служащего неким мостом между бизнесом и IT. Мы также сделали предположение,
что этот новый междисциплинарный SOAD-подход должен являться целостной методологией моделирования,
строящейся на современных, проверенных и доказавших свою эффективность подходах OOAD, EA и BPM.
В то время как нотация и методология применения SOAD еще только должны будут детально описаны, ключевые
элементы подхода, такие как концептуализация (или определение) сервисов, их классификация и агрегация,
политики и аспекты использования, сходящийся подход к моделированию, семантические переходы и сборка
сервисов (для повторного использования), уже могут быть определены.
SOAD потребует улучшений существующих методов программной инженерии, направленных на дальнейшее повышение
удобства их использования и расширения возможностей применения в проектах разработки корпоративных
приложений. Через некоторое время будут разработаны и лучшие практики и шаблоны.
Очевидно, что UML будет и в дальнейшем доминировать в качестве нотации моделирования процессов, однако,
вероятно, потребуется его улучшение для использования в SOAD с его более широкой предметной областью.
Следующими шагами на пути формализации SOAD будет определение необходимой сквозной методологии применения,
нотации, необходимых ролей, их обязанностей и сфер ответственности, а также утверждение предлагаемого
подхода в ходе реализации проектов.