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

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

3. Apache Axis

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

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

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

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

4. 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».

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

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

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

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

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

4. Язык  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.

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. Обоснование технических решений

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

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

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

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

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

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

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