Jean-Jacques Dubray, Метамодель WSPER
В списке материалов по моделированию сервисов и СОА указаны работы Jean-Jacques Dubray.
Среди них можно выделить:
Dubray пишет, что сейчас программные системы создаются так, что нет возможности менять их в соответствии с требованиями бизнеса и повторно использовать существующие приложения для создания новых. В этой ситуации бизнес не получает заявленной ценности от ИТ, а, напротив, тратит больше ресурсов на интеграцию, получая отрицательный ROI. Он утверждает, что основная идея и ценность СОА в подходе к созданию ИТ-активов (assets), которые можно повторно использовать (reuse) в различных контекстах, составляя (composition) из них новые приложения.
СОА предлагает новый способ повторного использования (reusability model). До СОА "reused" могли быть библиотеки (libraries), объекты, шаблоны (patterns). Но приложения (ИТ-активы), разрабатываемые на основе библиотек или с помощью определенного шаблона, не были "reusable" сами по себе.
Сервис (у Dubray) - это ИТ-актив (программный агент), который может быть повторно использован произвольным числом потребителей в контексте неизвестном во время проектирования (т.е. независимо от приложений, которые будут его вызывать). Context Independence ключевое свойство сервиса, для того, чтобы его можно было повторно использовать. По большому счету, контекст - это экземпляр бизнес-процесса, в котором используется сервис. Контекст должен определяться независимо от ИТ-актива.
Другие важные свойства сервисов:
Несмотря на то, что стандарты СОА плохо связаны между собой, в них заложен ряд инновационных идей (например, расширяемые структуры данных на основе 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), каждая из которых распологается в своем слое:
Модель Композиционного Программирования называется WSPER, что значит Web, Service, Process, Event, Resource. Это ключевые составляющие модели программирования. Метамодель WSPER комбинирует и расширяет концепции из стандартов WSDL, SCA/SDO и BPEL. Она состоит из 3 отдельных метамоделей: сервиса, ресурса и сборки. Ниже краткое описание состава этих метамоделей (В документе WSPER Primer приведены диаграммы классов, описывающие указанные метамодели).
Метамодель сервиса (Service metamodel)
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.
Среди них можно выделить:
- книгу Composite Software Construction. Understanding SOA in the Context of a Programming Model - ее можно скачать с сайта InfoQ
- видеопрезентацию с основными положениями
- описание метамодели WSPER с примером приложения на основе сервисов
Dubray пишет, что сейчас программные системы создаются так, что нет возможности менять их в соответствии с требованиями бизнеса и повторно использовать существующие приложения для создания новых. В этой ситуации бизнес не получает заявленной ценности от ИТ, а, напротив, тратит больше ресурсов на интеграцию, получая отрицательный ROI. Он утверждает, что основная идея и ценность СОА в подходе к созданию ИТ-активов (assets), которые можно повторно использовать (reuse) в различных контекстах, составляя (composition) из них новые приложения.
СОА предлагает новый способ повторного использования (reusability model). До СОА "reused" могли быть библиотеки (libraries), объекты, шаблоны (patterns). Но приложения (ИТ-активы), разрабатываемые на основе библиотек или с помощью определенного шаблона, не были "reusable" сами по себе.
Сервис (у Dubray) - это ИТ-актив (программный агент), который может быть повторно использован произвольным числом потребителей в контексте неизвестном во время проектирования (т.е. независимо от приложений, которые будут его вызывать). Context Independence ключевое свойство сервиса, для того, чтобы его можно было повторно использовать. По большому счету, контекст - это экземпляр бизнес-процесса, в котором используется сервис. Контекст должен определяться независимо от ИТ-актива.
Другие важные свойства сервисов:
- имеют контракт, в котором в т.ч. описан интерфейс сервиса и измеримые нефункиональные требования (Quality of Service)
- не имеют видимых зависимостей от других сервисов
- доступны, но "в спящем режиме" (idle) до получения запроса
- готовы к использованию (не требуют интеграции)
- составляются в новые сервисы (composable)
- могут иметь состояния (stateful)
- могут быть асинхронными
- сообщения/ безопасный обмен сообщениями независмый от конкретных технологий (HTTP, SOAP)
- сервисы/ взаимодействие между агентами, как паттерн обмена сообщениями; определение интерфейса (WSDL, WS Resource Framework/SDO, WS Notification - события, UDDI - регистр)
- единицы работы/ набор сервисов, оменивающихся сообщениями для достижения поставленной цели; композиция (composition) - сервис представлен как набор других сервисов, из которых он составлен; сборка (assembly) - сервисы, работающие вместе для достижения цели (SCA, WS-COORD, WS-BPEL).
- 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 описаниями поддерживает процесс непрерывных улучшений системы
- логическую архитектуру композитной системы (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). Описывает поведение интерфейса сервиса.
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.