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

Для запросов, которые лишь изменяют БД, необходимость в SOAP-обработчиках отсутствует и их реализацию можно делать непосредственно в методе класса web-службы.

 
< Пред   СОДЕРЖАНИЕ   Скачать   След >