Работа сетевых служб проводится следующим образом. Текст ее описания на WSDL хранится у поставщика службы. Компилятор языка WSDL создаст серверный переходник (обычно в виде сервлета) и регистрирует его на маршрутизаторе SOAP. Маршрутизатор при обращении к определенному ресурсу (URI) должен вызвать зарегистрированный переходник, который будет вызывать исходный объект. Этим реализация службы завершается. Теперь надо опубликовать в реестре техническую модель, ссылающуюся на автоматически полученное описание на языке WSDL, а затем опубликовать в реестре полноценную запись, в которой должны содержаться сведения об адресе, по которому служба доступна, и ссылка на техническую модель. Привязка к портам (статическая или динамическая) выполняется реестрами служб.
Для организации взаимодействия служб друг с другом надо следовать протоколам координации сетевых служб, которые строятся на основе понятия «разговора». Для описания протоколов координации служб важным является понятие «роли». Участники взаимодействия «играют» свои роли, обмениваясь сообщениями. Протокол накладывает ограничения на порядок, в котором такой обмен может происходить. Термин «разговор» относится ко всякой последовательности операций (обменов сообщениями), возникающей между клиентом и службой в процессе обращения к службе. Термин «координационный протокол» относится к спецификации набора допустимых разговоров. Существующие стандарты, в частности, стандарт языка описания разговоров сетевых служб WSCL пока не получили достаточной поддержки, поэтому для описания координационных протоколов применяются различные модели. Среди используемых моделей выделяются две: модель диаграмм последовательности и модель диаграмм активности. При описании координационных протоколов указывают роли участников.
Диаграммы последовательности распространены ввиду их простоты и интуитивной ясности, однако чем сложнее протокол, тем сложнее становится разобраться в этих диаграммах. Иногда прорисовывают несколько диаграмм (как при описании протокола TCP), но диаграмм может стать слишком много. Часто применяют диаграммы активности, с помощью которых показываются альтернативные и параллельные ветви разговоров.
Зная координационный протокол и роль, которую сетевая служба играет в этом протоколе, разработчики проектируют приложения, взаимодействующие с этой службой. Координационные протоколы помогают организовать динамическую привязку к службе, поскольку приложения, разработанные для участия в некотором протоколе, могут ограничить поиск сетевых служб в реестрах только теми, которые играют определенные роли. Координационные протоколы обычно хранятся в реестрах в виде технических моделей, а роли, исполняемые службой, могут указываться в шаблонах использования, ссылающихся на модели.
Координационные протоколы не раскрывают деталей реализации, что облегчает внесение изменений в программы взаимодействия служб, пока изменения в программах не затрагивают протокол. Ролевые протоколы являются подмножествами полных протоколов, но содержат только те операции и сообщения, которые необходимо знать исполнителю определенной роли. Координационные протоколы сетевых служб делятся на вертикальные и горизонтальные. Вертикальные протоколы относятся к отдельным отраслям (и называются бизнес протоколами). Обычно в них описывается: правильность построения конкретных бизнес транзакций, определяются форматы соответствующих документов, семантика содержимого этих документов.
Многие важные детали реализации в вертикальных протоколах отсутствуют, которые концентрируются на семантике обменов, а также на наборах правильных разговоров. С деталями имеют дело горизонтальные протоколы, в которых определяется общая инфраструктура, не зависящая от прикладной области. Их цель - наделить обмены, проходящие между службами, высокоуровневыми абстракциями, реализованными в системном слое сетевых служб прозрачно для разработчиков самих служб. Сложность сетевых служб в том, что они предназначены для взаимодействия не внутри, а между предприятиями, и многие, ранее разработанные методы, для них не пригодны. В частности, из-за длительности взаимодействия протоколы подтверждения типа 2РС использоваться не могут, так как они в момент этого подтверждения блокируют ресурсы. Следует разрабатывать новые стандарты (WS-Coordination, WS-Transaction).
