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

Курсовая работа

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

сервис архитектура заказ обработка

Тенденции, которые можно наблюдать на сегодняшний день, свидетельствуют к переходу на новый уровень проектирования систем — систем с сервис-ориентированной архитектурой (Service-Oriented Architecture, SOA). И наиболее перспективной технологией, на сегодняшний день, на которой реализуется SOA, является технология web-сервисов. В этой работе будут рассмотрены способы создания web-сервисов с использованием нескольких технологий — JAX-RPC, позволяющая создавать и обращаться к web-службам на платформе Java и BPEL — язык описания бизнес-процессов, построенных на взаимодействии web-служб.

Постановка задачи

Цель работы — создание набора web-сервисов, в совокупности предоставляющих службу online обработки заказов товаров, отличительной особенностью которого является поддержка проверки кредитоспособности покупателя и возможность управления статусом заказа. При этом разработанный сервис должен являться абсолютно независимым от других систем, и должен с легкостью интегрироваться в любую сервис-ориентированную архитектуру, которая поддерживает процесс online заказа товара.

В этой пояснительной записке отражены технические детали разработанного в рамках курсового проекта Описание проекта Web Seller можно найти в приложении к данному курсовому проекту (см. «Приложение А. Структура каталогов диска»), представленном в виде набора документов RUP, разработанных в рамках лабораторных работ по дисциплине «Распределенные информационные системы»: Glossary, Vision, Activity Diagram, Use cases, Software Architecture Document и Stakeholder Requests. бизнес-процесса (см. артефакт 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 для автоматизации процесса разработки Ant скрипт содержит набор утилит для сборки и тестирования проекта

. См. также Приложение Г. Задания Ant (Ant Targets).

Некоторые из этих технологий являются рекомендациями W3C.

Технологии Web-служб

WSDL

WSDL определяет диалект XML для описания возможностей web-служб. При помощи WSDL мы определяем, какие действия может выполнять эта служба — элементы и, какие типы данных используются — элемент, как клиент будет обращаться к web-службе (по какому протоколу, HTTP, SMTP и т. д.) — элемент, и где клиент может найти web-службу, какой у нее URL — за это отвечает элемент .

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, Метод — Операция, Исключительная ситуация — Ошибка)

§ Java-интерфейс должен расширять java.rmi.Remote, и каждый метод должен выбрасывать исключительную ситуацию java.rmi.RemoteException.

Отображение WSDL в Java

§ Основные типы схемы XML отображаются в основные типы Java

§ Структуры XML и составные типы отображаются в JavaBean

§ Перечисления преобразуются в public static final методы

§ Артефакты WSDL отображаются в соответствующие артефакты Java

Отображение службы

Элемент определяет то, где можно найти web-службу, посредством интерфейса, который в нем содержится.

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 позволяет конфигурировать цепочки обработчиков для сервиса элементами, , и (http://ws.apache.org/axis/java/reference.html). См. описание ant-цели axis-wsdl2java-server (добавление в файл развертывания (deployment descriptor) информации о SOAP Handler’ах, используя XSLT-преобразование).

Коротко об используемых технологиях Apache

Apache Software Foundation

Apache Software Foundation (ASF, [APACHE]) — это некоммерческая организация, которая поддерживает open source проекты. Отличительной особенностью ASF, среди прочих подобных организаций, является лицензия, под которой выпускается ПО ASF — Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html), которая позволяет использовать продукты под этой лицензией в коммерческих целях.

На данный момент под управлением ASF находится около 30 проектов, соответствующих разным направлениям в разработке ПО, от XML проектов до проектов серверных технологий.

В этом курсовом проекте использовались некоторые проекты ASF — это:

1. Jakarta Tomcat — эталонная реализация спецификаций Java Servlet и JSP;

2. Apache Axis В данном проекте мы не будем использовать Apache Axis в чистом виде, так как он уже интегрирован в ActiveBPEL Engine (см. раздел «BPEL Engine, ActiveBPEL, ActiveWebflow Professional»). Однако основные положения по работе с Axis (за исключением некоторых расширений для процесса развертывания служб) здесь остаются неизменными. — «контейнер» для web-служб;

3. Apache Xindice — XML-«база данных»;

4. Дополнительные API и инструменты позволяющие облегчить процесс создания приложений — Apache Ant, Log4j и другие.

Коротко опишем каждый из этих продуктов.

Jakarta Tomcat

Такие приложения как ActiveBPEL Engine и Apache Axis не могут работать отдельно и должны быть установлены в web-контейнер. Jakarta Tomcat ([TOMCAT]) — это одна из возможных реализаций такого web-контейнера.

Описание Jakarta Tomcat выходит за рамки данного курсового проекта. Подробнее о нем можно узнать на официальном сайте проекта (см. [TOMCAT]) или в одной из множества книг по этому проекту, например, [TOMCATBOOK].

Однако следует отметить несколько замечаний по структуре каталогов Tomcat и их назначению. Здесь и далее, будем считать, что переменная окружения %CATALINA_HOME% указывает на корневую папку, куда установлен Tomcat.

Среди прочих, необходимо выделить три каталога:

§ %CATALINA_HOME%/shared — здесь должны быть классы, которые будут доступны всем приложениям, установленным в web-контейнер. Если классы оформлены в виде jar’ов, то их необходимо поместить в подпапку /lib, если это просто скомпилированные Java-классы (*.class), тогда в подпапку /classes;

