Содержание


Интеграция BPMN и SoaM

Часть 1. Мотивация и подход

Comments

Серия контента:

Этот контент является частью # из серии # статей: Интеграция BPMN и SoaM

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Интеграция BPMN и SoaM

Следите за выходом новых статей этой серии.

В этой состоящей из трех частей серии "Интеграция BPMN и SoaML" объясняется использование взаимодополняющих сильных сторон каждого из стандартов. В статьях серии показывается, как:

  • Задавать требования к интеграции BPMN и SoaML, чтобы использовать преимущества их взаимодополняющих возможностей.
  • Лучше понимать концепции BPMN и SoaML, изучая их с разных точек зрения.
  • Сообщать о преобразованиях типа "модель в модель" для перевода BPMN в (из) SoaML при изменении моделей между поддерживаемыми инструментами.
  • Определять взаимосвязи между элементами модели, описанными на одном языке, с соответствующими концепциями на другом. Например, поведение участника в SoaML может быть связано с BPMN-процессом, описывающим реализацию этого поведения.
  • Оптимально использовать оба языка моделирования.
  • Применять более эффективные методики моделирования для повышения ценности моделей, понимания сложности, улучшения планирования и использования других преимуществ.
  • Создавать более эффективные описания многократно используемых активов.
  • Продвигать в инструментах поставщиков возможности интеграции, имеющиеся в спецификациях OSLC.
  • Предоставлять основу для расширения существующей спецификации OSLC дополнительными возможностями связывания.

Мотивация для интеграции BPMN и SoaML

Консорциум Object Management Group (OMG) утвердил спецификацию Business Process Modeling Notation (BPMN) 2.0, содержащую по сравнению со стандартом BPMN 1.0 ряд существенных обновлений, включая поддержку оркестровки, кооперации и хореографии процессов. OMG также утвердил язык SOA Modeling Language (SoaML) 1.0, являющийся расширением языка Unified Modeling Language (UML) 2 для моделирования сервис-ориентированной архитектуры (SOA). Эти стандарты во многом пересекаются, но каждый из них расставляет собственные акценты.

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

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

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

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

В части 2 описываются подходы каждого языка к следующим вопросам:

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

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

Структура и поведение

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

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

Пользователи BPMN и SoaML

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

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

Архитекторы решений отвечают за разработку эффективной и рациональной архитектуры решения, соответствующей текущим и ожидаемым требованиям. Они могут использовать UML – одну из основных спецификаций OMG для Model Driven Architecture (MDA), в которую добавлен профиль языка моделирования общего назначения SoaML. SoaML предоставляет широкий спектр возможностей для бизнес-анализа и анализа решений, включая проектирование и создания средств и сервисов. Интеграция BPMN и SoaML дает группам разработки готовое решение для создания и потребления сервисов.

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

Требования к интеграции BPMN и SoaML

Интеграция должна отвечать следующим требованиям:

Требование 1. Бизнес-аналитики могут схематически изображать BPMN-процессы, используя либо простую оркестровку, либо более детальные кооперацию (collaboration), разговоры (conversation) или хореографию (choreography) с другими участниками процессов. Эти процессы можно рассматривать как варианты использования UML для анализа требований. Каждая задача в дорожке, каждая дорожка в процессе и каждый процесс могут представлять требование к бизнес-действию. Затем эти задачи могут использоваться при идентификации сервисов-кандидатов для выполнения задач. Бизнес-аналитики должны иметь возможность создавать связи между задачей, дорожкой или процессом BPMN и одним или несколькими элементами SoaML ServicesArchitecture или ServiceInterface.

Требование 2. После определения возможностей SoaML его можно использовать для описания интерфейсов сервисов, предоставляющих эти возможности. Участники, предоставляющие сервисы, должны иметь методы их реализации.

Требование 3. Сервисы, определенные посредством SoaML ServicesInterface и предоставленные участниками в SoaML-процессе, могут быть вызваны с помощью ServiceTasks в BPMN-процессе. Эта возможность позволяет повторно использовать в BPMN сервисы, определенные посредством SoaML.

Требование 4. Метод (или реализация) операции сервиса, принадлежащий участнику, может быть смоделирован в SoaML как UML-метод Behavior (поведение). Методом Behavior могут быть Activity, Interaction, StateMachine или OpaqueBehavior. Принадлежащие участнику Behavior являются методами операций сервисов, предоставляемых участником, и используют операции сервисов, необходимые участнику. Должна существовать возможность использования BPMN-процесса для описания метода реализации операции сервиса.

