Ответы на вопросы upd / Воп_ сети2012 не кратко upd

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="SynonymService">

<wsdl:port binding="intf: getSynonymSoapBinding" name="Thesaurus"> <wsdlsoap:address

location="http://localhost:8080/axis/services/Thesaurus"/>

</wsdl:port>

</wsdl:service>

<documentation> Thesaurus WSDL File</documentation> </wsdl:definitions>

Предполагается, что данное описание находится в файле Thesaurus.wsdl.

Имя сервиса SynonymService определено в элементе service.

Далее определяются используемые пространства имен (часть определений пропущена).

В элементах <wsdl:message> описаны используемые типы SOAP посланий.

Используется два типа сообщений, которые называются getSynonymRespons и getSynonymReques. Первое содержит поле synonym, а второе – поле word. Оба поля представляют собой строки символов.

Элемент <wsdl:portType> называется Synonyms и выполняет только одну операцию getSynonym, которая получает входную переменную word. Входное послание имеет имя getSynonymRequest, а выходное – getSynonymResponse.

Элемент <wsdl:binding"> называется getSynonymSoapBinding. В нем указывается, что сервис работает в режиме запрос-ответ (использует rpc –

стиль), использует в качестве транспорта протокол HTTP, работает с SOAP

посланиями и выполняет операцию getSynonym. Затем в терминах SOAP

повторяется описание операции getSynonym.

Вэлементе <wsdl:service>, который называется SynonymService,

указывается место нахождения сервиса.

Элемент <documentation> может содержать любые комментарии.

Поскольку в рассматриваемом примере не используются сложные типы, то элемент <types> отсутствует.

WSDL спецификация может быть получена автоматически из файла реализации Web services, например, из Java файла или из описания интерфейса.

Имеется много разных систем поддержки работы с Web services. Одной из наиболее популярных является Apache eXtensible Interaction System (AXIS).

131

Можно выделить два альтернативных подхода к разработке Web сервисов:

подход по принципу «сверху-вниз и подход «снизу-вверх».

В первом случае разработка начинается с разработки WSDL описание,

которое используется для генерации скелетона и стаба, затем к ним добавляется бизнес логика.

Во втором случае разработка начинается с создания кода, который используется для генерации WSDL описания.

Например, в рамках существующих инструментальных средств имеются утилиты для выполнения упомянутых выше преобразований [35, 36].

46. UDDI

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

Реестр UDDI (UDDI Business Registry) представляет собой распределенную базу данных и по принципу работы подобна системе DNS. Для пользователя Реестр UDDI доступен как Web сервис.

Спецификация UDDI была разработана в 2000 году фирмами IBM, Microsoft

и Ariba. На момент написания данной книге последняя версия 3.х

(http://uddi.org/pubs/uddi_v3.htm).

В начале 2000-х годов многие крупные компании организовали и содержали

открытые (public) UDDI-реестры, где каждый желающий мог зарегистрировать собственный сервис и найти нужный сервис.

UDDI представляет собой документ в формате XML. UDDI имеет 3-х

уровневую организацию.

На верхнем уровне UDDI реестр представляет собой справочник,

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

(телефон, факс, Web сайт и т.п.) и бизнес идентификатор.

На втором уровне UDDI реестр представляет собой Желтые страницы, в

которых бизнес информация классифицируется по типу бизнеса, производимым продуктам. На третьем уровне UDDI реестр можно рассматривать как Зеленые страницы, где описаны способы доступа к сервисам.

132

Состав реестра UDDI. Реестр UDDI содержит четыре основные элемента и дополнительные элементы.

Основные элементы:

-бизнес сущности;

-бизнес сервисы;

-модель привязки;

-техническая модель сервиса.

Дополнительные элементы:

-утверждения;

-информация;

-подписка.

Элемент бизнес сущность <businessEntity> содержит уникальный в пределах реестра ключ UUID (Unique Universal Identifier), название фирмы

(вложенный элемент <name>), описание сферы деятельности организации, типы предоставляемых сервисов, контактная информация, ссылки URL. Небольшой организации обычно соответствует одна бизнес сущность, а большой организации, имеющей большое количество подразделений может соответствовать несколько бизнес сущностей.

Элементы бизнес сервисы <businessServices> вкладываются в элемент

бизнес сущность и описывает каждый из предоставляемых сервисов. В состав описания входит ключ UUID сервиса (serviceKey), имя сервиса (вложенный элемент <name>), описание и (или) ссылки на более подробную информацию. (Предоставляемые сервисы – это не обязательно Web-сервисы.)

Элементы модели привязки элемент <bindingTempiates> вкладываются в элемент <businesService> и описывают конкретные способы работы с данным сервисом. Это могу быть либо прямые ссылки в форме URL, либо косвенными,

например, в форме WSDL описания. Каждый элемент типа <bindingTempiate>

имеет уникальный ключ UUID указателя содержит ссылку на соответствующий ему элемент <tModel>.

Элемент техническая модель сервиса <tModel> (technical Model)

представляет собой подробное формальное описание каждой услуги. Данный элемент используется программным обеспечением и обычно оформляется как отдельный документ XML.

133

Кроме перечисленных выше, в UUID реестре имеются дополнительные элементы.

Элемент утверждение <publisherAssertion> представляет собой описание отношений между фирмами. Примерами отношений могут служить "parentchild"), т.е. одна организация является подразделением другой. Утверждение типа "identity"означает, что речь идет об одной и той же организации.

