Миграция приложений с платформы Oracle WebLogic Integration на платформу IBM Business Process Manager Advanced: Часть 2. Преобразования данных

В первой статье данного цикла были описаны инструменты и методики, которые с успехом применялись для миграции бизнес-процессов и связанных с ними артефактов платформы Oracle® WebLogic Integration (WLI) на платформу IBM Business Process Manager (BPM). Во второй статье описываются преобразования различных типов и API-интерфейсов (используемых для написания бизнес-логики в потоках платформы WLI) в типы и API-интерфейсы, которые могут быть использованы такой же бизнес-логикой, но исполняющейся на платформе IBM BPM.

Майк Цай, старший ИТ-специалист, IBM

Mike Cai photoМайк Цай (Mike Cai) был принят на работу в IBM после окончания колледжа в 2001 г. в качестве ИТ-специалиста группы по разработке корпоративных приложений в составе подразделения GBS (Global Business Services), где специализировался на создании Java/J2EE-приложений для различных заказчиков. Затем М. Цай перешел в группу по интеграции корпоративных приложений в качестве старшего ИТ-консультанта, где занимался преимущественно интеграцией больших корпоративных систем и приложений с использованием J2EE-платформ и таких технологий, как WebSphere Application Server, WebSphere MQ, WebSphere Lombardi Services, JMS, SOAP, BPEL, Service Bus, WebSphere Service Registry and Repository и т.д. Кроме того, М. Цай имеет опыт практической работы на самых различных должностях (архитектор, проектировщик, разработчик, технический руководитель, бизнес-аналитик, менеджер по дефектам и т.д.). В последние пять лет М. Цай специализируется преимущественно на таких пакетных продуктах, как BEA/Oracle WebLogic, Oracle Fusion, WLS, WLI, OSB, ODI и WLP. Он имеет опыт создания всего спектра компонентов, включая фронтальные JSP-компоненты, компоненты связующего уровня (JPD-компоненты и OSB-сервисы посредничества/преобразования) и серверные компоненты (веб-сервисы на базе SOAP и JMS).



Дэйв Малли, специалист по информационным технологиям, Systems Documentation, Inc. (SDI)

Дэйв Малли (Dave Mulley) - специалист по информационным технологиям в группе IBM Software Services for WebSphere Enablement в Raleigh, North Carolina. Дэйв работает в IBM с 1999 года, где занимается семейством продуктов WebSphere Business Integration. Связаться с ним можно по адресу dmulley@us.ibm.com



Дэвид ВандеПол, ИТ-специалист, IBM

David VandePol photoДэвид ВандеПол (David VandePol) работает в IBM с 2008 г. Сначала он занимался разработкой в составе группы по установке продукта WebSphere версий v7 и v8, а с момента основания в январе 2012 г. группы Competitive Migration Team является ее членом. Д. ВандеПол обладает глубокими знаниями по всем операционным системам, которые поддерживаются продуктами семейства WebSphere. В качестве специалиста по миграции Д. ВандеПол принимал участие в разработке учебных семинаров по миграции с конкурирующих серверов приложений и по миграции с версии на версию. Он провел множество таких семинаров в Канаде и в США. Д. ВандеПол успешно выполнил большое количество миграций с продуктов JBoss, WebLogic, Oracle Application Server и Tomcat для многочисленных заказчиков в разных странах мира.



Дональд Вайнз, ведущий ИТ-архитектор, IBM  

Дональд Вайнз (Donald Vines) работает в IBM ведущим ИТ-архитектором и отвечает за подразделение миграции на WebSphere в Северной Америке. В настоящее время он работает над разработкой архитектурных решений для крупнейших клиентов IBM и является наставником для проектировщиков и разработчиков ПО в SOA и в проектах по модернизации предприятий. В прошлом он был техническим представителем группы OMG, самого крупного в мире комитета по стандартам, и занимался разработкой протокола взаимодействия ORB в сетях TCP/IP (IIOP), который теперь используется в Интернете. Дон имеет сертификаты сертифицированного бизнес-архитектора компании Sun, сертифицированного Java-программиста компании Sun и сертифицированного специалиста по UML2 от OMG.



