Сервис как событие. Perdurant в онтологии DOLCE.

Towards an Ontological Foundation for Services Science. Roberta Ferrario and Nicola Guarino

Новая работа, которая предлагает ответ на вопрос: что есть сервис? Авторы подчеркивают необходимость подхода достаточно общего для рассмотрения всех видов сервисов (сервисов в разных контекстах), включая социальные, бизнес-ориентированные сервисы, которые зачастую опускаются при применении СОА.
Авторы - создатели DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering), которая относится к классу высших онтологий.

Предлагаемое определение:
A service is present at a time t and location l iff, at time t, an agent is explicitly committed to guarantee the
execution of some type of action at location l, on the occurrence of a certain triggering event, in the interest of
another agent and upon prior agreement, in a certain way.

При таком подходе сервис - это событие (event), основой которого является обязательство (commitment), гарантирующее что кто-то (провайдер) выполнит ряд действий в интересах кого-то (потребителя). Онтологически - это статическая временная сущность, событие (static event) - perdurant  в онтологии DOLCE. В контексте DOLCE, состояния и процессы (states and processes) - это особые типы событий.

Основные идеи:
  • Разграничение между service commitment (обязательство), service content , т.е. типы действий, которые должен выполнить провайдер (метод сервиса?), и service process, т.е. набор процессов, реализующих сервис.
  • Разграничение между service commitment (обязательство) и service availability (доступность), что позволяет учитывать моменты, когда обязательство выполняется, но сервис недоступен, например, рабочие перерывы.
  • Одно и то же понятие более не используется на разных уровнях абстракции: "abstract and concrete levels" (можно сравнить с methodology and endeavour levels из ISO 24744). Для авторов сервис всегда существует ТОЛЬКО на concrete level. Например, процедура, написанная на C и даже имеющая стандартный Веб-интерфейс, не является сервисом, но описанием процесса, его реализующего. Только когда процессор запускает такую процедуру, он производит сервис, который соответствует описанию.
  • Определение указывает на агента сразу, а не опускает это до уровня реализации. Разные агенты оказывают разные сервисы, хотя service content (содержимое сервиса) у них могут совпадать.
  • При указанном подходе сервисом нельзя владеть, так как он представляет собой событие. Поэтому же сервис не может быть передан. В этом отличие сервиса от продукта. В терминах DOLCE сервис - это perdurant (временный), а продукт - endurant (постоянный)
  • Поставляется не сервис, а service content (содержимое сервиса), которое представляет собой набор действий, которые надо выполнить в интересах потребителя. Т.о. сервис - это определенное обязательство (concrete commitment) по производству определенного содержимого (certain content), состоящего из действий определенного типа (actions of certain kind), выполненных определенным образом (in certain way). Совокупность различных действий, требуемых сервисом, составляют service process. "Service process implements a service". NOTE: можно провести аналогию с Ситуационной Инженерией Методов (http://techinvestlab.ru/586456). Сервис обеспечивает некоторую трансформацию. Ее состав определяется содержимым, service content (похоже на method chunks, microprocess), а реализуется она в виде service process (похоже на macroprocess)
  • Указывается на то, что сервис, как сложное событие, имеет 5 частей: service commitment (обязательство), service presentation (представление), service acquisition (приобретение), service process и service value exchange. Предлагается, что такое видение сервиса, может использоваться как основа для онтологии, которую можно применить к описанию сервиса и с внешней точки зрения (типично для веб-сервисов и SOA), и с внутренней (процессы трансформации).

Ниже схема структуры сервиса, предлагаемая Roberta Ferrario и Nicola Guarino в их работе.


(Towards an Ontological Foundation for Services Science. Roberta Ferrario and Nicola Guarino, ISTC-CNR, Laboratory for Applied Ontology)

На первый взгляд, подход имеет много преимуществ. Сервис рассматривается в широком контексте. Он описывается в терминах деятельности, а значит к его описанию можно применить метамодель ISO 24744. В статье даже есть упоминания о различных уровнях описания, аналогично уровням Methodology и Endeavour, упоминается enactment. Интересно предложение рассматриват сервис только на конкретном уровне реализации.
Однако, необходимо отдельно оценить насколько такой подход будет поддерживать преимущества, обеспечиваемые СОА.

EuSEC 2010 / DEMO и Praxeme

Тема ориентации на сервисы редко затрагивалась в докладах участников конференции. О СОА говорили создатели и пользователи MODAF, которая в версии 1.2 включает Service Layer. Был доклад "The service orientation of MODAF - conceptual framework and analysis", отмеченный ранее (http://kir-lis.livejournal.com/867.html):

  • В MODAF 1.2 применяется определение сервиса, предлагаемое OASIS. Как уже отмечалось (http://kir-lis.livejournal.com/1493.html), их метамодель еще не устоялась, а также критикуется JJ Dubray (http://kir-lis.livejournal.com/1269.html).
  • Авторы оценивают применимость концепции сервисов не только в контексте ПО, но и в более широком смысле, в контексте бизнеса. Правда бизнес, в случае MODAF, - это военные операции. Такой анализ интересен, так как есть стремление в рамках исследования выделить метамодель СОА, которую можно было бы применить не только к ПО, но и к оборудованию, и даже человеческим ресурсам. Основной вывод, сделанный авторами, в том, что заметные различия в контекстах ПО и военных операций, не позволят с ходу применить СОА в последнем случае. Требуется осторожное рассмотрение того, как концепция сервиса может быть применена в широком контексте. Одно из возможных применений это task lists, которые сравниваются с интерфейсами сервисов. В них описываются задача, которую требуется выполнить, но нет конкретных предписаний о том, кто и как это будет делать.
  • В настоящий момент MODAF 1.2 используется как средство коммуникации, общий язык. В этих условиях новый слой (Service Layer) не получил сразу широкого распространения. Отмечалось, что использование групп описаний сервисов в контексте ПО, а тем более в широком контесте, требует определения заинитересованных лиц (стейкхолдеров), чьи нужды будут удовлетворяться такими моделями. В настоящий момент и для текущих целей применяются другие группы описаний, предлагаемые MODAF.

Несколько докладов затрагивали MBSE и интеграцию различных групп описаний. Но почти никто не говорил о семантической интеграции. Фокус докладчиков на применение UML и SysML, имеющие ряд ограничений.

****

Знакомлюсь с методом DEMO. Возможно, предлагаемые Dietz'ом методы моделирования можно применить для описания Logic Aspect из Praxeme (http://kir-lis.livejournal.com/1845.html). Цель у них одна: снять зависимость между требованиями бизнеса и конкретной реализацией.

Метод Praxeme и место СОА в нем

Praxeme – это метод инженерии систем, а именно инженерии Enterprise Systems и их составляющих. Его авторы, методологи Dominique Vauquier и Pierre Bonnet, классифицируют Praxeme как «enterprise method». Метод в открытом доступе под лицензией Creative Commons, но много интересной информации пока еще только на французском языке (я его не знаю). Хотя в созданном Praxeme Institute (http://www.praxeme.org/) осознают важность распространения и постепенно занимаются переводом на английский.

Парадигма, лежащая в основе Praxeme, опирается на моделеориентированность, ориентацию на сервисы и управление жизненным циклом. Место, отведенное СОА в Praxeme, соответствует тому, как она позиционировалась при постановке задачи исследования (http://kir-lis.livejournal.com/289.html), т.е. в качестве промежуточного звена, снимающего зависимость потребностей бизнеса от деталей реализации. Поэтому имеет смысл покопать в этом направлении.

Отправная точка метода заключена в популярном вопросе: «Что должно описываться (моделироваться) в организации для того, чтобы она была более управляема, а ее функционирование приводило к положительному эффекту?». Постулируются принципы описания:

·         Реальность (система) должна рассматриваться с разных углов, которые соответствуют аспектам (aspects)

·         Реальность (система) должна описываться несколькими моделями, каждая из которых специализируется на отдельном аспекте

·         Есть набор аспектов, определенных методом.

Легко провести аналогию с ISO 42010 (ANSI/IEEE 1471-2000), но явно указывается на различие между view (группа описаний) и aspect. Группа описаний (view), связанная с конкретным типом акторов, может быть составлена из «информации, решений и элементов из разных аспектов». Далее предлагается Enterprise System Topology, в которой описывается связь аспектов, предлагаемых Praxeme (см. иллюстрацию ниже из [3]).



Upstream aspects. Отражают базовое знание о бизнесе, что он собой представляет, как организован, каковы цели, правила и ограничения. Никаких технических деталей и архитектур конкретных систем. Соответствует CIM из MDA. Показывает, что должно быть достигнуто. Архитектура бизнеса.

  • Semantic (conceptual, business essentials, basics). Описывает объекты реального мира, их связи между собой, их жизненный цикл (состояния и переходы), правила. Не включает в себя никаких организационных деталей (роли, действия)
  • Pragmatic (organizational). Описывает то, как объекты организованы для достижения целей. Организационные единицы, роли, полномочия, жизненный цикл системы, бизнес процессы, контекст выполнения работ
  • Geographic (contextual, communicational)

Downstream aspects. Техническая архитектура, реализация того, что должно быть достигнуто.

  • Technical (technological). Описание принимаемых технических решений
  • Software (application, IT). Включая веб-сервисы.
  • Hardware (logistics)
  • Physical (deployment). Маппинг софта на железо.

Logical aspect (functional). Располагается между Upstream и Downstream аспектами. Снимает зависимость архитектуры бизнеса от технической архитектуры. Именно здесь применяется СОА, в качестве стиля архитектурного проектирования. В рамках Praxeme могут применяться и другие стили.

 

В области СОА распространенными методами проектирования являются наборы лучших практик и эвристик. При таком подходе можно создать качественные системы, но затруднительно продемонстрировать, что набор сервисов был извлечен именно из потребностей бизнеса, а не является догадкой. Сторонники Praxeme утверждают, что множество сервисов может быть чуть ли не вычислено путем применения процедур, предлагаемых в рамках их метода. Для этого создателями метода принято несколько решений. Во-первых, ключевым является разделение Semantic и Pragmatic аспектов. Во-вторых, предлагается начинать проектирование с описания объектов, а не процессов. Утверждается, что начинать СОА-проект с тщательного изучения процессов организации является ошибкой. Ниже аргументация этих положений из презентации [3].

При моделировании выполняемой работы (activities) неизбежно делаются ссылки на объекты, поэтому некоторое моделирование данных будет обеспечено, в соответствии с этими указаниями. Но такой способ раскрытия объектов смешивает объекты разных типов, и, что критично для MDA, состояния объектов не распознаются и приравниваются к набору значений атрибутов. Более того, работы очень вариативны, зависят от культурных различий между отделами, от конкретных исполнителей, от темпа изменений в организации. Такая нестабильность не позволяет брать работы за основу архитектуры.

В Praxeme разделяют два вида объектов: Pragmatic (непосредственно поддерживают работы) и Semantic (сохраняют состояние организации). Утверждается, что надо начинать описывать систему именно с Semantic объектов. А уже из описаний их ЖЦ есть возможность сгенерировать значительное число работ из Pragmatic Aspect. Об этом не раз писал JJ Dubray (последний пост -  http://www.ebpml.org/blog2/index.php/2010/05/12/resource-lifecycles-and-rest) .

Из Semantic и Pragmatic аспектов порождается Logical аспект. Он включает в себя service models, flow models, data models. Сервисы не формируются в рамках интуитивного процесса, основанного на знаниях и навыках персонала, а выводятся из результатов моделирования на предыдущем этапе, что повышает коэффициент повторного использования. Flow models выводятся из переходов между состояниями бизнес-объектов в Semantic aspect. На рисунке ниже иллюстрация этой последовательности [3].

Порождение моделей главное преимущество Praxeme. Оно реализуется в соответствии с предлагаемыми процедурами.

 


 

Описание компонентов ПО (Software Packages) находится в Software aspect. Те вопросы, которые задаются авторами метода при решении задач интеграции существующих компонентов, аналогичны исследуемой проблеме. Какие объекты, какие функции покрывает компонент? Можем ли мы использовать только требуемые части пакета или нет? На эти вопросы могут дать ответы описания из Logical Aspect. Это даст возможность привести инфраструктуру ПО в соответствие с детяельностью организации.

 

К сожалению, нет документа с какой-либо метамоделью, нет определения сервиса. Но, скорее всего, сервис из Logical aspect соответствует именно способности (capability) выполнять какую-либо работу, а уже Software Aspect описывает механизм доступа к ней. Это к дискуссии OASIS SOA-RM TC об определении сервиса (http://kir-lis.livejournal.com/1493.html)

 

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

 

Материалы:

[1] http://www.praxeme.org/EnglishPage.html - страница с документами доступными на английском

[2] http://www.praxeme.org/DocumentsEnAnglais/SLB02-wp_EN.pdf Базовый документ с описанием метода (Introducing Praxeme ("Livre Blanc"))

[3] http://www.praxeme.org/DocumentsColleges/Instructeurs/AnIntroductionToTheMethodology.BH.2009.09.16.pdf - Презентация с комментариями к слайдам с описанием позиционирования СОА

[4] sustainableit.ifrance.com/ONSOAPXMOverviewBUsers.ppt презентация о применении Praxeme в инженерии СО-систем

Диссертационные исследования в области системной инженерии (EuSEC'10 Doctoral Workshop)

Организаторы конференции прислали сборник тезисов, представленных исследователями для участия в Doctoral Workshop на EuSEC 2010. Всего представлено 12 исследований:
  • половина работ затрагивает вопросы сложности интегрированного проектирования разных типов систем (embedded systems = софт + железо; socio technical systems = люди + софт + железо);
  • в 5 работах явно и неявно упоминается моделеориентированная системная инженерия (MBSE);
  • в 5 работах рассматриваются вопросы управления процессами ЖЦ (Development Processes), включая Ситуационную Инженерию Методов (SME);
  • непосредственно про Service Orientation работ нет;
  • решаются проблемы из авиационной промышленности, энергетики (атомной, ветряной), автомобильной промышленности.
Косвенно, эти пункты дают некоторую информацию об исследовательской деятельности в области СИ.

Ниже краткие заметки по работам, затрагивающим проблемы, которые обсуждаются в русском отделении INCOSE (http://incose.ru/)

1. Henric Andersson. Product Line Modeling - Variability and Configuration Principles for Models in Product Family Development.
Стоит задача использования динамического моделирования (simulation) для анализа линейки продуктов в авиационной промышленности. Исследователь ищет ответы на вопросы:
а) как выражать артефакты динамического моделирования;
б) как выражать встроенное ПО (embedded system);
в) какое место у модели окружения (environment model), которая не является частью продукта;
г) как создать систему конфигурирования динамической модели на основе модели продукта.
Исследователь предлагает выразить метамодель двух представлений продукта: PDM/PLM (статика) и simulation (динамика). Маппинг этих метамоделей должен показать, как проводить обмен данными между ними, каких классов может не хватать (например, набор параметров - parameter set). Для каждого компонента предлагается разработать и привязать отдельную динамическую модель. Реализация в виде XML документа.
Связь статической и динамической моделей продукта, обсуждалась в русском отделении INCOSE. Был разговор о том, что динамическая модель = модель продукта + набор параметров. Связь инструментов PDM/PLM  и simulation должна быть основана на единой модели данных (ISO 15926)

2. Matthias Biehl. Design Rationale Documentation for Model-based Development of Embedded Software Architectures.
Говорится о том, что необходимо моделировать/документировать логические обоснования (rationale) решений, принятых во время проектирования сложных систем. Поставленные вопросы:
а) как выражать обоснования, что должно быть выражено явно;
б) как связывать их с моделью архитектуры, обеспечивая трассировку;
в) как модели обоснований могут поддерживать повторное использование результатов проектирования.
Автор пишет, что исследование только начинается, и он планирует  предложить "notations, modeling formalism and tools" для документирования обоснований.
Принятие решений и их обоснование на развилках (trade-offs) процесса проектирования также обсуждалось русским отделением INCOSE. Стоит заметить, что важной является связь обоснований с целями (goals) проектирования. Об этом пишет ailev : http://ailev.livejournal.com/828431.html

3. Duncan Bourne. Distributed Control Systems for Aero Gas Turbine Engines: A Systems Approach to Architectural Optimisation.
Автор указывает на недостаток инструментов и техник проектирования архитектуры распределенных систем. Он планирует использовать генетические алгоритмы для проектирования и оценки таких архитектур. Оценка проводится по трем направлениям: Architectural Evaluation; Life Cycle Evaluation; Business Evaluation.
Интересно, но пока непонятно, как будет реализовано.

4. Marc Chevalier. The Reliability of Degraded Structural Systems in Changing High Temperature Environments.
Исследователь рассматривает проблему "железных/бетонных" систем, а точнее, вопросы надежности стальных конструкций в условиях высоких температур (атомная энергетика). Он последовательно применил подход системной инженерии и предлагает новый метод анализа надежности компонентов.
Делается акцент на математическом моделировании. Каким инструментарием пользуется автор? Скорее всего, предложенный метод можно реализовать в виде динамической модели АЭС, про которую рассказывал vvagr: http://community.livejournal.com/incose_ru/13302.html

5. Управление Жизненным Циклом (System Process, Development Process)
Håkan Gustavsson. Lean System Architecting
Christian Haerdt. Dynamic, Situational Adaptation of Development Processes
Peter Wallin. Key Challenges in System Architecture Development for Software-intensive Systems
Gustavsson анализирует существующие "System Architecting Processes" и на основе анализа хочет предложить улучшения.
Однако, в русском отделении INCOSE уже исследовали методы описания ЖЦ, и пришли к выводу, что нет решения, подходящего для всех ситуаций, необходима Ситуационная Инженерия Методов (Situational Method Engineering).
Об этом как раз и пишет Christian Haerdt.. Развивая идеи SME, он говорит, что можно использовать количественные индикаторы для оценки применимости разных методов в определенных ситуациях, нахождения неподходящих методов, поиска альтернатив. Более того, это поддается автоматизации. Haerdt предлагает интегрировать описание ситуаций в описания методов и хочет использовать этот подход для анализа методов MBSE. Указывается на прототип инструмента - Process Advisor (eclipse-based). Интересное исследование. А потом кто-нибудь придумает, как оценивать качественные показатели ситуаций...
Peter Wallin на основе проведенных опроса анализировал основные проблемы, возникающие во время проектирования архитектуры систем автомобиля и ПО. Самые основные:
* недостаток долгосрочной стратегии в области архитектуры
* недостаток методов и моделей оценки ценности для бизнеса при выборе разных архитектур (на этот вопрос пытается ответить Duncan Bourne - пункт 3)
* формализованные методы ценятся меньше, чем знания и компетенции отедльных людей
* недостаток методов проектирования архитектуры (There is a lack of process for architecture development).
Проблемы маппировались на практики СИ (ISO 15288). Указано, что основные вопросы связаны со следующими практиками: "life-cycle model management process, project portfolio management process, decision management process and the architectural design
process."

6. Paola Di Maio. Knowledge Reuse and Learning in Networked Organisations, a Systems Engineering Approach
Рассматривает проблему использования и распространения знания (Knowledge Reuse and Learning) как проблему сложной социо-технической системы. При такой постановке вопроса снова встает задача совместного управления системами людей, системами ПО и "железными" системами. Исследование на начальной стадии.
"Гуманитарное конфигурирование" обсуждалось на одном из заседаний русского отделения INCOSE: http://www.slideshare.net/ailev/ss-2605634

Что такое Service? Обзор дискуссии OASIS SOA RM Technical Committee

В описании материалов по моделированию СОА была поднята проблема определения "сервиса". Указанные источники по-разному интерпретируют этот термин. Для решения проблемы требуется сравнительный анализ предложенных определений.
Изучая OASIS SOA Reference Model (SOA-RM) (описание концептов СОА) и Reference Architecture Foundation (SOA-RAF) (абстрактное описание архитектурных компонентов, состоящих из концептов SOA-RM, с помощью которых можно реализовать СОА), наткнулся на интересную дискуссию создателей этих стандартов.
В январе завершился этап public review SOA-RAF 1.0. Члены Technical Committee получили обратную связь и, как не удивительно, начали обсуждать, что такое "сервис". Это им, видимо, уже надоело - один из тредов называется Service Definition "ad nauseam" (до отвращения). Выпуская уже второй стандарт, они осознали, что предложенное ими определение, не устраивает множество заинтересованных сторон, и поэтому тормозит распространение их продуктов. Практически вся апрельская  переписка SOA RM TC именно об этом. Две предпосылки:
  • Chris Partridge (профессиональный онтолог, создатель методики BORO - подробнее) написал письмо в TC. Он сравнил определения сервиса из стандартов OASIS, Open Group, OMG, метамоделей MoDAF, DoDAF и указал на явные расхождения.
  • При обзоре смежной спецификации OASIS SOA-EERP, которая была представлена на рассмотрение в апреле, участники SOA RM TC обнаружили определение сервиса, которое не соответствует SOA-RM.
Основные вопросы:

Service и SOA Service (SOAS)

Самый важный пункт обсуждения. Определены два разных подхода к определению сервиса:
  1. Service/ Business Service/ Notational Definition. Cервис как способность (capability) поставщика выполнить работу для потребителя. Также есть источники, которые видят сервис не как способность, а как уже само выполнение (performance).
  2. SOA Service/IT Service/ IT-oriented Definition. В этом контексте, упор на то, что сервис должен быть доступен потребителю. То, что не открыто для доступа - не сервис. Поэтому определяют сервис как средство (mechanism, resource, abstract resource, access point), обеспечивающее доступ к способности.
Спор о том, надо ли разделять Service и SOA Service.
  • Boris Lublinsky, Michael Poulin и другие, считают, что такое разделение станет причиной проблем. Оно противоречит SOA-RAF, которая позиционирует SOA между бизнесом и ИТ. При разделении, SOA будет восприниматься просто как техника декомпозиции. Предлагают, общее определение Service, которое включает в себя и бизнес, и техническую стороны. Lublinskiy утверждает, что Service должен быть результатом декомпозиции Enterprise Business Model (EBM).
  • Christopher Bashioum, Jeff Estefan (Jet Propulsion Laboratory, NASA) утверждает, что разделение требуется для того, чтобы подчеркнуть необходимость обеспечения доступа к функции, а стандарты SOA RM TC как раз ориентированы на IT-oriented definition of Service. Считает, что, если определить Service как декомпозицию EBM, то это ничем не отличается от обычной функциональной декомпозиции, которой занимаются уже 40 лет. "SOA выросла из Distribution Programming, поэтому определения, которые они дадут, должны помогать в разработке распределенных систем, а не просто организации бизнеса." На это оппоненты отвечают, что хотя функциональной декомпозицией занимаются уже давно, SOA поднимает ее с уровня приложения на уровень Enterprise Architecture.  И несмотря на то, что корни SOA  в Distribution Computing, но она не равняется распределенным вычислениям.
Естественен подход, когда Service in the context of SOA будет являться конкретизацией общего термина Service. Суммируя результаты дискуссии:
  • Service - это способность (capability), предлагаемая поставщиком потребителю, в соответствии с контрактом. (Сервис - это способность, но обратное не всегда верно).
  • Service (in the context of SOA) - это конкретизация Service, а значит тоже является способностью, а не средством доступа к ней. Но это определение накладывает ограничения, необходимые для описания сервиса в парадигме СОА. Service (in the context of SOA) is a capability that exposes/ is exposed as a business function in the context of the following constraints: offered and packaged by a provider and made accessible to customers;  access is provided using prescribed interface; exercised consistent with contracts and policies as specified in description.
Конечно, к консенсусу на этом они не пришли. Последний обмен мнениями весьма показателен:
  • Jeff Estefan. Приходит к выводу, что нельзя сойтись на точном опредлении сервиса в контексте СОА. Т.к. все зависит от интерпретации, а она разная для бизнеса и ИТ. Поэтому предлагает четко определиться с перспективой рассмотрения. Если основная цель SOA - это выравнивание ИТ-систем, которые реализуют сервисы, обеспечиваемые бизнесом, тогда при обсуждении SOA Service надо понимать, о чем говорим: о Business Service или об IT-capabilities, которые его реализуют. И хотя кто-то думает, что это одно и то же, эта позиция непрактична, т.к. бизнес и ИТ представлены разными сообществами.  Если SOA-RM фокусируется на ИТ, тогда предлагает называть SOA Service как Business-Aligned IT Capability. (Комментарий: Конечно, все зависит от интерпретации, точки зрени, перспективы, группы описаний, но есть методы для их объединения, поэтому я больше склоняюсь к следующей позиции, которую выражает Poulin. КЛ.)
  • Michael Poulin. Считает, что нет необходимости определяться с точкой зрения. 2 точки зрения, предложенные Jeff'ом, противоречат друг другу. "Мы говорим о SOA, которая располагается между ИТ и Бизнесом, и согласились, что сервис имеет 2 составляющих - техническую и бизнес. Эти составляющие можно определить совместно, избегая "фокусировки на ИТ", что будет нечестно." Предлагает: техническая составляющая сервиса - это business-aligned IT capability; бизнес составляющая - это strategy-aligned business capability that utilizes related IT-capability

Service Equivalence
От предлагаемого определения Service, зависят условия, при которых сервисы можно считать идентичными.
Приводится пример, банковских услуг. Например, есть 2 банка: Сбербанк и ВТБ. Предположим, они предлагают одинаковую функцию, с одинаковым эффектом, одни и те же интерфейсы и policies. Можно сказать, что это разные сервисы, так как различается контекст исполнения (разные поставщики и точки доступа). Но если ВТБ предлагает этот сервис через 2 разные точки доступа - это один и тот же сервис или нет? Если отвечаем, что service = capability, то да; если service = средство доступа, то нет.
На мой взгляд, это один и тот же сервис. Тут можно вспомнить JJ Dubray, который утверждает, что наиважнейшая характеристика сервиса - это независимость от контекста (Context Independence).

Service Composition
Обсуждалось, требует ли компоновка (composition) сервисов в новый сервис знания деталей их реализации. Очевидным кажется, что такие знания не должны требоваться. В противном случае, новый сервис будет зависеть от сервисов, из которых он составлен, что противоречит принципам SOA. Однако, несколько участников обсуждения были несогласны с этим. Было сказано, что конечному потребителю составного сервиса, может потребоваться узнать детали, не включенные в его интерфейс.
Lublinskiy объяснил, что конечный потребитель составного сервиса не должен знать о том, как реализованы сервисы, из которых он составлен, не потому, что необходимо скрывать детали реализации, а потому, что контракт заключен именно с составным сервисом.
Однако, требуется явное различение aggregator-consumers (те , кто использует сервис, чтобы скомпоновать из него новый) и end-user-consumers.

Contract/  Policies / Service Description
Вопрос в соотнесении этих понятий. Кроме того, различают и путают Service Contract и Consumer/Provider Contract.
Когда Service готов, provider представляет Service Description, которое включает также описание интерфейса и policies. Consumer решает использовать Service или нет. Если да, то на основе Service Description создается  Contract (соглашение между provider/consumer). Т.о. Contract не часть Description, а его производная. Description может существовать и без Contract, если еще нет потребителей, но Contract без Description не существует. Service Description (1) - (0...*) Contract.
Contract состоит из Policies. Более того, в него могут быть включены Policies, принадлежащие Consumer, т.к. как Contract - это дву-/много-стороннее соглашение.
Чтобы не было путаницы, контрактом предлагается называть именно Consumer/Provider Contract, а описание точки взаимодествия с сервисом, которую часто называют Service Contract, именовать как Interface.

Capability vs Function
Постоянно используется пара function/capability. Но это не синонимы. Предлагается: Capability - potential to perform function.
С Function сложнее:
  • repeatable "chunk" of work
  • performance of operation
Видно, что в первом случае Function очень близка по смыслу к методу из SME. Кроме того, требуется разделение function от смежных терминов "action" и "activity".

P.S.
  1. Удивительно, но только сейчас у них начинается обстоятельное обсуждение смысла "сервиса", решение проблемы многозначности этого термина, которая была отмечена при рассмотрении ресурсов по моделированию СОА. К этому подключились и онтологи в лице Chris Partridge. Это увеличивает шансы на успех.
  2. Это обсуждение помогает продвинуться в решении поставленной проблемы, но не помогает SOA RM TC, ответить на большинство претензий, которые JJ Dubray высказывает к SOA-RM, SOA-RA, SoaML.
  3. Кроме того, переписка позволяет взглянуть на то, как в действительности создаются стандарты, как ведутся дискуссии. Не скажу, что этот процесс без недостатков. Кому интересно, аудоизапись одного из заседаний располагается здесь.

********************************
В сторону, по поводу Model-Based Systems Engineering (моделеориентированной системной инженерии):

Jean-Jacques Dubray, Метамодель WSPER

В списке материалов по моделированию сервисов и СОА указаны работы Jean-Jacques Dubray.
Среди них можно выделить:Акцент автора на разработке программных систем. Поэтому предлагаемая метамодель WSPER включает в себя абстрактное описание реализации сервисно-ориентированных систем и наполнена концептами этого уровня.

Dubray пишет, что сейчас программные системы создаются так, что нет возможности менять их в соответствии с требованиями бизнеса и повторно использовать существующие приложения для создания новых. В этой ситуации бизнес не получает заявленной ценности от ИТ, а, напротив, тратит больше ресурсов на интеграцию, получая отрицательный ROI. Он утверждает, что основная идея и ценность СОА в подходе к созданию ИТ-активов (assets), которые можно повторно использовать (reuse) в различных контекстах, составляя (composition) из них новые приложения.

СОА предлагает новый способ повторного использования (reusability model). До СОА "reused" могли быть библиотеки (libraries), объекты, шаблоны (patterns).  Но приложения (ИТ-активы), разрабатываемые на основе библиотек или с помощью определенного шаблона, не были "reusable" сами по себе.
Сервис (у Dubray) - это ИТ-актив (программный агент), который может быть повторно использован произвольным числом потребителей в контексте неизвестном во время проектирования (т.е. независимо от приложений, которые будут его вызывать). Context Independence ключевое свойство сервиса, для того, чтобы его можно было повторно использовать. По большому счету, контекст - это экземпляр бизнес-процесса, в котором используется сервис. Контекст должен определяться независимо от ИТ-актива. 

Другие важные свойства сервисов:
  • имеют контракт, в котором в т.ч. описан интерфейс сервиса и измеримые нефункиональные требования (Quality of Service)
  • не имеют видимых зависимостей от других сервисов
  • доступны, но "в спящем режиме" (idle) до получения запроса
  • готовы к использованию (не требуют интеграции)
  • составляются в новые сервисы (composable)
  • могут иметь состояния (stateful)
  • могут быть асинхронными
Как уже упоминалось в посте о материалах по моделированию СОА, Dubray критически описывает сложившийся набор стандартов. В своей книге он демонстрирует как хаотически развивался стэк стандартов СОА , втискиваясь между стандартами B2B, BPM и интероперабельности. Dubray пишет, что эти стандарты смогли формализовать 3 вещи, которые должны обеспечивать P2P-коммуникацию прораммных агентов:
  • сообщения/ безопасный обмен сообщениями независмый от конкретных технологий (HTTP, SOAP)
  • сервисы/ взаимодействие между агентами, как паттерн обмена сообщениями; определение интерфейса (WSDL, WS Resource Framework/SDO, WS Notification - события, UDDI - регистр)
  • единицы работы/ набор сервисов, оменивающихся сообщениями для достижения поставленной цели; композиция (composition) - сервис представлен как набор других сервисов, из которых он составлен; сборка (assembly) - сервисы, работающие вместе для достижения цели (SCA, WS-COORD, WS-BPEL).
Все эти спецификации были созданы разными группами людей, в разных организациях по стандартизации, под давлением противоречивой "political agenda" . У создателей стандартов не было цели создать новую парадигму, целостную модель создания приложений (programming model), которую можно было бы использовать для разработки сервисно-ориентированных систем. Тем не менее СОА подразумевает под собой совершенно новые подходы к разработке. Dubray утверждает, что СОА базируется на "Inter-Action Oriented P2P programming model", а последнии 40 лет доминировала "CRUD-oriented Synchronous Client/Server model". Существующие методологии можно использовать для создания ИТ-активов, но не для создания составных приложений, которые могут легко изменяться и повторно использоваться. Вот некоторые пункты, отобранные из списка того, что должно измениться при переходе на новую модель:
  • Governance not just Project Management. Каждый актив должен быть классифицирован и помещен в регистр, предоставляющий набор инструментов для управления
  • Strategy and goals not just requirements. Это заявление связано с тем, что пишет ailev о целеориентированной инженерии требований
  • Contract and QoS not just functionality. Подчеркивается важность нефункциональных требований. Плюс отвязка контракта, интерфейса от самого сервиса
  • Resources not just data. Опора на жизненные циклы ресурсов (экземпляры бизнес объектов, например конкретный заказ, конкретный счет-фактура), а не манипулирование данными с помощью методов CRUD (Create, Read, Update, Delete), которые приводят к сильной зависимости между данными и их потребителем
  • Interactions not just invocations. Взаимодействие ресурсов управляется хореографией. ЖЦ ресурсов реализованы с помощью языка оркестровки (BPEL)
  • Assembly not just implementation. Чем больше сервисов становится доступно, тем больше времени тратится на сборку новых приложений из них, а не на их разработку
  • Accountability not just organization.  Этот пункт касается системной инженерии как системы учета. Необходимым становятся формальные описания сервиса на разных стадиях его ЖЦ (as-is, as-envisioned, as-specified, as-designed, as-built, as-deployed), а также трассировка между ними. Такая связь между as-is и as-deployed описаниями поддерживает процесс непрерывных улучшений системы
Dubray предлагает:
  • логическую архитектуру композитной системы (Composite Application Model), которую инстантиниирует с помощью стандартов веб-сервисов
  • Модель Композиционного Программирования (Composition Programming Model), т.е. метамодель, язык, описывающий основные концепции, применяющиеся при ориентации на сервисы

Несмотря на то, что стандарты СОА плохо связаны между собой, в них заложен ряд инновационных идей (например, расширяемые структуры данных на основе XML, концепции координации - хореография и оркестровка), которые не имеет смысла отбрасывать. Он считает, это очень большая удача, что, хоть и со скрипом, но их можно связать в единую модель программирования.
Цитата:
"Even though the SOA standard stack, including Web Services stack is close to delivering a programming model, the vendor interests are so divergent that it would be elusive to think that the stack will evolve naturally  towards a programming model. So, if we want to further understand how to build composite solutions from this set of disparate, albeit  innovative concepts, I suggest that we go up a level and take a look at specifying composite programming model. This approach is a lot more concrete than trying to go through all specifications and provide guidelines on how to use them individually or in combination with other specifications. Here, our intent to define a programming model which artifacts can be compiled into SOA standard artifacts such as XML Schemas, WSDLs, or BPELs and deployed in today's service oriented infrastructures."

Модель композитной системы сфокусирована на трех сущностях (task, process и service), каждая из которых распологается в своем слое:
  • Delivery services. Взаимодействия с пользователем выполняются в рамках назначения (task). Назначение представляет собой единицу работы, может быть единичными или участвовать в одном или нескольких определениях процессов.
  • Business process engine. Ключевой слой составного приложения (composite solution). Описания бизнес-процессов содержат бизнес логику решения, которая включает в себя набор назначений и сервисов для достижения конкретной цели. Здесь определяется контекст использования сервисов.
  • Enterprise services.  В этом слое выполняются основные функции приложения. Сервисы этого слоя оркеструются слоем бизнес-процессов или напрямую вызываются из слоя назначений.



Модель Композиционного Программирования называется WSPER, что значит Web, Service, Process, Event, Resource. Это ключевые составляющие модели программирования. Метамодель WSPER комбинирует и расширяет концепции из стандартов WSDL, SCA/SDO и BPEL. Она состоит из 3 отдельных метамоделей: сервиса, ресурса и сборки. Ниже краткое описание состава этих метамоделей (В документе WSPER Primer приведены диаграммы классов, описывающие указанные метамодели).

Метамодель сервиса (Service metamodel)
  • Интерфейс. Расширяет определение интерфейса из WSDL. Сервис может иметь несколько интерфейсов. Их набор назван "поверхностью" (surface) сервиса. В отличие от класса, сервис может раскрывать операции только посредством определения интерфейса.
  • Операции (Operations). Доступные внешние операции явно указываются в определении интерфейса сервиса. Операции связаны с ресурсами (resource) не напрямую, а через механизм представления (representation). Определены два дополнительных типа операций: запрос (query) и оповещение о событии (event notification). Последний тип используется для того, чтобы помечать операции, которые способны использовать инфраструктуру обработки событий. Событие определяется как экземпляр состояния (occurrence of state). Так как состояния явно описываются в WSPER, событие должно быть связано с состоянием ресурса.
  • Реализация (Implementation). WSPER поддерживает и реализацию сервиса, и реализацию отдельных операций. Dubray пишет, что Ориентация на объекты не предполагает такого разделения. Оно требуется потому, что шаги сервиса (service activities) часто имеют состояния (stateful), а операции отражают обмен сообщениями между конкретным шагом и другими шагами. WSPER использует некоторые концепции из языков оркестровки (например, BPEL), но более важно, что он связывает вместе понятия "ресурс", "состояние" и "сервис".
  • Назначения (Tasks / Human tasks). С точки зрения архитектора назначения представляют собой те же сервисы. Но их поведение во время выполнения отличается, так как назначения имеют особые операции и концепции, специфические для его ЖЦ (например, передача назначений другому исполнителю).
  • Поток (Flow). Описывает поведение интерфейса сервиса.
Метамодель ресурса (Resource metamodel). Ресурс представляет собой тип (в принципе, должен называться ТипРесурса). Множество экземпляров может соответствовать типу ресурса. Экземпляр ресурса - это устойчивый набор данных, который может быть уникально идентифицирован. Сервис управляет экземплярами типа ресурса. Структурированный ресурс назван сущностью (entity). Структура сущности описывается в соответствии с метамоделью SDO (Service Data Object) с помощью концептов element, attribute. Дополнительно, сущность может иметь одну или несколько машин состояний (Machine, State, Transition, Action). Она описывает возможные состояния, из которых состоит ЖЦ экземпляра сущности.
Mетамодель сборки (Assembly metamodel). Механизм сборки в WSPER связан со спецификацией SCA (Service Component Specification). Сборка состоит из набора компонентов. Сборка и компоненты - это объекты. которые могут быть непосредственно развернуты. Компонент отражает развертывание сервиса в среде исполнения. В языке WSPER "сервис" находится на том же уровне, что и "класс" в ОО языках программирования. Компонент состоит из одного или нескольких сервисов, связанных между собой набором коннекторов (connectors). Компонент открывает для доступа контракт, который является частью "поверхности" (surface) сервисов. Коннектор связывает две операции, которые имеют совпадающие паттерны обмена сообщениями (Message Exchange Patterns, MEP). Сборка может быть связана с потоком, описывающим последовательность сообщений, обмениваемых компонентами (хореография).

Необходимо отметить, что Dubray критикует OASIS Reference Model for SOA и другие метамодели, предложенные организациями по стандартизации, прежде всего за то, что в них не уделяется внимания композиции (composition) сервисов, их сборки в новые приложения. А это значит, что данные метамодели не могут обеспечить повторного использования - ключевого для СОА.

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

Jean-Jacques выражает некоторое отношение к указанной проблеме. Он пишет: "Определения процессов отражают точку зрения пользователей, выполняющих дела (activities). Эта ГО и единицы работы, лежащие в ее основании, редко отражает то, как система используется или даже конструируется. Фактически, со временем, процессы изменяются, но системы изменяются редко. Выгода от систем в том, чтобы убедиться, что процессы исполняются в соответствии со своими описаниями. В большинстве случаев, вы должны ожидать наличия разработчика переводящего описания процессов в пользовательские назначения, вызовы сервисов и взаимодействия сервисов. Автоматизация этой задачи разработки все еще в активной исследовательской фазе и не критична для создания композитных решений."
"Process definitions typically represent the point of view of user(s) performing activities. This point of view and their underlying units of work rarely reflect how a system is used or even constructed. Actually, over time, processes change but systems rarely do. The outcome of the system(s) is to make sure that this process executes as specified. In most cases, you should expect having a developer translating process definitions into user tasks, service invocations and service interactions. The automation of this development task is still in heavy
research mode and is not critical to start building composite solutions."

Надеюсь, что объединение метамоделей деятельности и СОА поможет в какой-то степени сделать так, чтобы описание деятельности отражало то, как система должна использоваться.

P.S. Dubray также пишет про метамодель-ориентированное программирование, связь моделирования и программирования, применение DSL. ailev писал об этом здесь. В этом посте приведены DSL, которые разработаны для WSPER.
 

EuSEC 2010 - PhD Synopsis

По ссылке можно ознакомиться с докладом, посланным для участия в Doctoral Workshop  на конференции EuSEC 2010. "Ontology-based Model Integration for Management of Service-Oriented Infrastructure". В нем в несколько другой формулировке описана поставленная задача.
Суть семинара в докладах аспирантов и докторантов о своих исследованияхв области СИ, получении обратной связи, советов по написанию работы.

На самой конференции будут доклады по смежным темам:
  • The service orientation of MODAF - conceptual framework and analysis. Pia Narman, Ulrik Franke, Michael Stolz. Эта работа тесно перекликается с темой проводимого исследования. В типовой архитектуре MODAF 1.2 (Ministry Of Defense Architecture Framework) появился новый слой, группа описаний Service View. В докладе рассматривается влияние этого слоя на Operation View и Strategic View, преимущества и недостатки ориентации на сервисы в связи с целями MODAF. Учитывая, что разработчиками MODAF проделана серьезная онтологическая работа (MODAF Ontology Paper - описана целая система онтологий разного уровня, включая высшую онтологию IDEAS), стоит обратить внимание на этото доклад и материалы по указанной архитектуре: Presentation on NATO Architecture Framework SOA Views; Transitioning an Organisation to SOA; Soft Systems (SSM) and MODAF.
  • Just enough ontology for innovation in systems engineering. Paola Di Maio. Длинный тьюториал посвещен применению онтологий в СИ. Автор указала, что конкретным приемам моделирования (coding to owl) будет уделено мало внимания. Основной упор на понимание и управление ЖЦ онтологий.
  • Portraying Aspects of System Life Cycle Models. Harold Lawson and Mats Persson. Предполагается, что будет приведен обзор различных групп описаний ЖЦ.
  • Ряд работ по средам моделирования: Cross-Domain Dependency Modelling - How to achieve consistent System Models with Tool Support, Rainer Stark, at al; Variability and Configuration Principles for Simulation Models in Product Line Development, Henric Andersson
Самым интересным будет услышать выводы сделанные докладчиками по MODAF. Надо посмотреть материалы по этой типовой архитектуре и понять что там понимается под сервисом, как это может быть применено для решения поставленной проблемы.

Материалы по моделированию сервисов (СОА)

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

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

Ниже приведен список основных материалов, которые будут использоваться:

1. Прежде всего, стоит обратить внимание, на продукты организаций по стандартизации (OASIS, The Open Group, OMG). Результатом их работы стало появление целого ряда стандартов и предложений для описания СОА, многие из которых пересекаются в значительной степени.
  • OASIS Reference Model for SOA Стандарт определяет типовое описание (reference model) как абстрактную структуру (abstract framework) для обеспечения понимания значимых связей между сущностями предметной области. По сути, типовое описание для СОА идентично онтологии СОА и включает набор концептов, аксиом и их взаимосвязей. Замечание: авторы отмечают, что, хотя выделенные концепты и связи могут применяться в различных "сервисных" окружениях, но предложенные определения сфокусированы на области разработки ПО и не обеспечивают полностью использования вне рамок домена софта.
  • The Open Group SOA Ontology Драфт стандарта аналогичный OASIS Reference Model for SOA, но предлагает несколько отличающийся набор концептов предметной области. Отличие SOA Ontology - явно указанное стремление к поддержке моделеориентрованной инженерии СОА. Разработанная онтология выражена и доступна на языке OWL-DL. Замечание: ведутся дискуссии по поводу того, что создано два перекрывающих друг-друга стандарта.
  • OASIS Reference Architecture for SOA Второй драфт типовой архитектуры для СОА. Типовая архитектура описывает то, как сущности из онтологии СОА, должны компоноваться для ее реализации. Reference Architecture представляет абстрактные архитектурные элементы (паттерны) и не зависит от конкретных технологий, протоколов и программных продуктов. Одним из преимуществ стандарта является использование ISO 42010 (один из стандартов системной инженерии), в качестве базы для архитектурного моделирования. Вводятся заинтересованные стороны со своими потребностями, группы описаний (view), которые эти потребности удовлетворяют, и методы описаний (viewpoint), с помощью которых создаются view. Подробнее здесь. Выделяются три группы описаний СОА: Service Ecosystem, Realizing SOAs, Owning SOAs. Уже по названиям этих ГО можно определить чьи потребности они удовлетворяют. Замечание: Типовая архитектура обладает тем же недостатком, что и типовой набор методов (reference processes). Они не могут быть использованы организацией в чистом виде, требуется адаптация. Возможно, по аналогии с ситуационной инженерией методов, здесь уместно говорить о ситуационной инженерии архитектуры.
  • The Open Group SOA Reference Architecture Драфт стандарта. Типовая архитектура представляется в виде набора слоев (layers), каждый из которых можно отождествить с группой описаний (view) из ISO 42010, однако, явно на это не указывается. Выделены слои: Operation System, Service Components, Services, Business Processes, Consumer, Integration, Quality of Service, Information Architecture, Governance.Уделено вниманию порождению (инстантиниации) конкретной архитектуры из типовой.
  • OMG SOA Modeling Language (SoaML) Specification for the UML Profile and Metamodel for Services (UPMS). Расширение UML для моделирования сервисов. Может рассматриваться как нотация для OASIS Reference Model for SOA. SoaML, по сравнению с UML, предоставляет дополнительные возможности для описания слабой связности сервисов, на которой основана СОА. Интеграция с UML позволяет применять порождающее моделирование от моделей абстрактной архитектуры к моделям для конкретной реализации; нотация может применяться для моделирования различных сервисных доменов и различных уровней абстракции сервисов; в планах интеграция SoaML с моделями BPMN, BMM и другими UML-based моделями.
  • Эти и другие стандарты, описывающие различные аспекты СОА, во многом повторяют друг друга. Конкурирующие OMG, The Open Group и OASIS совместно выпустили документ Navigating the SOA Open Standards Landscape Around Architecture, в котором предпринята попытка увязать костяк стандартов между собой. В документе, мало внимания уделено недостаткам сушществующих стандартов и тому, насколько они перекрывают друг друга. Необходимо критически подходить к представленной в нем информации. На титульной странице есть интересная OMG Note: This does not represent the official position of the Object Management Group. Видимо, к общему пониманию использования своих стандартов они так и не пришли. Ниже рисунок из этого документа, предлагающий версию связей между основными продуктами:
2. Существует ряд стандартов, сфокусированных на веб-сервисах, которые являются самой распространенной технологией реализации СОА. В них также заложены определенные метамодели. Прежде всего это: SOAP (протокол обмена сообщениями), WSDL (язык описания интерфейсов веб-сервисов), UDDI (стандарт для обеспечения хранения и поиска веб-сервисов), WS-BPEL (взаимодействие веб-сервисов).
Service Component Architecture - модель  для построения приложений и систем на основе СОА.
Service Data Object - спецификация для описания данных, обрабатываемых веб-сервисами.
В связи с тем, что стоит онтологическая задача, отдельно надо выделить стандарт OWL-S: Semantic Markup for Web Services, также известный как WSML (Web Service Modeling Language). Стандарт описывает онтологию веб-сервисов, выраженную на OWL. Рассматривается представление веб-сервиса в качестве процесса (Process как подкласс ServiceModel).

3. Jean-Jacques Dubray интересуется построением систем на основе СОА. Он считает, что развитие методов создания таких систем, существенно тормозится из-за существующего набора стандартов в этой области. Проблема в том, что все эти стандарты предлагают различную интерпретацию концептов предметной области, они разрозенены,  под ними нет единой метамодели. Те же метамодели, которые предлагаются стандартизирующими организациями (см. пункт 1), по его мнению, не помогают правильному  пониманию СОА, так как проедлагают метамодель сервисов, но не метамодель СОА.
Jean-Jacques Dubray разрабатывал WSPER  - метамодель, которая объединяет концепты из метамоделей WSDL, SCA/SDO и BPEL, и предназначенная для создания описания СОА, которое может быть эффективно использовано при разработке конкретных систем.
WSPER Primer

4. Существует ряд материалов, в которых рассматриваются проблемы моделирования сервисов. Среди них можно выделить:
  • "Engineering Service Oriented Systems. A Model Driven Approach" Karakostas B., Zorgios Y. В книге предлагается абстрактное понимание сервиса, которое не ограничивается сферой разработки ПО.
  • Работы Thomasa Erl'a и других авторов из серии The Prentice Hall Service Oriented Computing Series. Понимание ориентации на сервисы, как набора принципов проектирования ( "SOA. Principles of Service Design"), легло в основу SOA Manifesto
  • Michael Bell (2008). Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley. Предложена комплексная методика моделирования сервисов при разработке ПО, включающая в себя набор моделей для различных нужд - Service Oriented Modeling Framework.
  • IBM предлагает собственную методику - Service Oriented Modeling and Architecture (SOMA). Сфера примнения методики та же - разработка ПО.
Замечание
Очевидно, что в каждом из этих ресурсов, разный объект рассмотрения. Где-то сервис рассмаривается как концептуальная сущность (средство доступа к функциям ресурса), где-то как технология реализации (веб-сервис, приложение). Кто-то уделяет внимание тому, что такое сервис и как его описывать, кто-то концентрируется на том, как создавать и описывать архитектуру сервисов. Дополнительно, распространена путаница между сервисом (СОА) и сервисом (ITIL).

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

Постановка задачи

Деятельность современной организации поддерживается сложной ИТ-инфраструктурой. Одним из основных элементов такой ИТ-инфраструктуры является комплекс программных средств, применяемых для решения разнообразных задач. Для эффективной работы организации требуется установление соответствия между процессами деятельности и обеспечивающим ее набором ПО. Другими словами, используемые приложения должны предоставлять функции, которые необходимы для выполнения процессов. Невостребованные функции программного обеспечения (ПО) должны быть исключены из состава ИТ-инфраструктры для снижения затрат на ее поддержку.  Для процессов, которым необходима информационная поддержка, требуется предоставить (закупить/разработать) соответствующие функции для повышения эффективности. Эта проблема обсуждалась на рабочей встрече по проблемам системной инженерии.
 
Управление соответствием между деятельностью и комплексом ПО является одной из проблем системной инженерии (СИ). И деятельность организации, и ее программная инфраструктура (application infrastructure) являются комплексными системами. Базовый стандарт СИ, а именно ISO 15288 "Systems and software engineering — System life cycle processes", предписывает организациям выполнять соответствующую работу. В рамках организационных практик стандарт выделяет Управление Жизненным Циклом  (УЖЦ) , т.е. деятельностью, и Управление Инфраструктурой (УИ), частью которой является программная инфраструктура (см. рисунок). Для выполнения требований указанных практик требуется создание соответствующих моделей.

Деятельность описывается с помощью модели жизненного цикла (ЖЦ). В документе "Обзор стандартов описания жизненного цикла и его практик" рассмотрены методы такого моделирования. Сделан вывод о необходимости применения ситуационной инженерии методов.
Как моделировать инфраструктуру? В упрощенном виде, инфраструктура - это набор ресурсов. Ресурсы могут быть и железом, и софтом, и людьми. Станок, САПР, инженер - все это ресурсы, только входящие в разные части общей инфраструктуры. Каждый ресурс обладает рядом функций (capabilities). Потребитель, нуждается как раз не в ресурсе непосредственно, а именно в функциях, которые обеспечивает ресурс, и которые помогут ему выполнить свою работу. Упрощенный пример для наглядности. Начальнику склада нужны не рабочие, погрузчики и система управления складом (ресурсы). Его потребность в том, чтобы груз был размещен на месте хранения, хранился в соответствующих условиях и был переведен со склада на производство в нужное время (функции).
 
Сервис, в широком смысле, представляет собой как раз набор функций предоставленных поставщиком, который владеет ресурсом или контролирует его поставку, потребителю. Ориентация на сервисы предполагает, что каждый доступный ресурс в организации, может рассматриваться как потенциальный сервис, в том смысле, что этот ресурс может быть использован для предоставления функции. Об этом можно прочитать, например, в книге "Engineering Service Oriented Systems. A Model Driven Approach" Karakostas B., Zorgios Y. Исходя из указанного, мы можем использовать методы моделирования Сервисно-Ориентированной Архитектуры (СОА) для описания инфраструктуры предприятия.
Такой подход обладает рядом преимуществ, одно из которых состоит в том, что между описанием деятельности и описанием конкретных ресурсов (в нашем случае конкретных приложений) появляется дополнительный слой абстракции. Это облегчает обеспечение соответствия между процессами организации и программной инфраструктурой. Постепенный переход поставщиков ПО от монолитных продуктов к набору гранулярных модулей, которые могут собираться в единую систему, предоставит большую гибкость в управлении ИТ-инфраструктурой, отвечающей требованиям организации.
 
Итак, для описания деятельности предлагается использовать ситуационную инженерию методов, для описания ИТ-инфраструктуры - методы моделирования СОА. Для обоих указанных доменов используются различные языки и инструменты моделирования, в каждом из которых заложена своя интерпретация концептов предметной области. Это затрудняет получение комплексной модели, требуемоей для управления соответствием между деятельностью и ИТ-инфраструктурой. Стоит проблема семантической интероперабельности моделей. Для совмещения моделей деятельности и ИТ требуется определить концепты, соответствующих доменов в виде онтологий (OWL), определить их взаимосвязь и выразить все это в терминах общей высшей онтологии. В качестве последней предлагается использовать модель данных ISO 15926. Подробнее: http://www.slideshare.net/ailev/iso-15288-iso-15926.
 
В этом блоге планируется публиковать материалы исследования указанной проблемы. Рассматриваемые вопросы:
  • место ориентации на сервисы в системной инженерии
  • онтология СОА
  • взаимосвязь между онтологией деятельности и онтологией СОА
  • применение ISO 15926 в качестве стандарта совместимости моделей
  • методы моделирования СОА
  • методы моделирования онтологий на языке OWL, на языке шаблонов ISO 15926-7
  • инструментарий моделирования (платформы, методы создания)