Оркестровка.
Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.
Оркестровка относится к определению бизнес-процесса, который может взаимодействовать с внешними и внутренними Web-сервисами. Происходящие на основе обмена сообщениями взаимодействия включают бизнес-логику и порядок выполнения задач; они могут выходить за границы приложений и организаций, определяя долговременную, транзакционную, многошаговую бизнес-модель. Оркестровка всегда представляет управление с позиций одного участника процесса. Хореография позволяет каждому участнику описать свою часть взаимодействия. При использовании хореографии отслеживаются последовательности сообщений между несколькими участниками и источниками. Предлагаемые стандарты оркестровки и хореографии должны удовлетворять нескольким требованиям, относящимся к языку описания потока работ бизнес-процесса и инфраструктуре выполнения процесса. К числу этих требований относятся асинхронный вызов службы; управление исключительными ситуациями и обеспечение транзакционной целостности на основе компенсационного подхода; динамичность, гибкость и адаптируемость оркестровки к изменению потребностей бизнеса; возможность композиции сервисов более высокого уровня из существующих оркестрованных процессов.
К ранним языкам определения бизнес-процессов путем комбинирования Web-сервисов относятся XLANG компании Microsoft (www.gotdotnet.com/team/ xml_wsspecs/xlang_c/default.htm) и Web Services Flow Language (WSFL) компании IBM (www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf). XLANG основан на языке WSDL; его основное назначение состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. WSFL позволяет описывать как публичные, так и частные процессы. Определяется обмен данными, последовательность выполнения и отображение каждого шага процесса на конкретные операции.
Компании Sun Microsystems, BEA и Intalio разработали спецификацию языка Web Services Choreography Interface (WSCI — www.sun.com/software/xml/ developers/wsci/wsci-spec-10.pdf). Это расширение WSDL позволяет определить общую хореографию Web-сервисов.
Что такоеWeb-сервисы
Web-сервисами мы называем активный контент, реализующий некоторую функциональность, и данные, расположенные наWeb-серверах и предоставляемые для использования внешним приложениям.Web-сервисы полностью независимы от языка и платформы реализации. Внешние приложения работают с сервисами посредством стандартных протоколов и форматов данных. ТехнологияWeb-сервисов является краеугольным камнем программной моделиMicrosoft.NET.
Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA (см. рис. 1). Использование XML и Web-сервисов "поднимает SOA на более высокий уровень".
Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.
Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях.
Пример.
Для демонстрации возможностей SOAPможет быть использована недавно вышедшая реализацияSOAPToolkitверсии 2.0 производстваMicrosoft.
Объект SOAPClientвыступает в роли посредника (proxy), предоставляющего интерфейсWeb-сервиса и позволяющего работать с ним как с обычнымCOM-объектом (рис. 1).
Рис. 1. Механизм взаимодействия клиента и сервера SOAP.
Клиентское приложение создает экземпляр объекта SOAPClient.
SOAPClientчитает файлы описания методовWeb-сервиса (на языкахWSDLиWebServicesMetaLanguage,WSML). Эти файлы могут храниться и на стороне клиента.
Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса.SOAPClientформирует пакет запроса (SOAPEnvelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используетсяHTTP.
Серверное приложение Listener(это может бытьISAPI-приложение илиASP-страница) принимает пакет, создает объектSOAPServerи передает ему пакет запроса. Помимо этогоListenerобрабатываетHTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональностьSOAP-объектов.
SOAPServerчитает описаниеWeb-сервиса, загружает описание и пакет запроса в деревьяXMLDOM.
SOAPServerвызывает метод объекта или приложения, реализующего сервис.
Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServerв пакет ответа и отправляются клиенту.
Объект SOAPClientпроводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.
WSDL-файл - это документ в форматеXML, описывающий методы, предоставляемыеWeb-сервисом, а также параметры методов, их типы, названия и местонахождение сервисаListener. МастерSOAPToolkitавтоматически генерирует этот документ, фрагмент которого приведен ниже:
SOAPEnvelope(Пакет) - этоXML-документ, который содержит в себе запрос на выполнение метода или ответ на него. Удобнее всего рассматривать пакет как почтовый конверт, в который вложена информация (рис. 2).
Рис. 2. Структура SOAP-пакета.