19.02.2014

Введение

Фокусом любого бизнес-процесса всегда являются данные. В конечном итоге процесс — это не более чем выполняемые в надлежащее время и координированным образом операции транспортировки, извлечения, отбора, преобразования, трансформации и агрегации некоторых данных, основанных на некоторых других данных. На платформе Oracle WebLogic Integration (WLI) и на платформе IBM WebSphere Business Process Manager (IBM BPM) используются разные технологии связывания данных (привязки), поэтому функции для работы с данными играют ключевую роль при миграции WLI-потоков в BPM-процессы. В WLI-потоках обычно используются следующие технологии связывания данных и форматы данных.

  • XMLBeans— библиотека с открытым исходным кодом для связывания XML-данных и Java-данных, разработанная организацией Apache. Это стандартная для платформы WLI технология связывания данных, используемая потоками, Control-компонентами и различными артефактами этой платформы. В рабочем пространстве проекта WLI любые определения данных на основе схем (XSD) компилируются в XMLBeans-компоненты (специальные bean-компоненты Java™). XMLBeans-компоненты широко используются в WLI-потоке, а также на интерфейсных границах потоков, Control-компонентов, сервисов и т. д.
  • Java-объекты поддерживаются платформой WLI нативным образом. Широко используются в потоках, Control-компонентах и различных артефактах платформы WLI. Платформа WLI также поддерживает использование сериализованных типов Java в определениях интерфейсных параметров для различных WLI-артефактов. Это позволяет непосредственно передавать Java-объекты между интерфейсами потоков, Control-компонентов и других артефактов WLI.
  • Прочие технологии связывания XML-данных и Java-данных, основанные на отраслевых стандартах,— такие как Java Architecture for XML Binding (JAXB), — также применялись в различных реализациях по причине отсутствия соответствующих возможностей или недостаточной функциональности библиотеки XMLBeans. И глобальные, и локальные переменные могут быть декларированы с помощью сторонних binding-объектов. Они даже могут быть сохранены в stateful-транзакциях.

Основной технологией связывания данных на платформе IBM BPM является инфраструктура SDO (Service Data Objects). Это означает, что весь WLI-код (например, исполнительные узлы и Control-компоненты Java), в котором используются XMLBeans-объекты, должен быть переведен на SDO-синтаксис. Платформа IBM BPM не поддерживает прямой обмен объектами на основе сериализованных типов Java через интерфейсы между процессами и SCA-компонентами. Эти типы определений интерфейсов для платформы WLI также должны быть подвергнуты миграции на WSDL-интерфейсы с соответствующими обновлениями в реализациях. Другие технологии связывания, такие как JAXB, могут быть обработаны обработчиками данных продукта IBM BPM.

В этой статье описывается алгоритм миграции данных, представленных в вышеуказанных форматах, в нативную технологию связывания данных, которая применяется в процессах платформы IBM BPM (т.е. в SDO). В частности, в статье описываются проблемы такой миграции и способы их разрешения, предлагаются рекомендации по различным подходам; а также демонстрируются некоторые утилиты, созданные для ускорения миграции и повышения ее безопасности.

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


Пример интеграции на платформе WebLogic

В этом разделе описывается пример бизнес-данных и бизнес-процесса WLI, которые мы будем использовать в демонстрационных целях в остальной части этого цикла статей. Мы специально разработали эти бизнес-данные и этот процесс для демонстрации различных возможностей инструментария, предназначенного для миграции с платформы WLI на платформу IBM BPM.

Для представления бизнес-данных и бизнес-процесса мы воспользуемся языком UML. Если вам привычнее представление платформы WLI, можете открыть рабочее пространство проекта для этого примера, которое прилагается к статье (см. раздел Загрузка).

Бизнес-данные

