WWW.BOOK.LIB-I.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные ресурсы
 

« ...»

Оглавление

Введение

Глава 1. Архитектура XML Web-сервисов

Модель Message Oriented

Модель Service Oriented

Модель Resource Oriented

Модель Policy

Архитектура Service Oriented Architecture (SOA)

Основные технологии архитектуры Web-сервисов

XML

XML Namespaces

XML Infoset

XML Schema

SOAP 1.2

WSDL 2.0

Практическое применение Web-сервисов

UDDI

ebXML

DISCO

JAXR

Языки WS-BPEL и WS-CDL

WS-BPEL 2.0

WS-CDL 1.0

Глава 2. Расширения технологии Web-сервисов

WS-Policy, WS-PolicyAttachment и WS-PolicyAssertions

WS-Addressing

WS-Security

WS-Trust

WS-SecureConversation

WS-SecurityPolicy

WS-Federation

WS-Transfer

WS-ResourceTransfer и WS-Fragment

Оглавление WS-MetadataExchange

WS-Enumeration

WS-Eventing

WS-Management

WS-Discovery

WS-ReliableMessaging

WS-ReliableMessaging Policy

WS-MakeConnection

WS-Coordination

WS-AtomicTransaction

WS-BusinessActivity

Глава 3. Java Web-сервисы

JAXM и SAAJ

Пример Web-сервиса и клиента на основе JAXM и SAAJ

JAXP

Пример использования JAXP

JAXB

Инструменты xjc и schemagen

Binding Declaration

JAXB API

Пример использования JAXB

JAX-RPC

Инструменты wscompile и wsdeploy

JAX-RPC API

Пример использования JAX-RPC

JAX-WS

JAX-WS API

Модель программирования JAX-WS

Модель программирования на стороне сервера

Модель программирования на стороне клиента

Развертывание JAX-WS Web-сервисов и JAX-WS-клиентов

Пример создания JAX-WS Web-сервиса и JAX-WS-клиента

JAX-RS

JAX-RS API

Модель программирования и развертывания JAX-RS Web-сервисов

Формат JSON

WADL

Применение технологии JAX-RS

Глава 4. Проект Metro

Тестирование стека Metro

Оптимизация передачи двоичных данных (MTOM)

Адресация

Надежная доставка сообщений

Система безопасности

Создание клиента Web-сервиса

Опция Проверка подлинности имени пользователя с помощью симметричного ключа

Оглавление 5 Опция Username Authentication with Password Derived Key

Опция Безопасность совместных сертификатов

Опция Симметричная привязка к маркеру Kerberos

Опция Безопасность транспорта (SSL)

Опция Проверка подлинности сообщения по SSL

Опция Проверка подлинности SAML по SSL

Опция Одобрение сертификата

Опция Подтверждение подлинности отправителя SAML сертификатом........ 366 Опция Держатель ключа SAML

Опция Выпущенный STS маркер

Опция Выпущенный STS маркер с сертификатом службы

Опция Выпущенный STS маркер одобрения

Опция Выпущенный STS маркер поддержки

Поддержка протокола SOAP/TCP

Поддержка кодировки Fast Infoset

Поддержка WS-MakeConnection

Глава 5. Проект Apache CXF

Архитектура платформы CXF

Создание SOAP Web-сервисов с использованием CXF API

Связывание данных Aegis

Связывание данных XMLBeans

Опции features и обработчики Interceptors

Протоколы передачи сообщений

Поддержка протокола SOAP/HTTP

Поддержка протокола XML/HTTP

Поддержка протокола HTTPS





Apache Camel, JMS и Apache ActiveMQ

Проект Apache Camel

Проект Apache ActiveMQ

Локальный транспорт

Поддержка MTOM

Поддержка спецификаций WS-*

WS-Addressing

WS-ReliableMessaging

WS-Security

WS-SecurityPolicy

WS-Trust

WS-SecureConversation

JAX-RS

JavaScript

Глава 6. Проект Axis2

Конфигурационный файл axis2.xml

Архив AAR и развертывание Web-сервиса

Модули Axis2

Модель программирования Axis2 Web-сервисов

Axis2 XML-модель AXIOM

Client API

Оглавление Поддержка архитектуры REST

Связывание данных

ADB (Axis2 Databinding)

XMLBeans

JiBX

JAXB

Поддержка MTOM

Поддержка протокола HTTPS

HttpClient и аутентификация

Транспортные протоколы проекта Axis2

TCP

JMS

WS-ReliableMessaging

WS-Security

Приложение. Описание электронного архива

Список литературы

Предметный указатель

Введение Технология Web-сервисов — это технология создания распределенных систем, составленных из взаимодействующих между собой программных продуктов, созданных и работающих на основе различных платформ.

Web-сервисы призваны согласовывать работу больших, состоящих из множества частей приложений, предоставляя для приложений бизнес-функции обмена данными.

Помимо функции обмена данными между различными приложениями и платформами, Web-сервисы могут выступать как повторно-используемые компоненты приложения, предоставляющие разнообразные сервисы — от прогноза погоды до перевода с одного языка на другой.

Web-сервисы представляют собой программные компоненты, имеющие идентификатор URI, и взаимодействие с которыми осуществляется по Интернету с помощью открытых протоколов.

Коммуникация с Web-сервисами может выполняться с помощью различных транспортных протоколов, таких как HTTP, HTTPS, FTP, SMTP, BEEP, при этом Webсервисы можно подразделить на три вида: SOAP Web-сервисы, ориентированные на модель RPC — вызов удаленных процедур, XML Web-сервисы, ориентированные на сообщения, и RESTful Web-сервисы.

Первая группа Web-сервисов — это Web-сервисы, взаимодействие с которыми производится с использованием XML-сообщений по SOAP-протоколу (Simple Object Access Protocol), и имеющие интерфейсы, описанные в формате WSDL (Web Services Description Language). Такое описание интерфейса сервиса обеспечивает автоматическую генерацию кода на клиентской стороне, необходимого для связи с сервисом. Описание WSDL Web-сервиса может быть доступно клиенту с помощью реестра UDDI (Universal Description, Discovery, and Integration), в котором Webсервис предварительно зарегистрирован. SOAP-протокол может использовать различные транспортные протоколы — HTTP, FTP SMTP и др., однако чаще всего SOAP используется поверх HTTP. SOAP-сообщения, участвующие в обмене между клиентом и SOAP RPC Web-сервисом, имеют строго определенную структуру для передачи имени вызываемой удаленной процедуры и ее параметров, а также результата ее вызова.

Введение Вторая группа Web-сервисов — это XML Web-сервисы, ориентированные на сообщения. Эти XML Web-сервисы обеспечивают низкоуровневую обработку XMLсообщений, при этом Web-сервис обрабатывает полученные XML-данные целиком, как они есть, и полностью формирует ответное XML-сообщение. XML Webсервисы могут передавать и получать сообщения как в формате SOAP, так и в чистом XML-формате.

Третья группа Web-сервисов — это RESTful Web-сервисы, представляющие удаленные ресурсы, доступные с помощью HTTP-запросов. RESTful Web-сервисы обеспечивают взаимодействие с удаленными ресурсами, передавая клиенту их представление. RESTful Web-сервисы идентифицируются URL-адресом и обрабатывают HTTP-методы GET, PUT, POST и DELETE в ответ на запрос клиента. Технология REST Web-сервисов также может использовать WSDL-описание и SOAPпротокол для передачи сообщений, но может обходиться и без них.

Альтернативой использования технологии Web-сервисов для создания распределенных систем является применение технологий CORBA (Common Object Request Broker Architecture), Java RMI (Remote Method Implementation) и DCOM (Distributed Component Object Model).

Технология Web-сервисов развивается под эгидой организации W3C.

ПРИМЕЧАНИЕ World Wide Web Consortium (W3C) — международное сообщество, состоящее из постоянных членов (в 2009 году 338 организаций), штатных сотрудников и общественности, цель которого — разработка стандартов Web.

Стандарты сообщества W3C объединены в следующие группы:

Web-дизайн и приложения — стандарты для создания и отображения Webстраниц, включая обеспечение их доступности и интернационализации. Данная группа описывает такие технологии, как HTML, CSS, SVG, Ajax и др., а также создание Web-приложений для мобильных устройств;

