Содержание


Проверка корректности SOAP-сообщений Web-сервисов

Использование программы Web Services Validation Tool for WSDL and SOAP

Comments

По всей видимости, с приходом новых технологий и стандартов, таких как XML и HTTP, Web-сервисы обеспечили себе место в пантеоне интернет-инноваций. Но как возникла эта инновация?

Основную концепцию Web-сервисов можно проследить в США до середины 1960-х годов. В транспортной отрасли, например, в железнодорожных и судоходных компаниях, была представлена новая концепция обмена электронными данными между компьютерами, развившаяся далее в технологию EDI (Electronic Data Interchange – обмен электронными данными). Впервые я услышал о EDI от профессора бизнес-школы в 1980 году.

В 1996 году Национальный институт стандартов и технологий США анонсировал стандарт для EDI в издании Federal Information Processing Standards Publications (FIPS PUB 161-2). Согласно опубликованной спецификации, EDI является стандартом обмена строго отформатированными сообщениями между компьютерами. Обработка принимаемых сообщений осуществляется только компьютером, и эти сообщения обычно не предназначены для интерпретации человеком. Это именно то, чем занимаются Web-сервисы, за исключением того, что в середине 1960-х годов не существовало XML, Интернета и World Wide Web.

Для тех, кто не очень знаком с Web-сервисами, я вкратце рассмотрю определения и основные компоненты Web-сервисов.

Что такое Web-сервисы

Web-сервис – это программная система, предназначенная для поддержки межмашинных взаимодействий между вычислительными ресурсами по сети и использующая SOAP-сообщения (Simple Object Access Protocol), определенные консорциумом World Wide Web Consortium.

Simple Object Access Protocol (SOAP) – это простой расширяемый протокол, по которому происходит обмен структурированными и типизированными сообщениями в децентрализованной, распределенной сетевой среде. SOAP-сообщения записываются в формате языка Extensible Markup Language (XML) - простом и гибком текстовом формате, берущем начало от языка Standard Generalized Markup Language (SGML), который был разработан организацией International Organization for Standardization (ISO 8879:1986).

Web Services Description Language (WSDL) – это основанный на XML язык, на котором описывается интерфейс Web-сервисов.

Что произойдет при обмене ошибочными SOAP-сообщениями? Что произошло бы, если бы ошибочное SOAP-сообщение было обработано без предупреждения и даже использовалось для генерирования информации, предназначенной для принятия решения?

На практике невозможно сказать, корректны или нет данные в SOAP-сообщении. Однако можно проверить SOAP-сообщение на корректность, просмотрев его определение интерфейса или WSDL.

В реальной жизни отладить проблемы в SOAP-сообщениях очень непросто. Если в SOAP-сообщении имеется какая-то ошибка, от сервера Web-сервисов принимается код HTTP-ответа 500. Серверы Web-сервисов не предоставляют подробную информацию о том, в какой части SOAP-сообщения имеется проблема. Можно столкнуться с еще худшей ситуацией, когда от сервера Web-сервисов принимаются корректные SOAP-ответы без каких-либо сообщений об ошибках, и ни вы, ни ваши серверы Web-сервисов не могут понять проблемы в ваших SOAP-запросах и ответах. Например, вы хотели запросить текущие котировки акций компании B, но отправили на сервер Web-сервисов SOAP-сообщение с неправильно написанными тегами. Сервер Web-сервисов может проигнорировать неправильные теги и предоставить в ответном SOAP-сообщении значение по умолчанию, например, котировку акций компании A. Если это остается незамеченным, последствия могут быть катастрофическими.

Проблемы такого типа можно заблаговременно предотвратить при помощи инструмента Web Services Validation Tool for WSDL and SOAP. Он позволяет проверять корректность SOAP-сообщений, используя язык Web Service Definition Language (WSDL), еще до развертывания приложений, использующих Web-сервис. Программа анализирует синтаксис и корректность ваших SOAP-сообщений с WSDL и указывает на проблемы, подробно сообщая об ошибках и номерах строк. В результате вы больше не получаете раздражающие сообщения HTTP 500. Ваши SOAP-сообщения зашифрованы? Нет проблем. Программа дешифрует их и проверит для вас корректность дешифрованных SOAP-сообщений.

Эта программа была создана в помощь сотрудникам отдела поддержки IBM Web Services, решающим связанные с Web-сервисами проблемы на сервере IBM® WebSphere Application Server, о которых сообщают клиенты со всего мира. Программа предназначена для проверки корректности SOAP-сообщений. Если SOAP-сообщение имеет цифровую подпись, программа проверит и ее. С помощью Web Services Validation Tool for WSDL and SOAP можно даже отправлять SOAP-сообщения на серверы Web-сервисов и принимать ответные SOAP-сообщения. Программа была создана для того, чтобы исключить проблемы при промышленной эксплуатации за счет использования ее на ранних стадиях разработки, а также для того, чтобы уменьшить время решения проблем, возникающих в процессе эксплуатации.

Мы создадим очень простой Web-сервис. Сначала мы создадим простое Java™-приложение. После проверки работы Java-приложения мы с помощью IBM Rational® Application Developer for WebSphere® Software сгенерируем Web-сервис. Затем мы внесем некоторые изменения в сгенерированный Web-сервис. Наконец, мы используем программу Web Services Validation Tool for WSDL and SOAP для создания, проверки, передачи и приема SOAP-сообщений.

