Координация служб позволяет нескольким службам участвовать в одном разговоре между собой, их композиция обеспечивает службам возможность одновременно вести несколько разговоров с разными службами. Различные сетевые службы могут поддерживать разные протоколы, клиент сам реализует все протоколы, необходимые для обращения к службам.
Композиция сетевых служб итеративна, добавлением составных компонентов она позволяет создавать сколь угодно сложные приложения. Клиентом может быть сетевая служба, которая может рассматриваться в качестве компонента более высокоуровневой (композитной) службы.
Композиция сетевых служб не предполагает физической интеграции компонентов. Сетевые службы – это не библиотеки прикладных программ, а интерфейсы. Композиция сетевых служб эквивалентна указанию, к каким службам надо обратиться, в каком порядке это сделать, как надо управлять исключительными ситуациями. Базовые компоненты остаются отделенными от композитных служб.
Чаще всего программирование композитных сетевых служб ведется на традиционных языках. Для проведения композиции в системах TRPC в транзакционных мониторах применяются расширенные языки Транзакционный С и Транзакционный С++. Эти расширения, обычно принимающие форму библиотек и процедурных переходников, вводят языковые средства, необходимые для композиции. Стандарты сетевых служб тоже приводят к такому подходу, поскольку протокол SOAP превращает вызовы сетевых служб в вызовы удаленных процедур. Композитная сетевая служба при этом реализуется на уровне традиционных системных платформ как самая обычная (не композитная) служба. В получающихся программах бизнес логика оказывается перемешанной с низкоуровневыми деталями, что привело к созданию моделей высокого уровня, сходных с понятием рабочего потока. Для композиции сетевых служб предложены различные языки: XL, WSFL, BPML, BPEL.
Композиция служб определяет, как надо реализовывать сетевую службу, соединяя между собой другие службы. Системная поддержка должна заключаться в определении абстракций и инструментария, которые помогут четко описать и исполнить запрос к сетевой службе, позволив разработчикам концентрироваться не на низкоуровневых деталях, а на бизнес логике. Композиционную модель и язык композиции позволяют описывать объединяемые службы, порядок, в котором к ним надо обращаться, и способ определения параметров обращений к службам (способ построения сообщений). Спецификация композитной службы, выраженная на языке композиции, называется композиционной схемой. Схема определяет бизнес-логику композитной сетевой службы, она может выглядеть как программа, написанная на языке, специально разработанном для композиции. Окружение разработки обычно характеризуется графическим пользовательским интерфейсом, с помощью которого разработчики могут создавать композиционные схемы и графы зависимостей, обозначая порядок, в котором надо обращаться к службам. Графы и другая описательная информация транслируются в текстовые спецификации (композиционные схемы). Окружение выполнения (композиционный мотор) выполняет бизнес-логику композитной службы, обращаясь к службам – компонентам, определенным в схеме. Системная поддержка композиции позволяет реализовывать композитные службы на системном уровне сетевых служб, а не на уровне традиционной системной поддержки.
Композиция служб связана с реализацией операций внутри сетевых служб. Спецификации не сообщают клиентам и нигде не регистрируют. Они предназначены для системных слоев сетевых служб, которые автоматизируют композицию, обращаясь к операциям, предлагаемым другими сетевыми службами в соответствии с композиционной схемой. С точки зрения клиента все равно, является сетевая служба композитной или нет.
Имеется четкое различие между внутренней композицией и внешней координацией сетевых служб. Координационные протоколы - это общедоступные документы, создаваемые на основе стандартных языков. Эти документы регистрируются в реестрах с целью поддержки поиска при разработке и привязки при выполнении. Разговоры, подчиняющиеся координационным протоколам, поддерживаются контроллерами разговоров, цель которых связана не с выполнением бизнес-логики, а с диспетчеризацией сообщений, приходящих для внутренних объектов, и с верификацией правил протоколов.