Web-архитектура — описывает базисные технологии и принципы, включая URI и HTTP;

семантическая Web-информация — блок посвящен технологиям Web-данных, позволяющим создавать хранилища Web-данных, словари, а также определять правила для управления данными;

XML-стандарты — представляет такие стандарты, как XML, XQuery, XML Schema, XSLT, XSL-FO, Efficient XML Interchange (EXI) и др.;

Web-сервисы — описывает технологии обмена сообщениями;

Web-устройства — технологии Web-доступа везде, в любое время и с использованием любого устройства;

браузеры и инструменты — технологии для разработки программного обеспечения Web.

W3C-группа Web-сервисы содержит следующие подгруппы спецификаций (http://www.w3.org/standards/webofservices/).

Введение 9 Данные.

XML Schema — спецификации посвящены языку описания структуры XMLдокумента. XML-схема используется для проверки XML-документа на соответствие XML-схеме, после чего могут быть созданы объекты, соответствующие структуре XML-документа.

XML-binary Optimized Packaging — спецификации определяют способ включения бинарных данных в XML-документ. Стандарт включения бинарных данных оптимизирует передачу вместе с XML-документом двоичных данных большого объема, таких как изображения и различного рода мультимедийных данных.

XML — спецификации описывают язык Extensible Markup Language (XML).

RDF — спецификации описывают платформу Resource Description Framework (RDF) для представления данных в Web-сети.

GRDDL — спецификации описывают механизм Gleaning Resource Descriptions from Dialects of Languages извлечения RDF-контента из XMLдокументов.

Протоколы.

HTTP — спецификации описывают механизм расширения HTTP-протокола, включая расширение HTTP-протокола для электронной торговли, альтернативный HTTP-протоколу — протокол HTTP-NG и его части — протокол SMUX, протокол Binary Wire Protocol и Web Interface, представление HTTPпротокола с использованием RDF, библиотеку API для получения событий сервера с помощью HTTP-протокола.

SOAP — спецификации описывают SOAP-протокол обмена XML-сообщениями.

Web Services Addressing — спецификации определяют механизм обращения к Web-сервисам и обмена с ними сообщениями.

Web Services Architecture — спецификации описывают архитектуру и механизм работы технологии Web-сервисов.

Описание сервиса.

WSDL — спецификации определяют язык описания Web-сервисов Web Services Description Language.

Web Services Choreography — спецификации определяют язык Web Services Choreography Description Language (WS-CDL) описания последовательности и условий обмена сообщениями и взаимодействия Web-сервисов.

Web Services Policy — спецификации описывают механизм обеспечения требований и условий взаимодействия с Web-сервисами, позволяя Web-сервису ассоциироваться с набором правил — политикой, которой должен придерживаться потребитель Web-сервиса.

Введение Semantic Annotation for WSDL and XML Schema — спецификации определяют расширение WSDL для классификации, регистрации/обнаружения, сопоставления, композиции и вызова Web-сервисов.

Service Modeling Language (SML) — спецификации описывают язык моделирования сложных систем взаимосвязанных сервисов и ресурсов.

Web Services Resource Access — спецификации определяют основанные на SOAP протоколы для передачи больших данных, получения уведомлений о событиях Web-сервисов, управления основанными на Web-сервисах ресурсами.

Безопасность.

XML Encryption — спецификации описывают механизм шифрования данных и представления результатов шифрования в XML-документе.

XML Signature — спецификации описывают механизм цифровой подписи XML-документов.

XML Key Management Specification (XKMS) — спецификации описывают протокол распространения и регистрации публичных ключей цифровой подписи XML-документов.

Интернационализация — спецификации описывают интернационализацию Webсервисов, HTML- и XML-документов.

Технология Web-сервисов впервые официально была включена в качестве стандарта в спецификацию J2EE 1.4 в 2003 году. При этом основой Java-технологии Webсервисов стала спецификация Java API for XML-Based RPC (JAX-RPC), которая вместе с технологией Java APIs for XML Messaging (или SOAP with Attachments API for Java (SAAJ)) обеспечивала поддержку функциональной совместимости Webсервисов. С тех пор технология Web-сервисов платформы Java прошла большой эволюционный путь до спецификации Java API for XML-Based Web Services (JAXWS), ставшей стандартом платформы Java EE 5.

Знание технологии Web-сервисов является необходимым условием профессиональной квалификации программиста. Это видно из анализа требований к Javaпрограммисту в вакансиях на рынке труда (табл. В1).

Таблица В1. Требования к знаниям и опыту Java-программиста на рынке труда

–  –  –

В данной книге предлагаются к рассмотрению основы самой технологии Webсервисов, реализации технологии Web-сервисов в виде стандартов платформы Java и в таких распространенных Java-стеках Web-сервисов, как Metro, Apache CXF и Axis2.

Стек Metro представляет стек Web-сервисов, состоящий из реализаций технологий JAX-WS, JAXB и WSIT. Технология Metro является частью платформы Java EE и интегрирована с сервером GlassFish, позволяя создавать и развертывать безопасные и надежные Web-сервисы с поддержкой транзакций. При этом технология Metro гарантирует совместимость между Web-сервисами платформ Java EE и Microsoft.NET в приложениях, основанных на архитектуре Service Oriented Architecture (SOA).

Стеки Apache CXF и Axis2 представляют собой открытые платформы со средой выполнения для разработки и развертывания Web-сервисов, обеспечивающие поддержку спецификаций как самой технологии Web-сервисов, так и стандартов ее реализации платформой Java.

Архитектура XML Web-сервисов 59 ся для описания в элементе types сообщений, которые ссылаются на другие Webсервисы. Значения атрибутов wsdlx:interface и wsdlx:binding — QName-имена соответственно элементов interface и binding WSDL-описания Web-сервиса, на который ссылается сообщение. В частности, данные атрибуты могут быть применены для описания XML-элемента сообщения, значением которого является URLадрес конечной точки Web-сервиса.

Два элемента верхнего уровня — include и import — обеспечивают модульность WSDL-описания Web-сервиса.

Элемент include позволяет включить элементы interface, binding и service из другого WSDL-документа, имеющего то же пространство имен, что и основной WSDL-документ. Элемент include имеет обязательный атрибут location, значением которого является URL-адрес включаемого WSDL-документа.

Элемент import дает возможность ссылаться в основном WSDL-документе на элементы импортируемого WSDL-документа, принадлежащие другому пространству имен. Элемент import имеет обязательный атрибут namespace, указывающий пространство имен импортируемого WSDL-документа, и необязательный атрибут location — URL-адрес импортируемого WSDL-документа.

Практическое применение Web-сервисов Web-сервисы реализуются в виде программных компонентов на основе какой-либо из платформ, например Microsoft.NET или Java, и разворачиваются на сервере приложений, например IIS или GlassFish. При этом кроссплатформенность взаимодействия с Web-сервисами обеспечивается XML-форматом их описания и XMLформатом сообщений, участвующих в обмене с Web-сервисами. Однако такая архитектура налагает и ограничения на применение технологии Web-сервисов.

Взаимодействие с Web-сервисом подразумевает разбор XML-сообщения при его получении, затем, после выполнения необходимых операций, упаковку результатов снова в XML-сообщение перед его отправкой. Такая обработка увеличивает накладные расходы. Поэтому при создании программного комплекса на одной платформе, работающего на одном компьютере или в локальной сети, для увеличения скорости работы лучше обойтись без включения в программный комплекс Webсервисов. Если же Web-сервис создается с целью предоставления услуги для широкого круга потребителей, заранее не известных и клиентские приложения которых могут работать на различных платформах, или для включения в программный комплекс, компоненты которого работают в распределенной среде на различных платформах, тогда применение технологии Web-сервисов будет хорошим решением.

Проектирование распределенной SOA-системы, реализующей технологию Webсервисов, основывается на классификации Web-сервисов по их типу взаимодействия с клиентом, по типу клиента для Web-сервиса, по модели обработки запроса Web-сервисом.

Глава 1 Исходя из модели обработки клиентского запроса, Web-сервисы подразделяются следующим образом:

метод-ориентированные Web-сервисы;

документ-ориентированные Web-сервисы;

ресурс-ориентированные Web-сервисы.

В модели обработки метод-ориентированного, или RPC, Web-сервиса содержимое сообщения тесно связано с вызываемыми процедурами интерфейса, явно указывая имя процедуры, а также имена и значения параметров процедуры. Таким образом, главная задача такого сообщения — это передача параметров процедуры интерфейса RPC Web-сервиса. При получении сообщения RPC Web-сервисом данные сообщения преобразуются в значения параметров вызываемой процедуры, после выполнения которой формируется ответ клиенту, также тесно связанный с процедурой.

Такой подход имеет свои недостатки. Каждый клиент RPC Web-сервиса должен заранее точно знать все детали интерфейса Web-сервиса, что вызывает тесную связь между клиентом и Web-сервисом — при изменении имени или параметров процедуры необходимо делать обновление всех клиентов такого Web-сервиса.

В модели обработки документ-ориентированного Web-сервиса содержание сообщений явно не связано с процедурами интерфейса, и их структура полностью определяется XML-схемой, что дает возможность проверки сообщений относительно XML-схемы в реальном времени. Это создает более слабую связь между клиентом и Web-сервисом, т. к. все изменения производятся в XML-схеме, а не в WSDLописании и самих сообщениях.

Документ-ориентированный Web-сервис оперирует сообщениями целиком, а не параметрами процедуры, как RPC Web-сервис. Такой подход имеет и свои недостатки — увеличивается сложность интерпретации функциональности Web-сервиса, ведь для этого дополнительно требуется анализ структуры сообщений, обрабатываемых Web-сервисом. Для строго документ-ориентированных Web-сервисов в WSDL-описании вообще не требуется определение операций — центральную роль играет XML-схема. Для строго метод-ориентированных Web-сервисов основную нагрузку несет WSDL-описание, содержащее определения процедур интерфейса и их параметров, а XML-схема не требуется.

Ресурс-ориентированные Web-сервисы основываются на архитектуре передачи состояния представления REST (Representational State Transfer) и оперируют представлениями ресурсов. RESTful Web-сервисы поддерживают четыре операции — GET, PUT, POST и DELETE, — аналогичные соответствующим HTTP-методам, с помощью которых производятся запрашиваемые клиентом действия с ресурсами, представленными Web-сервисами, каждый из которых идентифицируется своим URL-адресом.

Архитектура REST упрощает анализ клиентского запроса, т. к. HTTP-методы запроса напрямую связываются с операциями REST Web-сервиса. Однако при этом каждый клиентский запрос, в случае строго ресурс-ориентированных WebАрхитектура XML Web-сервисов 61 сервисов, должен содержать всю необходимую информацию для его обработки, т. е. состояние клиентского запроса не сохраняется сервером. Кроме того, отличие REST Web-сервисов состоит в ограничении "один ресурс — один URL-адрес" и в названии и количестве операций, ограниченных GET, PUT, POST и DELETE.

Web-сервисы могут иметь клиентов двух типов. Первый тип клиента — это клиентское приложение, взаимодействие которого с Web-сервисом инициирует реальный пользователь. Такого рода приложения могут быть либо "тонким" клиентом (Webбраузер), либо "толстым" клиентом (самостоятельные настольные приложения с графическим интерфейсом пользователя). Второй тип клиента — это программный компонент, автоматически совершающий запрос Web-сервису без участия человека.

Взаимодействие клиента с Web-сервисом может быть синхронным или асинхронным. В случае синхронного взаимодействия, после отправки клиентом запроса Web-сервису, все его действия блокируются до тех пор, пока не будет получен ответ. При асинхронном взаимодействии действия клиента не блокируются, а обработка ответа производится после его получения от Web-сервиса.

Таким образом, существуют следующие основные сценарии взаимодействия с

Web-сервисом:

однонаправленный запрос — клиент посылает сообщение Web-сервису или Web-сервисам, которые его обрабатывают, но не генерируют ответ;

синхронный "запрос — ответ" — синхронный обмен сообщениями между клиентом и Web-сервисом;

асинхронный "запрос — ответ" — асинхронный обмен сообщениями между клиентом и Web-сервисом;

RPC-вызов — клиент вызывает процедуру интерфейса Web-сервиса путем сериализации параметров процедуры в сообщение и отправки его Web-сервису;

ошибки — выполнение процедуры интерфейса Web-сервиса завершается ошибкой, и клиент получает сообщение об ошибке;

запрос с подтверждением — клиент получает от Web-сервиса сообщение об успешной или неудачной доставке клиентского запроса;

передача через посредников — клиентское сообщение передается конечному Web-сервису через промежуточные Web-сервисы, при этом возможна маршрутизация и трекинг;

кэширование — в случае схожего клиентского запроса ответ ему посылается из кэша;

диалог — сообщения, участвующие в обмене клиента с Web-сервисом, группируются в логические наборы с сохранением состояния;

дополнительная функциональность — обмен сообщениями производится с дополнительными требованиями, такими как кодирование (при сериализации пересылаемые данные дополнительно шифруются), аутентификация (клиент должен послать в запросе логин и пароль или сертификат для доступа к WebГлава 1 сервису), целостность (сообщения снабжаются электронной подписью для гарантии их целостности при пересылке), транзакции (при обмене сообщений устанавливается контекст транзакции) и др.

При создании Web-сервиса с целью предоставления услуги для широкого круга потребителей, заранее не известных, необходимо позаботиться о том, чтобы потенциальные пользователи Web-сервиса смогли его найти.

Для обычных пользователей Интернета Web-сервисы становятся доступными с помощью элементов управления, размещенных на Web-страничках сайтов. Заполняя форму и нажимая кнопку Submit или активируя гиперссылку, посетитель сайта, сам того не осознавая, может осуществлять запрос к Web-сервису.

Для Web-разработчиков публичный Web-сервис необходимо зарегистрировать в каком-либо из открытых реестров, чтобы его могли включить в SOA-систему. Такого рода реестры доступны в Интернете на Web-страницах сайтов, публикующих списки Web-сервисов, которые предназначены для широкой аудитории. Примеры публичных Web-сервисов можно посмотреть по адресу http://www.xmethods.net или http://www.service-repository.com.

При использовании Web-сервисов в корпоративных средах создаются специальные закрытые реестры, позволяющие осуществлять как статический, так и динамический поиск нужного Web-сервиса. Существуют различные стандарты для создания корпоративных реестров. Наиболее распространенные среди них — это UDDI, ebXML и DISCO.

UDDI UDDI (Universal Description, Discovery and Integration, http://uddi.xml.org) — стандарт для создания платформонезависимого, основанного на XML, реестра, позволяющего публиковать и находить WSDL-описания Web-сервисов.

UDDI-реестр дает возможность доступа потребителям Web-сервисов к информации о поставщиках, функциональности и деталях реализации Web-сервисов. Для администрирования UDDI-реестров создаются или используются готовые UDDIсерверы, представляющие собой приложения, которые обеспечивают хранение и управление информацией о Web-сервисах в различного рода базах данных, включая классификацию, каталогизацию, обновление версий и тестирование Webсервисов.

Кроме того, подписка на UDDI-реестр гарантирует получение уведомлений об изменениях в реестре. По своей сути UDDI-сервер представляет собой набор Web-сервисов, осуществляющих управление UDDI-реестром. Пример UDDIсервера с открытым исходным кодом можно посмотреть по адресу http:// openuddi.sourceforge.net или http://ws.apache.org/juddi.

UDDI-реестр логически разделен на три типа каталогов, образующих иерархию, подобную телефонному справочнику:

белые страницы — предоставляют информацию о поставщиках Web-сервисов, включая имя поставщика, его описание, контактную информацию;

желтые страницы — классифицируют Web-сервисы по сферам применения;

Архитектура XML Web-сервисов 63 зеленые страницы — предоставляют информацию о деталях реализации Webсервисов, необходимую для доступа к ним.

Информация, относящаяся к вышеперечисленным каталогам, описывается моделью данных UDDI, представляющей данные в виде наборов сущностей, каждая из которых хранится в виде XML-элемента соответствующего XML-файла:

businessEntity описывает поставщика Web-сервиса;

businessService описывает набор Web-сервисов, предоставляемых определенным поставщиком;

bindingTemplate содержит техническую информацию о реализации Webсервиса, ссылается на tModel;

tModel содержит информацию о типе Web-сервиса, протоколах, используемых Web-сервисом, дополнительных требованиях к использованию Web-сервиса, характеристики Web-сервиса и т. д.;

publisherAssertion описывает отношения между элементами businessEntity;

subscription устанавливает требование отслеживать изменения в наборе сущностей.

WSDL-описание Web-сервиса и UDDI-документ соотносятся между собой следующим образом:

WSDL-элемент interface описывается UDDI-элементом tModel;

WSDL-элемент service описывается UDDI-элементами businessService и bindingTemplate.

Каждый хранящийся в UDDI-реестре XML-файл с данными имеет свой уникальный UDDI-идентификатор и структуру, которая определяется XML-схемами.

Управление информацией UDDI-реестра осуществляют UDDI-узлы, представляющие собой наборы Web-сервисов, поддерживающих специальные узловые API:

UDDI-запрос;

UDDI-публикация;

UDDI-безопасность;

UDDI-хранение;

UDDI-подписка;

UDDI-репликация.

Клиент UDDI-реестра, в свою очередь, должен поддерживать следующие клиентские интерфейсы API:

UDDI-прослушивание подписки;

UDDI-установка пользовательского набора значений, характеризующих Webсервис для более эффективного поиска.

Все UDDI API представлены XML-элементами, которые упаковываются в SOAPсообщения, участвующие в обмене между клиентом и UDDI-узлом. При этом конГлава 1 кретная UDDI-реализация в виде UDDI-сервера предоставляет клиентам свою библиотеку API, позволяющую программным образом взаимодействовать с UDDIреестром и динамически осуществлять публикацию и поиск Web-сервисов.

ebXML ebXML (Electronic Business using eXtensible Markup Language, http://ebxml.

xml.org) — стандарт, основанный на XML и обеспечивающий инфраструктуру обмена бизнес-информацией и создание общей XML бизнес-среды для различных компаний. Стандарт ebXML позволяет создавать с помощью XML бизнесдокументы и описания бизнес-процессов и хранить их в реестре, давая возможность статически и динамически осуществлять поиск информации о бизнеспартнерах. Таким образом, предназначение ebXML гораздо шире, чем хранение и управление информацией о Web-сервисах в корпоративной среде. Основной целью стандарта ebXML является создание единого глобального электронного рынка. Поэтому организация ebXML-реестра возможна как для отдельной корпоративной среды, так и для консорциума, объединяющего компании определенной индустрии.

Стандартный сценарий использования реализации ebXML состоит из следующих шагов:

1. Компания А решает присоединиться к использованию ebXML-реестра, после этого она запрашивает у ebXML-реестра требования к локальной ebXMLреализации. Далее компания А устанавливает свою локальную ebXML-систему, позволяющую взаимодействовать с ebXML-реестром и локальными ebXMLсистемами бизнес-партнеров.

2. Компания А создает и регистрирует для хранения профиль Collaboration Protocol Profile (CPP) в ebXML-реестре, используя свою локальную ebXML-систему.

Компания может зарегистрировать несколько CPP-профилей, описывающих различные возможности сотрудничества компании для различных регионов или подразделений компании. Каждому CPP-профилю в ebXML-реестре присваивается свой уникальный глобальный идентификатор GUID. CPP-профиль — это

XML-документ, структура которого определяется следующими элементами:

CollaborationProtocolProfile — корневой элемент CPP-профиля. Элемент имеет атрибуты, определяющие пространства имен для элементов документа (xmlns:tp="http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpaxsd"), для XML Digital Signature (xmlns:ds="http://www.w3.org/ 2000/09/xmldsig#") и для XLink (xmlns:xlink="http://www.w3.org/1999/ xlink"), а также атрибуты cppid (идентификатор документа) и version (версия XML-схемы документа);

PartyInfo — информация о компании в целом или о подразделениях компании. В последнем случае присутствует несколько элементов PartyInfo.

Элемент имеет атрибуты partyName (имя организации или подразделения), defaultMshChannelId (указывает элемент DeliveryChannel, используемый по умолчанию для асинхронной доставки сообщений, переопределяется элеменАрхитектура XML Web-сервисов 65 том OverrideMshActionBinding) и defaultMshPackageId (указывает элемент Packaging, используемый по умолчанию для отправки сообщений). Элемент

PartyInfo содержит следующие дочерние элементы:

PartyId — идентификатор;

PartyRef — с помощью атрибута xlink:href указывает URI-ссылку на ресурс, содержащий дополнительную информацию о компании или подразделении;

CollaborationRole — роль, которую компания или подразделение выполняет в контексте Business Process Specification, например покупатель или продавец. Элемент CollaborationRole содержит вложенные элементы: ProcessSpecification (ссылка на документ Business Process Specification, определяющий взаимодействие с бизнес-партнерами, т. е.

бизнес-процессы), Role (указывает, какая роль в документе Business Process Specification поддерживается), ApplicationCertificateRef (указывает сертификат, используемый на уровне приложения), ApplicationSecurityDetailsRef (указывает политику безопасности, используемую на уровне приложения) и ServiceBinding (указывает элемент DeliveryChannel, используемый для обмена сообщениями). Элемент ServiceBinding содержит вложенные элементы Service (указывает Web-сервис, оперирующий сообщениями), CanSend (описывает детали исходящих сообщений), CanReceive (описывает детали входящих сообщений);

Certificate — сертификат, используемый в целях безопасности;

SecurityDetails описывает политику безопасности и доверенные сертификаты с помощью вложенных элементов TrustAnchors и SecurityPolicy;

DeliveryChannel описывает детали обмена сообщениями, включая протоколы с помощью вложенного элемента MessagingCharacteristics и ссылок на элементы Transport и DocExchange;

Transport описывает детали транспортного протокола обмена сообщениями с помощью вложенных элементов TransportSender и TransportReceiver;

DocExchange описывает детали обмена сообщениями, такие как электронная подпись и шифрование, используя вложенные элементы ebXMLSenderBinding и ebXMLReceiverBinding;

OverrideMshActionBinding определяет элемент DeliveryChannel, используемый для асинхронной доставки сообщений;

SimplePart — компоненты, используемые для создания составных сообщений; имеет атрибуты id (идентификатор компонента) и mimetype (тип содержимого части сообщения);

описывает упаковку сообщений перед отправкой с помощью Packaging вложенных элементов ProcessingCapabilities и CompositeList;

Глава 1 Signature содержит электронные подписи CPP-профиля;

Comment — комментарии.

XML-документы Business Process Specification, на которые ссылается CPPпрофиль, описывают взаимоотношения с бизнес-партнерами, роли и ответственность компании, хореографию бизнес-документов компании. Документы Business Process Specification также хранятся в ebXML-реестре.

3. Компания В находит с помощью своей локальной ebXML-системы в ebXMLреестре CPP-профиль компании А. Если компания В, после анализа CPPпрофиля компании А, заинтересуется участием в бизнес-процессах компании А, тогда из двух CPP-профилей компаний В и А генерируется документ Collaboration Protocol Agreement (CPA), который затем посылается компании А для утверждения. После утверждения CPA-документа компания А пересылает его обратно компании В, и CPA-документ используется для конфигурирования обеих локальных ebXML-систем, что делает возможным обмен сообщениями между двумя компаниями. Далее две компании обмениваются бизнесдокументами и следуют бизнес-процессам в соответствии с CPA-документом.

CPA-документ также является XML-документом и имеет следующую структуру:

CollaborationProtocolAgreement — корневой элемент документа, имеет атрибуты cpaid (идентификатор документа) и version (версия XML-схемы);

Status — текущий статус документа (proposed, agreed и signed);

Start — дата и время начала создания документа;

End — дата и время окончания создания документа;

— ограничение количества взаимодействий межConversationConstraints ду двумя компаниями с помощью атрибутов invocationLimit и concurrentConversations;

структура элемента схожа со структурой элемента PartyInfo PartyInfo, CPP-профиля за исключением того, что должны быть как минимум два элемента для каждой из компаний, участвующих в соглашении;

структура элемента схожа со структурой аналогичного элеменSimplePart, та CPP-профиля;

структура элемента схожа со структурой аналогичного элемента Packaging, CPP-профиля;

Signature — цифровые подписи одной или обеих компаний;

структура элемента схожа со структурой аналогичного элемента Comment, CPP-профиля.

Таким образом, ebXML-реестр может служить хранилищем для CPP-документов, характеризующих компании и их возможности, документов Business Process Specification, описывающих бизнес-процессы, в которых компании могут участвовать, CPA-соглашений и других сопутствующих документов.

Архитектура XML Web-сервисов 67 Локальные ebXML-системы компаний обмениваются между собой ebXMLсообщениями по протоколу ebXML Message Service Protocol с помощью Webсервисов сообщений Messaging Service, детали которых описаны в документах CPP, CPA и Business Process Specification. В свою очередь ebXML-реестр имеет интерфейс, реализованный набором Web-сервисов, обеспечивающих взаимодействие с ebXML-реестром путем обмена ebXML-сообщениями между ebXML-реестром и локальными ebXML-системами компаний. Взаимодействие между ebXMLреестром и локальной ebXML-системой также может определяться отдельным CPA-соглашением.

Интерфейс ebXML-реестра состоит из двух частей:

Life Cycle Management отвечает за управление объектами в ebXML-реестре;

Query Management обеспечивает поиск информации в ebXML-реестре.

Web-сервисы ebXML-реестра могут поддерживать обмен сообщениями с клиентом как по SOAP-протоколу, так и по ebXML-протоколу. В случае обмена по SOAPпротоколу клиент ebXML-реестра должен получить WSDL-описание Web-сервисов реестра для того, чтобы начать с ним взаимодействие. В случае же обмена по ebXML-протоколу клиент должен заключить CPA-соглашение с ebXMLреестром.

При обмене сообщениями между двумя компаниями происходит обмен бизнесдокументами. При этом бизнес-документы могут использовать компоненты библиотек Core Library и Business Library, которые локальные ebXML-системы компаний могут загрузить из ebXML-реестра. Библиотеки Core Library и Business Library содержат общую бизнес-информацию и описания общих бизнес-процессов для данного ebXML-реестра.

ebXML-описания Web-сервисов гораздо шире, чем WSDL- и UDDI-описания, т. к.

включают в себя более детальную характеристику компаний и определения бизнеспроцессов, а формат ebXML-сообщений является расширением SOAP-формата.

Спецификация ebXML Message Specification определяет ряд элементов расширения для блоков заголовков и тела SOAP-конверта, относящихся к маршрутизации, деталям обмена, безопасности, надежности и т. д.

Познакомиться с конкретными реализациями технологии ebXML можно на официальном сайте проекта (http://www.ebxml.org/tools).

DISCO DISCO — это технология компании Microsoft, предназначенная для публикации и поиска Web-сервисов.

Технология DISCO определяет формат документа, описывающий функциональность и способ взаимодействия с Web-сервисом. Такой DISCO-документ размещается в определенном каталоге сервера, предоставляющего данный Web-сервис.

Технология DISCO поддерживается платформой Microsoft.NET, соответственно используемый сервер — это IIS (Internet Information Services).

Глава 1

DISCO-документ имеет следующую структуру:

disco:discovery — корневой элемент, имеет обязательный атрибут xmlns:

указывающий пространство имен disco="http://schemas.xmlsoap.org/disco/", документа;

contractRef — ссылка на WSDL-описание Web-сервиса с помощью атрибута атрибут элемента docRef ссылается на дополнительную документацию ref, Web-сервиса. Элемент contractRef принадлежит к пространству имен xmlns="http://schemas.xmlsoap.org/disco/scl/";

discoveryRef и schemaRef указывают ссылки на другие DISCO-документы и XML-схемы, используя атрибуты ref. Элемент schemaRef принадлежит к пространству имен xmlns="http://schemas.xmlsoap.org/disco/schema/".

Поиск DISCO-документов осуществляется с помощью утилиты командной строки disco.exe, которая генерирует файл results.discomap, содержащий информацию о результатах поиска, и загружает все найденные файлы. Утилита disco.exe принимает в качестве аргумента URL-адрес DISCO-документа. Далее утилита командной строки wsdl.exe генерирует клиентские заглушки Web-сервиса, используя сгенерированный файл results.discomap.

DISCO-документ также может иметь следующий вид:

dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17" /dynamicDiscovery В этом случае при запросе к данному DISCO-документу утилитой disco.exe происходит автоматическая генерация DISCO-документа, описывающего Web-сервисы, развернутые в каталоге vroot IIS-сервера. При этом с помощью элемента exclude первоначального DISCO-документа (атрибут path) можно исключить подкаталог vroot из поиска. Такой поиск называется динамическим DISCO-поиском.

JAXR Библиотека Java API for XML Registries (JAXR) обеспечивает стандартный механизм для доступа к различным XML-реестрам, таким как ebXML или UDDI.

Клиентские приложения, использующие JAXR, могут быть Web-браузерами XMLреестров, компонентами Java EE или настольными приложениями. При этом реализация библиотеки JAXR должна обеспечивать доступ к Web-сервисам интерфейса конкретного XML-реестра.

Библиотека JAXR API состоит из двух пакетов:

javax.xml.registry.infomodel (табл. 1.1) содержит интерфейсы, описывающие информационную модель JAXR, которая определяет типы объектов и отношения между объектами, хранящимися в XML-реестре;

javax.xml.registry (табл. 1.2—1.4) содержит интерфейсы и классы, обеспечивающие доступ к XML-реестрам.

Архитектура XML Web-сервисов 69

–  –  –

Языки WS-BPEL и WS-CDL Основой корпоративной деятельности является бизнес-процесс. Бизнес-процесс — это последовательность действий, приводящая к заданному бизнес-результату.

Компания может состоять из множества подразделений, которые вовлекаются в ее различные бизнес-процессы. Кроме того, компания может участвовать в бизнеспроцессах с другими компаниями.

Для автоматизации учета и управления корпоративной деятельностью могут создаваться и внедряться распределенные SOA-системы, состоящие из Web-сервисов.

Такие SOA-системы также могут автоматизировать деятельность как внутри отдельной компании, так и взаимодействуя между несколькими компаниями.

Работа корпоративной SOA-системы тоже основывается на выполнении бизнеспроцессов, состоящих из взаимодействий входящих в SOA-систему Web-сервисов.

Соответственно для проектирования корпоративной SOA-системы необходима формализация бизнес-процессов и описание их связи с Web-сервисами. Поэтому для моделирования бизнес-процессов в контексте технологии Web-сервисов были разработаны языки WS-BPEL (Web Services Business Process Execution Language) и WS-CDL (Web Services Choreography Description Language).

Язык WS-BPEL описывает оркестровку Web-сервисов, а язык WS-CDL — их хореографию. В чем же различие между оркестровкой и хореографией?

Оркестровка Web-сервисов — это описание локального бизнес-процесса компании в виде набора взаимодействий внутренних и внешних для данной компании Webсервисов. При оркестровке контроль над бизнес-процессом осуществляется данной компанией с помощью центрального координатора, который также может быть представлен Web-сервисом. Центральный координатор управляет взаимодействием Web-сервисов, вовлеченных в бизнес-процесс, и определяет порядок выполнения ими заданных действий.

Хореография Web-сервисов — это описание глобального бизнес-процесса или, иначе, публичного протокола, с помощью которого несколько участников, которые могут быть и различными компаниями, обмениваются сообщениями с целью достижения общего бизнес-результата. При таком подходе не требуется центральный координатор, т. к. в данном случае каждый Web-сервис сам владеет информацией о том, когда выполнять свои операции и с каким другим Web-сервисом ему необходимо взаимодействовать.

Таким образом, оркестровка и хореография — это два разных подхода в описании бизнес-процессов и интеграции Web-сервисов. Оркестровка — описание бизнеспроцесса с точки зрения центрального координатора, а хореография — описание бизнес-процесса как совместного действия различных участников, каждый из которых знает в нем свою роль. Можно сказать, что хореография Web-сервисов способна реализоваться набором оркестровок Web-сервисов.

–  –  –

являющегося контейнером для декларации взаимоотношений между участниками процесса, обработки данных и выполняемых действий.

Спецификация WS-BPEL 2.0 поддерживает такие спецификации, как XML Schema 1.0, XPath 1.0, SOAP 1.1, WSDL 1.1, UDDI 2.0 и WS-Addressing.

XML-документ BPEL-процесса, как правило, создается с помощью BPELвизуального редактора и затем исполняется BPEL-сервером управления бизнеспроцессами. Таким образом, BPEL-процесс объединяет Web-сервисы и выступает как центральный координатор — к BPEL-серверу, исполняющему BPEL-процесс, поступают клиентские запросы, инициирующие запуск BPEL-процесса, и от BPELсервера исходят ответы клиенту. BPEL-процесс устанавливает порядок, в котором должны быть вызваны, последовательно или параллельно, объединенные BPELпроцессом Web-сервисы. При этом набор Web-сервисов, вовлеченных в конкретный процесс, может меняться в зависимости от того, какой клиент вызывает BPELпроцесс. Реализуется же BPEL-процесс в виде Web-сервиса, фактически являющегося составным из объединяемых Web-сервисов, т. е. такой новый составной Web-сервис и разворачивается в BPEL-сервере. Поэтому BPEL-проект состоит из BPEL-описания (*.bpel), WSDL-описания составного BPEL Web-сервиса (*.wsdl) и XML-схем, описывающих структуры данных проекта (*.xsd).

Технология BPEL поддерживается различными серверами приложений и средами разработок, в том числе Oracle BPEL Process Manager, Oracle Application Server, NetBeans, GlassFish, Eclipse, JBoss, WebLogic, WebSphere и др.

BPEL-описание может быть двух типов — абстрактное и исполняемое.

Абстрактное BPEL-описание дает общее описание бизнес-процесса, скрывая его конкретные детали исполнения и тем самым давая возможность по-разному реализовывать BPEL-процесс. Абстрактное BPEL-описание определяет, что должен BPEL-процесс делать, но не описывает, как он должен это делать. Абстрактное BPEL-описание может использоваться в качестве формальной документации или как шаблон для реализации в виде исполняемого BPEL-описания.

Исполняемое BPEL-описание полностью определяет и детализирует выполнение бизнес-процесса и поэтому сразу может выполняться конкретным BPEL-сервером.

Исполняемое BPEL-описание

Корневым элементом BPEL-документа является элемент process (рис. 1.9), который имеет следующие атрибуты:

обязательный атрибут name — имя документа;

обязательный атрибут targetNamespace — целевое пространство имен BPELописания;

необязательный атрибут queryLanguage — используемый язык запросов, по умолчанию значение атрибута urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0 представляет использование языка XPath 1.0 для создания запросов;

необязательный атрибут expressionLanguage — используемый язык выражений, по умолчанию значение атрибута urn:oasis:names:tc:wsbpel:2.0:sublang:

xpath1.0 представляет использование языка выражений XPath 1.

0;

Архитектура XML Web-сервисов 73

Рис. 1.9. Общая схема элемента process исполняемого BPEL-документа

необязательный атрибут suppressJoinFailure определяет обработку ошибок условий, определенных в элементе joinCondition. Если значение атрибута no (по умолчанию), тогда исключение перехватывается соответствующим обработчиком ошибок, определенным элементом faultHandlers. Если значение атрибута yes, тогда действие, связанное с ошибочным условием, пропускается и производится проверка других условий, если они присутствуют;

необязательный атрибут exitOnStandardFault. Если значение атрибута yes, тогда BPEL-процесс завершается при возникновении стандартной BPEL-ошибки (за исключением joinFailure). В противном случае (по умолчанию) стандартная BPEL-ошибка обрабатывается соответствующим обработчиком ошибок;

обязательный атрибут xmlns определяет, является ли BPEL-документ абстрактным или исполняемым. Для абстрактного BPEL-документа пространство имен — http://docs.oasis-open.org/wsbpel/2.0/process/abstract, для исполняемого — http://docs.oasis-open.org/wsbpel/2.0/process/executable.

BPEL-описание может расширяться с помощью элементов extensions, которые могут содержать новые атрибуты и элементы, расширяющие BPEL-спецификацию.

В качестве обязательных элемент extensions содержит атрибуты namespace (пространство имен расширений) и mustUnderstand (yes или no; указывает, обязательна ли для BPEL-процессора обработка расширений).

С помощью элемента scope можно разделить BPEL-процесс на части, каждая из которых будет реализовывать свою бизнес-логику. Элемент scope имеет обязательный атрибут name и определяет, что все его дочерние элементы имеют область видимости только в пределах данного элемента scope.

Элемент import позволяет объявить зависимость BPEL-описания от внешних

XML-схем или WSDL-описаний. Элемент import имеет следующие атрибуты:

необязательный атрибут namespace — пространство имен импортируемого документа;

Глава 1 необязательный атрибут location — URI-адрес импортируемого документа;

обязательный атрибут importType — URI-идентификатор кодировки импортируемого документа (http://www.w3.org/2001/XMLSchema — для документов XML Schema 1.0 и http://schemas.xmlsoap.org/wsdl/ — для документов WSDL 1.1).

Элемент partnerLinks описывает связи BPEL-процесса с партнерами, которые могут быть Web-сервисами, вызываемыми BPEL-процессом, Web-сервисами, вызывающими BPEL-процесс и Web-сервисами, вызываемыми и вызывающими BPEL-процесс. Каждый BPEL-процесс имеет, по крайней мере, одну связь с вызывающим его клиентом и как минимум одну связь с вызываемым им Web-сервисом, исполняющим функцию, требуемую клиентом.

Элемент partnerLinks является контейнером для элементов partnerLink, описывающих конкретные связи с партнерами. Элемент partnerLink имеет следующие атрибуты:

обязательный атрибут name — имя связи;

обязательный атрибут partnerLinkType — ссылка на QName-имя элемента BPEL-процесса;

partnerLinkType WSDL-описания необязательный атрибут myRole — роль BPEL-процесса в связи;

необязательный атрибут partnerRole — роль партнера в связи;

ПРИМЕЧАНИЕ Существует два типа связей BPEL-процесса с партнерами. Первый тип связи описывает асинхронное взаимодействие BPEL-процесса с партнером. В этом случае необходимо определить две роли. Например, BPEL-процесс асинхронно вызывает Web-сервис, тогда partnerRole указывает, что партнер предоставляет свой Web-сервис для BPEL-процесса, а myRole указывает, что производится обратный вызов BPEL-процесса для возврата ответа. Или клиент асинхронно вызывает BPEL-процесс, тогда myRole указывает, что BPELпроцесс предоставляет сервис клиенту, а partnerRole указывает, что производится обратный вызов клиента для возврата ответа. Второй тип связи описывает синхронное взаимодействие BPEL-процесса с партнером. В этом случае нужно определить только одну роль.

Например, BPEL-процесс синхронно вызывает Web-сервис, тогда partnerRole указывает, что партнер предоставляет свой Web-сервис для BPEL-процесса. Или клиент синхронно вызывает BPEL-процесс, тогда myRole указывает, что BPEL-процесс предоставляет сервис клиенту.

необязательный атрибут initializePartnerRole указывает необходимость инициализации связей при развертывании BPEL-процесса (возможные значения атрибута — yes или no). Если процесс сам инициализирует свои связи, например при использовании действия assign, тогда значение атрибута устанавливается no; если же связи необходимо инициализировать заранее при развертывании, тогда значение атрибута устанавливается равным yes.

Каждая связь характеризуется взаимоотношениями между двумя Web-сервисами с указанием ролей, выполняемых Web-сервисами, и определением интерфейсов portType, обеспеченных Web-сервисами для обмена сообщениями. Каждая роль связывается с portType с помощью элемента partnerLinkType, определенного в WSDL-описании BPEL-процесса, на который ссылается обязательный атрибут partnerLinkType элемента partnerLinks.

Архитектура XML Web-сервисов 75

Элемент partnerLinkType включается в WSDL-описание BPEL-процесса как элемент расширения WSDL-спецификации с пространством имен http://docs.oasisopen.org/wsbpel/2.0/plnktype. Элемент partnerLinkType имеет следующий синтаксис:

wsdl:definitions name="NCName" targetNamespace="anyURI"...

...

plnk:partnerLinkType name="NCName" plnk:role name="NCName" portType="QName"/ plnk:role name="NCName" portType="QName"/?

/plnk:partnerLinkType...

/wsdl:definitions Соответственно синхронным или асинхронным взаимодействиям в элементе partnerLinkType могут быть определены одна или две роли.

Таким образом, элемент partnerLinks определяет взаимоотношения с партнерами, обеспечивая при этом связь с Web-сервисами. Однако связь с Web-сервисом партнера может быть установлена и динамически, например, действием assign с использованием элемента sref:service-ref (пространство имен http:// docs.oasis-open.org/wsbpel/2.0/serviceref).

Элемент sref:service-ref содержит информацию о конкретной реализации интерфейса Web-сервиса партнера и используется для динамической связи с ним.

Элемент sref:service-ref имеет атрибут reference-scheme (XML-схема конечной точки Web-сервиса) и дочерние элементы, которые могут быть элементами WS-Addressing, описывающие реализацию Web-сервиса.

Элемент messageExchanges BPEL-описания определяет сообщения, участвующие в обмене BPEL-процесса с партнерами. Элемент messageExchanges служит контейнером для элементов messageExchange, имеющих обязательный атрибут name — имя сообщения.

Элемент variables представляет BPEL-переменные, предназначенные для хранения BPEL-данных. BPEL-данные могут двух типов — данные, содержащиеся в сообщениях, и данные самого BPEL-процесса. Поэтому состояние всего BPELпроцесса сохраняется с помощью BPEL-переменных.

Элемент variables имеет обязательный атрибут name — имя переменной. Существуют три типа BPEL-переменных — переменные WSDL-сообщений, переменные простых типов или имеющие тип, описанный XML-схемой, и переменные, определенные элементами XML-схемы. Соответственно тип BPEL-переменной указывается атрибутами messageType, type и element элемента variables. BPELпеременные, объявленные как дочерние элементы variables элемента process, называются глобальными, а BPEL-переменные, объявленные как дочерние элементы variables элемента scope, называются локальными.

BPEL-переменные могут иметь свойства. Свойства BPEL-переменных определяются в WSDL-описании BPEL-процесса с помощью элемента расширения Глава 1 (пространство имен http://docs.oasis-open.org/wsbpel/2.0/varprop).

vprop:property

Синтаксис элемента vprop:property следующий:

wsdl:definitions name="NCName" vprop:property name="NCName" type="QName"? element="QName"? /...

/wsdl:definitions BPEL-свойство характеризуется именем и типом данных.

Для указания соответствия BPEL-свойства определенному полю сообщения или значению BPEL-переменной существует элемент WSDL-расширения vprop:

propertyAlias. Синтаксис элемента vprop:propertyAlias таков:

wsdl:definitions name="NCName"...

vprop:propertyAlias propertyName="QName" messageType="QName"?

part="NCName"? type="QName"? element="QName"?

vprop:query queryLanguage="anyURI"??

queryContent /vprop:query /vprop:propertyAlias...

/wsdl:definitions Для указания соответствия BPEL-свойства полю сообщения используются атрибуты messageType и part (соответствие части сообщения), а для указания соответствия BPEL-свойства значению BPEL-переменной — атрибуты type или element. Вложенный элемент query устанавливает соответствие значения BPEL-свойства значению определенного поля сообщения или значению определенной BPELпеременной.

Предназначением BPEL-процесса является интеграция Web-сервисов в одном бизнес-процессе с определением порядка их вызова. Поэтому в качестве главных элементов BPEL-описание содержит объявления действий (рис. 1.10), определяющих поведение BPEL-процесса. BPEL-действия могут быть двух типов — структурные действия (табл. 1.5), содержащие другие действия и определяющие связи между ними, и базовые действия (табл. 1.6) для выполнения простых операций BPELпроцесса.

–  –  –

Элементы toParts и fromParts служат контейнерами для соответствующих элементов toPart и fromPart. Элемент toPart отвечает за копирование данных из BPEL-переменной (обязательный атрибут fromVariable — имя переменной) в часть исходящего сообщения (обязательный атрибут part — имя части сообщения). Элемент fromPart отвечает за копирование данных из части сообщения (обязательный атрибут part — имя части сообщения) в BPEL-переменную (обязательный атрибут toVariable — имя переменной).

При взаимодействии BPEL-сервера с клиентами и Web-сервисами партнеров может быть создано несколько одновременно работающих экземпляров BPEL-процесса.

Поэтому возникает необходимость доставки сообщений нужному экземпляру BPEL-процесса. Элемент correlationSets позволяет объединять взаимодействия с партнерами в диалоги. Элемент correlationSets может быть дочерним элементом как элемента process, так и элемента scope. Элемент correlationSets имеет обязательные атрибуты name (имя корреляции) и properties (набор свойств BPEL-переменных сообщений, которые идентифицируют диалог). Свойства корреляции, содержащиеся в сообщениях, должны иметь простые типы, и как раз они и обеспечивают объединение взаимодействий с партнерами в диалоги. Ссылка на корреляцию осуществляется в действиях invoke, receive и reply, связанных с обменом сообщениями, с помощью вложенного элемента correlations. Элемент correlations служит контейнером для элемента correlation, имеющего обязательный атрибут set (ссылка на имя элемента correlationSets) и дополнительные атрибуты initiate (yes — действие должно инициализировать корреляцию, join — действие должно инициализировать корреляцию, если она еще не инициализирована, и no — действие не инициализирует корреляцию) и pattern (request, или response, или request-response, указывает, к какому сообщению в обмене применяется корреляция).

При возникновении ошибок BPEL-процесса они могут быть перехвачены и обработаны обработчиком ошибок. Обработчик ошибок BPEL-процесса описывается элементом faultHandlers, который служит контейнером для обязательных элементов catch и дополнительного элемента catchAll.

Элемент catch содержит действия, обрабатывающие ошибку, и имеет дополнительные атрибуты faultName (имя обрабатываемой ошибки), faultVariable (имя переменной, содержащей информацию об ошибке) и faultMessageType (WSDL-тип данных ошибки) или faultElement (XML-тип данных ошибки). Элемент catchAll содержит действия, которые могут обрабатывать все остальные ошибки.

Обработчик ошибок может быть встроен в действие invoke с помощью элементов catch и catchAll. Существуют стандартные ошибки BPEL-процесса, которые описаны в табл. 1.7.

–  –  –

При возникновении каких-либо ошибок BPEL-процесса может возникнуть необходимость отменить уже выполненные действия. Для совершения альтернативных действий служит компенсационный обработчик. Компенсационный обработчик описывается элементом compensationHandler, содержащим альтернативные действия. Элемент compensationHandler может объявляться в элементе scope или быть прямо встроенным в действие invoke и вызываться действиями compensateScope или compensate, которые используются в элементах catch, catchAll, compensationHandler и terminationHandler.

В случае возникновения ошибки BPEL-процесса необходимо корректным образом завершить работающие действия перед запуском обработчика ошибок. Для этого Глава 1 существует обработчик завершения, который описывается элементом содержащим завершающие действия. Обработчик завершеterminationHandler, ния может быть объявлен по умолчанию, как и компенсационный обработчик и обработчик ошибок, а может быть добавлен в отдельный элемент scope.

BPEL-процесс также может иметь набор обработчиков событий, вызываемых в случае возникновения соответствующего события. Обрабатываемые события могут быть двух типов: входящие WSDL-сообщения или временные сигналы. Обработчик событий описывается элементом eventHandlers.

Элемент eventHandlers служит контейнером для элементов onEvent и onAlarm.

Элемент onEvent аналогичен действию receive, дополнительно включая элемент scope с обрабатывающими действиями. Элемент onAlarm может содержать элементы for, until и repeatEvery, определяющие временные интервалы, и содержит элемент scope с обрабатывающими действиями.

Как уже было сказано, целью применения элемента scope является разделение

BPEL-процесса на части, каждая из которых реализует свою бизнес-логику. Элемент scope сам является действием и обеспечивает контекст для своих вложенных действий путем определения переменных, партнерских связей, обмена сообщений, корреляций и различного рода обработчиков. Элемент scope имеет следующие дополнительные атрибуты:

name — идентификатор элемента;

suppressJoinFailure определяет обработку ошибок условий, определенных в элементе joinCondition;

isolated. Если значение атрибута yes, тогда действие scope обеспечивает контроль над доступом к совместно используемым с другими действиями scope ресурсами — переменным, партнерским связям и т. д., т. е. изоляция гарантирует завершение всех операций изолированного элемента scope, изменяющих ресурсы, перед доступом к ним другого элемента scope. По умолчанию значение атрибута — no;

exitOnStandardFault. Если значение атрибута yes, тогда BPEL-процесс завершается при возникновении стандартной BPEL-ошибки (за исключением Если значение атрибута no (по умолчанию) — стандартная BPELjoinFailure).

ошибка обрабатывается соответствующим обработчиком ошибок.

Язык BPEL обеспечивает несколько стандартных функций для работы с данными.

Это BPEL-функции bpel:getVariableProperty и bpel:doXslTransform.

Функция object bpel:getVariableProperty(string, string) извлекает свойства из BPEL-переменных. Первый аргумент функции — имя переменной, второй аргумент — имя свойства.

Функция object bpel:doXslTransform(string, node-set, (string, object)*) используется в действии assign для XSLT-преобразования содержимого BPELпеременной из одного XML-типа в другой XML-тип. Первый аргумент функции — URI-адрес таблицы XSLT-стилей преобразования одного XML-документа в другой Архитектура XML Web-сервисов 85 XML-документ, второй аргумент — BPEL-переменная, содержимое которой трансформируется, представленная XPath-узлом элемента, и дополнительные параметры функции являются XSLT-параметрами "имя — значение".

Для работы с данными язык BPEL использует запросы и выражения, языки которых определяются атрибутами queryLanguage и expressionLanguage. По умолчанию для запросов и выражений используется язык XPath 1.0 (значение атрибутов queryLanguage и expressionLanguage — urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0).

Кроме того, т. к. язык XPath 1.0 не обеспечивает трансформацию XML-документов, язык BPEL поддерживает спецификацию XSLT 1.0 (функция bpel:doXslTransform).

Спецификация XSLT 1.0 рассмотрена в приложении "Язык XSLT" справки "Приложения" и PDF-файле в каталоге Приложения компакт-диска.

Абстрактное BPEL-описание Абстрактное BPEL-описание регламентирует BPEL-процесс частично, опуская конкретные детали его выполнения или заменяя их специальной конструкцией opaque.

Абстрактное BPEL-описание может использоваться для описания BPEL-процесса с разных точек зрения, как первоначальный этап в разработке BPEL-процесса, для определения самой возможности взаимодействия между бизнес-партнерами и т. д.

Поэтому каждое абстрактное BPEL-описание должно указывать свой профиль использования, определяющий предназначение абстрактного BPEL-описания.

Синтаксически абстрактное BPEL-описание отличается от исполняемого BPELописания:

значением http://docs.oasis-open.org/wsbpel/2.0/process/

Abstract

атрибута xmlns элемента process, указывающим пространство имен BPEL-документа;

дополнительным атрибутом abstractProcessProfile элемента process, указывающим URI-идентификатор профиля использования абстрактного BPELописания;

наличием конструкций opaque в описании BPEL-процесса.

Конструкция opaque может скрывать конкретные детали BPEL-процесса, замещая следующие элементы BPEL-описания:

выражения — выражения, содержащиеся в элементах transitionCondition, joinCondition, condition, until, for, repeatEvery, startCounterValue, finalCounterValue, branches, from, to заменяются атрибутом соответствующего элемента opaque="yes";

действия — элемент действия замещается элементом opaqueActivity;

значения атрибутов заменяются ##opaque;

элемент from заменяется opaqueFrom/.




Похожие работы:

«Матеріали науково-методичного семінару УДК 005:8 Кошель Н.В., инженер, ГП “НАЭК “Энергоатом”, Завальнюк С.А., инженер, ГП “НАЭК “Энергоатом”, Гогунський В.Д., д-р техн. наук, проф.,, кафедра "Управліня системами безпеки життєдіяльності", Одеськ...»

«Лекция 3. Для рассмотрения знания и познания как объективаций необходимо изучить знаковую ситуацию со стороны ее онтологических характеристик. Сейчас я начну с краткого описания некоторых существенных особенностей объективации знания и познания. В...»

«Проект ЭКСПЕРТНОЕ ЗАКЛЮЧЕНИЕ Совета при Президенте Российской Федерации по кодификации и совершенствованию гражданского законодательства по проекту федерального закона "О внесении изменений в некоторые законодательные акты Российской Ф...»

«БЮЛЛЕТЕНЬ ОРГАНОВ МЕСТНОГО САМОУПРАВЛЕНИЯ ГОРОДА НОВОСИБИРСКА № 4 2 февраля 2017 г. город Новосибирск 19.01.2017 ЗАКЛЮЧЕНИЕ по результатам публичных слушаний по проекту постановления мэрии города Новосибирска "О проекте межевани...»

«Выполнить мой Долг перед Богом Для носителей Священства Ааронова Выполнить мой Долг перед Богом Для носителей Священства Ааронова Интерактивную версию этого пособия, а также другие материалы в Интернете м...»

«© 2000 г. В.В. ПЕТУХОВ ПОЛИТИЧЕСКИЕ ЦЕННОСТИ И ПОВЕДЕНИЕ СРЕДНЕГО КЛАССА ПЕТУХОВ Владимир Васильевич кандидат философских наук, директор Центра социально-политического анализа РНИСиНП. Отношение к актуаль...»

«Лариса Вергиз Цветы. Лучше, чем у всех. Секреты, хитрости, подсказки умного садовода. Лунный календарь: самый удобный и полезный Серия "Лучшие рецепты умного садовода" http://www.litres.ru/pages/biblio_book/?art=6649383 Лар...»

«Программа по управлению границами в Центральной Азии BOMCA ЧТО ТАКОЕ BOMCA?Общая цель BOMCA: Содействовать в том, чтобы в Центральной Азии поэтапно внедрялись современные методы управления границей. Современные методы управ...»

«Теория расписаний Е. В. Щепин Школа Яндекса по анализу данных Оглавление 1. Алгоритмы теории расписаний 2 2. NP-полные задачи 6 1. Алгоритмы теории расписаний Задачи одного процессора. Дана совокупность J из n-заданий, для которых известны времена их исполнения процессором, так что через |J| обозначаетс...»

«Приложение № 3. Образец сертификата ценных бумаг – облигаций серии 05 Образец Лицевая сторона Акционерный Коммерческий Банк "Московский Банк Реконструкции и Развития" (открытое акционерное общество) Место нахождения: 119034, г.Москва, Еропкинский пер., д.5 стр.1 Почтовый адрес: 119034...»

«Л.П. МОИСЕЕВА Мы жили тогда на планете другой. Тема России в поэзии русского зарубежья первой волны эмиграции Мы волна России, вышедшей из берегов. Владимир Набоков. Юбилей. Узнает ли когда-нибудь она, Моя невер...»

«Исполнительный директор Всероссийского Союза Страховщиков Н.И. Малышев "15" июня 2009 г. УТВЕРЖДЕНО Приказом Генерального директора Согласовано с Федеральной службой ЗАО "Страховая группа "УралСиб" страхового надзора от 15.06.2009 № 78 (письмо от 02.11.2005 № 44-11616/02-01) ПРАВИЛА СТРАХОВАНИЯ (СТАНДАРТНЫЕ) ГРАЖДАНСКОЙ ОТВЕТС...»

«0908633 EISENMANN Водоподготовка • Очистка сточных вод Это EISENMANN Новшества и стратегии по оптимизации производства, технологического процесса и внутрипроизводственной логистики являются нашим хлебом насущным. EISENMANN строит установки для технологи отделки поверхнос...»

«Іі.Г ГИ1 ГМЛРУІ?) і : л и ж /і? Р і'У І ь КІИ ІІТН4‘) іы.‘ин л л іили гэіиюи эоипкн кои п I1XIІІ I/ ІЛ амО Л \\\ ъщшт^и іиіііУ ’ ніа**^ Л" /\Х/\Х\Ххх/-— -чч ;Цна годовому изданію съ пере­ Выходятъ два раза въ мсяцъ...»

«Максим Горький Поль Верлен и декаденты "Public Domain" Горький М. А. Поль Верлен и декаденты / М. А. Горький — "Public Domain", 1896 "В декабре прошлого года в Париже умер Поль Верлен, поэтдекадент и основатель этой болезненно извращённой литератур...»








 
2017 www.book.lib-i.ru - «Бесплатная электронная библиотека - электронные ресурсы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.