АрхитектураCORBA. Статическая и динамическая CORBA. Компонентная модель CORBA. Основные сервисы CORBA

CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология.

Компонентная модель CORBA (CCM) — недавнее дополнение к семейству определений CORBA.

CCM была введена начиная с CORBA 3.0 и описывает стандартный каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise JavaBeans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы, порты.

Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.

Очереди сообщений. JMS

Java Message Service (JMS) — стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе J2EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов.

JMS поддерживает две модели обмена сообщениями: «от пункта к пункту» и «издатель-подписчик».

Модель «от пункта к пункту» характеризуется следующим:

Каждое сообщение имеет только одного адресата

Сообщение попадает в «почтовый ящик», или «очередь» адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт.

После получения сообщения адресат посылает извещение.

Модель «издатель-подписчик» характеризуется следующим:

Подписчик подписывается на определённую «тему»

Издатель публикует своё сообщение. Его получают все подписчики этой темы

Получатель должен работать и быть подписан в момент отправки сообщения

Веб сервисы. SOAP

Web-сервисы. В самом общем виде понятие Web-сервиса можно определить как сервис (услугу) которая предоставляется через WWW с использованием языка XML и протокола HTTP.

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

Свойства Web-сервисов. Все Web-сервисы обладают имеют следующими свойствами:

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

· являются самоописываемыми, поскольку метаданные, описывают сообщения передается вместе с сообщением и не требуется никаких внешних хранилищ метаданных;

· могут быть опубликованы, обнаружены и вызваны через Интернет причем для этого используют простые установившиеся стандарты, такие как HTTP и существующая сетевая инфраструктура;

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

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

· открыты и основаны на стандартах, технической основой Web-сервисов являются XML и HTTP, значительная часть технологии Web-сервисов создана с использованием проектов с открытым исходным кодом;

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

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

· являются действенным средством интеграции унаследованных приложений.

