Проектирование сервисов для сервис-ориентированной архитектуры – сервисы online обработки заказа товаров с учетом кредитоспособности поку

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

6.5         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.

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

7.1         Разработка 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", Приложение А. Структура каталогов диска).

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

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

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

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

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

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

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-службы.

7.3.1        Класс 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.

7.3.2        Класс WebSellerDBHandler

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

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

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

public static Order createOrder()

{

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

                            "Test Customer Name");

              CartItem[] cartItems = {

                            new CartItem(

                                          new Product("testProductID1",

                                                        new BigDecimal(10), "testDescription1"), 1),

                            new CartItem(

                                          new Product("testProductID2",

                                                        new BigDecimal(29), "testDescription2"), 2)

                            };

              Cart cart = new Cart("Test Shop Name", cartItems);

              Order order = new Order("fakedOrderID",

                            OrderState.fromString(OrderState._PENDING), customer, cart);

              return order;

}

...

//              Вызов web-службы

String orderID = getWebSellerDB().addOrder(new SingleOrderBox(createOrder()));

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

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

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

{

              Node singleOrderBoxNode = requestMessage.getSOAPBody().getFirstChild();

              Node orderNode = singleOrderBoxNode.getFirstChild();

              String orderXml = orderNode.toString();

              String resourceID = addOrder(orderXml);

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

private String addOrder(String orderXml) throws XMLDBException

{

              //              Add this order to the database

              String resourceID = XindiceHelper.getInstance().insert(orderXml);

              updateOrderState(resourceID, OrderState.PENDING);

              return resourceID;

}

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

orderXml = replaceWithRealOrderID(orderXml, resourceID);

replaceSoapBody(requestMessage, boxOrderXml("singleOrderBox", orderXml));

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

public String addOrder(SingleOrderBox orderBox)

throws 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 database

              String resourceID = XindiceHelper.getInstance().insert(orderXml);

              updateOrderState(resourceID, OrderState.PENDING);

              return resourceID;

}

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

public static void updateOrderState(String orderID, OrderState newOrderState)

              throws XMLDBException

{

              String xupdate =

                            "<xu:modifications version=\"1.0\"" +

                            " xmlns:xu=\"http://www.xmldb.org/xupdate\"" +

                            ">" +

                            "<xu:update select=\"//order/state\">" +

                                          newOrderState.getValue() +

                            "</xu:update>" +

                            "</xu:modifications>";

              XindiceHelper.getInstance().update(orderID, xupdate);

}

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

private String getOrdersByCustomerID(String customerID)

              throws XMLDBException, Exception

{

              StringBuffer orderSequence = new StringBuffer();

              QName[] namespaces = null;

              String xpath = "//order[customer/customerID='" + customerID + "']";

              ResourceIterator results = XindiceHelper.getInstance().select(xpath, namespaces);

              while (results.hasMoreResources()) {

                            Resource res = results.nextResource();

                            String orderXml = getCleanOrderXml((String) res.getContent());

                            orderSequence.append(orderXml);

              }

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

}

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

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

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

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

1. Инициализация
2. Процедура проверки кредитоспособности
3. Управление состоянием заказа

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

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

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

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

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

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

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

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

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

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

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

1. Подтверждения заказа
2. Отмены заказа
3. Таймаута

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

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

7.4.3.1     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"

              propertyName="tns:orderID" query="/webseller:cancelOrderID"/>

<bpws:propertyAlias messageType="messages:confirmOrderMessage" part="orderID"

              propertyName="tns:orderID" query="/webseller:confirmOrderID"/>