Наш поток представляет собой простой процесс заказа на покупку, который запускается при получении XML-документа Purchase Order (заказ на покупку). XSD-схема процесса Purchase Order показана на рис. 1.

Рисунок 1. XSD-схема Purchase Order
Purchase Order XSD

Кликните, чтобы увидеть увеличенное изображение

Рисунок 1. XSD-схема Purchase Order

Purchase Order XSD

Бизнес-процесс на платформе WLI

Основной процесс представлен файлом Process.jpd и показан в виде UML-диаграммы на рисунке 2. Он начинается с проверки клиента на наличие достаточных денежных средств. При положительном результате проверки вызываются два параллельных потока: один поток занимается выставлением счета; другой поток использует подпроцесс, который проверяет наличие товаров и отсылает JMS-сообщение со списком имеющихся в наличии товаров и списком отсутствующих в наличии товаров. После завершения параллельных потоков создается счет-фактура, а затем клиенту отсылается электронное письмо, информирующее клиента о том, что его заказ обработан.

Рисунок 2. WLI-процесс: Process.jpd
WLI Process: Process.jpd

Кликните, чтобы увидеть увеличенное изображение

Рисунок 2. WLI-процесс: Process.jpd

WLI Process: Process.jpd

WLI-подпроцесс представлен файлом isItemInStockSubProcess.jpd и показан в виде UML-диаграммы на рисунке 3. Этот подпроцесс отправляет запрос в базу данных для определения текущего уровня запасов заказываемого товара, а затем (при наличии достаточных запасов) вычитает заказанное количество из текущего объема запасов. В заключение этот подпроцесс возвращает логическое значение вызвавшему его процессу.

Рисунок 3. WLI подпроцесс: IsItemInStockSubProcess.jpd
WLI SubProcess: IsItemInStockSubProcess.jpd

Подробное описание каждого шага этих потоков содержится в примере приложения, ссылка на который приведена в разделе Загрузки.


Миграция XMLBeans

В рамках общего процесса миграции, описанного в первой статье данного цикла, экспорт BPEL-файлов и WSDL-файлов из JPD-потока платформы WLI и импорт этих файлов в инструмент IBM Integration Designer с помощью подключаемого модуля BPEL 2.0 Importer Plugin (с адаптацией для WLI) обеспечит большую часть преобразований, требуемых для миграции JPD-потоков платформы WLI в процессы платформы IBM BPM. Более детально эта процедура будет описана в четвертой статье этого цикла.

Однако везде, где для манипулирования объектами XMLBeans используется программный Java-код, этот код необходимо модифицировать вручную, чтобы он смог манипулировать SDO-объектами. В случае XMLBeans используются методы get<FieldName> и set<FieldName>; а в случае SDO используются методы get и set, а также pass в имени поля. В большинстве ситуаций достаточно заменить операторы присваивания для использования SDO-синтаксиса, как показано в следующем примере.

В таблице 1 показано одно и тоже условное ветвление IsItemInStock в примере для платформы WLI и в потоке для платформы IBM BPM после миграции. В нашем примере процесса после подтверждения наличия товар добавляется в список поставки.

Таблица 1. Условное ветвление IsItemInStock
WLI IBM BPM
IsItemInStock in WLI exampleIsItemInStock in BPM process

В узле исполнения платформы WLI, который носит название AddItemToShippingList информация о заказанном товаре для вывода и выделения извлекается с помощью XMLBeans-методов get (рис. 4).

Рисунок 4. Импортированный Java-фрагмент AddItemToShipment
Imported AddItemToShipment Java snippet

Мигрированный Java-фрагмент AddItemToShipment в BPM использует для получения этой же информации о заказанном товаре SDO-синтаксис get (рис. 5).

Рисунок 5. Мигрированный Java-фрагмент AddItemToShipment, представленный в SDO-синтаксисе
Migrated AddItemToShipment in SDO syntax

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