Требование 5. BPMN может определять сообщения и объекты данных. SoaML может определять классы, типы данных, простые типы и типы сообщений. Должна быть возможность использования SoaML для определения информации для BPMN. Также должна быть возможность использования любой информации, определенной в BPMN-процессе, в интерфейсах сервисов и методах в SoaML.

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

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

  • Определять возможности SoaML (или сервисы-кандидаты) из BPMN-процессов.
  • Определять, описывать и реализовывать сервисы с помощью SoaML.
  • Использовать BPMN для определения метода реализации элемента Operation SoaML-интерфейса ServiceInterface, определенного участником.
  • Вызывать операцию сервиса, определенную SoaML-интерфейсом ServiceInterface и предоствленную SoaML-участником, как ServiceTask в BPMN-процессе.
  • Совместно использовать спецификации (классы, типы данных, сообщения) в BPMN и SoaML.
  • Использовать SoaML для определения жизненных циклов BPMN-объектов данных, реагирующие на бизнес-события.

Подходы к интеграции

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

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

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

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

Руководящие принципы выбора подхода к интеграции

Разработке подхода к интеграции помогут следующие руководящие принципы:

  • Определяйте возможные вопросы в спецификациях BPMN и SoaML:
    • Повышайте качество спецификаций.
    • Улучшайте понимание спецификаций.
    • Способствуйте интеграции независимо от ее реализации.
  • Минимизируйте нежелательную связанность между спецификациями и поддерживающими их метамоделями.
  • Обеспечивайте автономность спецификаций и возможность их использования как по отдельности, так и вместе.
  • Минимизируйте затраты на реализацию для поставщиков и пользователей.
  • Уделяйте основное внимание взаимодополняющим возможностям моделирования, а не сходствам и совпадениям.
  • Определяйте концепции и темы, отвечающие требованиям, независимо от специфики BPMN и SoaML:
    • Что такое структура и поведение взаимодействующих поставщиков и потребителей сервисов?
    • Какие сервисы предоставляются и кто является их потребителем?
    • Как реализуются и используются сервисы?
  • Исследуйте сходства и различия на конкретных примерах.
  • Используйте сильные стороны каждой спецификации и избегайте их слабых мест.
  • Отдавайте предпочтение семантически богатым связям между элементами в стандартах, а не обмену информацией между ними с соответствующими преобразованиями.
  • Обеспечивайте поддержку обмена информацией.

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

Поскольку BPMN и SoaML разрабатывались независимо разными группами (с некоторым пересечением) и в настоящее время являются принятыми спецификациями, в каждый из этих стандартов интеграция изначально не закладывалась. Хотя процесс жизненного цикла спецификаций OMG поощряет интеграцию спецификаций, их разработчикам зачастую приходится учитывать специфичные RFP-требования, ограниченные ресурсы и сжатые сроки. Эти факторы вынуждают при разработке спецификации уделять основное внимание специфичным RFP-требованиям, иногда в ущерб интеграции с другими стандартами.

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

Подход к интеграции 1. Интеграция отсутствует

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

Подход к интеграции 2. Обмен моделями

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

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

Чтобы свести к минимуму эти проблемы, следует придерживаться методологий или передового опыта, снижающих потребность в редактировании артефактов, полученных при обмене между инструментами. Например, BPMN можно использовать для конкретной высокоуровневой, независимой от вычислений бизнес-модели (CIM). Затем можно применить преобразование модель-в-модель для создания в SoaML базовой платформенно-независимой модели (PIM), используемой при разработке SOA-моделей для конкретной платформы (PSM) и генерирования кода. В этом подходе для различных ролей применяются разные нотации и инструменты, позволяющие воспользоваться сильными сторонами каждого аспекта полного жизненного цикла проекта. Подробное описание этого подхода выходит за рамки данной статьи, однако отображения модель-в-модель могут быть весьма полезными.

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

Подход к интеграции 3. Интеграция с помощью метамодели

