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

2. Технологии  Web-служб

1. WSDL

WSDL определяет  диалект XML для описания возможностей  web-служб. При помощи WSDL мы определяем, какие действия может выполнять эта служба – элементы <message/> и <portType/>, какие типы данных используются – элемент <types/>, как клиент будет обращаться к web-службе (по какому протоколу, HTTP, SMTP и т.д.) – элемент <binding/>, и где клиент может найти web-службу, какой у нее URL – за это отвечает элемент <service/>.

2. JAX-RPC

Если описать  основное назначение JAX-PRC в одном предложении, то можно сказать, что этот API определяет правила для преобразования информации WSDL о типах портов в Java и наоборот. Есть несколько простых правил, рассмотрим их ниже.

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.

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

• Основные  типы схемы XML отображаются в основные типы Java
• Структуры XML и составные типы отображаются в JavaBean
• Перечисления преобразуются в public static final методы
• Артефакты WSDL отображаются в соответствующие артефакты Java

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

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.

3. SOAP Handlers

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

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

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

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

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-преобразование).

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

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

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

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