Для этого существующие определения схем (XSD) необходимо скомпилировать в XMLBeans-объекты и включить в Java classpath. Обычно это делается автоматически с помощью инструмента BEA Weblogic Workshop или Jdeveloper при добавлении XSD-файлов к проекту Schema. Продукты IBM BPM и Integration Designer не предоставляют готовых к использованию библиотек и компиляций XMLBeans, однако вы сможете загрузить вариант XMLBeans с открытым исходным кодом с веб-сайта Apache, а затем скомпилировать XSD-файлы в XMLBeans.

После того как требуемые XSD-файлы будут скомпилированы в XMLBeans-объекты Java и помещены в classpath, фрагмент кода процесса (фрагмент) можно модифицировать для его использования аналогично любым другим Java-объектам. Конечно, потребуется преобразование из XMLBean-объектов в SDO-объекты. Эта задача решается при помощи соответствующей миграционной утилиты IBM. Результаты такой модификации использованных выше примеров показаны на рисунках 6 и 7.

Рисунок 6. XMLBeans-объекты и компилированные JAR-файлы XSD-библиотеки в classpath
XMLBeans and compiled XSD library JAR files on the classpath

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

Рисунок 7. Мигрированный Java-фрагмент AddItemToShipment, использующий преобразование между SDO и XMLBeans
Migrated AddItemToShipment Java snippet using SDO to/from XMLBeans conversion

Несложно увидеть, что мы добавили лишь преобразование поступающего SDO-объекта в XMLBean-объект. В результате мы можем повторно использовать весь существующий код. В конце фрагмента мы просто преобразовали XMLBeans-объекта обратно в SDO-объект. При повторном использовании XMLBeans-объектов в BPM-процессе необходимо учитывать три важных момента.

  1. Каждую SDO-переменная, область действия которой не ограничивается исключительно пределами Java-фрагмента (т. е., глобальные и локальные переменные процесса) и которая была преобразована в XMLBeans-объект с целью манипулирования, необходимо преобразовать обратно в первоначальную SDO-переменную.
  2. Скомпилированный JAR-файл XMLBeans-объекта содержит набор первоначальных XSD-файлов. Когда JAR-файл помещается в classpath проекта для модуля BPM-процесса, по существу происходит дублирование XSD-файлов в этом classpath. Это может вызвать сбой загрузчика артефактов BPM-сервера и породить проблемы при развертывании. В таких случаях можно вручную распаковать JAR-файлы, удалить XSD-файлы, а затем снова упаковать JAR-файлы. Эти XSD-файлы предназначены для извлечения/просмотра схемы и не влияют на манипуляции с самими XMLBeans-объектами.
  3. С точки зрения всей последовательности операций преобразования между SDO-объектами и XMLBeans-объектами несколько ухудшают общую производительность, однако эти издержки очень невелики. Дополнительным преимуществом при этом является возможность повторного использования кода без каких-либо модификаций. Конечно, если при профилировании вашего приложения обнаружатся проблемы, вы всегда можете преобразовать типы данных и API-интерфейсы с помощью какого-либо другого подхода из числа описанных в этой статье.

К счастью, при использовании WSDL-кода, экспортированного из инструмента WLI BEA Workshop или Jdeveloper, на стороне интерфейса требуются лишь минимальные изменения. XMLBeans-объекты компилируются из тех же XSD-файлов, с помощью которых были определены WSDL-файлы, поэтому эти же вайлы можно использовать с SDO-объектами в интерфейсах платформы IBM BPM. В примере WSDL-кода в листинге 1 необходимо скорректировать только атрибут schemaLocation, поскольку структура файлов у продукта BPM несколько отличается от структуры файлов у продукта WLI.

На рис. 8 показан WSDL-интерфейс для основного процесса в примере для платформы WLI после его импорта на платформу IBM BPM. Он использует первоначальное XSD-определение для типа входного параметра.

Рисунок 8. WSDL-интерфейс в IBM BPM, использующий первоначальное XSD-определение
WSDL Interface in IBM BPM using the original XSD

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

