Проектирование сервисов для сервис-ориентированной архитектуры: сервисы online обработки заказа товаров с учетом кредитоспособности покупателя
Курсовая
работа
Проектирование
сервисов для сервис-ориентированной архитектуры: сервисы online обработки заказа товаров
с учетом кредитоспособности покупателя
сервис архитектура заказ обработка
Введение
Тенденции, которые можно наблюдать на сегодняшний день,
свидетельствуют к переходу на новый уровень проектирования систем - систем с
сервис-ориентированной архитектурой (Service-Oriented Architecture, SOA). И наиболее
перспективной технологией, на сегодняшний день, на которой реализуется SOA, является технология web-сервисов. В этой работе
будут рассмотрены способы создания web-сервисов с использованием нескольких технологий
- JAX-RPC, позволяющая создавать и
обращаться к web-службам на платформе Java и BPEL - язык описания бизнес-процессов, построенных на
взаимодействии web-служб.
Постановка задачи
Цель работы - создание набора web-сервисов, в совокупности
предоставляющих службу online обработки заказов товаров, отличительной
особенностью которого является поддержка проверки кредитоспособности покупателя
и возможность управления статусом заказа. При этом разработанный сервис должен
являться абсолютно независимым от других систем, и должен с легкостью
интегрироваться в любую сервис-ориентированную архитектуру, которая
поддерживает процесс online заказа товара.
В этой пояснительной записке отражены технические детали
разработанного в рамках курсового проекта бизнес-процесса (см. артефакт Vision в каталоге "Артефакты RUP",
Приложение А. Структура каталогов диска).
Готовый код бизнес-процесса, описанного на языке BPEL, а также исходные тексты WSDL-документов и других программных
артефактов можно найти на диске, прилагаемом к этому проекту (см. Приложение А.
Структура каталогов диска).
Далее мы будем ссылаться на данное описание системы, и приводить
исходные коды с подробными комментариями, где это необходимо.
Разработка
по методике RUP
Данный курсовой проект разрабатывался с использованием
некоторых подходов, описанных в RUP’е. Так как данный проект является учебным и
своей главной целью не ставит получение готового, конкурентоспособного
продукта, то практически, подход, описанный в RUP, приходится изменять.
В частности, сложно определить потребности заинтересованных сторон
в конечном продукте (см. артефакты Stakeholder Requests в каталоге "Артефакты RUP",
Приложение А. Структура каталогов диска). На этом этапе имеется лишь
техническое задание на курсовое проектирование, в котором говорится, какие из
технологий программирования необходимо применить в данном проектировании.
Описание назначения продукта обычно точно определить не удается и здесь остро
встает вопрос об управлении рисками в процессе разработки. К сожалению, этому
вопросу уделяется довольно мало времени или он вообще остается не затронутым. В
связи со всем вышесказанным целесообразным можно считать начинать процесс
разработки с составления диаграммы активности (см. Activity Diagram в
каталоге "Артефакты RUP", Приложение А. Структура каталогов диска), в
которой будут описаны в общем виде все процессы, которым нужно уделить внимание
(Business Use Cases).
Уже на этом этапе можно примерно представить, где и каким образом можно
применить те технологии, использование которых является непосредственной целью
курсового проекта. Набор документов RUP,
среди которых Vision, Supplementary Specification, Use Cases, Software Architecture Document,
позволяют описать как формальные, так и неформальные требования к
функциональности и вариантам использования системы. В этом проекте не уделялось
внимание планированию итераций - основополагающему моменту в модели RUP. Планирование учебного процесса (серии
лабораторных работ по данной дисциплине) в виде модели waterfall lifecycle
(модель водопада) - когда каждый из этапов разработки выполняется один и только
один раз, противоречит принципам итерационности RUP. В связи с этим вероятность того, что документы, разработанные в
ходе лабораторных работ, содержат неточности, очень велика. Нарушение еще
одного принципа RUP, что студент совмещает в себе все роли,
которые участвуют в разработке процесса, также увеличивают вероятность того,
что заявленный в техническом задании проект - провалится на том или ином этапе
разработки.
Адаптация RUP к учебному
процессу не должно противоречить его принципам для того, чтобы получить
желаемые результаты - снизить риски и получить рабочий прототип разрабатываемой
программной системы.
Функциональная
декомпозиция системы
Далее перечислены функции, которыми обладают разработанные
сервисы. Развернутые описания прецедентов, включая диаграммы взаимодействия
можно найти в артефакте Use Cases (каталог "Артефакты RUP",
Приложение А. Структура каталогов диска).
Рисунок 1 Диаграмма вариантов использования
Вариант использования:
Обработать заказ
§ Актант: Внешняя система (Покупатель)
§ Краткое описание: На вход нашей системе поступает
документ заказа товара. В случае если сумма заказа не превышает некоторой
суммы N, установленной магазином, которому принадлежит заказ, этот
заказ ставится в очередь и ожидает подтверждения клиентом в магазине.
После того, как клиент подтвердил или отменил заказ или истекло время ожидания,
заказ удаляется из системы.
Вариант использования: Подтвердить заказ
§ Актант: Внешняя система (Продавец магазина)
§ Краткое описание: Покупатель (клиент, оформивший
заказ) приходит в магазин и предъявляет удостоверение, номер которого
использовался при составлении заказа. Продавец по номеру удостоверения находит
заказы, которые зарегистрированы на этого клиента и подтверждает заказ.
Вариант использования: Отменить заказ
§ Актант: Внешняя система (Покупатель), Время
§ Краткое описание: Клиент может в любое время,
которое не превосходит интервала ожидания подтверждения заказа, отменить свой
заказ. Также по таймауту наша система может убрать заказ из очереди.
Вариант использования: Получить документы заказа клиента
§ Актант: Внешняя система (Покупатель, Продавец
магазина)
§ Краткое описание: Актант может получить список
документов заказа, которые в данный момент находятся в обработке в нашей
системе, для определенного клиента, указав идентификатор клиента во внешней
системе, который был предоставлен нашей системе в документе заказа.
Термины, выделенные жирным шрифтом описаны в глоссарии; см.
Приложение Б. Глоссарий.
Структурная организация системы
Разработанную систему можно позиционировать как набор служб
для сервис-ориентированной архитектуры. В данной работе реализованы две службы
- служба хранения заказов (WebSellerDB) и служба представляющая собой
бизнес-процесс обработки заказа (WebSeller), согласно диаграмме активности,
представленной в приложении к курсовому проекту.
Внешние интерфейсы к разработанным сервисам оформлены в виде web-служб, что позволяет интегрировать эти
сервисы в другие системы. В связи с этим не ставилось целей разработать целиком
архитектуру программной системы, такие как проектирование интерфейса
пользователя, проектирование документов заказов конечной системы, в которой
будут использоваться разработанные сервисы. Напротив, разработанные структуры
данных и интерфейсы позволяют с легкостью интегрировать эти сервисы в уже существующие
системы, обеспечивая совместимость на уровне данных (см. раздел «Разработка XML-схемы документа заказа») и на уровне
интерфейсов взаимодействия (SOAP over HTTP).
Описание разработанных сервисов
Как было сказано выше, в данном проекте разработаны два
сервиса, которые можно включить в сервис-ориентированную архитектуру
приложения, где нужно организовать хранилище документов заказов и/или сервис
обработки документа заказа. Разработанные сервисы имеют интерфейсы web-служб (WSDL), что позволяет с легкостью
интегрировать их в любую современную архитектуру.
Сервис
хранения документов заказов (WebSellerDB)
Этот сервис предоставляет функции сохранения, поиска,
удаления и изменения некоторых частей документов заказа (изменение статуса
документа заказа). Формат документа заказа описан XML-схемой domain.xsd.
Фактически все документы заказов хранятся в базе данных Apache Xindice, которая позволяет
хранить коллекции XML-документов.
Данный сервис является вспомогательным и используется
сервисом обработки заказов.
Сервис обработки заказов (WebSeller)
Использование данного сервиса предполагает особую организацию
процесса покупки товара, когда необходимо, чтобы покупатель подтвердил
сделанный им заказ, например, придя в магазин и оплатив покупку. Данный сервис
предоставляет все необходимые функции для реализации этого процесса, включая
функции подтверждения, отмены заказа или обработка таймаута (см. Activity Diagram в каталоге "Артефакты RUP", Приложение А. Структура
каталогов диска).
Данный сервис реализован на языке BPEL и в качестве иллюстрации некоторых возможностей этого языка, в
частности обращение к другим BPEL-процессам,
в алгоритм работы этого сервиса была включена функция проверки
кредитоспособности путем вызова стороннего сервиса, также оформленного в виде web-службы (см. Activity Diagram в
каталоге "Артефакты RUP", Приложение А. Структура каталогов диска).
Сервис, который эмулирует данную функциональность, можно найти на сайте ActiveBPEL в примерах бизнес-процессов - пример Loan Approval,
он также есть в приложении к курсовому проекту на компакт диске (см. all.tar.gz/loan_approval
в каталоге "Другие проекты", Приложение А. Структура каталогов
диска).
Схема данных
Apache Xindice
управляет коллекциями документов (см. раздел «Apache Xindice»).
Аналогично тому, как в реляционной БД мы определяем набор таблиц, здесь мы
должны определиться с иерархией и типом документов, которые будут храниться,
для того чтобы составлять запросы к БД, такие как выборка, изменение и др.
Схема хранилища документов представлена на рисунке (Рисунок 2 Схема данных БД).
Рисунок 2 Схема данных БД
Краткое
описание и роль используемых технологий
XML-технологии
В данном проекте XML играет
центральную роль. Все задействованные в проекте технологии, так или иначе,
связаны с XML. Описание данных предметной области -
документов заказа, представлено схемой XML (domain.xsd). Описание интерфейсов web-служб - документы WSDL, также являются документами XML. Даже база данных, используемая в проекте
([XINDICE]) работает не с привычными таблицами
реляционной базы данных, а с иерархическими коллекциями XML-документов и языками доступа и управления
данными здесь являются XPath и XUpdate ([XUPDATE]). В проекте также используется язык XSLT совместно с утилитой Apache Ant для автоматизации процесса разработки.
Некоторые из этих технологий являются рекомендациями W3C.
Технологии Web-служб
WSDL
WSDL определяет диалект XML для описания возможностей web-служб. При помощи WSDL
мы определяем, какие действия может выполнять эта служба - элементы <message/>
и <portType/>, какие типы данных используются - элемент <types/>,
как клиент будет обращаться к web-службе (по какому протоколу, HTTP, SMTP и т.д.)
- элемент <binding/>, и где клиент может найти web-службу, какой у нее URL
- за это отвечает элемент <service/>.
JAX-RPC
Если описать основное назначение JAX-PRC в одном предложении, то
можно сказать, что этот API определяет правила для преобразования информации
WSDL о типах портов в Java и наоборот. Есть
несколько простых правил, рассмотрим их ниже.
Отображение
Java в WSDL
§ Основные типы Java отображаются в основные
типы схемы XML (Boolean, String, Integer, и т.д.)
§ Примитивные типы используют держатель (Holder)
классов (которые не наследуются от java.lang.Object, такие как int, byte и
т.д.)
§ Классы JavaBean отображаются в структуру схемы XML
§ Артефакты Java отображаются в
соответствующие артефакты WSDL (Пакет - Документ WSDL, Интерфейс - PortType,
Метод - Операция <operation/>, Исключительная ситуация - Ошибка <fault/>)
§ Java-интерфейс должен
расширять java.rmi.Remote, и каждый метод должен выбрасывать исключительную
ситуацию java.rmi.RemoteException.
Отображение
WSDL в Java
§ Основные типы схемы XML отображаются в основные
типы Java
§ Структуры XML и составные типы отображаются
в JavaBean
§ Перечисления преобразуются в public static final
методы
§ Артефакты WSDL отображаются в
соответствующие артефакты Java
Отображение
службы
Элемент <service/> определяет то, где можно найти web-службу, посредством
интерфейса <port/>, который в нем содержится.
JAX-RPC определяет интерфейс с именем javax.xml.rpc.Service.
Конкретный класс, который будет реализовывать этот интерфейс, должен
существовать во время исполнения. Интерфейс Service содержит методы, которые
клиент может использовать для вызова фактической web-службы.
Есть два различных стиля, в которых клиенты могут
использовать для вызова web-службы посредством интерфейса Service. Один -
это использование proxy-объекта, который возвращается одним из методов getPort()
интерфейса Service. Этот proxy-объект предоставляет методы web-службы локально,
преобразуя тип порта из документа WSDL в Java. Еще один вариант - это использовать объект javax.xml.rpc.Call.
Объект Call представляет один вызов web-службы. Он позволяет нам устанавливать параметры
и другие переменные вызова, а затем исполнять запрос.
Отображение типов
Технология web-служб основана на обмене XML-сообщениями. Мы хотим
создавать приложения на Java, поэтому нужно найти способ преобразовывать
конструкции XML в объекты Java. Реестр отображения типов (public
TypeMappingRegistry javax.xml.rpc.Service.getTypeMappingRegistry()) содержит
запись для каждого типа данных, с которым имеет дело web-служба, а именно его XML-определение (типа), Java-определение и то, как
преобразовывать их друг в друга. Последнее определено парой интерфейсов Serializer
и Deserializer. Serializer преобразовывает Java-объект в строку XML, а Deserializer
выполняет обратную операцию. Большинство реализаций JAX-RPC поставляются с набором
предопределенных сериализаторов и десериализаторов, которые могут
преобразовывать наиболее общие типы данных, поэтому, если пользоваться
основными типами, такими как String, Integer, Boolean и т.д. в интерфейсе нашей
web-службы, нам не нужно
будет ничего делать. В пакет Apache Axis, который мы будем использовать в данной работе,
предоставляет также классы BeanSerializer и BeanDeserializer для преобразования
объектов JavaBean в XML и наоборот.
JAX-RPC и SOAP
JAX-RPC API был определен таким образом, чтобы позволить нам
использовать его независимо от протокола, который используется для вызова web-служб. Тем не менее,
сегодня большинство web-служб используют SOAP в качестве протокола вызова. Поэтому в
спецификации JAX-RPC есть специальный раздел, который объясняет, как использовать JAX-RPC по отношению только к SOAP.
Взаимодействие с web-службой по протоколу SOAP может происходить одним
из двух способов, или стилей. Один стиль называется стилем rpc, а другой - это
документоориентированным стилем (document style). Вкратце стиль rpc означает, что вызов web-службы рассматривается
как вызов функции, когда функции передаются параметры и возвращается
результирующее значение. Документоориентированный стиль подразумевает, что мы
посылаем документ XML web-службе, а в ответ можем получить, а можем и не
получить другой документ XML.
Поверх стиля вызова существуют два основных способа
кодирования данных в сообщение SOAP: один - это использовать кодировку SOAP по умолчанию,
определенную в спецификации SOAP, а другой называется буквенным XML (literal XML). При работе с буквенной
кодировкой (или вообще при отсутствии кодировки) вы не кодируете никаких
данных, а добавляете порцию данных XML в тело SOAP.
Почти во всех случаях используются только две из этих
комбинаций: web-службы либо поддерживают RPC-стиль вызова с
кодировкой SOAP по умолчанию, либо они поддерживают документоориентированный
стиль с буквенной кодировкой XML. Спецификация JAX-RPC требует, чтобы любая
реализация API поддерживала две упомянутые выше комбинации, другие возможные
комбинации являются необязательными. Фактически спецификация требует, чтобы
клиентский API в этих двух случаях не отличался, так чтобы могли использовать web-службы в обоих стилях
одинаковым образом. Из этого правила есть исключение в случае, когда
отсутствует простое отображение типа, определенного в документе WSDL, в тип Java. Один простой пример
этого - это если бы схема XML определяла, чтобы атрибуты были частью документа
XML. Атрибуты не могут быть
отображены в типы Java. В этих случаях интерфейс будет содержать объект, который будет
просто оболочкой конструкции XML.
SOAP Handlers
Механизм SOAP Handlers позволяет встраивать обработчики для
входящих и исходящих SOAP-сообщений. Эти обработчики можно организовывать
в цепочки, определив порядок вызова обработчиков во время прохождения запроса.
Axis предоставляет интерфейс org.apache.axis.Handler.
Рассмотрим некоторые методы:
Таблица 1 Описание основных методов класса org.apache.axis.Handler
SOAP Handlers можно применять для разных задач,
например: журналирование запросов, система безопасности или даже изменение SOAP-сообщения. В интерфейсе Handler также присутствует метод
generateWSDL(MessageContext), который вызывается, когда клиент хочет получить WSDL сервиса (например,
набрав адрес сервиса в браузере + “?wsdl”).
Регистрация SOAP Handlers
Файл deployment descriptor позволяет конфигурировать цепочки обработчиков для сервиса
элементами <requestFlow>, <responseFlow>, <chain> и <handler>
(#"535100.files/image004.gif">
Рисунок 3 WSDL-документы
Файл webseller-definitions.wsdl определяет иерархию
типов для исключительных ситуаций, где родительским типом является абстрактный
тип webseller:Fault и два дочерних типа - webseller:orderProcessingFault для
исключительных ситуаций, происходящих в BPEL-процессе и webseller:storageFault
чтобы обозначить ошибки обращения к базе данных через web-службу.
Для описания web-служб используется document/literal кодирование.
Таким образом, 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=\"#"535100.files/image005.gif">
Рисунок 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>
<!-- Коррелирование событий по этому набору на примере
события подтверждения заказа -->
<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. (#"535100.files/image011.gif">
Рисунок 10 Структура каталогов диска
§ "Другие проекты" - установочные дистрибутивы
используемых технологий (см. раздел «Используемые инструменты»).
§ "Курсовой проект (WebSeller)"
- разработанный курсовой проект, включая:
o "Пояснительная
записка" - эта пояснительная записка;
o "Плакаты" -
разработанные чертежи и плакаты;
o "Артефакты RUP"
- разработанные артефакты RUP;
o "Проект WebSeller
для Eclipse 3.1.1" - архив проекта WebSeller.
§ "Настроенный Tomcat" -
сконфигурированный Tomcat, с установленными сервисами проекта WebSeller.
Приложение
Б
Глоссарий
Артефакт Глоссарий также представлен на прилагаемом диске, см. Glossary в каталоге "Артефакты RUP",
Приложение А. Структура каталогов диска
Список терминов
§ BPEL - Business Process Execution
Language
§ Внешняя система - система, которая использует наш
бизнес-процесс через своих клиентов - продавцов и покупателей.
o Так как данная система
является учебной, в ней не рассматривается вопрос разделения ролей актантов,
таких как продавец или покупатель. Они все представлены одним актантом -
внешняя система.
§ Документ заказа - структура данных (XML-документ), который
содержит информацию о заказе, а именно: статус документа заказа, идентификатор
заказа, выдаваемый нашей системой при сохранении документа заказа в БД,
информация о покупателе, его контактную информацию и его идентификатор во
внешней системе; информация о корзине покупателя, в которой содержится
информация о магазине, в котором совершается покупка, товарах и их количестве,
которые собирается купить покупатель.
§ Статус документа заказа - может принимать
значения STATE_PENDING, STATE_CREDIT_STATUS, STATE_WAITING.
o STATE_PENDING - документ заказа
поступил в систему;
o STATE_CREDIT_STATUS - документ заказа
проходит проверку на кредитоспособность покупателя;
o STATE_WAITING - документ заказа
находится в режиме ожидания подтверждения или отмены заказа.
§ Сумма заказа N - сумма, установленная
для данного магазина, ниже которой магазин может самостоятельно предъявить
кредит покупателю. В случае если сумма заказа больше N, наша система обращается
к сторонней службе проверки кредитоспособности покупателя.
§ Продавец магазина - подтверждает факт явки
покупателя в магазин за получением товара.
§ Время - специальный актант, который по прошествии
определенного времени T извлекает заказ из системы, если покупатель не подтвердил
заказ (т.е. продавец не зафиксировал факт явки покупателя).
Приложение
В
Создание
рабочего окружения
Используемые инструменты
Для развертывания понадобятся:
1. Java 1.5.0 (см. [JAVA])
2. Tomcat 5.5.12 (см. [TOMCAT])
. Apache Xindice 1.1b4 (см. [XINDICE])
. ActiveBPEL engine v1.2 (см. [AEBPEL])
. Apache Axis 1.2.1 (см. [AXIS])
6. Apache Ant 1.6.5
(см. [ANT])
Тестирование системы на совместимость с другими
версиями не проводилось.
Установка исполняемой среды
Для детальной информации по установке см. оригинальные инструкции
по установки конкретного ПО. Ниже будут рассмотрены вопросы, касаемо интеграции
ПО, перечисленного в разделе «Используемые инструменты».
Будем считать, что установка производится на
«чистую» систему, так что вопросы совместимости с уже установленным ПО здесь
рассматриваться не будут.
Переменные
окружения
Для продолжения работы необходимо определить следующие
переменные окружения:
Таблица 2 Переменные окружения
Процесс
установки
1. Распаковать Tomcat (apache-tomcat-5.5.12.tar.gz)
в %CATALINA_HOME%;
2. Распаковать Tomcat Compatibility Pack (apache-tomcat-5.5.12-compat.tar.gz)
для поддержки Java 1.4.x;
3. Распаковать Ant (apache-ant-1.6.5-bin.tar.bz2)
в %ANT_HOME%;
4. Собрать xindice.war (или скачать готовый архив [XINDICE]) и скопировать его в %CATALINA_HOME%\webapps\;
5. xindice.jar в %CATALINA_HOME%\shared\lib\;
6. Установить activebpel-1.2;
§ activebpel-1.2\install.bat
§ xalan-2.5.2.jar
§ xmldb-api-20030701.jar
§ xmldb-api-sdk-20030701.jar
§ xmldb-common-20030701.jar
§ xmldb-xupdate-20040205.jar
§ xmlrpc-1.1.jar
8. Установить параметры ActiveBPEL Engine (<#"535100.files/image013.gif">
Рисунок 11 Рабочая область (Workspace) Eclipse 3.1.1
Рисунок
12 Рабочая область
(Workspace) ActiveWebflow Professional
([AXIS]) предлагает вспомогательные средства для
разработки web-служб - утилиты WSDL2Java и Java2WSDL (см. сноску №6). Для автоматизации
разработки в поставку Axis также
входит набор задач (taskdef) для Apache
Ant ([ANT]), которые позволяют работать с этими и некоторыми другими
утилитами (например, AdminClient).
Напомним, что Ant интегрирован в среду разработки Eclipse, что позволяет наладить процесс автоматизации
разработки web-служб (см. Приложение Г. Задания Ant (Ant Targets)).
Настройка
JUnit и Ant
Для того чтобы можно было запускать JUnit-тесты из Ant-скрипта в среде Eclipse, необходимо в настройках
Ant в Eclipse указать путь, по
которому располагается файл junit.jar (Window à Preferences… à Ant à Runtime à Classpath à Ant Home Entries à Add JARs…).
Для того чтобы JUnit тесты
можно было запускать из командной строки с использованием задания test (ant
test), необходимо предварительно в %ANT_HOME%/lib скопировать файл junit.jar.
Это можно сделать заданием deploy-junit (см. Приложение Г. Задания Ant (Ant Targets)).
За дополнительной информацией можно обратиться к Apache Ant FAQ (#"535100.files/image015.gif">
Рисунок 13 Возможные ошибки в Project Build Path
Пути к необходимым библиотекам в CLASSPATH заданы относительно
переменной classpath (classpath variable) CATALINA_HOME. Не следует ее путать с переменной окружения.
Эта переменная имеет отношение только к Eclipse.
Рисунок 14 Добавление Classpath Variable
Чтобы добавить переменную classpath нужно выполнить следующее (Рисунок 14 Добавление Classpath Variable): Project à
Properties… à Java
Build Path à Вкладка
Libraries à Add
Variable… à
Configure Variables… à New… à Добавить переменную CATALINA_HOME со
значением пути корневого каталога Tomcat à OK.
Приложение
Г
Задания
Ant (Ant Targets)
Ниже приведен набор заданий Ant, разработанных для
проекта Web Seller. Исходный текст скрипта, с подробными комментариями, приведен на
диске: файл webseller/ant/build.xml.
Некоторые задания предназначены для использования в среде Eclipse для автоматизации
процесса разработки. Другие, такие как test, build и clean - дублируют
функциональность Eclipse и предназначены в основном для работы с командной строкой.
Рисунок 15 Задания Ant-скрипта для
проекта Web Seller