Элемент информация <operationalInfo> содержит дату создания и последней модификации записи в реестре, идентификатор узла реестра,

идентификатор владельца информации.

Ниже приведено описание структуры UUID реестра.

<businessDetail>

<businessEntity businessKey=‖[Уникальный идентификатор]‖>

Имена, описания, контакты, . .

<businessServices>

<businessService serviceKey=‖[ Уникальный идентификатор]‖ businessKey=‖[Уникальный идентификатор]‖>

Имена, описания, ..

<bindingTemplates>

<bindingTemplate bindingKey=‖[ Уникальный идентификатор]‖ serviceKey=‖

[Уникальный идентификатор]‖>

описания ..

<accessPoint

URLType=‖http‖>http://www...</accessPoint> <tModelInstanceDetails> <tModelInstanceInfo>

<tModelKey>[ Уникальный идентификатор]</tModelKey>

Descriptions, ..

<instanceDetails>

Описания, URL, ..

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

...

</bindingTemplates> <categoryBag>...<tModelKey>[ Уникальный

идентификатор]</tModelKey>...

</categoryBag>

</businessService>

...

</businessServices> <identifierBag>...<tModelKey>[Уникальный

идентификатор]</tModelKey>...

134

</identifierBag> <categoryBag>...<tModelKey>[Уникальный

идентификатор]</tModelKey>...</categoryBag> </businessEntity>

...

</businessDetail>

Программный интерфейс UDDI. Для работы с реестром UDDI

пользователю предоставляется API.

Функции, входящие в состав UDDI API, модно разделить на четыре группы:

функции, позволяющие регистрировать и изменять описания сервисов в UDDI реестре, которые называют save_xxx функции;

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

функции для поиска сервисов, которые называют find_xxx

функции;

функции для удаления сервисов, которые называют delete_xxx

функции;

Под символами "ххх" имеется в виду тип объекта ("business", "service",

"binding", "tModel").

С точки зрения пользователя, UDDI реестр – это Web-сервис, для обращения к которому ему следует направить SOAP послание, поэтому пользовательский интерфейс можно определить и в терминах SOAP посланий,

которые можно направлять на вход реестра.

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

программистов часто используется пакет классов UDDI4J (UDDI for Java),

разработанный фирмой IBM, который доступен на сайте http://sourceforge.net/projects/uddi4j/. (На момент написания книги последней версией была версия 2.0.5 от 2006 года.)

В данном пакете все обращения к реестру UDDI идут через класс-посредник

UDDIProxy, который преобразует все обращения в функции UDDI API. Методы этого класса называются так же, как и функции UDDI API: save_business (), find_service () и т.п. Они возвращают объекты классов, которые представляют собой SOAP-структуры [32, 33].

135

47. Бизнес процессы

136

48. СОА. ITIL

ITIL (произносится как «айти́л», англ. IT Infrastructure Library —

библиотека инфраструктуры информационных технологий) — библиотека,

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

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

