Терминология, применяемая при описании композиционных моделей, близка к терминологии СУРП. Компонентная модель определяет объединяемые элементы в терминах предположений о таких компонентах. Оркестровая модель определяет абстракции и языки, используемые для определения порядка вызова служб. Модель данных и доступа к данным определяет методы описания данных и обмена данными между компонентами. Модель выбора службы определяет способ статической или динамической привязки. Транзакционная модель определяет транзакционную семантику, которая ассоциирована с композицией. Управление исключениями определяет способ управления исключительными ситуациями в работе службы.
Компонентная модель
Одни службы отличаются от других типами компонентов и предположениями об этих компонентах. Модель может предполагать, что компоненты реализуют некоторый набор стандартов (HTTP, SOAP, WSDL и WS-Transaction). Такие предположения снижают гетерогенность системы. Предположения можно ограничить, приняв, что компоненты обмениваются XVIL-сообщениями. Преимущество: более общая модель, недостаток: усложнение работы из-за гетерогенности. Могут применяться промежуточные решения, приводящие к использованию сложных языков и сложных систем с множеством форматов и протоколов. Язык композиции BPEL предполагает, что компонентами являются службы, описанные на WSDL.
Оркестровая модель
Оркестровка позволяет различным службам организоваться в единое целое. В ней описывается порядок вызова служб и условия, при которых определенная служба может вызываться или не вызываться. Применяются разные модели описания оркестровок: диаграммы активности, сети Петри, p-исчисление, диаграммы состояний, иерархии активностей, оркестровка на основе правил.
Модель данных и доступа к данным
Данные, используемые при композиции служб, делятся на данные приложений и управляющие данные. Прикладные данные – параметры, посылаемые или получаемые в сообщениях. Управляющие данные используются для вычисления условий перехода, они используются композиционным мотором при выполнении процесса. Обычно переменных процесса мало, их типы ограничены строковыми, целыми, вещественными, а иногда и составными типами. Значения управляющих данных обычно извлекаются из сообщений, получаемых сетевыми службами. Прикладные данные более сложны и разнообразны.
Для передачи данных между активностями, существуют два подхода: журнальный и подход явного потока данных. Журнальный подход аналогичен языкам программирования: все данные композитной службы именуются и перечисляются явно. Модификации переменных выполняются при получении сообщения «атомарно», прежние значения переменных стираются. Активности могут иметь разный уровень доступа к переменным (чтение/запись или только чтение). Каждый запуск активности заводит отдельный журнал. Подход явного потока данных требует, чтобы в дополнение к потоку управления явным элементом композиции был поток данных. На диаграммах активностей прорисовываются линии, и разработчик указывает, что входные данные одной активности (используемые, например, для сообщений, составляющих операции) должны браться из результатов ранее выполненной активности. Потоки данных гибче журналов, но сложнее: они создают неявные управляющие зависимости, поскольку активности, являющиеся источниками данных, должны завершаться до начала работы активностей, получающих эти данные.
Модель выбора службы
Композиционная схема описывает посылаемые и получаемые сообщения, а также порядок, в котором проводятся обмены. Для выполнения композиционной логики мотор должен в дополнение к схеме знать еще, какая служба является получателем сообщения. В композиционных схемах эта информация указывается абстрактно (вместо номера порта его тип или роль получателя). Перед отправкой сообщения все типы портов должны заменяться номерами. Способы привязки к службе: статическое связывание, динамическое связывание по ссылке, динамическое связывание с поиском и динамический выбор операции. Вставка адреса службы в спецификацию композитной службы полезна при построении прототипов и тестировании. Недостаток: трудность отслеживания изменений URI служб, а также то, что все отдельные запуски композитной службы всегда обращаются к одной и той же службе. При использовании подхода ссылок URI служб берутся из переменных процесса. Присваивание указателя переменной происходит в результате выполнения предыдущей операции, его можно извлекать из указателя клиента, обратившегося к композитной службе, он может быть явно задан при установке службы на машине. Если указатель должен быть динамически извлечен из справочника, этому действию надо сопоставить отдельную активность, то есть операцию интерфейса сетевой службы некоторого реестра, которая определяет указатель службы и записывает его в некоторую переменную. Динамическое связывание с поиском позволяет для каждой активности описывать запрос к справочнику. Результат обработки запроса используется для определения службы, которую надлежит вызывать, при этом необходимо формулировать критерии выбора службы из списка. Композиционные модели могут проводить динамическое связывание не только на уровне целых служб, но и на уровне отдельных операций. Такой подход называется динамическим выбором операции. Этот подход усложняет оркестровку, которой при росте вариантов выбора становится трудно управлять. Динамические операции полезны в тех случаях, когда набор параметров операции меняется в зависимости от выбранной службы.
Транзакционное поведение композитных служб определяется внедрением в оркестровую схему атомарных областей. На диаграммах такие области окружают наборы активностей, обладающие свойством «все или никто». Атомарность достигается выполнением протоколов 2РС, которые реализуются системой, не требуя от разработчика программирования. Решение проблемы менее строгой транзакционной семантики связано с применением компенсаций, когда результаты подтвержденных операций отменяются выполнением других операций. Применение такого подхода означает, что при возникновении ошибки для осуществления частичного отката операций атомарной области системный слой сетевых служб должен инициировать и выполнить протокол компенсации подтвержденных активностей. Транзакционная модель саг позволяет разбивать длительные транзакции на подтранзакции, имеющие традиционные транзакционные свойства и исполняемые в некотором предопределенном порядке. При завершении они подтверждаются, снимая блокировки и показывая результат другим транзакциям. Откат саги выполняется прерыванием всех активных подтранзакций и компенсацией подтвержденных подтранзакций в порядке, обратном выполнению. Ответственность за реализацию компенсации возлагается на разработчика службы, то есть на стороны компонентов, а не на сторону композиции. Если компонент уже имеет компенсационную логику, разработчик композиции освобождается от ее реализации, а обращается к компенсационной операции.
Управление исключениями
Исключения обычно вызываются ошибками в системе или в вызываемых приложениях, либо могут быть ситуациями, предусмотренными семантикой сетевой службы. При использовании подходов, основанных на потоках, в конце каждой операции результат проверяется на наличие ошибок, и, если ошибка есть, выполняются соответствующие действия. В случаях, когда вызванная операция не возвращает никакого результата, для каждой активности вводят тайм-ауты, при срабатывании которых мотор останавливает активность. Методика «попытка-перехват-возбуждение» ассоциирует исключение с группой активностей и вводит логическое условие, связанное с композиционными данными. Если условие выполнено, выполняется часть программы, управляющая исключением. После этого, в зависимости от спецификации исключения, процесс может повторить активность, повторить обработку исключения или просто остановиться. Такая методика полезна, если оркестровая модель допускает определение групп активностей и ассоциирования с этими группами отдельных свойств, или если оркестровка может быть структурирована в иерархии. Преимущества: отделение обычной логики от логики исключений, структурирование определения исключений, возможность описания стратегии продолжения работы после завершения обработки исключения.
Подходы, основанные на правилах, управляют исключениями на основе правил «событие-условие-действие», с помощью которых событие облекается в форму сообщений, посылаемых композитной службе, или в форму тайм-аутов. Условие есть логическое выражение, которое проверяет, действительно ли событие относится к исключительной ситуации, которую надо обработать вызовом операции или прерыванием транзакции. Правила обычно определяются в некотором текстовом виде, дополняя графическую нотацию, определяемую оркестровкой. Подходы, основанные на правилах, разделяют нормальное и исключительное поведение процесса, но в системе появляется еще один язык, который надо изучать и интерпретировать.
