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

Министерство  образования и науки Российской Федерации

Федеральное агентство по образованию

Владимирский  государственный университет

Кафедра информационных систем и информационного  менеджмента

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

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

Выполнил: магистрант гр. ИМр-204

      Гусев Д.И.

Проверил: Александров Д.В.

 
 
 
 
 
 
 
 
Владимир, 2005

 

Содержание

 

1. Введение

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

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

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

В этой пояснительной  записке отражены технические детали разработанного в рамках курсового проекта¹ бизнес-процесса (см. артефакт Vision в каталоге "Артефакты RUP", Приложение А. Структура каталогов диска).

Готовый код  бизнес-процесса, описанного на языке BPEL, а также исходные тексты WSDL-документов и других программных артефактов можно найти на диске, прилагаемом к этому проекту (см. Приложение А. Структура каталогов диска).

Далее мы будем  ссылаться на данное описание системы, и приводить исходные коды с подробными комментариями, где это необходимо.

3. Разработка  по методике 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 к учебному процессу не должно противоречить его принципам для того, чтобы получить желаемые результаты – снизить риски и получить рабочий прототип разрабатываемой программной системы.

4. Функциональная  декомпозиция системы

Далее перечислены  функции, которыми обладают разработанные  сервисы. Развернутые описания прецедентов, включая диаграммы взаимодействия можно найти в артефакте Use Cases (каталог "Артефакты RUP", Приложение А. Структура каталогов диска).

Рисунок 1 Диаграмма вариантов использования

1. Вариант использования: Обработать заказ

• Актант: Внешняя система (Покупатель)
• Краткое описание: На вход нашей системе поступает документ заказа товара. В случае если сумма заказа не превышает некоторой суммы N, установленной магазином, которому принадлежит заказ, этот заказ ставится в очередь и ожидает подтверждения клиентом в магазине. После того, как клиент подтвердил или отменил заказ или истекло время ожидания, заказ удаляется из системы.

2. Вариант использования: Подтвердить  заказ

• Актант: Внешняя  система (Продавец магазина)
• Краткое описание: Покупатель (клиент, оформивший заказ) приходит в магазин и предъявляет удостоверение, номер которого использовался при составлении заказа. Продавец по номеру удостоверения находит заказы, которые зарегистрированы на этого клиента и подтверждает заказ.

3. Вариант использования: Отменить заказ

• Актант: Внешняя  система (Покупатель), Время
• Краткое описание: Клиент может в любое время, которое не превосходит интервала ожидания подтверждения заказа, отменить свой заказ. Также по таймауту наша система может убрать заказ из очереди.

4. Вариант использования: Получить документы заказа клиента

• Актант: Внешняя  система (Покупатель, Продавец магазина)
• Краткое описание: Актант может получить список документов заказа, которые в данный момент находятся в обработке в нашей системе, для определенного клиента, указав идентификатор клиента во внешней системе, который был предоставлен нашей системе в документе заказа.

Термины, выделенные жирным шрифтом описаны в глоссарии; см. Приложение Б. Глоссарий.

5. Структурная организация системы

Разработанную систему можно позиционировать как набор служб для сервис-ориентированной архитектуры. В данной работе реализованы две службы – служба хранения заказов (WebSellerDB) и служба представляющая собой бизнес-процесс обработки заказа (WebSeller), согласно диаграмме активности, представленной в приложении к курсовому проекту.

Внешние интерфейсы к разработанным сервисам оформлены  в виде web-служб, что позволяет интегрировать эти сервисы в другие системы. В связи с этим не ставилось целей разработать целиком архитектуру программной системы, такие как проектирование интерфейса пользователя, проектирование документов заказов конечной системы, в которой будут использоваться разработанные сервисы. Напротив, разработанные структуры данных и интерфейсы позволяют с легкостью интегрировать эти сервисы в уже существующие системы, обеспечивая совместимость на уровне данных (см. раздел «Разработка XML-схемы документа заказа») и на уровне интерфейсов взаимодействия (SOAP over HTTP).

1. Описание  разработанных сервисов

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

1. Сервис  хранения документов заказов (WebSellerDB)

Этот сервис предоставляет функции сохранения, поиска, удаления и изменения некоторых  частей документов заказа (изменение статуса документа заказа). Формат документа заказа описан XML-схемой domain.xsd.

Фактически все  документы заказов хранятся в  базе данных Apache Xindice, которая позволяет хранить коллекции XML-документов.

Данный сервис является вспомогательным и используется сервисом обработки заказов.

2. Сервис  обработки заказов (WebSeller)

Использование данного сервиса предполагает особую организацию процесса покупки товара, когда необходимо, чтобы покупатель подтвердил сделанный им заказ, например, придя в магазин и оплатив покупку. Данный сервис предоставляет все необходимые функции для реализации этого процесса, включая функции подтверждения, отмены заказа или обработка таймаута (см. Activity Diagram в каталоге "Артефакты RUP", Приложение А. Структура каталогов диска).

Данный сервис реализован на языке BPEL и в качестве иллюстрации некоторых возможностей этого языка, в частности обращение к другим BPEL-процессам, в алгоритм работы этого сервиса была включена функция проверки кредитоспособности путем вызова стороннего сервиса, также оформленного в виде web-службы (см. Activity Diagram в каталоге "Артефакты RUP", Приложение А. Структура каталогов диска). Сервис, который эмулирует данную функциональность, можно найти на сайте ActiveBPEL в примерах бизнес-процессов - пример Loan Approval, он также есть в приложении к курсовому проекту на компакт диске (см. all.tar.gz/loan_approval в каталоге "Другие проекты", Приложение А. Структура каталогов диска).

2. Схема данных

Apache Xindice управляет коллекциями документов (см. раздел «Apache Xindice»). Аналогично тому, как в реляционной БД мы определяем набор таблиц, здесь мы должны определиться с иерархией и типом документов, которые будут храниться, для того чтобы составлять запросы к БД, такие как выборка, изменение и др. Схема хранилища документов представлена на рисунке (Рисунок 2 Схема данных БД).

Рисунок 2 Схема данных БД

6. Краткое описание и роль используемых технологий

1. XML-технологии

В данном проекте  XML играет центральную роль. Все задействованные в проекте технологии, так или иначе, связаны с XML. Описание данных предметной области – документов заказа, представлено схемой XML (domain.xsd). Описание интерфейсов web-служб – документы WSDL, также являются документами XML. Даже база данных, используемая в проекте ([XINDICE]) работает не с привычными таблицами реляционной базы данных, а с иерархическими коллекциями XML-документов и языками доступа и управления данными здесь являются XPath и XUpdate ([XUPDATE]). В проекте также используется язык XSLT совместно с утилитой Apache Ant для автоматизации процесса разработки².

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