Листинг 1. Код WSDL XML в IBM BPM, использующий первоначальное XSD-определение
<types>
	<xsd:schema>
		<xsd:import namespace=”http://temp.openuri.org/DemoApp/PurchaseOrder.xsd”
				schemaLocation=”../data/PurchaseOrder.xsd” />
	</xsd:schema>
</types>

<message name=”Process_clientRequestMsg”>
	<part name=”purchaseOrder” element”pur:PurchaseOrders” />
</message>

Миграция типов Java

Платформа WLI допускает широкое применение "регулярных" Java-объектов (не являющихся XMLBeans-объектами) на основе ее потоков работ и Control-компонентов. При этом создаются два дополнительных типа данных и API-интерфейсы, которые должны быть обработаны в ходе миграции:

  • Нативные Java-объекты как глобальные переменные
  • Нативные Java-объекты как параметры входа и выхода для интерфейсов

С другой стороны, платформа IBM BPM поддерживает только глобальные переменные на базе XSD и некоторые простые типы Java, такие как String, Integer, Double и т.д. Аналогичная ситуация имеет место при вызове SCA-интерфейсов и WSDL-интерфейсов. В случае, когда сложные типы Java (например, Collections и Throwables) используются в качестве глобальных переменных или передаются в SCA-компоненты, их необходимо преобразовать в нечто иное, чтобы платформа BPM смогла их сохранять и обрабатывать.

IBM BPM поддерживает тип XML-схемы xsd:base64Binary и привязывает его к Java-объекту в виде байтового массива. Таким образом, при необходимости сохранения или распространения сложных или специальных Java-объектов их можно преобразовать в байтовые массивы. Утилиты IBM для миграции с платформы WLI предоставляют средства для решения этой задачи.

Процесс IsItemInStockSubProcess в примере для WLI принимает JAXB-объект с информацией о товаре в качестве входа. С точки зрения основного процесса это означает, что информация о товаре, хранящаяся в XMLBeans-объекте, перед ее отправкой в подпроцесс должна быть преобразована в JAXB. Узел управления процессом IsItemInStockSubProcess содержит фрагмент для преобразования входного параметра из XMLBeans в JAXB перед его вызовом. Этот WLI-узел после его миграции на платформу IBM BPM становится Java-фрагментом, который осуществляет вызов.

Таблица 2. Вызов процесса IsItemInStockSubProcess и связанные действия
WLI IBM BPM
IsItemInStockSubProcess node in WLI exampleIsItemInStockSubProcess node in IBM BPM example

В методе transformToJAXB основного WLI-процесса информация о товаре преобразуется и сохраняется в глобальной переменной с типом JAXB-объект (this.product), (рис. 9).

Рисунок 9. Импортированный Java-фрагмент transformToJAXB
Imported transformToJAXB Java snippet

Глобальная переменная product заменяется типом данных base64Binary (рис. 10).

Рисунок 10. Мигрированная глобальная переменная product.
Migrated global variable product

В мигрированном Java-фрагменте transformToJAXB SDO-объект (productDocument) преобразован в JAXB-объект и хранится в глобальной переменной (product) с типом байтовый массив (рис. 11).

Рисунок 11. Мигрированный Java-фрагмент transformToJAXB
Migrated transformToJAXB Java snippet

Если сложный Java-объект передается через какой-либо интерфейс, ассоциированный с ним WSDL-интерфейс необходимо изменить соответствующим образом (при этом тип элемента должен быть изменен на base64Binary).

Процесс IsItemInStockSubProcess в WLI-примере импортируется в IBM BPM как бизнес-процесс. Его интерфейс управления импортируется как WSDL-интерфейс.

Таблица 3. Интерфейс процесса IsItemInStockSubProcess
WLI IBM BPM
IsItemInStockSubProcess in WLI exampleIsItemInStockSubProcess in IBM BPM example

