2.Xindice XML-RPC API - для создания Xindice-приложений на других языках;

3.Core Server API - API ядра системы для добавления нового функционала.

XML:DB API эквивалентна функциональности которую предоставляют JDBC и ODBC для доступа к реляционным базам данных.

XML:DB API основана на концепции коллекций, которые хранят ресурсы. Вообще ресурсом может быть все что угодно: XML-документ, blob-объект или любой другой тип, но Xindice поддерживает только работу с XML-ресурсами - ресурсами, содержимое которых - XML-документы.

Xindice предоставляет реализацию XML:DB API Core Level 1: обязательный сервис XPathQueryService (возможности выполнения XPath запросов), необязательные -XUpdateQueryService (выполнение запросов XUpdate) и

CollectionManagementService (базовый функционал для добавления и удаления коллекций).

Также Xindice предоставляет ряд других, специфический классов: DatabaseInstanceManager (программное управление сервером) и CollectionManager (создание и конфигурирование коллекций внутри сервера). См. также разделы «Схема данных» и «Класс XindiceHelper».

Другие инструменты Apache

В этом проекте часто использовались и другие технологии Apache, такие как Apache Ant ([ANT]) и Log4j ([LOG4J]).

Apache Ant изначально создавался как альтернатива GNU make. Он позволяет оформлять типовые задания в файле сборке (обычно он называется build.xml) и выполнять их из командной строки Примерами таких заданий могут быть: «копирование/перемещение/удаление файлов/папок/наборов файлов и/или папок», «выполнение внешних программ», «запуск JUnit-тестов», «компилирование Java-классов», «вызов XSLT-процессора» и многое другое. К тому же, Ant предоставляет расширения для создания дополнительных определений заданий. Например, Axis предоставляет описания заданий для использования утилит Java2WSDL, WSDL2Java и AdminClient.

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

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

Язык BPEL

Язык BPEL (Business Process Execution Language) - язык программирования с XML синтаксисом, предназначенный для описания поведения бизнес-процессов, основанных на web-службах.

Язык BPEL предоставляет набор активностей, таких как вызов других web-служб (invoke/receive/reply), ограничение областей видимости переменных (scope), поддержка транзакционного поведения и длительных операций в пределах областей видимости (scope/compensate), активности для работы с исключительными ситуациями (throw/catch), активности управления последовательными и параллельными потоками исполнения (sequence/flow) и др.

На раду с этими активностями в язык BPEL введены операции низкого уровня, такие как it/then/else, while, switch и т.д.

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

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

Начальные точки называются стартовыми активностями; значение их атрибута createInstance установлено в yes. Когда срабатывает стартовая активность, создается новый экземпляр бизнес-процесса. С этого момента различные экземпляры процесса идентифицируются набором данных, так называемых correlation sets. Эти данные уникальным образом идентифицируют процесс и могут изменяться во время выполнения процесса.

BPEL основан на наборе других web-технологий, таких как WSDL 1.1, XML Schema 1.0, XPath 1.0, и WS Addressing.

BPEL Engine, ActiveBPEL, ActiveWebflow Professional

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

Существует несколько реализаций BPEL Engine, как коммерческих, так и бесплатных с открытым кодом. В данном проекте используется реализация ActiveBPEL ([AEBPEL]). Эта реализация основана на Apache Axis (см. раздел «Apache Axis»), что позволяет разворачивать в ActiveBPEL Engine как BPEL-процессы, так и обычные web-службы.

Для описания BPEL-процессов подойдет любой текстовый редактор, однако проще всего воспользоваться графическим дизайнером, таким как, например, ActiveWebflow Professional ([AEWEBFLOW]). ActiveWebflow разработан как plug-in для платформы Eclipse; c его помощью можно свести разработку BPEL процесса от текстового редактора к разработке в стиле WYSIWYG. Также, ActiveWebflow предоставляет возможность отлаживать созданный бизнес-процесс в режиме эмуляции и функции автоматической публикации службы в ActiveBPEL Engine.

Обоснование технических решений

Разработка XML-схемы документа заказа

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

