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

portType="prch:PurchaseEquipmentPT"

operation="BuyEquipment"

variable="EquipmentRequest" createInstance="yes" />

...

<receive> ожидает когда клиент вызовет операцию BuyEquipment и

сохраняет параметры запроса в переменной EquipmentRequest. Строка createInstance="yes" указывает на то, что треуется создать новый экземпляр бизнес процесса.

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

...

<!—Подготовка входного сообщения для менеджера --> <assign>

<copy>

<from variable="EquipmentRequest" part="EquipmentType"/> <to variable="PermissionRequest" part=" EquipmentType"/>

</copy>

</assign>

...

Теперь может быть вызван сервис ManagerService. Для этого используется

<invoke>. Применяется партнерская связь managerLT и вызывается операция

GetPermission и осуществляется обращение к порту типу

EquipmentPerchasePermissionPT. Поскольку это синхронное обращение, то запрос ждет ответа, который сохраняется в переменной PermissionResponse:

...

<!— синхронное обращение к менеджеру для получения разрешения --> <invoke partnerLink="managerLT"

portType="prch:EquipmentPurchasePermissionPT"

operation="GetPermission"

inputVariable="PermissionRequest" outputVariable="PermissionResponse" />

...

151

Следующий шаг должен вызвать веб-сервисы обеих компаний. Для этого требуется подготовить входные сообщения (для простоты будем считать, что они идентичны для обоих сервисов). Сообщение PermissionRequest может состоять из нескольких частей, но нас будет интересовать только одна часть – тип оборудования, полученная из запроса клиента:

...

<!—Подготовка запроса к сервисам компаний --> <assign>

<copy>

<from variable="PermissionResponse" part="EquipmentType"/> <to variable=" EquipmentDetails" part="EquipmentType"/>

</copy>

</assign>

...

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

использовав либо XPath с выражением <assign>, либо сервис преобразования

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

Теперь можно вызывать веб-сервисы компаний поставщиков. Для параллельного вызова сервисов применяется активность <flow>. Оба сервиса асинхронные и поэтому реализуются активность <invoke> и активность

<receive>.

Результаты, полученные от компаний, сохраняются в переменных

AResponse и BResponse соответственно:

...

<!—Параллельное обращения к сервисам компаний --> <flow>

<sequence>

<! --Асинхронный вызов Web-сервиса Компании А и ожидание ответа -->

152

<invoke partnerLink="CompanyALT" portType="spl:PriceListAPT" operation="GetPrice" inputVariable="EquipmentDetails" />

<receive partnerLink="CompanyALT" portType="spl:FlightCallbackPT" operation="CompanyACallback" variable="AResponse" />

</sequence>

<sequence>

<!-- Асинхронный вызов Web-сервиса Компании B и ожидание ответа --> <invoke partnerLink=" CompanyBLT"

portType="spl:PriceListAPT"

operation="GetPrice" inputVariable="EquipmentDetails" />

<receive partnerLink=" CompanyBLT" portType="spl:FlightCallbackPT" operation=" CompanyBCallback" variable="BResponse" />

</sequence>

</flow>

...

На следующем шаге осуществляется выбор лучшего по стоимости

предложения посредством использования активности <switch>.

...

<!-- Выбор лучшего варианта и формирование ответа клиенту -->

<switch>

153

<case condition="bpws:getVariableData('AResponse', 'confirmationData','/confirmationData/Price')

<= bpws:getVariableData(' BResponse', 'confirmationData','/confirmationData/Price')">

<!-- Вариант от компании А --> <assign>

<copy>

<from variable="AResponse" />

<to variable="Response2employer" /> </copy>

</assign>

</case>

<otherwise>

<!-- Вариант от компании B --> <assign>

<copy>

<from variable="BResponse" />

<to variable="Response2employer" /> </copy>

</assign>

</otherwise>

</switch>

...

В элементе <case> для сравнения предложений используется BPEL-функция getVariableData и определяется имя переменной. Цена находится в разделе confirmationData сообщения, который является единственной частью сообщения, но это все же требуется определить. Также нужно определить выражение вопроса, чтобы задать местонахождение элемента цены. Здесь это делается простым выражением XPath 1.0.

154

Если предложение от A лучше, чем от B, копия переменной AResponse

помещается в переменную Response2employer. В противном случае копируется переменная BResponse.

Затем посредством использования активности <invoke> результаты работы бизнес процесса возвращаются клиенту. Для этого используется партнерская связь purchaseLT и вызывается операция SendPurchaseInfo по типу порта

ClientCallbackPT:

...

<!—Формирование ответа клиенту --> <invoke partnerLink="purchaseLT"

portType="emp:ClientCallbackPT"

operation="SendPurchaseInfo" inputVariable="Response2 employer" />

</sequence>

</process>

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

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

Корректная и полная реализация стандарта BPEL должна поддерживать следующий набор стандартов веб-сервисов: WSDL 1.1, XML Schema 1.0, XPath

1.0, WS-Addressing, UDDI v2.0, WS-Security (необязательно).