WSDL-интерфейс, экспортированный из инструмента WLI BEA Workshop или из инструмента Jdeveloper, определяет тип входного параметра для процесса IsItemInStockSubProcess с использованием полного типа JAXB-объекта с именем пакета, который не является допустимым XSD-типом с точки зрения IBM BPM.

Процесс IsItemInStockSubProcess принимает JAXB-объект с информацией о товаре в качестве входа.

Рисунок 12. Импортированный WSDL-интерфейс процесса IsItemInStockSubProcess
Imported WSDL interface of the IsItemInStockSubProcess process

Код WSDL XML в листинге 2 демонстрирует несуществующий элемент в определении входного параметра.

Листинг 2. Импортированный код WSDL XML процесса IsItemInStockSubProcess process
<types>
	<xsd:schema xmlns=”http://www.bea.com/wli/jpd” targetNamespace=”http://www.bea.com/wli/jpd”>
		<xsd:element name=”com.ibm.issw.demo.jaxb.impl.ProductImpl”/>
	</xsd:schema>
</types>

<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” element=”jpd:com.ibm.issw.demo.jaxb.imple.ProductImpl”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean” />
</message>

Мигрированный WSDL-интерфейс декларирует входной параметр как base64Binary (рис. 13).

Рисунок 13. Мигрированный WSDL-интерфейс процесса IsItemInStockSubProcess
Migrated WSDL interface of the IsItemInStockSubProcess process

Мигрированный WSDL-код, показанный в листинге 3, определяет входной параметр как base64Binary, что является допустимым XSD-типом для переноса байтового массива SDO-объектов в инфраструктуре BPM. Тип base64Binary – это примитивный XSD-тип, поэтому код WSDL XML процесса IsItemInStockSubProcess не нуждается в импорте дополнительной схемы.

Листинг 3. Мигрированный код WSDL XML процесса IsItemInStockSubProcess
<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” type=”xsd:base64Binary”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean”/>
</message>

Миграция других инфраструктур связывания XML с Java

Несмотря на то, что по умолчанию носителем данных для приложений платформы WLI является технология XMLBeans, иногда в качестве первичных контейнеров данных используются другие инфраструктуры связывания XML с Java, такие как JAXB. Такая замена может оказаться предпочтительной по множеству причин, включая проблемы совместимости, снижение производительности при использовании технологии XMLBeans, необходимость соответствия стандартам и т. д. Какой бы ни была конкретная причина, типичная реализация со сторонней инфраструктурой связывания включает шаблон для прямого и обратного преобразований между XMLBeans и сторонней привязкой в ключевых местоположениях. Эта ситуация подобна описанным выше преобразованиям XMLBeans-SDO, поэтому для миграции этой сторонней привязки XML-Java с платформы WLI на платформу BPM можно применять аналогичные подходы.

Мы проиллюстрируем эти проблемы на примере популярной инфраструктуры связывания JAXB. В случае обычных Java-программ в потоке продукта WLI или таких артефактов, как узел исполнения или метод типа custom control, любой небольшой фрагмент JAXB-кода можно преобразовать непосредственно в SDO-синтаксис. Это преобразование очень похоже на преобразование, которое мы делали раньше при преобразование вызовов вида getFirstName в вызовы вида get("FirstName").

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

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

Таблица 4. Инициализация в процессе IsItemInStockSubProcess
WLI IBM BPM
IsItemInStockSubProcess initialization in WLI exampleIsItemInStockSubProcess initialization in IBM BPM example

После получения информации о товаре процесс IsItemInStockSubProcess извлекает идентификатор товара (product ID) и информацию о его требуемом количестве в качестве подготовки к проверке наличия (рис. 14).

Рисунок 14. Инициализация в импортированном процессе IsItemInStockSubProcess
Imported IsItemInStockSubProcess process initialization