§orderID - идентификатор этого документа заказа в пределах BPEL-процесса. Так как это значение используется только в нашем процессе, то за его формирование отвечает сам процесс, а не внешняя система;

§state - статус документа заказа в системе; изменяется по мере продвижения документа заказа через BPEL-процесс;

§customer - информация о покупателе; по ней BPEL-процесс сможет при необходимости обратиться к сервису проверки кредитоспособности, предоставив номер удостоверения личности - personalID - и имя покупателя - customerName, как того требует BPEL-процесс Loan Approval, который используется для этих целей. Так же для покупателя должен быть предоставлен его идентификатор во внешней системе, чтобы при выполнении запроса к базе, в которой хранятся текущие заказы (сервис WebSellerDB), находящиеся на данный момент в обработке BPEL-процесса, получить информацию о покупателе. Тот же самый принцип для товаров с элементом схемы product/productID, см. ниже.

§cart - корзина продуктов покупателя; помимо продуктов, в ней также содержится имя магазина - shopName, для которого оформлен этот документ заказа. Таким образом, данную службу можно интегрировать в сервис-ориентированные архитектуры разных магазинов, установив и настроив ее один раз;

§product - описание продукта; в него входит элемент productID (см. выше), а также элементы price и description, которые позволяют принять решение о необходимости проверки на кредитоспособность и в случае необходимости оной эти параметры передаются сервису Loan Approval.

XML-схема, описывающая данный документ заказа находится в файле domain.xml (см. webseller\wsdl\domain.xsd в архиве проекта в каталоге "Проект WebSeller для Eclipse 3.1.1", Приложение А. Структура каталогов диска).

Разработка WSDL-описаний

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

Рисунок 3 WSDL-документы

Файл webseller-definitions.wsdl определяет иерархию типов для исключительных ситуаций, где родительским типом является абстрактный тип webseller:Fault и два дочерних типа - webseller:orderProcessingFault для исключительных ситуаций, происходящих в BPEL-процессе и webseller:storageFault чтобы обозначить ошибки обращения к базе данных через web-службу.

Для описания web-служб используется document/literal кодирование.

Организация доступа к БД

Apache Xindice использует формат XML для работы с БД в то время как клиенты web-службы используют объекты и классы конкретного языка программирования (в нашем случае это язык Java). Следовательно, необходимо каким-то образом осуществлять преобразование объектов Java в XML и наоборот. Такое преобразование описано в спецификации JAX-RPC - JAX-RPC и SOAP. В тоже время механизм SOAP Handlers позволяет получить доступ к SOAP-сообщению запроса, используя объект класса MessageContext.

Таким образом, SOAP Handler может стать промежуточным звеном, который позволит реализовать все запросы к БД, которые требуют сохранения объектов Java в XML-виде в БД, используя их SOAP-представление (в цепочке <requestFlow>). С другой стороны, все запросы, которые должны делать выборку и возвращать результат, обрабатывать в <responseFlow>, делая выборку из БД и формируя на этой основе ответное SOAP-сообщение.

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

Класс XindiceHelper

Вспомогательный класс net.sf.dmitrygusev.webseller.data.XindiceHelper предоставляет уровень абстракции для работы с сервисами БД, такими как org.xmldb.api.modules.XPathQueryService, org.xmldb.api.modules.XUpdateQueryService и интерфейсом org.xmldb.api.base.Collection как с основными команд управления данными языка SQL - select/insert/update/delete, предоставляя одноименные методы. В качестве языка выборки здесь используется XPath, в качестве языка изменения данных - XUpdate.

Класс WebSellerDBHandler

Этот класс является SOAP Handlerом для web-службы WebSellerDB, который перехватывает вызовы службы, перенаправляя запросы БД классу XindiceHelper, он изменяет фактические SOAP-сообщения, заполняя их данными.

Приведем пример добавления документа заказа в БД и опишем последовательность действий.

Вызов web-службы осуществляется в обычном порядке (либо используя клиентские заглушки в случае JAX-RPC клиента, либо активностью invoke языка BPEL);

