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

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.

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-ответ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<correlationSets>

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

</correlationSets> 

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

  <onMessage operation="confirmOrder" partnerLink="OrderProcessingLink"

            portType="order-processing:WebSeller" variable="confirmOrderMessage">

            <correlations>

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

            </correlations>

            <invoke inputVariable="deleteOrderMessage" name="DeleteOrder"

                  operation="deleteOrder" outputVariable="processVoidReply"