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

6.2.2.1     Отображение 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.

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

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

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

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

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

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

Элемент <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 и наоборот.

6.2.2.4     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.

6.2.3        SOAP Handlers

Механизм SOAP Handlers позволяет встраивать обработчики для входящих и исходящих SOAP-сообщений. Эти обработчики можно организовывать в цепочки, определив порядок вызова обработчиков во время прохождения запроса.

Axis предоставляет интерфейс org.apache.axis.Handler. Рассмотрим некоторые методы:

Таблица 1 Описание основных методов класса org.apache.axis.Handler

SOAP Handlers можно применять для разных задач, например: журналирование запросов, система безопасности или даже изменение SOAP-сообщения. В интерфейсе Handler также присутствует метод generateWSDL(MessageContext), который вызывается, когда клиент хочет получить WSDL сервиса (например, набрав адрес сервиса в браузере + “?wsdl”).

6.2.3.1     Регистрация SOAP Handlers

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

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

6.3.1        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[3] – «контейнер» для web-служб;
3. Apache Xindice – XML-«база данных»;
4. Дополнительные API и инструменты позволяющие облегчить процесс создания приложений – Apache Ant, Log4j и другие.

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

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

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

6.3.3        Apache Axis

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

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

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

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

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

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

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

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

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

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

6.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. Эти данные уникальным образом идентифицируют процесс и могут изменяться во время выполнения процесса.