Первоначальный код инициализации в инфраструктуре WLI использовал для извлечения необходимой информацию о товаре и о его количестве методы get JAXB-объекта. Если вы осуществили миграцию этого фрагмента путем модификации его кода для манипулирования SDO-объектами, то вам потребуется лишь изменить get- и set-методы, а сам фрагмент примет вид, показанный на рисунке 15.

Рисунок 15. Мигрированный процесс IsItemInStockSubProcess, использующий SDO-синтаксис
Migrated IsItemInStockSubProcess process initialization using SDO syntax

С другой стороны, если бы вы хотели повторно использовать этот код, вы ограничились бы преобразованием поступающего SDO-объекта в JAXB-объект, повторно использовали бы весь существующий код, а затем преобразовали бы JAXB-объект в SDO-объект. Результирующий фрагмент имел бы вид, показанный на рисунке 16, где для преобразования из SDO в JAXB используется утилита для миграции с WLI на IBM.

Рисунок 16. Инициализация мигрированного процесса IsItemInStockSubProcess, использующего прямое и обратное преобразование JAXB – SDO
Migrated IsItemInStockSubProcess process initialization using JAXB to/from SDO conversion

JAXB-объекты полностью подобны любым другим Java-объектам. Это означает, что на платформе WLI эти объекты могут быть декларированы как глобальные переменные и переданы в Control-элементы платформы WLI как параметры. Что касается глобальных переменных JAXB, то они могут быть обработаны как любые другие глобальные переменные Java, как было описано в предыдущем разделе под названием Миграция типов Java, поэтому мы больше не будем рассматривать их в этом разделе. Тем не менее для передачи JAXB-объектов через интерфейсы управления WLI или через интерфейсы подпроцесса имеется несколько альтернативных решений, описываемых ниже.

Веб-сервисы и процессы, вызываемые в инфраструктуре BPM, обычно представляются как "импорты" (Import) или как SCA-интерфейсы. Платформа IBM BPM позволяет определять для этих «импортов» и SCA-интерфейсов обработчики данных, способные преобразовывать поступающие данные из одного формата в другой. В сценарии миграции JAXB-объект можно отправить как SDO-объект типа base64Binary или типа String, как было описано ранее. Результирующий «импорт» или SCA-интерфейс может иметь присоединенный к нему специальный обработчик данных, способный преобразовать этот тип base64Binary или String в обычный SDO-объект на основе XSD. Это позволяет веб-сервису или процессу беспрепятственно принимать на вход обычный SDO-объект. Дополнительная информация по обработчикам данных продукта BPM содержится в разделеПреобразование формата данных в объектах импорта и экспорта в Информационном центре по продукту IBM BPM.

Далее, поскольку технология JAXB представляет собой связывание между XML и Java, она базируется на XSD. Это означает, что на платформе IBM BPM вместо преобразования этих объектов в байтовые массивы и декларирования их как xsd:base64Binary в WSDL-интерфейсе (см. раздел Миграция типов Java), в WSDL-интерфейсах можно попросту повторно использовать XSD-типы JAXB-объектов.

Процесс IsItemInStockSubProcess в примере для WLI импортируется в IBM BPM как бизнес-процесс. Его интерфейс управления импортируется как WSDL-интерфейс.

Таблица 5. Интерфейс процесса IsItemInStockSubProcess
WLI IBM BPM
IsItemInStockSubProcess in WLI exampleIsItemInStockSubProcess in IBM BPM example

Интерфейс IsItemInStockSubProcess принимает на вход JAXB-объект с информацией о товаре. WSDL-интерфейс, экспортированный из инструмента WLI BEA Workshop или Jdeveloper, задает тип входного параметра для интерфейса IsItemInStockSubProcess с использованием полного типа JAXB-объекта с именем пакета.

Рисунок 17. Импортированный WSDL-интерфейс процесса IsItemInStockSubProcess
Imported WSDL interface of the IsItemInStockSubProcess process

Код WSDL XML, показанный в листинге 4, иллюстрирует неопределенный элемент в определении входного параметра.