Среди свободно распространяемых программных продуктов,

предоставляющих возможности генерации скриптов BPEL, можно выделить

Netbeans BPEL Designer - компонент Netbeans Enterpise Pack, представляющий собой бесплатное дополнение к NetBeans и добавляющий к его функциональным возможностям средства визуального проектирования приложений с сервис-ориентированной архитектурой. NetBeans Enterprise Pack

содержит средства для проектирования BPEL, схем XML, WSDL файлов, а так же средства обеспечения безопасности веб-сервисов. BPEL Designer позволяет оркестрировать веб-сервисы, а именно: создавать, разрабатывать, запускать и

155

тестировать бизнес-процессы BPEL, соответствующие спецификации WS-BPEL

2.0. Кроме того, данный продукт предоставляет визуальные средства,

позволяющие быстро и эффективно оркестрировать веб-сервисы в рамках

бизнес-взаимодействия.

Среди платных программных продуктов известен Oracle BPEL Process Manager (BPM) - инфраструктурное решение для проектирования, размещения и управления бизнес-процессами по стандарту BPEL.

156

50. Уровни интеграции. Интеграция данных

Данный подход называют также интеграцией, ориентированной на информацию (Information-Oriented Integration) [40].

Этот подход ориентирован, в первую очередь, на интеграцию данных,

которые хранятся в базах данных и обычно имеет целью создание API,

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

системы репликации баз данных;

федеративные базы данных;

использование API для доступа к стандартным ERP

системам.

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

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

Существует множество различных способов реализации репликации данных.

Функция поддержки репликаций может быть встроена в СУБД; нужные сведения можно экспортировать в файл для последующего импорта в другой системе, а также переслать внутри сообщений с помощью соответствующего промежуточного ПО. Более подробную информацию об общих принципах реализации механизмов реализации механизмов репликации можно найти,

например, в [25]

Федеративные базы данных (Federated Database System) – это системы,

которые позволяют прозрачным для пользователя образом интегрировать множество автономных баз данных, которые могут располагаться на разных хостах сети. Федеративные базы данных называют также виртуальными БД.

157

Федеративная (виртуальная) БД предоставляет пользователю единый хорошо определенный интерфейс для доступа к распределенным данным, при этом сами данные не перемещаются и не изменяются, т. е. нет препятствий для того, чтобы одна и та же автономная БД входила в состав более чем одной виртуальной БД.

Использование API для доступа к стандартным ERP системам предполагает использование хорошо определенных интерфейсов для организации взаимодействия создаваемых пользовательских приложений с такими пакетными приложениями как Enterprise Resource Planning (ERP) системы,

такими как SAP, Oracle, PeopleSoft. Обычно это делается посредством использования адаптеров (коннекторов).

158

51. ESB

Сервисная шина предприятия (англ. enterprise service bus, ESB) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервисориентированной архитектуры.

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

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

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

поддержка синхронного и асинхронного способа вызова служб; использование защищѐнного транспорта, с гарантированной доставкой

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

доступ к данным из сторонних информационных систем с помощью готовых или специально разработанных адаптеров;

обработка и преобразование сообщений; оркестровка и хореография служб;[3]

разнообразные механизмы контроля и управления (аудиты, протоколирование.

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

159

52. Грид

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

Грид с точки зрения сетевой организации представляет собой согласованную, открытую и стандартизованную среду, которая обеспечивает гибкое, безопасное, скоординированное разделение вычислительных ресурсов и ресурсов хранения[1] информации, которые являются частью этой среды, в рамках одной виртуальной организации.

Концепция грид

Грид является географически распределѐнной инфраструктурой, объединяющей множество ресурсов разных типов (процессоры, долговременная и оперативная память, хранилища и базы данных, сети), доступ к которым пользователь может получить из любой точки, независимо от места их расположения.[3]

Идея грид-компьютинга возникла вместе с распространением персональных компьютеров, развитием интернета и технологий пакетной передачи данных на основе оптического волокна (SONET, SDH и ATM), а также технологий локальных сетей (Gigabit Ethernet). Полоса пропускания коммуникационных средств стала достаточной, чтобы при необходимости привлечь ресурсы другого компьютера. Учитывая, что множество подключенных к глобальной сети компьютеров большую часть рабочего времени простаивает и располагает ресурсами, большими, чем необходимо для решения их повседневных задач, возникает возможность применить их неиспользуемые ресурсы в другом месте.

Типы грид-систем

В настоящее время выделяют три основных типа грид-систем: Добровольные гриды — гриды на основе использования добровольно

предоставляемого свободного ресурса персональных компьютеров; Научные гриды — хорошо распараллеливаемые приложения

программируются специальным образом (например, с использованием Globus Toolkit);

Гриды на основе выделения вычислительных ресурсов по требованию (коммерческий грид, англ. enterprise grid) — обычные коммерческие приложения работают на виртуальном компьютере, который, в свою очередь, состоит из нескольких физических компьютеров, объединѐнных с помощью грид-технологий.

160