SOAP – это основанный на XML протокол, определяющий механизм обмена сообщениями. Протокол SOAP появился в 1998 году как W3C спецификация. В ранних версиях спецификации SOAP расшифровывался как Simple Object Access Protocol. В последних версиях этот термин не никак расшифровывается. На момент написания данной книги последней была версия 1.2 от апреля 2007 года (спецификация находится по адресу http://www.w3.org/TR/2007/).

Хотя SOAP имеет много общего с XML-RPC, но имеются и принципиальные отличия. Во-первых протокол SOAP не различает вызов процедуры и ответ на него, а просто определяет формат послания (message) в виде документа XML, который может содержать вызов процедуры, ответ на него, запрос на выполнение каких-то других действий или просто текст, а, во вторых, SOAP послание представляет собой самоописываемый документ, включающий, в частности, описания пространств имен. Структуру SOAP послания определяет соответствующая XML Schema. Для пересылки SOAP посланий обычно используется HTTP POST метод, хотя можно использовать и другие протоколы, такие как FTP, SMTP.

SOAP послание включает два элемента: заголовок (Header) и тело (Body), которые помещаются в контейнер (Envelope). SOAP послание представляет собой правильный XML документ. Заголовок является факультативным элементом, а тело – обязательным.

В качестве примера рассмотрим пример сервера, который находит синоним слова с посредством вызова метода getSynonym.

<?xml version="1.0" encoding="Windows-1251"?>

<SOAP-ENV:Envelope

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAPENV="

http://schemas.xmlsoa.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:SOAPENC="

http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

< getSynonym>

<word xsi:type="xsd:string">аэроплан</word>

< </getSynonym >

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

В теле запроса в элемент word, который имеет тип XSD string, помещается исходное слово. В ответ на запрос клиенту поступает ответное послание, которое имеет вид:

<?xml version="1.0" encoding=" Windows-1251"?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<getSynonymResponse

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/">

<getSynonymResult xsi:type=

"xsd:string">самолет</getSynonymResult>

</getSynonymResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Рассмотрим пример создания простейшей службы, которая может находить синоним.

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

Создание серверной части не вызывает проблем. Для работы с AXIS достаточно написать текст сервиса. Для этого создаем файл SynonymService.java:

// SynonymService.java

public class SynonymService {

public String getSynonym(String word) {

//Находим в словаре требуемый синоним

…………….

//Возвращаем синоним

return "" + synonym;

}

Данный файл необходимо переименовать в SynonymService.jws и не компилируя поместить в каталог webapps (при работе с AXIS). После этого сервис готов к использованию

Клиентская часть приложения сложнее. При работе с AXIS вначале создается объект класса service, который предназначен для установления связи с Web сервисом. Он предоставляет экземпляр класса call, который заносятся параметры запроса, в частности, адрес и имя Web-сервиса "getSynonym". После того как запрос сформирован, Axis обращается к Web-услуге посредством вызова метода invoke (). Запрос направляется серверу приложений, работающему по указанному в запросе адресу. На сервере запускается сервлет AxisServiet, который разбирает SOAP послание, находит требуемый .jws файл, компилирует и запускает с требуемыми параметрами. После выполнения требуемых действий сервлет формирует SOAP послание в которое помещается результат. Послание отправляется клиенту. Там оно разбирается. Для клиента результат доступен как результат выполнения метода invoke () [36].

Веб сервисы. WSDL

Свойства Web-сервисов. Все Web-сервисы обладают имеют следующими свойствами:

· являются действенным средством интеграции унаследованных приложений.

WSDL используется для описания интерфейсов Web services. Средствами WSDL можно описать, где находится Web-сервис и каким образом к нему следует обращаться. WSDL описание позволяет создавать независимое от платформы и языка реализации описание Web-сервиса. Нетрудно заметить, что WSDL имеет много общего с IDL, используемым в RPC. WSDL описание представляет собой XML документ, структура которого показана на рис. 5.2.

<types>	Что делается
<message>
<portType>
<binding>	Как делается
<service>	Где находится
<import>
<documentation>

</definitions>

Рис. 5.2. Структура XML документа

В качестве корневого элементы WSDL описания используется элемент <definitions>, в который вкладываются семь элементов, пят из которых являются основными, а два - вспомогательными.

В качестве основных выступают следующие элементы:

- <types>;

- <message>;

- <portType>;

- <binding>.

В качестве вспомогательных выступают элементы:

- <import>;

- <documentation>.

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

Элемент <types> присутствует, если требуется определить сложные типы с помощью языка XSD. В противном случае данный элемент отсутствует.

Элемент <message> описывает каждое из SOAP посланий в терминах «запрос-ответ». В этот элемент вкладываются элементы <part>. При использовании процедурного стиля в каждый такой элемент описывается имя и тип одного аргумента запроса или возвращаемого значения. При использовании документного стиля элементы <part> могут описывать отдельную часть послания MIME-типа "multipart/related".

Элемент <portType> описывает интерфейс Web-службы, который также называют пунктом назначения (endpoint) или портом (port), сервисов, называемых операциями.Отдельные операции описываются как вложенными элементы <operation>, которая описывает отдельный сервис. Имеется 4 вида сервисов. Два простых действия (получение послания и отправка ответа) и два комбинированных действия (отправка послания — получение ответа и получение послания — отправка ответа). Действия типа получение и отправка посланий описываются вложенными элементами <input> и <output>, а также сообщением об ошибке (элемент <fault>).

Элемент <serviceType> содержит множество вложенных элементов <portType>. Один и тот же порт может быть связан с несколькими сервисами.

Элемент <binding> описывает формат пересылки послания: протоколы и его тип. Каждый элемент <message> может быть связан с несколькими такими элементами<binding>, по одному для каждого способа пересылки.

Элемент <service> определяет место нахождения сервиса как один или несколько портов, каждый из которых описывается вложенным элементом <port>, содержащим адрес интерфейса Web-сервисы.

Кроме перечисленных выше основных элементов есть еще два вспомогательных элемента.

Элемент <import> включает файл с XSD схемой описания WSDL или другой WSDL-файл.

Элемент <documentation> представляет собой комментарий, который можно включить в любой элемент описания WSDL.

Принято говорить, что элементы <types>, <message> и <portType> определяют какие именно услуги предоставляет данный сервис.

Элементы <binding> определяет как реализована Web-служба, т.е. как к ней обращаться.

Элементы <service> определяет где располагается сервис.

Ниже в качестве примера приведен фрагмент WSDL описания.

<?xml version="1.0" encoding="UTF-8"?>

name="SynonymService"

targetNamespace="http://www.vocab.ru/Thesaurus.wsdl"

xmlns="http://www.w3.org/ns/wsdl"

. . . . . . . .

<wsdl:definitions . . .

<wsdl:message name="getSynonymResponse">

<wsdl:part name="synonym" type="SOAP-ENC:string"/>

</wsdl:message>

<wsdl:message name="getSynonymRequest">

<wsdl:part name="word" type="SOAP-ENC:string"/>

</wsdl:message>

<wsdl:portType name="Synonyms">

<wsdl:operation name="getSynonym" parameterOrder="word">

<wsdl:input message="intf: getSynonymRequest"/>

<wsdl:output message="intf:getSynonymResponse"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="getSynonymSoapBinding" type="intf:Thesaurus">

<wsdlsoap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="getSynonym">

<wsdlsoap:operation soapAction=""/>

<wsdl:input>

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:myDirectory" use="encoded"/>

</wsdl:input>

<wsdl:output>

<wsdlsoap:body

encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:myDirectory" use="encoded"/>

</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).

Можно выделить два альтернативных подхода к разработке Web сервисов: подход по принципу «сверху-вниз и подход «снизу-вверх».

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

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

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

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 реестр можно рассматривать как Зеленые страницы, где описаны способы доступа к сервисам.

Состав реестра 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.

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

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

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

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

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

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

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

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

описания ..

<accessPoint

URLType=”http”>http://www...</accessPoint>

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

Descriptions, ..

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

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

...

</bindingTemplates>

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

</categoryBag>

</businessService>

...

</businessServices>

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

</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].

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