public static Order createOrder()

{customer = new Customer("testCustomerID", "testPersonalID",

"Test Customer Name");[] cartItems = {CartItem(Product("testProductID1",BigDecimal(10), "testDescription1"), 1),CartItem(Product("testProductID2",BigDecimal(29), "testDescription2"), 2)

};cart = new Cart("Test Shop Name", cartItems);order = new Order("fakedOrderID",.fromString(OrderState._PENDING), customer, cart);order;

}

...

//Вызов web-службыorderID = getWebSellerDB().addOrder(new SingleOrderBox(createOrder()));

Здесь необходимо обратить внимание на то, что фактический идентификатор заказа не известен на момент вызова и должен быть возвращен в качестве результата методом addOrder().

Этот вызов будет перехвачен SOAP Handlerом WebSellerDBHandler. Для операции addOrder() будет выполнен этот код:

if (!isJustDebug() && "addOrder".equals(operationName))

{singleOrderBoxNode = requestMessage.getSOAPBody().getFirstChild();orderNode = singleOrderBoxNode.getFirstChild();orderXml = orderNode.toString();resourceID = addOrder(orderXml);

В этом коде из SOAP-сообщения мы получаем строковое представление XML-документа заказа, сформированного на клиенте, и вызываем метод WebSellerDBHandler.addOrder() - добавления заказа в БД:

private String addOrder(String orderXml) throws XMLDBException

{

//Add this order to the databaseresourceID = XindiceHelper.getInstance().insert(orderXml);(resourceID, OrderState.PENDING);resourceID;

}

Используя класс XindiceHelper, документ сохраняется в БД и возвращается идентификатор этого документа. Далее этот идентификатор необходимо поместить в оригинальный SOAP-запрос, чтобы получить доступ к этому значению в методе web-службы WebSellerDBSoapBindingImpl.addOrder():

orderXml = replaceWithRealOrderID(orderXml, resourceID);(requestMessage, boxOrderXml("singleOrderBox", orderXml));

Далее этот запрос отправиться далее по цепочке SOAP Handlerов и дойдет до фактического метода web-службы:

public String addOrder(SingleOrderBox orderBox)RemoteException, StorageFault

{

//The order is already stored in the database with WebSellerDBHandler.

//OrderBox.getOrder().getOrderID() is the order database real ID now.

return orderBox.getOrder().getOrderID();

}

В итоге клиенту вернется фактический идентификатор этого документа в БД.

Обратите внимание на вызов метода updateOrderState() в методе addOrder():

private String addOrder(String orderXml) throws XMLDBException

{

//Add this order to the databaseresourceID = XindiceHelper.getInstance().insert(orderXml);(resourceID, OrderState.PENDING);resourceID;

}

Метод updateOrderState() выполняет изменение статуса документа заказа, выполняя XUpdate запрос к БД:

public static void updateOrderState(String orderID, OrderState newOrderState)XMLDBException

{xupdate =

"<xu:modifications version=1.0" +

" xmlns:xu=#"justify">">" +

"<xu:update select=//order/state>" +.getValue() +

"</xu:update>" +

"</xu:modifications>";.getInstance().update(orderID, xupdate);

}

Механизм выборки данных из БД и подмена фактического ответа SOAP-сообщения, по сути, не отличаются от выше изложенного:

private String getOrdersByCustomerID(String customerID)XMLDBException, Exception

{orderSequence = new StringBuffer();[] namespaces = null;xpath = "//order[customer/customerID='" + customerID + "']";results = XindiceHelper.getInstance().select(xpath, namespaces);(results.hasMoreResources()) {res = results.nextResource();orderXml = getCleanOrderXml((String) res.getContent());.append(orderXml);

}boxOrderXml("multipleOrderBox", orderSequence.toString());

}

Для запроса к базе используется XPath. Здесь метод getCleanOrderXml() убирает метаинформацию из результата запроса и формирует строковое XML-представление документа заказа, которое можно будет помещать SOAP-ответ.

BPEL-процесс для сервиса WebSeller

BPEL-процесс для сервиса WebSeller соответствует тому, который приведен на диаграмме активности.

Разработанный процесс можно разделить на три части:

1.Инициализация

2.Процедура проверки кредитоспособности

.Управление состоянием заказа

Рассмотрим подробнее каждый из них.

Инициализация

На этом этапе процесс инициализирует значения всех переменных, которые ему понадобятся для дальнейшей работы, в них входит и подсчет общей стоимости и составление списка продуктов корзины покупателя, для дальнейшей их передачи сервису проверки кредитоспособности, а также на этом этапе документ заказа сохраняется в БД. Все эти действия не зависят друг от друга, поэтому могут выполняться параллельно, располагаясь в активности Flow.

Рисунок 4 Инициализация бизнес-процесса

Процедура проверки кредитоспособности

Процедура проверки кредитоспособности запускается в случае, если общая сумма заказа, посчитанная на предыдущем этапе, превышает определенное пороговое значение (в данном примере, 10000).

Рисунок 5 Вызов внешней службы проверки кредитоспособности (ApproveLoan)

Прежде чем осуществить вызов службы ApproveLoan, процесс изменяет статус документа заказа в БД. В случае если служба ApproveLoan вернет отрицательный ответ, то есть в кредите отказано, будет выброшено исключение orderProcessingFault с соответствующим сообщением об ошибке. Это исключение будет обработано на уровне всего процесса. См. раздел «Обработка ошибок» ниже.

В случае если в процессе проверки будет выброшено исключение loanProcessFault, то оно ловится тут же и выбрасывается новое исключение типа orderProcessingFault с соответствующим сообщением об ошибке.

Управление состоянием заказа

После выполнения первых двух этапов, в случае если не было исключительных ситуаций, процесс перейдет в состояние ожидание: статус документа в БД измениться на OrderState.WAITING и процесс будет ожидать наступления одного из трех событий:

1.Подтверждения заказа

2.Отмены заказа

.Таймаута

.

Рисунок 6 Состояние ожидания бизнес-процесса

В случае если клиент подтвердил заказ (путем вызова метода WebSeller.confirmOrder(orderID)), этот заказ удаляется из БД и процесс завершает свою работу. Во всех остальных случаях процесс завершится исключительной ситуацией типа orderProcessingFault с соответствующим наступившему событию кодом ошибки.

Correlation Set

BPEL-процесс, как и любая другая web-служба, не обладает состоянием. И для того чтобы различать потоки событий от разных пользователей, чтобы определенное событие пришло именно для того документа заказа, для которого его отправил клиент, в BPEL предусмотрен набор идентификаторов, которые позволяют BPEL Engineу различать экземпляры процессов (instances) и осуществлять маршрутизацию сообщений - это Correlation Sets.

Для данного процесса в качестве набора таких идентификаторов выступает идентификатор документа заказа (orderID). Наборы Correlation Set связываются с сообщениями, определенными в WSDL-документах web-службы для чего используются расширения языка BPEL для WSDL (файл properties.wsdl):

<bpws:property name="orderID" type="xsd:string"/>

<bpws:propertyAlias messageType="messages:cancelOrderMessage" part="orderID"="tns:orderID" query="/webseller:cancelOrderID"/>

<bpws:propertyAlias messageType="messages:confirmOrderMessage" part="orderID"="tns:orderID" query="/webseller:confirmOrderID"/>

Ссылка на объявленное свойство из BPEL-процесса:

<!-- Объявление набора -->

<correlationSets>

<correlationSet name="corellateOverOrderID" properties="cor:orderID"/>

</correlationSets>

<!-- Коррелирование событий по этому набору на примере события подтверждения заказа -->

<onMessage operation="confirmOrder" partnerLink="OrderProcessingLink"="order-processing:WebSeller" variable="confirmOrderMessage">

<correlations>

<correlation initiate="yes" set="corellateOverOrderID"/>

</correlations>

<invoke inputVariable="deleteOrderMessage" name="DeleteOrder"="deleteOrder" outputVariable="processVoidReply"="OrderStorageLink" portType="data:WebSellerDB"/>

</onMessage>

Обработка ошибок

В разработанном BPEL-процессе присутствуют два обработчика ошибок уровня процесса:

Рисунок 7 Глобальные обработчики ошибок BPEL-процесса WebSeller

В случае возникновения ошибки с типом orderProcessingFault, необходимо удалить из БД ранее сохраненный заказ. Для этого в BPEL предусмотрена активность compensate, которая должна выполнить активность compensationHandler региона (Scope), переданного ей в качестве параметра. Такой обработчик объявлен в регионе ScopeOrder (см. Рисунок 4 Инициализация бизнес-процесса). Обработанные исключения выбрасываются на следующий уровень - клиенту, вызвавшему службу WebSeller.

Развертывание (deployment) Web-служб

Для того чтобы развернуть (установить) сервисы можно воспользоваться разработанными заданиями ant (см. Приложение Г. Задания Ant (Ant Targets)). Условно можно определить три типа заданий Ant, разработанных для данного проекта:

1.Для компилирования и сборки проекта;

2.Для развертывания проекта (установки web-служб и BPEL-процессов);

.Для запуска тестов.

На этапе сборки проекта создается файл архива, который можно устанавливать в ActiveBPEL Engine: webseller/wsr/webseller.wsr - web-служба WebSellerDB. Архив BPEL-процесса WebSeller - webseller/bpr/webseller.bpr - создается при помощи ActiveWebflow Professional.

Для сборки проекта необходимо выполнить команду (webseller/ant/ - рабочий каталог):build

Все, что нужно для развертывания - это скопировать файлы архивов служб в каталог %CATALINA_HOME%/bpr. Сделать это можно командой:deploy

Для запуска тестов можно воспользоваться командами:

ant deploy-junittest

Тестовые примеры

Для созданного BPEL-процесса в качестве эмуляции системы, в которую интегрирован этот сервис, разработан набор JUnit-тестов (класс net.sf.dmitrygusev.webseller.test.TestWebSeller).

Краткое описание тестов и результатов их работы

В классе TestWebSeller эмулируются три исхода вызова службы:

1.Нормальное завершение обработки заказа подтверждением от клиента (метод testOrderProcessingConfirm());

2.Отмена сделанного заказа (метод testOrderProcessingCancel());

.Таймаут (метод testOrderProcessingTimeout()).

Пример выполнения теста с таймаутом

Рисунок 8 Пример выполнения BPEL-процесса в тесте с таймаутом

Рисунок 9 Глобальные обработчики исключительных ситуаций

Заключение

Сервис-ориентированные архитектуры (Service-Oriented Architectures, SOA) сегодня очень популярны. Хотя SOA не предполагает использование web-служб в качестве сервисов, на сегодняшний день преимущественно именно web-службы используются для построения SOA. В связи с этим на ряду с поддержкой разработки web-служб в языках ООП (JAX-RPC/SAAJ/JAXM, если рассматривать в контексте языка Java) появляются также специфические языки, которые позволяют создавать новые сервисы на основе уже существующих. Примером такого языка является рассмотренный в данной работе язык BPEL, который позволяет специалистам с квалификацией ниже, чем разработчики языков ООП, например, бизнес аналитикам, с легкостью описывать бизнес-процессы, работающие в реальных SOA, пользуясь графическими нотациями, предоставляющие более высокий уровень абстракции для описания сервиса. Используя BPEL, новые сервисы могут разрабатываться за считанные дни и недели, против месяцев и годов, которые пришлось бы потратить на их реализацию, используя технологии более низкого уровня, таких как JAX-RPC/SAAJ/JAXM.

Использованные технологии и источники информации

1.[AEBPEL]ActiveBPEL, LLC - это софтверная организация, работающая в open source, которая лицензирует и распространяет технологию ActiveBPEL™ engine. ActiveBPEL engine - это runtime environment, которая способна исполнять процессы, созданные согласно спецификации Business Process Execution Language for Web Service (BPEL4WS, или просто BPEL) версии 1.1. (#"justify">Приложение А