Третья редакция ITIL (ITIL v.3) была выпущена в мае 2007. В ней полностью переработаны и по-новому организованы разделы, чтобы поддержать новый подход «формата жизненного цикла услуг». ITIL v.3 содержит уже только пять книг и состоит из:

Стратегия услуг (англ. Service Strategy) Проектирование услуг (англ. Service Design) Преобразование услуг (англ. Service Transition) Эксплуатация услуг (англ. Service Operation)

Постоянное улучшение услуг (англ. Continual Service Improvement) Использованный в библиотеке процессный подход полностью

соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей «эффективности» (KPI), а также на ресурсах, затраченных на достижение этих целей.

ITIL представляет собой набор документов применяемых для практического внедрения подходов IT Service Management (ITSM).

Наиболее известными являются десять базовых процессов, обеспечивающих поддержку и предоставление ИТ сервисов, которые описаны в

IT Service Management (ITSM):

Процесс управления инцидентами Процесс управления проблемами Процесс управления конфигурациями Процесс управления изменениями Процесс управления релизами Процесс управления уровнем услуг

Процесс управления мощностями (ѐмкостью) Процесс управления доступностью Процесс управления непрерывностью Процесс управления финансами

Вструктуре процессов ITIL и ITSM важную роль играет служба поддержки пользователей — Service Desk.

137

49. BPEL

Веб-сервисы представляют собой интерфейсы для доступа к автономным,

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

XML документ, при этом не имеет значения каким именно образом формируются эти послания.

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

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

является XML документом.

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

написанное на языке BPEL, можно рассматривать как Веб-сервис, и к нему можно обращаться посредством посылки SOAP посланий.

BPEL является интерпретируемым языком и для его использования необходимо наличие процессора (движка).

Основу BPEL составляют три ключевые свойства: асинхронность,

координация потоков и управление исключительными ситуациями.

Асинхронность имеет дело с асинхронными взаимодействиями,

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

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

138

асинхронными сервисами. Координация потока включает интерфейс с WSDL,

действия потока, переменные XML и отвечает за координацию. BPEL

использует WSDL для обращения к сообщениям, вызванным операциям и типам портов. Действия с потоком используют общие переменные XML, так что компенсационные обработчики (compensation handlers) должны сохранять снимки данных, которые могут быть использованы обработчиком.

Компенсационные обработчики могут отменить шаги, которые были уже завершены.

Управление исключительными ситуациями. Управление исключительными ситуациями имеет дело с синхронными ошибками,

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

большие усилия сосредоточены на управлении исключительными ситуациями,

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

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

Краткая история возникновения BPEL и действующие спецификации.

BPEL был разработан на базе двух более ранних языков описания бизнес-

процессов WSFL и Xlang фирмы IBM и Microsoft соответственно. Первый стандарт BPEL (BPEL4WS) сразу в версиях 1.0 и 1.1 появился в 2003 г. На момент написания данной книги последней была версия WS-BPEL 2.0, которая появилась в апреле 2007 года и доступна на сайте http://docs.oasisopen.org/wsbpel/2.0/. В июне 2007 г. были опубликованы спецификации

BPEL4People и WS-HumanTask, где описывались возможности реализации в

BPEL взаимодействия с людьми. Последние версии этих документов можно найти по адресу http://docs.oasis-open.org/.

Оркестровка и хореография веб-сервисов. Принято выделять два основных подхода к объединению веб-сервисов в бизнес-процессы:

-оркестровка (Orchestration);

-хореография (Choreography).

Идея оркестровки состоит в том, что в системе имеется единственный

BPEL-процессор (движок), который выполняет функции интерпретатора BPEL-

файлов. Для внешнего мира BPEL-процессор доступен как Веб-сервис. Получив

139

запрос, движок уже от своего имени рассылает SOAP послания Веб-сервисам,

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

поэтому оркестровка является централизованным механизмом с явным определением операций и порядком инициирования работы веб-сервисов (рис.

6.1).

Рис. 6.1. Схема оркестровки

Использование хореографии (рис. 6.2), напротив, не предполагает использование центрального координатора.

Рис. 6.2. Схема хореографии

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

140