UBS | Публикации о технологиях веб-сервисов

Элементы сервисно-ориентированного анализа и проектирования
Междисциплинарный подход к моделированию в проектах построения SOA

Olaf Zimmermann, Старший IT-архитектор (Senior IT Architect), IBM Enterprise
Pal Krogdahl, Системный архитектор (Solution Architect), IBM
Clive Gee, Старший архитектор решений (Senior Solution Architect), IBM

© IBM 2004, Оригинальный текст на английском языке
© UBS 2005, Перевод и адаптация на русский язык

На русском языке публикуется впервые с разрешения авторов


Опыт первых проектов построения сервисно-ориентированных архитектур (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 существует три основных уровня абстракции:

  • Операции: Транзакции, представляющие собой отдельные логические единицы работы (logical unit of work, LUW). Выполнение операции обычно заключается в однократном или многократном чтении, записи или изменении данных. SOA-операции можно прямо сопоставить с методами в объектно-ориентированном подходе. Они имеют специфичный структурированный интерфейс и возвращают также структурированные отклики. Так же как и в случае методов, выполнение некоторой операции может привести к инициации выполнения других операций.
  • Сервисы: Представляют собой логические группы операций. Например, если мы посмотрим на CustomerProfiling (Создание профиля клиента) как на сервис, то тогда Lookup customer by telephone (Найти клиента по номеру телефона), List customers by name and postal code (Составить список клиентов с именами и почтовыми индексами) и Save data for new customer (Сохранить данные о новом клиенте) будут ассоциированными с этим сервисом операциями.
  • Бизнес-процессы: Стабильно существующий набор действий либо деятельностей, выполняемых с определенной бизнес-целью. Бизнес-процессы обычно осуществляют многократные вызовы сервисов. Примерами бизнес-процессов являются: Initiate New Employee (Принять на работу нового сотрудника), Sell Products or Services (Продавать товары или услуги) и Fulfill Order (Исполнить приказ).
В терминах SOA бизнес-процесс состоит из совокупностей операций, которые исполняются в заданном порядке согласно заданному набору бизнес-правил. Упорядочение, отбор и исполнение операций называется хореографией сервиса или процесса. Как правило, хореографируемые (здесь мы вводим новый русскоязычный термин, отражающий перевод англоязычного choreographed - прим. перев.) сервисы вызываются для того, чтобы реализовать какие-либо бизнес-события.

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

Почему недостаточно BPM, EA и OOAD

Опыт первых проектов построения 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. По горизонтальной оси рисунка представлены фазы жизненного цикла проекта, по вертикальной - различные уровни абстракций или области знаний, где обычно применяется моделирование.

Позиционирование BPM, EA и OOAD

Рис. 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 (элементы и техники) описываемого нового подхода.

SOAD и его составляющие: OOAD, BPM и EA

Рис. 2: SOAD и его составляющие: OOAD, BPM и EA

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

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 расширяет сферу применения процессных моделей от фазы анализа до фазы реализации. Подобные исполняемые модели поднимают весь спектр новых вопросов, таких как:

  • Какие аспекты должны быть описаны посредством BPEL, а какие - посредством WSDL? В чем различие между процессной моделью и более традиционными программными моделями?
  • Каким образом такие элементы как нефункциональные требования и характеристики качества сервиса должны учитываться в моделях?
  • Какое количество логики должно реализовываться с помощью расширений BPEL-движков для языков программирования, а какое ее количество - с помощью более привычного программирования, например, в J2EE?
  • Каким образом можно оценить качество исполняемых процессных моделей и какие лучшие практики могут быть для этого применены?
  • Какую роль играет инжиниринг BPEL-потоков? Является ли эта роль ролью в области бизнес-экспертизы (например, роль аналитика) либо ролью в области разработки (например, роль архитектора ПО)?
Все существующие на сегодняшний день BPM-подходы могут рассматриваться в качестве отправной точки для SOAD, однако, их необходимо усилить дополнительными техниками, позволяющими отделить предполагаемые сервисы и их операции от процессных моделей. Более того, процессное моделирование в SOAD должно быть синхронизировано с моделированием вариантов использования (здесь дается наиболее распространенный в русскоязычной литературе вариант перевода англоязычного термина "use case" - прим. перев.) на стадии проектирования и отвечать на вопросы, относящиеся к моделированию с помощью BPEL.

Oбъектно-ориентированная (ОО) парадигма против сервисно-ориентированной (SO)

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

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

Фундаментальными принципами OO являются:

  • Инкапсуляция: Объектом ПО является обособленный программный пакет, имеющий физические свойства (данные) и функциональность (поведение), имитирующие его аналог в реальном мире. Объект Account (Счет), например, имеет баланс и механизм его пополнения либо уменьшения.
  • Сокрытие информации: Хорошо структурированные объекты имеют простые интерфейсы и не раскрывают для внешнего мира внутренние механизмы своего функционирования. Примером сокрытия информации, заимствованным из реального мира, может служить такая аналогия: нет необходимости детально понимать, как работает автомобиль, чтобы ездить на нем.
  • Классы и экземпляры: Классы представляют собой шаблоны, определяющие какой тип свойств и поведения имеет данный тип объектов ПО. Экземплярами называются обособленные объекты, имеющие индивидуальные значения вышеупомянутых свойств. Создание нового экземпляра класса называется инстанциацией. Если использовать биологическую аналогию, то человек будет являться классом. Все люди имеют такие свойства как рост, вес, цвет волос и глаз и т. д. Каждый человек является экземпляром класса, например, HumanBeing, со своими значениями роста, веса и т. д. Классы не имеют ограничений на время существования, в то время как их экземпляры имеют ограниченное время жизни.
  • Ассоциации и наследование: Способность отражать ассоциации между классами и объектами является ключевым понятием ОО. Наследование можно определить как сильную форму ассоциации, используемую для отражения отношений "является" ("is-a"): аналогичным образом биологические виды организованы в иерархии царств, типов, классов, отрядов, семейств, родов и видов. В дальнейшем мы часто будем встречать аналогии иерархии объектов ПО в реальном мире. Когда мы создаем финансовое приложение Entities, нам скорее всего потребуется спроектировать такие классы как CheckingAccount (Проверить баланс счета), SavingsAccount (Сберегательный счет) и LoanAccount (Ссудный счет). Если попробовать разобраться чуть подробнее (см. Рис 3), то можно увидеть, что эти классы имеют много общих свойств, таких как, например, баланс счета, возможность пополнять либо уменьшать баланс счета и так далее.

    Пример наследования класса в нотации UML

    Рис. 3: Пример наследования класса в нотации UML

    Вместо того, чтобы дублировать код, который определяет и управляет этими свойствами, можно создать общий родительский класс Account (Счет), который будет иметь баланс счета и сможет обрабатывать транзакции, связанные с пополнением либо уменьшением счета. Все другие классы будут являться некими специализированными формами объекта Account. Например, класс LoanAccount будет иметь отрицательный баланс при значениях между нулем и некоторым условленным максимумом, а SavingsAccount будет иметь положительный баланс, отражать операцию начисления процентов и т. п.

  • Обмен сообщениями: Для того, чтобы выполнять любую полезную работу, объекты ПО должны иметь возможность взаимодействовать друг с другом. Взаимодействовать они могут, обмениваясь сообщениями. Например, перечисление $1000 со счета, обслуживающего чеки клиента, на сберегательный счет может быть выполнено путем отправки сообщения debit с аргументом $1000 экземпляру класса CheckingAccount и соответствующего сообщения credit экземпляру класса SavingsAccount. Когда экземпляр получает сообщение, он выполняет соответствующую функцию, называемую методом, которая имеет то же наименование, что и сообщение.
  • Полиморфизм: Данный термин описывает ситуацию, когда при получении одного и того же сообщения два или более класса реагируют на него различным образом. Например, и FreeCheckAccount и CheckingAccount должны отвечать на сообщение debit ($100), но экземпляр FreeCheckingAccount баланс должен дебетовать счет ровно на $100, в то время как экземпляр CheckingAccount должен дебетовать его баланс на $100 плюс комиссия за транзакцию.
ОО поддерживает весь жизненный цикл создания приложений, включая анализ, проектирование и собственно разработку приложений:
  • OOAD позволяет определить оптимальный набор объектов и наиболее естественную иерархию классов для их реализации.
  • ОО-разработка фокусируется на инкрементной разработке приложений, в ходе которой за одну итерацию реализуется лишь один бизнес-сценарий или вариант использования. Такой инструментарий как IBM WebSphere® Studio Application Developer помогает разработчикам быстро создавать и тестировать ОО-приложения.
  • ОО-runtime-среда, реализуемая, например, с помощью JavaTM Virtual Machine и J2EE, имеющей механизм разнесения объектов по разным серверам для обеспечения взаимодействия между ними, выполняет программный код и предоставляет приложениям сервисы (такие как сбор мусора например (удаление ресурсов, которые больше не нужны как объекты)).

Главная проблема современных ОО-методов проектирования при их использовании в сервисно-ориентированном подходе - степень детализации их моделей находится на уровне класса, что является слишком низким уровнем абстракции для моделирования бизнес-сервисов. Сильные ассоциации, такие как наследование, создают сильное связывание (и, следовательно, сильную зависимость) между взаимодействующими сторонами. Сервисно-ориентированная парадигма напротив способствует гибкости и возможности быстрого перестроения систем посредством слабого связывания. В настоящее время в концепции 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.

Иерархия сервисов в SOAD

Рис. 5: Иерархия сервисов в SOAD

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

Элементы SOAD

В этом разделе мы рассмотрим требования, предъявляемые к SOAD, более подробно и попробуем определить его основные понятия и элементы. Нашей целью будет являться инициация дискуссии по вопросам формализации SOAD с целью определения направлений дальнейшей работы.

Что дает SOAD?

Для SOAD можно сформулировать следующие требования:

  • Для SOAD должны быть формально (максимально формально) определены методология (применения SOAD - прим. перев.) и нотация, как это сделано для других методологий проектирования. SOAD не должен начинаться с "чистого листа": комбинируя нужным образом элементы OOAD, BPM и EA, можно определить основные элементы SOAD.
  • SOAD должен иметь структурированный метод концептуализации сервисов:
    • Использование OOAD позволяет определить классы и объекты на уровне приложения, в то время как с помощью BPM разрабатываются событийные модели. SOAD же позволяет объединить эти результаты в единое целое.
    • Метод концептуализации сервисов SOAD должен быть ориентирован не на варианты использования, а на бизнес-события и процессы. Разработка моделей вариантов использования должна являться вторым шагом, выполняемым на более низком уровне абстракции.
    • Метод концептуализации должен включать в себя синтаксис, семантику и политики использования. Это необходимо для построения специализированных конструкций моделей, обеспечения семантических переходов между ними и runtime discovery (динамический поиск сервиса по заданному описанию (например, с помощью WSDL-файла) в UDDI-реестре, привязка к нему и вызов для исполнения - прим. перев.).
  • Для SOAD должны быть сформулированы четкие критерии качества и лучшие практики (дающие, например, ответ на вопрос о степени детализации моделей). Должен быть также решен вопрос о ролях, поднимаемый в BPEL, а именно: каковы сферы ответственности для каждой из ролей (например, для ролей Разработчика, Архитектора и Аналитика)?
  • SOAD также должен давать ответ на вопрос: что не является "правильным" сервисом? Например: объект, не обладающий свойством повторности использования, не может являться объектом рассмотрения SOA (т. е. сервисом). Другим примером являются нефункциональные требования систем реального времени, которые не порождают каких-либо накладных расходов при обработке XML-контента.
  • SOAD должен способствовать сквозному моделированию (т. е. созданию моделей на всех уровнях абстракции системы - прим. перев.) и обладать обширной инструментальной поддержкой. Если предполагается, что SOA привносит в бизнес гибкость и быстроту адаптации, то же самое ожидается и от поддерживающего SOA метода, связывающего бизнес-область с областями разработки архитектуры и проектирования приложений.

Критерии качества

В настоящее время уже можно определить некоторые общие принципы и критерии качества, которые могут послужить основой процесса проектирования при использовании SOAD:

  • Корректно созданные сервисы привносят в бизнес гибкость и быстроту адаптации. Они способствуют простоте реконфигурирования и повторности использования систем посредством слабого связывания, инкапсуляции и сокрытия информации.
  • Правильно спроектированные сервисы (количество зависимостей между которыми минимизированы, а имеющиеся - четко прописаны) применимы не только в корпоративных приложениях.
  • Абстракции сервисов должны образовывать единое целое, должны быть закончены и непротиворечивы. Например, при проектировании сервисов и их операций можно вспомнить о методе Create, Read, Update, Delete and Search (CRUDS).
  • Часто высказывается мнение, что сервисы (например, не являющиеся диалоговыми (т. е. не использующие при взаимодействии диалоговый тип обмена сообщениями - прим. перев.)) не имеют состояния как объекты (stateless services). Данное утверждение должно быть ослаблено по отношению к сервисам в том смысле, что они могут не иметь состояния настолько, насколько это возможно в конкретной проблемной области или в конкретном контексте.
  • Система имен сервисов должна быть понятной экспертам предметной области, не обладающими глубокими техническими знаниями.
  • В SOA все сервисы должны следовать единой, легко идентифицируемой (например, с помощью используемых в ходе проектирования шаблонов и образцов) философии проектирования и использовать одни и те же шаблоны взаимодействия.
  • При разработке сервисов, а также при использовании их потребителями услуг в дополнение к знанию предметной области должны быть необходимы лишь базовые навыки программирования. Экспертные знания в области промежуточного ПО (ПО промежуточного уровня, middleware) должны быть необходимы только незначительному числу специалистов, работающих в компаниях-вендорах, занимающихся разработкой инструментария и IDE для создания веб-сервисов, а не в компаниях, создающих корпоративные SOA-приложения.

Идентификация и определение сервиса

Техники моделирования на бизнес-уровне, исповедующие принцип "сверху вниз", например CBM, могут служить отправной точкой при моделировании в SOA. Но, как уже отмечалось, реализация SOA редко начинается с "чистого листа" - создание SOA-решения почти всегда заключается в интеграции унаследованных систем путем их декомпозиции на сервисы, операции, бизнес-процессы и бизнес-правила (см. также Рис. 6):

  • Существующие приложения и ПО вендоров декомпозируются на наборы отдельных сервисов, каждый из которых представляет собой группу связанных операций (подход "снизу вверх").
  • Бизнес-процессы и бизнес-правила формулируются путем абстрагирования при изучении приложений в отдельных BPM, управляемых бизнес-моделью хореографии сервисов.
Декомпозиция сервиса

Рис. 6: Декомпозиция сервиса

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

Прямой и непрямой бизнес-анализ

BPM и прямой анализ требований посредством интервью с акционерами, а также CBM являются очевидными и хорошо зарекомендовавшими себя способами идентификации сервисов.

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

Декомпозиция предметной области

Декомпозиция предметной области, анализ подсистем, создание целевой модели и другие подобные техники, как было отмечено в Endrei, являются первыми и самыми многообещающими попытками построения метода структуризации процессов SOA или методологии концептуализации сервисов, основанными на ранних работах Levi и Arsanjani. В развитие данной темы также внесла свой вклад работа FODA SEI.

Степень детализации моделей сервисов

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

Соглашения об обозначениях

Необходимо определить корпоративные соглашения об обозначениях (пространства имен XML, систему имен Java-пакетов, Интернет-доменов). В этой связи можно рекомендовать следующее: всегда обозначать сервисы существительными, а их операции глаголами. Подобное правило является отличной практикой, введенной еще в ходе применения OOAD.

Первые элементы SOAD

Кроме осознания необходимости использования при формализации 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-приложение, программные объекты должны содержать все необходимые бизнес-правила и описывать осуществляемые бизнес-процессы.

Однако, у данного подхода существует несколько практических недостатков:

  • На многих шагах приведенного примера осуществляется взаимодействие существующих унаследованных систем с базами данных (например, биллинговых систем, систем планирования и инвентаризации), которые, скорее всего, не были спроектированы с учетом OO-парадигмы (в подобных ситуациях может помочь применение adapter pattern или mediator pattern).
  • Чтобы сделать систему максимально гибкой, необходимо, чтобы процессы или потоки работ могли быть модифицированы без внесения изменений в программный код. Это может обеспечить соблюдение следующих правил:
    • Для осуществления стандартного сервисного техобслуживания по достижении пробега в 24000 милей требуется 4 литра масла. Дополнительные объемы масла должны использоваться только в случае превышения данной нормы или в случае, если клиенту требуется масло высшего качества (например, синтетическое масло).
    • Существует ряд стандартизированных для каждой отрасли норм трудозатрат, необходимых для выполнения работ по техобслуживанию автомобилей, которые можно почерпнуть из унаследованных систем. Пока норма трудозатрат не будет превышена на X%, клиенту должен выставляться счет согласно стандартной стоимости человеко-часа. Только в случае превышения нормы появляется основание для расчета дополнительной оплаты работ.
    • Если трудозатраты на техобслуживание превышают плановые на Y%, клиент должен своевременно оповещаться об этом.

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

Например, вероятно следует объединить Work Order (Наряд на выполнение работ) и Work Order Item (Пункт наряда на выполнение работ) с Work Order Services (Услуги, оказываемые согласно наряду на выполнение работ) и создать сервисы Scheduling (Планирование), Catalog (Каталог) и Inventory (Список). Поскольку не существует экземпляров сервисов, не существует и эквивалента отношений между сервисами. Модель сервисов для нашего примера показана на Рис. 9.

Модель сервисов для примера

Рис. 9: Модель сервисов для примера

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

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

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

Процессы подобного типа могут быть адекватно описаны с помощью модели перехода состояний (state transition model) (выполненной, например, в UML). Рис. 10 демонстрирует пример того, как можно смоделировать бизнес-поток с использованием метода конечных автоматов. Данная иллюстрация является общим представлением того, как в ходе осуществления бизнес-процесса может меняться состояние наряда на выполнение работ.

BPM для примера

Рис. 10: BPM для примера

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

Рис. 11 показывает пример хореографии бизнес-процесса, охватывающей шаги 1-5 бизнес-сценария, показанного на Рис. 10 (например, клиент определяет работы, которые необходимо выполнить для его автомобиля и назначает встречу для выполнения работ).

Модель бизнес-взаимодействия для примера

Рис. 11: Модель бизнес-взаимодействия для примера

Выводы и перспективы на будущее

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

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

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

Очевидно, что UML будет и в дальнейшем доминировать в качестве нотации моделирования процессов, однако, вероятно, потребуется его улучшение для использования в SOAD с его более широкой предметной областью.

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


Комментарии к статье принимаются по адресу info@ubs.ru.

Вопросы? Ответим в течение часа.