Простой Web-сервис можно создать при помощи программы IBM Rational Application Developer for WebSphere Software. Web-сервисы можно создавать двумя путями:

  1. Разработка "сверху вниз" (top-down) разработка, при которой Java-классы, реализующие Web-сервисы, генерируются из WSDL.
  2. Разработка "снизу вверх" (bottom-up), при которой Web-сервис генерируется из Java bean-компонента или корпоративного Java bean-компонента.

В следующем примере мы реализуем Web-сервис, используя метод разработки снизу вверх. Сначала мы создадим простое Java-приложение. Затем мы сгенерируем Web-сервис Java bean-компонента из Java-приложения, используя программу IBM Rational Application Developer for WebSphere Software.

Создание Java-приложения

Сначала мы создадим Java-приложение, выдающее приветствие. Если имя не указано, приложение возвратит текст "Hello, buddy!". Если имя указано, приложение возвратит текст "Hello,", за которым следует это имя. Ниже приведен код Java-приложения DemoWebService, находящегося в демонстрационном пакете. Метод hello() возвращает строку, зависящую от имени.

Листинг 1. DemoWebService.java
 /*
 * @author: Jinwoo Hwang
 * Copyright 2010 IBM Corporation
 */

package demo;

public class DemoWebService {
	public String hello(String name) {
		if (name == null)
			return "Hello, buddy!";
		else
			return "Hello, " + name + "!";
	}
}

Тестирование Java-приложения

Очень важно протестировать Java-приложение перед созданием из него Web-сервиса. Для запуска приложения можно написать класс с методом main(). Можно также использовать функциональность Universal Test Client, предоставляемую продуктом IBM Rational Application Developer v7, для быстрого тестирования без написания тестового кода. Достаточно просто выбрать Universal Test Client из контекстного меню Java-класса для запуска Test Client.

  1. В Universal Test Client разверните Objects > DemoWebService.
  2. Выберите метод hello.
  3. Введите строку или ваше имя в поле Value и нажмите кнопку Invoke.
Рисунок 1. Universal Test Client
Рисунок 1. Universal Test Client
Рисунок 1. Universal Test Client

Можно также выполнить тест, указав параметр null, и посмотреть, что произойдет. Если в метод hello() передается параметр null, возвращается строка "Hello, buddy!", как и ожидалось.

Рисунок 2. Universal Test Client с параметром null
Рисунок 2. Universal Test Client с параметром null
Рисунок 2. Universal Test Client с параметром null

Создание Web-сервиса

Пока все работает хорошо. Приступим к генерированию Web-сервиса из Java-класса, используя метод разработки Web-сервисов снизу вверх.

  1. Выберите Java-приложение DemoWebService и создайте новый Web-сервис из IBM Rational Application Developer.
Рисунок 3. Создание нового XML Web-сервиса
Рисунок 3. Создание нового XML Web-сервиса
Рисунок 3. Создание нового XML Web-сервиса
  1. Поскольку мы создали Java-класс, выберите Bottom up Java bean Web service в списке Web service type. Выберите Start client и нажмите кнопку Finish. Если бы у нас был EJB-класс, мы могли бы также написать EJB-компонент (Java Enterprise bean) для генерирования Web-сервиса.
Рисунок 4. Выбор реализации сервиса
Рисунок 4. Выбор реализации сервиса
Рисунок 4. Выбор реализации сервиса

Если все прошло нормально, вы увидите в Java Resources рядом с DemoWebService.java сгенерированный DemoWebServiceDelegate.java.

Рисунок 5. DemoWebService.java
Рисунок 5. DemoWebService.java
Рисунок 5. DemoWebService.java

При просмотре DemoWebServiceDelegate.java можно обнаружить аннотацию Java Web-сервиса @javax.jws.WebService, которая указывает targetNamespace, serviceName и portName в классе DemoWebServiceDelegate. Создается экземпляр DemoWebService и из метода hello()DemoWebService создается другой метод hello(). При желании более подробно узнать об аннотациях Java Web-сервисов обратитесь к документу Java Specification Request(JSR) 181. Метаданные Web-сервисов для платформы Java.

Листинг 2. DemoWebServiceDelegate.java
/*
 * @author: Jinwoo Hwang
 * Copyright 2010 IBM Corporation
 */
package demo;

@javax.jws.WebService(targetNamespace = "http://demo/", 
        serviceName = "DemoWebServiceService", 
        portName = "DemoWebServicePort")
public class DemoWebServiceDelegate {

	demo.DemoWebService _demoWebService = new demo.DemoWebService();

	public String hello(String name) {
		return _demoWebService.hello(name);
	}

}

Создание WSDL

В проекте клиентской программы можно также обнаружить, что были сгенерированы файлы DemoWebServiceService.wsdl и DemoWebServiceService_schema1.xsd. DemoWebServiceService.wsdl содержит информацию на языке Web Service Definition Language, описывающую сетевые сервисы для созданного ранее Java-приложения. DemoWebServiceService_schema1.xsd содержит XML-схему, описывающую структуру типов данных, использующихся в SOAP-сообщениях.