Этот подход обеспечивает наилучшую интеграцию, но имеет высокую стоимость разработки. Вместо изменения спецификаций BPMN или SoaML можно создать новую объединяющую метамодель для расширения и связывания спецификаций. Объединяющую метамодель можно создать, например, с помощью пакета UML 2, метамодели MOF, профиля UML или спецификаций Open-Services for Lifecycle Collaboration (OSLC). Затем в BPMN- или SoaML-инструменты можно включить поддержку объединяющей метамодели или создать отдельный инструмент, поддерживающий обе спецификации и интеграцию.

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

Заключение

BPMN и SoaML – два стандарта, недавно принятых консорциумом OMG. Хотя эти стандарты во многом пересекаются, каждый из них расставляет собственные акценты. BPMN используется для простой оркестровки действий в бизнес процессе и распространяется на поддержку кооперации процессов, а затем на хореографию взаимодействий между процессами. SoaML предназначен для описания архитектур сервисов и инкапсулирует взаимодействия между участниками архитектуры сервисов, используя контракты сервисов для моделирования соглашений об уровнях обслуживания (SLA).

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


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: Integrating BPMN and SoaML: Part 1. Motivation and approach (EN).
  • Моделирование SOA, часть 1. Идентификация сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2007 г.): первая статья в серии из пяти частей, посвященной разработке программного обеспечения на основе сервис-ориентированной архитектуры (SOA) (EN).
  • Моделирование SOA, часть 2. Описание сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2007 г.): вторая статья в серии из пяти частей, посвященной разработке программного обеспечения на основе сервис-ориентированной архитектуры (SOA) (EN).
  • Моделирование SOA, часть 3. Создание сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2007 г.): третья статья в серии из пяти частей, посвященная практической реализации основанных на SOA Web-сервисов (EN). Создание сервисов начинается с решений о том, какой компонент какие сервисы будет предоставлять. После принятия этих решений моделируется реализация функциональности каждого сервиса и практическое использование необходимых сервисов. Затем с помощью имеющейся в IBM Rational Software Architect функции выполняется преобразование UML в SOA для создания Web-сервиса, который можно использовать в IBM WebSphere Integration Developer для реализации, тестирования и развертывания готового решения.
  • Моделирование SOA, часть 4. Компоновка сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2007 г.): четвертая статья в серии из пяти частей, посвященная сборке и подключению поставщиков сервисов, смоделированных в части 3 Создание сервисов, и координации их взаимодействия для предоставления готового решения, соответствующего бизнес-требованиям (EN). В ней также демонстрируется выполнение бизнес-требований участником сервиса.
  • Моделирование SOA, часть 5. Реализация сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2007 г.): пятая статья в серии из пяти частей, посвященная практической реализации архитектуры, согласованной с архитектурными и проектными решениями, принятыми в модели сервисов (EN).
  • Статья Сервис-ориентированные моделирование и архитектура: идентификация, описание и реализация сервисов для вашей SOA (Али Арсанджани (Ali Arsanjani), ноябрь 2004 г.) посвящена методике Service Oriented Modeling and Architecture (SOMA), разработанной IBM Global Business Services (EN).
  • Моделирование бизнес-сервисов (Джим Амсден (Jim Amsden), developerWorks, октябрь 2005 г.). В этой статье описывается взаимосвязь между моделированием бизнес-процессов и моделированием сервисов, позволяющая получить выгоду от обоих (EN).
  • Проектирование и разработка более эффективной SOA. Часть 1: введение в интегрированные возможности IBM по проектированию и созданию улучшенной SOA (developerWorks, май 2011 г.): первая статья серии из пяти частей, посвященной коммерческим решениям для проектирования и разработки сервис-ориентированных систем. Эта статья начинается с обсуждения некоторых перспектив и проблем, связанных с переходом на сервис-ориентированный подход в ИТ-системах. Затем в ней дается общее описание передовых методик и инструментов для использования преимуществ и решения проблем (EN).
  • Спецификации OMB BPMN и OMG SoaML: дополнительная информация об этих спецификациях, которую можно загрузить в PDF-формате.
  • Загрузите ознакомительную версию программного обеспечения IBM Rational Software Architect.
  • Загрузите ознакомительные версии продуктов IBM и оцените возможности инструментов разработки приложений и ПО промежуточного уровня семейств DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=1011442
ArticleTitle=Интеграция BPMN и SoaM: Часть 1. Мотивация и подход
publish-date=07212015