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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: курсовая работа. Добавлен: 26.04.2012. Сдан: 2011. Страниц: 14. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Министерство  образования и науки Российской Федерации
Федеральное агентство по образованию
Владимирский  государственный университет
Кафедра информационных систем и информационного  менеджмента
Курсовая  работа
Проектирование  сервисов для сервис-ориентированной архитектуры – сервисы online обработки заказа товаров с учетом кредитоспособности покупателя
                Выполнил: магистрант гр. ИМр-204
                      Гусев Д.И.
                Проверил: Александров Д.В.
 
 
 
 
 
 
 
 
Владимир, 2005
 

Содержание
 


    Введение
Тенденции, которые  можно наблюдать на сегодняшний  день, свидетельствуют к переходу на новый уровень проектирования систем – систем с сервис-ориентированной  архитектурой (Service-Oriented Architecture, SOA). И наиболее перспективной технологией, на сегодняшний день, на которой реализуется SOA, является технология web-сервисов. В этой работе будут рассмотрены способы создания web-сервисов с использованием нескольких технологий – JAX-RPC, позволяющая создавать и обращаться к web-службам на платформе Java и BPEL – язык описания бизнес-процессов, построенных на взаимодействии web-служб.
    Постановка  задачи
Цель работы – создание набора web-сервисов, в совокупности предоставляющих службу online обработки заказов товаров, отличительной особенностью которого является поддержка проверки кредитоспособности покупателя и возможность управления статусом заказа. При этом разработанный сервис должен являться абсолютно независимым от других систем, и должен с легкостью интегрироваться в любую сервис-ориентированную архитектуру, которая поддерживает процесс online заказа товара.
В этой пояснительной  записке отражены технические детали разработанного в рамках курсового проекта1 бизнес-процесса (см. артефакт 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 для автоматизации процесса разработки2.
Некоторые из этих технологий являются рекомендациями 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
Метод Когда вызывается
init() Когда создается  цепочка, содержащая данный Handler
cleanup() Когда цепочка, содержащая данный Handler, заканчивает обработку запроса
invoke(MessageContext) Вызывается  для фактической обработки запроса
onFault(MessageContext) Вызывается, когда  Handler выбрасывает исключение
SOAP Handlers можно применять для разных задач, например: журналирование запросов, система безопасности или даже изменение SOAP-сообщения. В интерфейсе Handler также присутствует метод generateWSDL(MessageContext), который вызывается, когда клиент хочет получить WSDL сервиса (например, набрав адрес сервиса в браузере + “?wsdl”).
          Регистрация SOAP Handlers
Файл deployment descriptor позволяет конфигурировать цепочки обработчиков для сервиса элементами <requestFlow>, <responseFlow>, <chain> и <handler> (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 (apache.org/licenses/LICENSE-2.0.html), которая позволяет использовать продукты под этой лицензией в коммерческих целях.
На данный момент под управлением ASF находится около 30 проектов, соответствующих разным направлениям в разработке ПО, от XML проектов до проектов серверных технологий.
В этом курсовом проекте использовались некоторые  проекты ASF – это:
    Jakarta Tomcat – эталонная реализация спецификаций Java Servlet и JSP;
    Apache Axis3 – «контейнер» для web-служб;
    Apache Xindice – XML-«база данных»;
    Дополнительные 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 на официальном сайте (xml.apache.org/xindice/faq.html).
Xindice поддерживает XML:DB API (xmldb-org.sourceforge.net).
Xindice хранит коллекции документов в иерархической форме, так же как хранятся файлы в файловой системе. Xindice предоставляет язык запросов XPath (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:
    XML:DB XML Database API – для создания Xindice-приложений на Java;
    Xindice XML-RPC API – для создания Xindice-приложений на других языках;
    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 (см. webseller\wsdl\domain.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-службы.
        Класс XindiceHelper
Вспомогательный класс net.sf.dmitrygusev.webseller.data.XindiceHelper предоставляет уровень абстракции для работы с сервисами БД, такими как org.xmldb.api.modules.XPathQueryService, org.xmldb.api.modules.XUpdateQueryService и интерфейсом
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.