Рисунок 6. DemoWebServiceService.wsdl
Рисунок 6. DemoWebServiceService.wsdl
Рисунок 6. DemoWebServiceService.wsdl

При просмотре файла DemoWebServiceService.wsdl можно увидеть, что он имеет в корне набор элементов определений (definitions element). В элементе определений имеются 6 элементов:

  • types (типы);
  • message (сообщение);
  • portType (тип порта);
  • binding (связывание);
  • service (сервис);
  • port (порт).

Types определяет типы данных, используемые при обмене сообщениями. В DemoWebServiceService.wsdl мы импортируем DemoWebServiceService_schema1.xsd вместо определения типов данных в WSDL-файле.

Message определяет сообщения, обмен которыми происходит. У нас есть 2 сообщения: "hello" и "helloResponse". Сообщение hello имеет часть, называемую "parameters". Эта часть имеет элемент "tns:hello". Сообщение helloResponse имеет часть, называемую "parameters", которая аналогична hello. Эта часть имеет элемент "tns:helloResponse". Элементы hello и helloResponse определяются в файле DemoWebServiceService_schema1.xsd. Мы вскоре их рассмотрим.

Port Type – поддерживаемые оконечными точками операции. Каждая операция предоставляет входное и выходное сообщения. Наша операция "hello" состоит из входного сообщения "tns:hello" и выходного сообщения "tns:helloResponse". Эти операции соответствуют обмену запрос-ответ. WSDL предоставляет 4 различных примитива обмена для оконечной точки:

  • one-way (однонаправленный);
  • request-response (запрос-ответ);
  • solicit-response (требование-ответ);
  • notification (уведомление).

При однонаправленном обмене оконечная точка только принимает сообщение. При обмене "запрос-ответ" оконечная точка принимает сообщение и отправляет соответствующее сообщение. При обмене «требование-ответ» оконечная точка отправляет сообщение и принимает соответствующее сообщение. При обмене "уведомление" оконечная точка только отправляет сообщение.

Binding определяет детали протокола и спецификации формата сообщений для операций и сообщений, определяемых типом порта. Для атрибута style у нас используется значение document. Атрибут style предоставляет 2 различных стиля сообщения: rpc и document. В стиле rpc сообщения содержат параметры и возвращаемые значения. В стиле document сообщения содержат документы. В атрибуте transport указывается URI для транспортировки SOAP. Указанное значение http://schemas.xmlsoap.org/soap/http означает, что в спецификации SOAP будет использоваться HTTP-связывание. URI для HTTP-заголовка SOAPAction для HTTP-связывания SOAP указывается в атрибуте soapAction. Поскольку используется HTTP-связывание SOAP, значение атрибута soapAction является обязательным. Для атрибута soapAction мы используем пустую строку "". Элемент soap:body определяет, как компонуются части сообщения внутри элемента body SOAP-сообщения. Атрибут use предоставляет 2 различных варианта: literal (литерал) и encoded (закодированный). Мы используем literal. Это означает, что мы выбрали определение конкретной схемы, используя либо атрибут type, либо элемент. При использовании варианта encoded применяется тип abstract с правилами кодирования.

Service определяет набор используемых портов.

Port определяет оконечную точку коммуникации, указывая сетевой адрес для связывания.

сетевой адрес для связывания. В нашем случае адресом оконечной точки SOAP является http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.

Листинг 3. DemoWebServiceService.wsdl
<?xml version="1.0" encoding="UTF-8"?> 
<definitions name="DemoWebServiceService" targetNamespace="http://demo/"
	xmlns="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
	xmlns:tns="http://demo/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<types>
		<xsd:schema>
			<xsd:import namespace="http://demo/" 
                schemaLocation="DemoWebServiceService_schema1.xsd" />
		</xsd:schema>
	</types>
	<message name="hello">
		<part element="tns:hello" name="parameters" />
	</message>
	<message name="helloResponse">
		<part element="tns:helloResponse" name="parameters" />
	</message>
	<portType name="DemoWebServiceDelegate">
		<operation name="hello">
			<input message="tns:hello" />
			<output message="tns:helloResponse" />
		</operation>
	</portType>
	<binding name="DemoWebServicePortBinding" type="tns:DemoWebServiceDelegate">
		<soap:binding style="document"
			transport="http://schemas.xmlsoap.org/soap/http" />
		<operation name="hello">
			<soap:operation soapAction="" />
			<input>
				<soap:body use="literal" />
			</input>
			<output>
				<soap:body use="literal" />
			</output>
		</operation>
	</binding>
	<service name="DemoWebServiceService">
		<port binding="tns:DemoWebServicePortBinding" name="DemoWebServicePort">
			<soap:address
				location=
                "http://localhost:9081/HelloWorldWSProject/DemoWebServiceService" />
		</port>
	</service>
</definitions>

Создание схемы

Мы импортируем DemoWebServiceService_schema1.xsd из DemoWebServiceService.wsdl. Рассмотрим файл DemoWebServiceService_schema1.xsd. Он написан на языке определения XML Schema для описания структуры и ограничений содержимого XML-документов. У нас есть 2 элемента: hello и helloResponse. Каждый элемент имеет тип. Тип hello имеет элемент "arg0", являющийся строкой. Элемент "arg0" является необязательным, поскольку значение атрибута minOccurs в его объявлении равно 0. Если для атрибута minOccurs задано значение 1 или больше, элемент необходимо указывать. То же касается элемента "return" в типе helloResponse.