СОА. 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.

BPEL

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

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

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

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

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

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

Координация потоков включает параллельные потоки выполнения, образцы соединений и динамические потоки. В реальных приложениях бизнес-потоки могут включать образцы сложных взаимодействий как с синхронными, так и с асинхронными сервисами. Координация потока включает интерфейс с 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.oasis-open.org/wsbpel/2.0/. В июне 2007 г. были опубликованы спецификации BPEL4People и WS-HumanTask, где описывались возможности реализации в BPEL взаимодействия с людьми. Последние версии этих документов можно найти по адресу http://docs.oasis-open.org/.

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

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

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

Идея оркестровки состоит в том, что в системе имеется единственный BPEL-процессор (движок), который выполняет функции интерпретатора BPEL-файлов. Для внешнего мира BPEL-процессор доступен как Веб-сервис. Получив запрос, движок уже от своего имени рассылает SOAP послания Веб-сервисам, участие которых необходимо для реализации бизнес-процесса. Задействованные веб-сервисы не знают, что они вовлечены в бизнес-процесс более высокого уровня. Только движок обладает полной информацией о выполняемой задаче, и поэтому оркестровка является централизованным механизмом с явным определением операций и порядком инициирования работы веб-сервисов (рис. 6.1).

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

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

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

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

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

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

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

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

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

Абстрактные бизнес-протоколы (Abstract business protocols) определяет обмен публичными сообщениями между участниками. Они не включают внутренние детали потока процессов, не являются выполнимыми и находятся в парадигме хореографии.

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

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

Описание процессов в BPEL.BPEL-процесс состоит из активностей (activities). Различают базовые (basic) и структурные (structured). Базовые активности не включают в себя другие активности и выполняют такие элементарные действия как прием сообщения от партнера или выполнения элементарных действий с данными. Структурированные активности включают в себя другие активности и обеспечивают реализацию бизнес логики.

Важнейшими базовыми активностями являются активности, ориентированные на получение и отправку сообщений. Это активности типа invoke, receive и reply, которые определяют два способа взаимодействии: асинхронное и синхронное взаимодействия.

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

Синхронное взаимодействие реализуется с помощью пары активностей. Сервис реализует активность типа receive – находится в состоянии ожидания запроса. Получив запрос, сервер формирует ответ, посредством реализации активности reply . До получения ответа вызывающая сторона находится в состоянии ожидания, т.е. находится в заблокированном состоянии.

Имеются и другие базовые активности, такие как активности, ориентированные на присвоение значений переменным (assign), остановка реализации сервиса (terminate), отсутствие действий (empty), также активность типа pick и Event Handler, ориентированные на поддержку работы с событиями.

В рамках BPEL определен достаточно широкий набор структурированных активностей, основными из которых являются следующие:

· задание последовательности выполнения действий (<sequence>);

· цикл (<while>);

· выбор одного из нескольких альтернативных маршрутов (<pick>);

· параллельное выполнение (<flow>);

· обработка ошибок <throw> и <catch>;

· объединение нескольких действий (<scope>);

· и др.

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

Структура BPEL-документа.В самом общем виде структура документа BPEL выглядит следующим образом:

<! -- Определение партнерских связей -->

</partnerLinks>

</variables>

</sequence>

</process>

Внутри контейнера, заключенного в теги <process> включает следующие вложенные элементы:

- партнерские связи <partnerLinks>;

- описания переменных <variables>;

- описание последовательности обращений к web-сервисам <sequence>.

<22 23 242526 27 28 >

Дата добавления: 2018-09-24; просмотров: 821;