§ %CATALINA_HOME%/webapps — здесь располагаются web-приложения, которые Tomcat автоматически развертывает при запуске (помещение каталогов с web-приложениями в папку webapps — не единственный способ развертывания). Отметим также, что структура каталогов web-приложения закреплена отдельной спецификацией.

§ %CATALINA_HOME%/bpr — об этом каталоге речь пойдет ниже, в разделе «Развертывание (deployment) Web-служб».

Теперь должны быть понятны некоторые моменты из процесса установки исполняемой среды (см. раздел «Установка исполняемой среды»).

Apache Axis

Axis — это исполнительная подсистема SOAP. Axis предоставляет реализацию JAX-RPC и

расширяемую реализацию, которая допускает огромную гибкость настройки.

Axis является нейтральным по отношению к производителю инструмент.

Axis имеет собственный standalone контейнер для отладочных целей, а также интегрируется в любой другой сервер приложений. Хорошим примером здесь является Jakarta Tomcat.

Apache Xindice

Apache Xindice — это XML-«база данных». Она хранит и индексирует сжатые XML документы, обеспечивая доступ клиентов к этим данным. Эта система была задумана для хранения большого числа маленьких XML-документов. О достоинствах и недостатках Xindice можно прочитать в разделе FAQ на официальном сайте (http://xml.apache.org/xindice/faq.html).

Xindice поддерживает XML: DB API (http://xmldb-org.sourceforge.net).

Xindice хранит коллекции документов в иерархической форме, так же как хранятся файлы в файловой системе. Xindice предоставляет язык запросов XPath (http://www.w3.org/TR/xpath) для выборки элементов из коллекций и поддерживает язык XUpdate (см. XML: DB API), позволяющий изменять коллекции.

Новые версии Xindice устанавливаются в контейнер (например, Tomcat) в виде web-приложения (WAR). Путь к базе данных — корневой элемент всех коллекций — или отдельной коллекции задается при помощи URI вида:

xmldb:xindice://localhost:8080/xindice/db/orders. Здесь xmldb: xindice — имя протокола, localhost:8080 — сервер и порт, /xindice — контекст web-приложения Xindice, /db — база данных (корневая коллекция), orders — название коллекции.

В одной базе можно создать несколько коллекций, причем, в каждой коллекции могут быть как вложенные коллекции, так и XML-документы.

Xindice предоставляет средства управления коллекциями в виде командной строки и набора API:

1. XML: DB XML Database API — для создания Xindice-приложений на Java;

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 (см. websellerwsdldomain.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-представление (в цепочке). С другой стороны, все запросы, которые должны делать выборку и возвращать результат, обрабатывать в, делая выборку из БД и формируя на этой основе ответное 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 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 =

"

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

" >" +

" «+

newOrderState.getValue () +

" «+

" «;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Таймаута

4.

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

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

Correlation Set

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

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

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

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

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

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

operation="deleteOrder" outputVariable="processVoidReply"

partnerLink="OrderStorageLink" portType="data:WebSellerDB" />

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

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

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

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

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

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

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

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

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

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

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

ant build

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

ant deploy

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

ant deploy-junit

ant test

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

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

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

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

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

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

3. Таймаут (метод 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. (http://activebpel.org/)

2. [AEWEBFLOW]Основанный на стандартах набор продуктов управления процессами, которые позволяют информационным аналитикам создавать, устанавливать и управлять составлением процессов, которые имеют 100% совместимость с BPEL 1.1. ActiveWebflow состоит из интегрированных визуальных средств разработки (ActiveWebflow Professional) и окружением исполнения BPEL уровня предприятия (ActiveWebflow Enterprise). В двух словах, аналитики процессов и разработчики приложений могут использовать ActiveWebflow Professional чтобы создавать и тестировать BPEL-процессы, для дальнейшего развертывания этих процессов в ActiveWebflow Enterprise. (http://www.active-endpoints.com/products/index.html)

3. [ANT]Apache Ant — это Java-based build tool. (http://ant.apache.org/)

4. [AXIS]Apache Axis — это реализация SOAP («Simple Object Access Protocol»), рекомендованного W3C. (http://ws.apache.org/axis/)

5. [JAVA]Технология Java (http://java.sun.com/)

6. [TOMCAT]Официальная эталонная реализация технологий Servlet 2.4 и JavaServer Pages 2.0. (http://jakarta.apache.org/tomcat/index.html)

7. [XINDICE]Реализация с открытым кодом XML-«базы данных». (http://xml.apache.org/xindice/)

8. [XUPDATE]Язык для изменения XML-документов. (http://xmldb-org.sourceforge.net/xupdate/)

9. [APACHE]Официальный сайт Apache Software Foundation, (www.apache.org)

Приложение А

Структура каталогов диска

Рисунок 10 Структура каталогов диска

§ «Другие проекты» — установочные дистрибутивы используемых технологий (см. раздел «Используемые инструменты»).

§ «Курсовой проект (WebSeller)» — разработанный курсовой проект, включая:

o «Пояснительная записка» — эта пояснительная записка;

o «Плакаты» — разработанные чертежи и плакаты;

o «Артефакты RUP» — разработанные артефакты RUP;

o «Проект WebSeller для Eclipse 3.1.1» — архив проекта WebSeller.

§ «Настроенный Tomcat» — сконфигурированный Tomcat, с установленными сервисами проекта WebSeller.

Приложение Б

Глоссарий

Артефакт Глоссарий также представлен на прилагаемом диске, см. Glossary в каталоге «Артефакты RUP», Приложение А. Структура каталогов диска