Листинг 4. DemoWebServiceService_schema1.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://demo/" version="1.0"
	xmlns:tns="http://demo/" xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:element name="hello" type="tns:hello" />

	<xs:element name="helloResponse" type="tns:helloResponse" />

	<xs:complexType name="hello">
		<xs:sequence>
			<xs:element minOccurs="0" name="arg0" type="xs:string" />
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="helloResponse">
		<xs:sequence>
			<xs:element minOccurs="0" name="return" type="xs:string" />
		</xs:sequence>
	</xs:complexType>
</xs:schema>

Начало работы с программой Web Services Validation Tool for WSDL and SOAP

Итак, мы рассмотрели WSDL и схему. Давайте запустим сервер Web-сервисов, чтобы можно было активизировать Web-сервис из программы Web Services Validation Tool for WSDL and SOAP.

Для запуска программы Web Services Validation Tool for WSDL and SOAP необходима среда времени исполнения Java 6 (или выше) и API цифрового кодирования и декодирования XML, соответствующие спецификациям консорциума World Wide Web Consortium "XML Encryption Syntax and processing" (http://www.w3.org/TR/xmlenc-core/).

IBM Java 6 предоставляет реализацию JSR 106: XML Digital Encryption APIs. Если у вас установлена система IBM Java 6, значит, все готово для работы и устанавливать больше ничего не нужно.

Если в вашей среде времени исполнения Java 6, например, Sun Microsystems™ Java 6, нет XML Digital Encryption APIs, необходимо установить библиотеки, реализующие JSR 106, или пакет Apache™ XML Security version 1.4.3, который можно скачать по адресу http://santuario.apache.org/. Достаточно просто загрузить двоичный дистрибутив, разархивировать его в каталог и указать инструментальной программе, где находится этот каталог, используя параметры командной строки -vmargs и -DAXS.

На момент написания данной статьи программа Web Services Validation Tool for WSDL and SOAP поддерживала JSR 106 и Apache XML Security version 1.4.3 для XML Digital Encryption and Decryption. Если вы хотите проверять цифровые подписи в SOAP-сообщениях, вам необходимы библиотеки, реализующие JSR 105: XML Digital Signature APIs. К счастью, виртуальные машины Java 6 от Sun Microsystems и IBM предоставляют реализации JSR 105. Именно поэтому Java 6 был выбран в качестве минимального требования к среде времени исполнения Java. Если ваша среда Java 6 не предоставляет библиотек, реализующих JSR 105, вам необходимо их найти.

Программу Web Services Validation Tool for WSDL and SOAP можно скачать по адресу http://www.alphaworks.ibm.com/tech/wsvt бесплатно. Установка ее очень проста. Разархивируйте пакет в каталог и запустите wsvt.exe. Если ваша виртуальная машина Java по умолчанию не является средой Java 6, поддерживающей цифровые подписи XML и цифровое шифрование и дешифрование, необходимо указать месторасположение Java 6 с параметром -vm, например:

wsvt –vm c:\IBMjava6\bin\java.exe

Опять-таки, если у вас есть IBM Java 6, больше ничего устанавливать не нужно. Все необходимое уже включено в IBM Java 6. При использовании Java 6 от Sun Microsystems необходимо указать программе месторасположение Apache XML Security для дешифрования зашифрованных SOAP-сообщений.

Например, следующая команда запустит программу с Sun Java 6 и Apache XML Security library version 1.4.3, расположенную в каталоге C:\xml-security-1_4_3\libs:

wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs

Ниже приведен список файлов библиотеки Apache XML security, фактически использующихся программой Web Services Validation Tool for WSDL and SOAP, хотя Apache XML security version 1.4.3 поставляется с 9-ю jar-файлами:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.

В MANIFEST.MF программы Web Services Validation Tool for WSDL and SOAP указана следующая информация:
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: .,
external:$AXS$/commons-logging.jar,
external:$AXS$/serializer.jar,
external:$AXS$/xalan.jar,
external:$AXS$/xmlsec-1.4.3.jar

Вот почему было необходимо указывать –vmargs –DAXS=C:\xml-security-1_4_3\libs, чтобы среда Sun Java 6 дешифровала зашифрованные SOAP-сообщения.

Я потратил довольно много времени на устранение конфликтов загрузки классов и несовместимостей среди относящихся к XML классов, находящихся в среде времени выполнения Sun Java, Apache XML Security и некоторых плагинах Eclipse. Настройка среды времени исполнения IBM Java прошла без труда, поскольку эта среда поставляется с реализацией JSR 106 и не требует Apache XML Security.

Создание проекта

Теперь, после настройки и запуска инструментальной программы, можно создать новый проект. В проекте могут содержаться WSDL-файл, несколько файлов схемы, ассоциированных с WSDL-файлом, и SOAP-сообщения в XML-файлах. Если в проекте имеется несколько WSDL-файлов, используется только один из них, а другие игнорируются при проверке корректности XML-файла SOAP-сообщения. Для использования другого WSDL-файла необходимо создать отдельный проект. Каждое SOAP-сообщение должно содержаться в файле с расширением .xml, иначе оно не будет рассматриваться как SOAP-сообщение.

  1. Щелкните правой кнопкой мыши и выберите New > Project.
Рисунок 7. Создание нового проекта
Рисунок 7. Создание нового проекта
Рисунок 7. Создание нового проекта
  1. Выберите Project в General.
Рисунок 8. Выбор мастера
Рисунок 8. Выбор мастера
Рисунок 8. Выбор мастера
  1. Введите "Test Project" в поле Project name и нажмите кнопку Finish.
Рисунок 9. Имя проекта
Рисунок 9. Имя проекта
Рисунок 9. Имя проекта

Импорт WSDL и схемы

Мы создали проект "Test Project". Теперь в него можно импортировать WSDL и XSD.

  1. Выберите проект, а затем из контекстного меню выберите Import.
Рисунок 10. Импорт
Рисунок 10. Импорт
Рисунок 10. Импорт
  1. Выберите File System в General.
Рисунок 11. Выбор источника импорта
Рисунок 11. Выбор источника импорта
Рисунок 11. Выбор источника импорта
  1. Выберите каталог, в котором хранятся WSDL и XSD.
  2. Выберите 2 файла (DemoWebServiceService.wsdl и DemoWebServiceService_schema1.xsd) и нажмите кнопку Finish.
Рисунок 12. Импорт из файловой системы
Рисунок 12. Импорт из файловой системы
Рисунок 12. Импорт из файловой системы

Обзор WSDL и схемы

Теперь у нас есть проект с WSDL и XSD. Можно дважды щелкнуть левой кнопкой мыши на WSDL для просмотра WSDL в режиме Design (проектирование) и Source (исходный код). В режиме Design можно визуализировать Web-сервис с входными и выходными данными.

Рисунок 13. Режим Design
Рисунок 13. Режим Design
Рисунок 13. Режим Design

В режиме Source можно просматривать и редактировать WSDL в текстовом редакторе.

Рисунок 14. Режим Source
Рисунок 14. Режим Source
Рисунок 14. Режим Source

Если XSD-файлы нельзя открыть в XSD-редакторе, их можно открыть в XML-редакторе, выбрав Open With > XML Editor в контекстном меню этого XSD-файла.

Рисунок 15. Открытие в XML-редакторе
Рисунок 15. Открытие в XML-редакторе
Рисунок 15. Открытие в XML-редакторе

Мы открыли DemoWebServiceService_schema1.xsd в XML-редакторе.

Рисунок 16. XML-редактор
Рисунок 16. XML-редактор
Рисунок 16. XML-редактор

Создание SOAP-сообщения

Итак, у нас есть WSDL и схема, готовые для проверки корректности SOAP-сообщений. Приступим к тестированию программы Web Services Validation Tool for WSDL and SOAP с SOAP-сообщением. Необходимо включить SOAP-сообщение в проект. SOAP-сообщение должно содержаться в файле с расширением .xml, чтобы можно было проверить его корректность.

  1. Выберите New > XML для создания SOAP-сообщения в проекте.
Рисунок 17. Новый XML
Рисунок 17. Новый XML
Рисунок 17. Новый XML
  1. Выберите Test Project для родительской папки нового SOAP-сообщения. Если файл еще не выбран, введите "DemoSOAPMessage.xml" в поле File name и нажмите кнопку Finish.
Рисунок 18. Ввод родительской папки
Рисунок 18. Ввод родительской папки
Рисунок 18. Ввод родительской папки

Программа автоматически вызывает XML-редактор с новым XML-файлом. В нем нет ничего, кроме строки с версией и кодировкой xml. Хорошо, что у нас есть хоть что-нибудь до начала создания SOAP-сообщения с нуля. Вы знаете, как составлять SOAP-сообщение? Не беспокойтесь. В следующем разделе мы по шагам рассмотрим действия по его созданию.

Рисунок 19. Новый XML-файл
Рисунок 19. Новый XML-файл
Рисунок 19. Новый XML-файл

Для создания SOAP-сообщения можно активизировать "hello" сервиса, используя параметр "parameters" с указанием моего имени - "Jinwoo". Конечно же, вы можете использовать свое собственное имя. Используется пространство имен http://demo/. Будьте внимательны - оно пишется как http://demo/, а не http://demo, это существенно.

Листинг 5. HelloWorldSOAPmessage.xml
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ns0="http://demo/">
	<soapenv:Body>
		<ns0:hello>
			<parameters>Jinwoo</parameters>
		</ns0:hello>
	</soapenv:Body>
</soapenv:Envelope>

Вы видите в этом SOAP-сообщении проблемы? Если да, не беспокойтесь. Мы разберемся с этим позже.

Рисунок 20. DemoSOAPMessage.xml
Рисунок 20. DemoSOAPMessage.xml
Рисунок 20. DemoSOAPMessage.xml

Передача SOAP-сообщения

Вы готовы отправить сообщение на сервер Web-сервисов?

  1. Выберите SOAP-сообщение и выберите Transmit SOAP Request and Receive SOAP Response в программе Web Services Validation Tool for WSDL and SOAP.
Рисунок 21. Отправка SOAP-запроса и получение SOAP-ответа
Рисунок 21. Отправка SOAP-запроса и получение SOAP-ответа
Рисунок 21. Отправка SOAP-запроса и получение SOAP-ответа
  1. В окне Transmit SOAP Request and Receive SOAP Response можно заполнить Service Address, SOAPAction и Content-Type. В данном приложении нам не нужно указывать SOAPAction, поскольку мы использовали пустую строку "" для атрибута soapAction в разделе связывания файла DemoWebServiceService.wsdl.
  2. Введите http://localhost:9081/HelloWorldWSProject/DemoWebServiceService в поле Service Address, если сервер работает на локальном компьютере на порту localhost:9081. В противном случае необходимо ввести реальный адрес, по которому доступен Web-сервис.
  3. Выберите text/html для поля Content-Type.
  4. Нажмите кнопку OK для отправки SOAP-сообщения на сервер.
Рисунок 22. Ввод адреса оконечной точки сервиса
Рисунок 22. Ввод адреса оконечной точки сервиса
Рисунок 22. Ввод адреса оконечной точки сервиса

Прием SOAP-сообщения

Если сервер настроен и работает, вы должны получить SOAP-ответ. Если ответ не приходит, проверьте корректность адреса и типа содержимого.

Рисунок 23. Ответ
Рисунок 23. Ответ
Рисунок 23. Ответ

Проверка корректности SOAP-сообщения

Отлично! Мы приняли SOAP-ответ. Он также сохраняется в проекте. Но подождите. Вы видите, что что-то не так? Мы получили "Hello, buddy!" вместо "Hello, Jinwoo!". Что пошло не так? Не имеете понятия?

К сожалению, сервер Web-сервисов не позволил нам узнать, что было не так. Никаких предупреждений. Ситуация, когда отправляются непредсказуемые SOAP-ответы и сервер Web-сервисов не имеет понятия, что происходит не так, может быть очень опасной. Даже получатели SOAP-ответов могут не заметить проблем в рассматриваемом SOAP-сообщении.

Инструмент Web Services Validation Tool for WSDL and SOAP позволяет определить, что происходит не так.

Листинг 6. Ответ
<?xml version="1.0" encoding="UTF-8"?>
        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns2:helloResponse xmlns:ns2="http://demo/">
      <return>Hello, buddy!</return>
    </ns2:helloResponse>
  </soapenv:Body>
</soapenv:Envelope>

Далее будет продемонстрировано, как проверить корректность файла DemoSOAPMessage.xml и определить наличие проблем в SOAP-ответе.

  1. Выберите ответное SOAP-сообщение и нажмите кнопку Validate.
Рисунок 24. Проверка корректности ответного SOAP-сообщения
Рисунок 24. Проверка корректности ответного SOAP-сообщения
Рисунок 24. Проверка корректности ответного SOAP-сообщения

Программа Web Services Validation Tool for WSDL and SOAP нашла ошибку в SOAP-сообщении.

Invalid SOAP message:cvc-complex-type.2.4.a:Invalid
content was found starting with element 'parameters'. One of '{arg0} is expected.
Рисунок 25. Ошибочное SOAP-сообщение
Рисунок 25. Ошибочное SOAP-сообщение
Рисунок 25. Ошибочное SOAP-сообщение

Редактирование SOAP-сообщения

  1. Программа жалуется на значение "parameters". Измените его на arg0 и сохраните.
Листинг 7. Измененное SOAP-сообщение
<?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 	
        xmlns:ns0="http://demo/">
	<soapenv:Body>
		<ns0:hello>
			<arg0>Jinwoo</arg0>
		</ns0:hello>
	</soapenv:Body>
</soapenv:Envelope>
  1. Проверьте корректность модифицированного ответного SOAP-сообщения. Больше никаких сообщений об ошибках не появляется.
Рисунок 26. Редактирование SOAP-сообщения
Рисунок 26. Редактирование SOAP-сообщения
Рисунок 26. Редактирование SOAP-сообщения
  1. Теперь мы готовы отправить модифицированное ответное сообщение на сервер. Выберите SOAP-сообщение, а затем выберите Transmit SOAP Request and Receive SOAP Response.
Рисунок 27. Передача SOAP-запроса и прием SOAP-ответа
Рисунок 27. Передача SOAP-запроса и прием SOAP-ответа
Рисунок 27. Передача SOAP-запроса и прием SOAP-ответа
  1. В окне Transmit SOAP Request and Receive SOAP Response введите http://localhost:9081/HelloWorldWSProject/DemoWebServiceService в поле Service Address, если сервер работает на порту localhost:9081.
  2. Выберите text/html для поля Content-Type и нажмите кнопку OK.
Рисунок 28. Передача SOAP-запроса
Рисунок 28. Передача SOAP-запроса
Рисунок 28. Передача SOAP-запроса

В этот раз, как и ожидалось, приходит правильный ответ.

Рисунок 29. Корректный ответ
Рисунок 29. Корректный ответ
Рисунок 29. Корректный ответ
Листинг 8. SOAP-ответ
<?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns2:helloResponse xmlns:ns2="http://demo/">
      <return>Hello, Jinwoo!</return>
    </ns2:helloResponse>
  </soapenv:Body>
</soapenv:Envelope>

Обнаружение неправильного пространства имен

Что произойдет, если отправить сообщение с неправильным пространством имен?

  1. Измените пространство имен на http://demo2/ и сохраните сообщение.
Рисунок 30. Изменение пространства имен
Рисунок 30. Изменение пространства имен
Рисунок 30. Изменение пространства имен
Листинг 9. Изменение пространства имен
<?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 	
    xmlns:ns0="http://demo2/">
	<soapenv:Body>
		<ns0:hello>
			<arg0>Jinwoo</arg0>
		</ns0:hello>
	</soapenv:Body>
</soapenv:Envelope>
  1. Затем можно отправить запрос на сервер.
Рисунок 31. Отправка сообщения
Рисунок 31. Отправка сообщения
Рисунок 31. Отправка сообщения

Вы увидите исключительную ситуацию IOException: Server returned HTTP response code:500 for URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.

Рисунок 32. IOException
Рисунок 32. IOException
Рисунок 32. IOException

Сервер Web-сервисов передал в ответе информацию об исключительной ситуации IOException, но этой информации недостаточно для обнаружения ошибки. Проверьте корректность сообщения при помощи инструментальной программы, если хотите получить более подробные данные для решения проблемы.

Рисунок 33. Проверка корректности сообщения
Рисунок 33. Проверка корректности сообщения
Рисунок 33. Проверка корректности сообщения

Программа сообщает: "Invalid SOAP message:cvc-complex-type.2.4.a:Invalid content was found starting with element ‘ns0:hello'. One of '{"http://demo/":hello,"http://demo/":helloResponse}' is expected".

Это сообщение указывает, что ожидается значение http://demo/. Именно это, а не HTTP-код ответа 500, нам нужно узнать.

Рисунок 34. Некорректное SOAP-сообщение
Рисунок 34. Некорректное SOAP-сообщение
Рисунок 34. Некорректное SOAP-сообщение

Проверка корректности зашифрованных SOAP-сообщений

Что если ваши SOAP-сообщения зашифрованы? Никаких проблем, если у вас имеются ключи и пароли. Просто выберите SOAP-сообщение и Validate точно так же, как это делается для любых других обычных SOAP-сообщений. Если ваше SOAP-сообщение зашифровано, на экране появится запрос, аналогичный показанному на рисунке 35.

Рисунок 35. Выбор хранилища ключей
Рисунок 35. Выбор хранилища ключей
Рисунок 35. Выбор хранилища ключей

На момент написания данной статьи поддерживается 3 типа хранилищ ключей (keystore):

  1. Java Key Store (JKS).
  2. Java Cryptography Extension Key Store (JCEKS).
  3. Personal Information Exchange Syntax Standard (Public Key Cryptography Standards #12).

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

Рисунок 36. Выбор ключа
Рисунок 36. Выбор ключа
Рисунок 36. Выбор ключа

Если вся информация верна, программа сгенерирует дешифрованное SOAP-сообщение и проверит его корректность.

Рисунок 37. Дешифрованное SOAP-сообщение
Рисунок 37. Дешифрованное SOAP-сообщение
Рисунок 37. Дешифрованное SOAP-сообщение

В настоящее время поддерживаются следующие алгоритмы шифрования:

  • Advanced Encryption Standard (AES) в режиме Cipher Block Chaining (CBC) с вектором инициализации (128/192/256 битов).
  • Advanced Encryption Standard (AES) Key Encryption (128/192/256 битов).
  • Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption.
  • Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption в режиме Cipher Block Chaining (CBC).
  • RSA Cryptography Specifications Version 1.5.
  • RSA Optimal Asymmetric Encryption Padding (OAEP) – метод с функцией генерирования маски.

Проверка корректности SOAP-сообщений с цифровой подписью

Что если ваше SOAP-сообщение имеет цифровую подпись? Просто выберите SOAP-сообщение, а затем выберите SOAP Message Digital Signature Verification.

Рисунок 38. SOAP Message Digital Signature Verification
Рисунок 38. SOAP Message Digital Signature Verification
Рисунок 38. SOAP Message Digital Signature Verification

Если цифровая подпись корректна, вы увидите следующий экран:

Рисунок 39. Корректная цифровая подпись SOAP-сообщения
Рисунок 39. Корректная цифровая подпись SOAP-сообщения
Рисунок 39. Корректная цифровая подпись SOAP-сообщения

В противном случае программа сообщит об ошибке в подписи. В настоящее время поддерживаются следующие спецификации и алгоритмы цифровых подписей:

  • Secure Hash Algorithm 1 (SHA-1)
  • Hash Message Authentication Code (HMAC)
  • Digital Signature Algorithm (DSA)
  • Public-Key Cryptography Standards (PKCS #1)
  • RSA Encryption Algorithm with Secure Hash Algorithm (SHA-1)
  • Canonical XML Version 1.0 and 1.1
  • XSL Transformations (XSLT) Version 1.0
  • XML Path Language (XPath) Version 1.0
  • Base64

Доступ к сервису Национального метеобюро США с использованием SOAP-сообщения

Созданный и протестированный нами простой Web-сервис работает нормально. Можно ли использовать данную программу в "реальной" среде? Можно попробовать поработать с реальным Web-сервисом Национального метеобюро США, предоставляемым организацией U.S. National Oceanic and Atmospheric Administration (NOAA).

  1. Создайте проект.
Рисунок 40. Создание проекта
Рисунок 40. Создание проекта
Рисунок 40. Создание проекта
  1. Создайте XML-код SOAP-сообщения.
Рисунок 41. Ввод родительской папки
Рисунок 41. Ввод родительской папки
Рисунок 41. Ввод родительской папки
Рисунок 42. Новый XML-файл
Рисунок 42. Новый XML-файл
Рисунок 42. Новый XML-файл

Национальное метеобюро США поддерживает базу данных National Digital Forecast Database (NDFD), к которой можно обратиться посредством Web-сервиса SOAP (Simple Object Access Protocol). Подробная информация приведена по адресу http://www.weather.gov/forecasts/xml/.

Национальное метеобюро США предоставляет много разных Web-сервисов. Можно попробовать поработать с сервисом NDFDgenByDay, предоставляющим прогнозы погоды для точки с заданной широтой и долготой.

Для доступа к NDFDgenByDay необходимо предоставить следующую информацию:

Таблица 1. NDFDgenByDay
Service Name (имя сервиса)NDFDgenByDay
Endpoint (оконечная точка)http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (SOAP-действие)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
encodingStyle (стиль кодирования)http://schemas.xmlsoap.org/soap/encoding/
Namespace (пространство имен)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
latitude (широта)Десятичное число
longitude (долгота)Десятичное число
startDate (начальная дата)Дата
numDays (количество дней)Целое число
format (формат)Строка

В данном примере мы хотим создать SOAP-запрос на получение недельного прогноза для местности с координатами (LAT38.9,LON-77.01), начиная с 2010-07-23 в 24-часовом формате:

Листинг 10. SOAP-запрос
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
	<SOAP-ENV:Body>
		<ns6244:NDFDgenByDay>
			<latitude xsi:type="xsd:string">38.99</latitude>
			<longitude xsi:type="xsd:string">-77.01</longitude>
			<startDate xsi:type="xsd:string">2010-07-23</startDate>
			<numDays xsi:type="xsd:string">7</numDays>
			<format xsi:type="xsd:string">24 hourly</format>
		</ns6244:NDFDgenByDay>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Мы не указывали пространство имен, потому что сервис работал без него. Если с пространством имен возникнут какие-либо проблемы, задайте его.

Рисунок 43. Пространство имен SOAP
Рисунок 43. Пространство имен SOAP
Рисунок 43. Пространство имен SOAP

Выберите сообщение и Transmit SOAP Request and Receive SOAP Response в программе Web Services Validation Tool for WSDL and SOAP.

Таблица 2. Запрос информации
ИмяЗначение
Endpoint (оконечная точка) http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (SOAP-действие) http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
Content-type (тип содержимого)text/xml; charset=utf-8
Рисунок 44. Отправка запроса
Рисунок 44. Отправка запроса
Рисунок 44. Отправка запроса

Итак, мы получили данные с прогнозом погоды из сервиса Национального метеобюро США! Однако их непросто прочитать из-за специальных HTML-объектов.

Рисунок 45. Ответное сообщение
Рисунок 45. Ответное сообщение
Рисунок 45. Ответное сообщение

Можно изменить расширение файла на .html и просмотреть его в Web-браузере.

Рисунок 46. Переименование xml-файла
Рисунок 46. Переименование xml-файла
Рисунок 46. Переименование xml-файла
Рисунок 47. Новое имя
New name
New name

Откройте полученный HTML в Web-браузере.

Рисунок 48. Открытие в Web-браузере
Рисунок 48. Открытие в Web-браузере
Рисунок 48. Открытие в Web-браузере

Теперь можно увидеть полученные XML-данные. Однако все равно содержимое читать тяжело из-за отсутствия форматирования.

Рисунок 49. Выходные XML-данные
Рисунок 49. Выходные XML-данные
Рисунок 49. Выходные XML-данные

Можно просто скопировать содержимое и создать новый XML-документ для форматирования.

Рисунок 50. Копирование XML
Рисунок 50. Копирование XML
Рисунок 50. Копирование XML

Создайте новый XML-файл, скопируйте в него содержимое и выполните форматирование.

Рисунок 51. Новый XML-файл
Рисунок 51. Новый XML-файл
Рисунок 51. Новый XML-файл

Теперь данные прогноза стало значительно легче читать.

Рисунок 52. Форматированное сообщение
Рисунок 52. Форматированное сообщение
Рисунок 52. Форматированное сообщение

Если этот совет покажется вам не слишком удобным, можете использовать свой собственный метод форматирования HTML. Большинство Web-сервисов предлагает результаты в XML-формате, поэтому вам не придется прибегать к этому приему постоянно.

Заключение

Мы создали, преобразовали, приняли и проверили корректность SOAP-сообщений, используя программу Web Services Validation Tool for WSDL and SOAP. Эта программа позволяет точно определить проблемы, которые большинство серверов Web-сервисов даже не способно обнаружить, что может привести к серьезным последствиям в реальной жизни. Использование этой программы на этапе разработки позволяет сократить время устранения проблем в ходе эксплуатации.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=855475
ArticleTitle=Проверка корректности SOAP-сообщений Web-сервисов
publish-date=01182013