Листинг 4. Импортированный код WSDL XML процесса IsItemInStockSubProcess
<types>
	<xsd:schema xmlns=”http://www.bea.com/wli/jpd” targetNamespace=”http://www.bea.com/wli/jpd”>
		<xsd:element name=”com.ibm.issw.demo.jaxb.impl.ProductImpl”/>
	</xsd:schema>
</types>

<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” element=”jpd:com.ibm.issw.demo.jaxb.imple.ProductImpl”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean” />
</message>

Мигрированный WSDL-интерфейс определяет тип входного параметра как Product. Это тот же XSD-тип, из которого компилируется JAXB-объект. Для надлежащего связывания WSDL-интерфейсу необходимо добавить импорт схемы.

Рисунок 18. Мигрированный WSDL-интерфейс процесса IsItemInStockSubProcess
Migrated WSDL interface of the IsItemInStockSubProcess process

Мигрированный код WSDL XML, в котором определен входной параметр IsItemInStockSubProcess, использует тип из той же XSD-схемы, на основе которой генерировался JAXB-объект (см. Листинг 5).

Листинг 5. Мигрированный код WSDL XML процесса IsItemInStockSubProcess
<types>
	<xsd:schema>
		<xsd:import
			namespace=”http://DemoAppWLI.migration.issw.ibm.com/DemoApp/Products.xsd” 
			schemaLocation=”../../data/Products.xsd” />
	</xsd:schema>
</types>


<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part element=”prod:Product” name=”product”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean”/>
</message>

Этот подход является предпочтительным, поскольку он облегчает контроль XML-нагрузки в процессе тестирования; он сокращает потребность в преобразовании между JAXB, байтовыми массивами и SDO-объектами, а также является гораздо более естественным способом для обработки XML-сообщений.

Кроме того, устранение необходимости преобразования между JAXB, байтовыми массивами и SDO-объектами исключительно удобно в сценариях миграции, в которых весь JAXB-код или его большая часть заменяются SDO-эквивалентами. В конце концов, и SDO, и JAXB –современные инфраструктуры связывания с сопоставимыми характеристиками и показателями производительности, чего нельзя сказать о более ранних версиях XMLBeans, поставляемых с более старыми средами исполнения WLI.


Заключение

В статье описана миграция широко применяемых форматов данных и API-интерфейсов, используемых при написании бизнес-логики бизнес-процесса на платформе Oracle WLI, в форматы данных и API-интерфейсы, которые используются при написании бизнес-логики на платформе IBM BPM. Рассмотрено использование XMLBeans, нативных Java-объектов и других связывающих технологий, таких как JAXB. Приведены примеры WLI-артефактов, использующих эти форматы, и описаны изменения, необходимые для повторного использования бизнес-логики в потоке IBM BPM.

В этой статье не рассматривалась миграция преобразований данных платформы WLI, используемых для преобразования между такими форматами данных, как XML, не-XML и Java. Подобное преобразование можно реализовать с помощью таких инструментов, как JPD Palette или XQuery Mapper в инфраструктуре WLI. Эти разновидности преобразования данных можно было бы встроить в управление преобразованием для платформы WLI. Миграция Control-компонентов преобразования и связанных артефактов (DTF, XQ, XSLT) будет рассмотрена в 3-й части этого цикла.

В этой статье также не рассматривается создание метаданных для описания данных в не-XML форматах. Обычно в инфраструктуре WLI эта операция выполняется с помощью инструмента Format Builder, который обрабатывает привязку при наличии входа и выхода потока. Эта тема также будет рассмотрена в 3 части этого цикла в рамках миграции встроенных Control-компонентов (например, компонента Database control).


Загрузка

ОписаниеИмяРазмер
Пример WLI-приложения WLIDevWorksDemo.zip15 МБ

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=963325
ArticleTitle=Миграция приложений с платформы Oracle WebLogic Integration на платформу IBM Business Process Manager Advanced: Часть 2. Преобразования данных
publish-date=02192014