はじめに

XML や HTTP などの新しい技術と標準の出現により、Web サービスはインターネット革新技術の殿堂入りを果たしたようです。けれどもそもそもこの革新技術はどこから生まれたのでしょうか。

Web サービスの基本的な概念は、米国の 1960年代半ばにまで遡ることができます。当時、鉄道会社や船会社などの運送業界は、コンピューター間で電子データを交換するという新たな概念を導入しました。この概念がのちに発展したのが EDI (Electronic Data Interchange) です。私がビジネス・スクールの教授から初めて EDI について聞いたのは、1980年代のことでした。

1996年、米国国立標準技術研究所は FIPS PUB (Federal Information Processing Standards Publication: 連邦情報処理標準) 161-2 のなかで、EDI (Electronic Data Interchange: 電子データ交換) に関する標準を発表しました。この刊行物によると、EDI とは、厳格にフォーマットが規定されたメッセージをコンピューター間で交換することです。受信したメッセージの処理はコンピューターによってのみ行われ、通常、人間による介入は意図されていません。1960年代半ばには XML もインターネットも、そして World Wide Web もなかった点を除けば、これはまさに Web サービスそのものです。

Web サービスにそれほど馴染みのない方のために、これから簡単に、Web サービスの定義と主要なコンポーネントの概要を紹介しておきます。

上に戻る

Web サービスとは何か

Web サービスとは、計算リソース同士がネットワークを介して相互運用可能なマシン間で対話できるようにするソフトウェア・システムのことです。この対話は、World Wide Web Consortium によって定義された SOAP (Simple Object Access Protocol) メッセージを使用して行われます。

分散型ネットワーク環境で構造化かつ型定義されたメッセージを交換するために使用されるのは、単純で拡張可能なプロトコル、SOAP (Simple Object Access Protocol) です。SOAP メッセージのフォーマットは XML (Extensible Markup Language) で作成されます。この単純で柔軟なテキスト・フォーマットは、International Organization for Standardization によって開発された SGML (Standard Generalized Markup Language)、すなわち ISO 8879:1986 に由来します。

Web サービスのインターフェースを記述するための言語は、XML をベースとした WSDL (Web Services Description Language) です。

ここで、誤った SOAP メッセージが交換された場合について考えてみてください。SOAP メッセージが誤っていることに気付かずにこれを処理し、しかもそのメッセージから意思決定者のための情報を生成したとしたら一体どうなるでしょうか。

事実上、SOAP メッセージに含まれるデータが正しいかどうかを判断することはできません。しかし少なくとも、SOAP メッセージのインターフェース定義、つまり WSDL を調べて SOAP メッセージが有効であるかどうかを確認することはできます。

現実には、SOAP メッセージに潜んでいる問題をデバッグするのは極めて難しいことです。SOAP メッセージに何らかのエラーがあると、Web サービス・サーバーから HTTP レスポンス・コード 500 を受け取りますが、Web サービス・サーバーは SOAP メッセージのどの部分に問題があるのかについては詳しい情報を提供しません。さらに厄介な事態として、Web サービス・サーバーからエラー・メッセージが送られることもなく有効な SOAP レスポンス・メッセージを受信したにもかかわらず、SOAP リクエスト・メッセージおよびその SOAP レスポンス・メッセージに問題があるということを、ユーザーおよび Web サービス・サーバーがどちらも認識していないという場合があります。例えば、ある時点での B 社の株価をリクエストするときに、タグのスペルを誤って入力した SOAP メッセージを Web サービス・サーバーに送信したとします。この場合、Web サービス・サーバーはタグのスペルが誤っていることを無視し、SOAP レスポンス・メッセージにデフォルトの値として A 社の株価を提供する恐れがあります。この誤りが見過ごされたとすると、莫大な損害になりかねません。

このような問題を事前に防ぐ手段として利用できるのが、Web Services Validation Tool for WSDL and SOAP です。このツールを使えば、Web サービス・アプリケーションがデプロイされる以前から、WSDL (Web Service Definition Language) で SOAP メッセージを検証することができます。このツールは、WSDL で SOAP メッセージを分析、構文解析、検証し、詳しいエラー・メッセージと行番号によって問題を特定します。あの HTTP レスポンス・コード 500 に悩まされることはもうありません。さらに、SOAP メッセージが暗号化されているとしても問題ありません。ツールが自動的に暗号化を解除して SOAP メッセージを検証してくれます。

Web Services Validation Tool for WSDL and SOAP は、世界各地のクライアントからレポートされた IBM® WebSphere Application Server での Web サービス関連の問題解決に取り組む IBM Web Services サポート・チームの支援ツールとして作成されています。このツールでは SOAP メッセージを検証することができます。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 サービスを構築するには、以下の 2 つの方式があります。

1. トップダウン開発。WSDL からWeb サービス実装の Java™ クラスを生成する方式です。
2. ボトムアップ開発。Java Bean または Enterprise Java Bean から Web サービスを生成する方式です。

以下の例では、ボトムアップ開発方式で Web サービスを実装する手順を説明します。つまり、最初に単純な Java アプリケーションを構築し、IBM Rational Application Developer for WebSphere Software を使用して Java アプリケーションからボトムアップ Java Bean Web サービスを生成するという手順です。

上に戻る

Java アプリケーションの作成

まず初めに、ユーザーに挨拶する Java アプリケーションを作成します。ユーザー名を指定しなければ、このアプリケーションは「Hello, buddy!」と表示します。ユーザー名を指定すると、「Hello,」の後にユーザー名が表示されます。以下は、パッケージ・デモに含まれている DemoWebService という名前の Java アプリケーションです。hello() メソッドが、ユーザー名に応じた文字列を返します。

 /*
 * @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 サービスを作成する前に、Java アプリケーションをテストすることは非常に重要な点です。アプリケーションを実行するには、main() メソッドを持つクラスを作成します。また、IBM Rational Application Developer バージョン 7 に提供されている Universal Test Client を利用すれば、テスト・コードを作成することなく簡単にテストを実行することができます。この場合に必要な作業は、このテスト・クライアントを起動するために、Java クラスのコンテキスト・メニューで Universal Test Client をクリックすることだけです。

1. Universal Test Clientで、「Objects (オブジェクト)」 > 「DemoWebService」の順に展開します。
2. hello メソッドを選択します。
3. 「Value (値)」フィールドに文字列またはユーザー名を入力して、「Invoke (起動)」をクリックします。

null パラメーターでテストして、この場合の動作を確認することもできます。null パラメーターが hello() メソッドに渡されると、正常に「Hello, buddy!」が返されます。

上に戻る

Web サービスの作成

ここまでは、すべて順調に運んでいます。次は、ボトムアップの Web サービス開発方式を用いて、Java クラスから Web サービスを生成する番です。

1. IBM Rational Application Developer で Java アプリケーションの DemoWebService を選択し、新規 Web サービスを作成します。

2. Java クラスは作成済みなので、Web サービス・タイプには「Bottom up Java bean Web service (ボトムアップ Java Bean Web サービス)」を選択します。続いて「Start client (クライアントの起動)」を選択し、「Finish (完了)」をクリックします。EJB (Enterprise Java Bean) クラスを使用する場合には、EJB を作成して Web サービスを生成することもできます。

何も問題がなければ、Java Resources の DemoWebService.java の右隣に DemoWebService.java が生成されているはずです。

DemoWebServiceDelegate.java を見てみると、@javax.jws.WebService という Java Web サービス・アノテーションがあることに気付くはずです。このアノテーションは DemoWebServiceDelegate クラスに targetNamespace、serviceName、portName を指定しています。このクラスで DemoWebService のインスタンスが作成され、DemoWebService の hello() メソッドから別の hello() メソッドが定義されます。Java Web サービス・アノテーションの詳細については、JSR (Java Specification Request) 181: Web Services Metadata for the Java Platform を参照してください。

/*
 * @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 には、前の手順で作成した Java アプリケーションのネットワーク・サービスを記述する WSDL (Web Service Definition Language) が含まれます。DemoWebServiceService_schema1.xsd には、SOAP メッセージで使用するデータ型の構造を記述する XML スキーマが含まれます。

DemoWebServiceService.wsdl を見てみると、ルートには一連の定義をするための要素があり、各定義要素には以下の 6 つの要素が含まれます。

• types
• message
• portType
• binding
• service
• port

types: メッセージ交換で使用するデータ型を定義します。DemoWebServiceService.wsdl には、WSDL ファイルにデータ型を定義する代わりに DemoWebServiceService_schema1.xsd をインポートします。

message: 交換するメッセージを定義します。DemoWebServiceService.wsdl に定義されているメッセージは、「hello」と「helloResponse」の 2 つです。hello メッセージには「parameters」という名前のパーツがあり、このパーツには「tns:hello」要素があります。helloResponse メッセージにあるパーツも hello と同じく「parameters」という名前ですが、このパーツの要素は「tns:helloResponse」です。hello 要素と helloResponse 要素は、DemoWebServiceService_schema1.xsd に定義されます。このファイルについては、この後すぐに説明します。

portType: エンドポイントでサポートされる操作を定義します。この場合のエンドポイントがサポートする操作は、入力メッセージと出力メッセージを指定します。この操作は「hello」という名前で、入力メッセージ「tns:hello」と出力メッセージ「tns:helloResponse」からなります。これは、リクエスト/レスポンス転送です。WSDL ではエンドポイントに対し、以下の 4 つの転送プリミティブを規定しています。

• 単方向 (one-way)
• リクエスト/レスポンス (request-response)
• 送信請求/レスポンス (solicit-response)
• 通知 (notification)

単方向タイプの転送プリミティブでは、エンドポイントはメッセージを受信するだけです。リクエスト/レスポンス・タイプの転送プリミティブでは、エンドポイントがメッセージを受信した後、対応するメッセージを送信します。送信請求/レスポンス・タイプの転送プリミティブでは、エンドポイントがメッセージを送信し、対応するメッセージを受信します。通知タイプの転送プリミティブでは、エンドポイントはメッセージの送信のみを行います。

binding: portType で定義された操作とメッセージに対するプロトコルの詳細およびメッセージ・フォーマットの仕様を定義します。ここでは、style 属性に「document」が指定されています。style 属性はメッセージのスタイルとして、rpc と document のいずれかを指定します。rpc スタイルのメッセージにはパラメーターと戻り値が含まれ、document スタイルのメッセージには文書が含まれます。transport 属性の値は、SOAP 転送用の URI に設定されます。この値が http://schemas.xmlsoap.org/soap/http となっているということは、SOAP 仕様の HTTP バインディングが使用されることを意味します。SOAP の HTTP バインディングに対応する SOAPAction HTTP ヘッダーの URI は、soapAction 属性に指定します。SOAP の HTTP プロトコル・バインディングを使用することから、soapAction 属性には値が必要です。ここでは、soapAction 属性に空の文字列、"" が使用されています。soap:body 要素は、SOAP メッセージの body 要素内でメッセージ・パーツをどのようにアセンブルするかを指定します。use 属性には、literal および encoded の 2 つのオプションがあります。ここで使用するのは literal です。これはつまり、element 属性または type 属性のいずれかを使用して具体的なスキーマ定義を選択することを意味します。use 属性が encoded に指定されている場合は、エンコーディング規則に従って抽象型を使用することになります。

service: 関連するポートのセットを定義します。

port: バインディングのネットワーク・アドレスを指定することによって、通信エンドポイントを定義します。

http://localhost:9081/HelloWorldWSProject/DemoWebServiceService が、この SOAP エンドポイントのアドレスです。

<?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.wsdl から DemoWebServiceService_schema1.xsd をインポートします。ここで、DemoWebServiceService_schema1.xsd を見てください。XML スキーマ定義言語で書かれているこのファイルは、XML 文書の構造を記述し、XML 文書の内容を制約します。このファイルには hello と helloResponse という 2 つの要素があり、それぞれの要素が型を指定しています。hello 型には文字列である arg0 という要素が含まれます。arg0 要素は、この要素のなかで宣言されている minOccurs 属性の値が 0 となっていることから、オプションです。minOccurs 属性に 1 以上の値が使われているとしたら、要素が表示されることになります。helloResponse 型の return 要素についても同様です。

<?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 Services Validation Tool for WSDL and SOAP から Web サービスを呼び出せるようにします。

Web Services Validation Tool for WSDL and SOAP を実行するには、Java 6 以降のランタイム環境と、World Wide Web Consortium の XML Encryption Syntax and Processing 仕様 (http://www.w3.org/TR/xmlenc-core/) に基づく XML デジタル暗号化および暗号化解除用の API が必要です。

IBM Java 6 には JSR 106: XML Digital Encryption APIs の実装が用意されています。したがって、IBM Java 6 を使用している場合には、すぐに作業を開始することができます。他にインストールしなければならないものは何もありません。

Sun Microsystems™ Java 6 などの Java 6 ランタイム環境を使用していて、その Java 6 に XML Digital Encryption API が備わっていない場合には、JSR 106 を実装するライブラリーか、または http://santuario.apache.org/ から入手できる Apache™ XML Security バージョン 1.4.3 をインストールする必要があります。後者の場合に必要な作業は、バイナリー・ディストリビューションのコピーをダウンロードしてディレクトリーに解凍し、このディレクトリーの場所を –vmargs および –DAXS コマンドライン・オプションを使用してツールに知らせるだけです。

この記事を執筆している時点で、Web Services Validation Tool for WSDL and SOAP が XML デジタル暗号化および暗号化解除用にサポートしているのは、JSR 106 と Apache XML Security バージョン 1.4.3 ですが、SOAP メッセージのデジタル署名を検証するには JSR 105: XML Digital Signature APIs を実装するライブラリーが必要です。幸い、Sun Microsystems と IBM の Java 6 仮想マシンは JSR 105 の実装を提供します。このことが、Java ランタイム環境の最小要件として Java 6 を選んだ理由となっています。お使いの Java 6 が JSR 105 を実装するライブラリーを提供していない場合は、JSR 105 をサポートするライブラリーを見つけてください。

Web Services Validation Tool for WSDL and SOAP のコピーは、http://www.alphaworks.ibm.com/tech/wsvt から無料で入手することができます。インストール手順は至って簡単で、パッケージをディレクトリーに解凍し、wsvt.exe を実行するだけです。デフォルトの Java 仮想マシンが、XML デジタル署名およびデジタル暗号化/暗号化解除をサポートする Java 6 でない場合には、–vm オプションを使って Java 6 の配置場所を指定してください。以下は、その一例です。

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

ここでも同じく、IBM Java 6 を使用している場合は、他にインストールしなければならないものは何もありません。必要なものはすべて IBM Java 6 に組み込まれています。一方、Sun Microsystems の Java 6 を使用している場合は、暗号化された SOAP メッセージを暗号化解除するために、Apache XML Security の配置場所をツールが把握できるようにする必要があります。

例として、Apache XML Security ライブラリー・バージョン 1.4.3 がインストールされた Sun Java 6 でツールを起動するとします。このライブラリーが置かれている場所は、C:\xml-security-1_4_3\libs: wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs です。

以下に、Web Services Validation Tool for WSDL and SOAP が実際に使用する Apache XML Security ライブラリー・ファイルを記載します (ただし、Apache XML Security バージョン 1.4.3 には 9 つの JAR ファイルが付属しています)。
commons-logging.jar
serializer.jar
xalan.jar
xmlsec-1.4.3.jar

Web Services Validation Tool for WSDL and SOAP の MANIFEST.MF には、以下の内容が指定されています。
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

以上の理由から、Sun Java 6 環境で暗号化された SOAP メッセージを暗号化解除するためには、 –vmargs –DAXS=C:\xml-security-1_4_3\libs が必要となります。

Sun Java ランタイム環境、Apache XML Security、そしていくつかの Eclipse プラグインにある XML 関連のクラスの間でのクラス・ロードの競合と非互換性を解決するために、私は相当の時間を費やしました。それと比べると、JSR 106 実装が付属していて、Apache XML Security の要らない IBM Java ランタイム環境では、いとも簡単にツールの実行を始めることができます。

上に戻る

プロジェクトの作成

ツールが稼働状態になったところで、早速、新しいプロジェクトの作成に取り掛かります。プロジェクトには WSDL ファイルと、この WSDL ファイルに関連する複数のスキーマ・ファイル、そして XML ファイルの SOAP メッセージを含めることができます。プロジェクトに複数の WSDL ファイルがある場合、SOAP メッセージの XML ファイルの妥当性検証を行う際には、そのうち 1 つの WSDL ファイルだけが使用され、残りの WSDL ファイルは無視されます。別の WSDL ファイルを使用するには、別のプロジェクトを作成する必要があります。各 SOAP メッセージは、ファイル拡張子が .xml のファイルに含めてください。こうしないと、SOAP メッセージとして処理されません。

1. ツール上でマウスを右クリックして「New (新規)」 > 「Project (プロジェクト)」の順に選択し、新規プロジェクトを作成します。

2. 「General」フォルダーの下にある「Project」を選択します。

3. 「Project name (プロジェクト名)」フィールドに「Test Project」と入力し、「Finish (完了)」をクリックします。

上に戻る

WSDL とスキーマのインポート

「Test Project」というプロジェクトを作成したら、このプロジェクトに WSDL と XSD をインポートします。

1. プロジェクトを選択し、コンテキスト・メニューで「Import (インポート)」をクリックします。

2. 「General」フォルダーの下にある「File System」を選択します。

3. WSDL と XSD を保存するディレクトリーを選択します。
4. DemoWebServiceService.wsdl と DemoWebServiceService_schema1.xsd の 2 つのファイルを選択し、「Finish (完了)」をクリックします。

上に戻る

WSDL とスキーマの確認

これで、プロジェクトに WSDL と XSD がインポートされました。WSDL をダブルクリックすることで、設計モードとソース・モードのそれぞれで WSDL を確認することができます。設計モードでは、Web サービスの入力および出力を視覚化することができます。

ソース・モードでは、テキスト・エディターで WSDL を表示して編集することができます。

XSD ファイルを XSD エディターで開けない場合、XSD ファイルのコンテキスト・メニューから「Open With (開く)」 > 「XML Editor (XML エディター)」を選択すれば、XSD ファイルを XML エディターで開くことができます。

以下は、XML エディターで開いた DemoWebServiceService_schema1.xsd です。

上に戻る

SOAP メッセージの作成

SOAP メッセージを検証するための WSDL とスキーマが用意できました。次は、SOAP メッセージを使って Web Services Validation Tool for WSDL and SOAP のテストをします。それにはプロジェクトに SOAP メッセージを含める必要があります。SOAP メッセージは、妥当性検証の対象となる .xml ファイル拡張子の付いたファイルに保存します。

1. プロジェクト内に SOAP メッセージを作成するには、「New (新規)」 > 「XML」の順に選択します。

2. 新規に作成する SOAP メッセージの親フォルダーとして「Test Project」を選択します。DemoSOAPMessage.xml が選択された状態になっていなければ、「File name (ファイル名)」フィールドにこのファイル名を入力して「Finish (完了)」をクリックします。

ツールが自動的に新規 XML ファイルを XML エディターに開きます。このファイルには、XML のバージョンとエンコーディングが示された行しかありませんが、SOAP メッセージを一から作成するのではなく、すでに最初から何らかの入力がされているのは助かります。SOAP メッセージを組み立てる方法を知らなくても心配は要りません。次のセクションでは、SOAP メッセージの作成手順を説明します。

SOAP メッセージを組み立てるには、「parameters」パラメーターに、例えば私の名前「Jinwoo」を指定して「hello」サービスを呼び出します。もちろん皆さん自身の名前を使用しても構いません。名前空間には「http://demo/」を使用します。「http://demo」ではなく、「http://demo/」としていることに注意してください。最後にスラッシュが付くか付かないかによって、大きな違いがあります。

<?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 メッセージには問題があることに気付いた方はいますか？問題があるとしても、心配しないでください。この後、その問題に対処することになります。

上に戻る

SOAP メッセージの送信

いよいよ、SOAP メッセージを Web サービス・サーバーに送信します。

1. Web Services Validation Tool for WSDL and SOAP で SOAP メッセージを選択して、「Transmit SOAP Request and Receive SOAP Response (SOAP リクエストの送信と SOAP レスポンスの受信)」をクリックします。

2. 「Transmit SOAP Request and Receive SOAP Response (SOAP リクエストの送信と SOAP レスポンスの受信)」ウィンドウでは、「Service Address (サービス・アドレス)」、「SOAPAction (SOAP アクション)」、「Content-Type (コンテンツ・タイプ)」の各フィールドに情報を入力することができます。しかし、このアプリケーションでは SOAPAction を入力する必要はありません。DemoWebServiceService.wsdl の binding セクションで、soapAction 属性に空の文字列 "" を使用したからです。
3. サーバーが localhost:9081 にある場合は「Service Address (サービス・アドレス)」に「http://localhost:9081/HelloWorldWSProject/DemoWebServiceService」と入力します。そうでない場合は、Web サービスにアクセスできる正しいアドレスを入力してください。
4. 「Content-Type (コンテンツ・タイプ)」には「text/html」を選択します。
5. 「OK」をクリックして SOAP メッセージをサーバーに送信します。

上に戻る

SOAP メッセージの受信

サーバーが稼働していれば、SOAP レスポンスが返されるはずです。何のレスポンスも返されない場合は、指定したアドレスとコンテンツ・タイプの両方が正しいことを確認してください。

上に戻る

SOAP メッセージの検証

見事、SOAP レスポンスを受け取りました。このメッセージはプロジェクトにも保存されます。しかしちょっと待ってください。何かが間違っていることがわかりますか？受け取ったのは、「Hello, Jinwoo!」ではなく、「Hello, buddy!」というレスポンスです。原因として思い当たるふしはありますか?

残念ながら、Web サービス・サーバーはこの問題を通知してくれませんでした。エラー・メッセージもなければ、警告メッセージもありません。これは、予期せぬ SOAP レスポンスを送信したとしても、Web サービス・サーバーはまったくそのことに気付いていないという非常に危険な事態になりかねません。SOAP レスポンスの受信側でさえも、問題の SOAP メッセージに存在するエラーに気付かない可能性があります。

Web Services Validation Tool for WSDL and 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, buddy!</return>
    </ns2:helloResponse>
  </soapenv:Body>
</soapenv:Envelope>

DemoSOAPMessage.xml ファイルを検証して、SOAP リクエスト・メッセージに問題があるかどうかを調べる手順は以下のとおりです。

1. SOAP リクエスト・メッセージを選択し、「Validate (検証)」をクリックします。

この操作により、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.

上に戻る

SOAP メッセージの編集

1. ツールは parameters 要素に問題があると通知しているので、この要素の値を arg0 に変更して保存します。

    
<?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>

2. 変更した SOAP リクエスト・メッセージを検証します。今度はエラー・メッセージが表示されないはずです。

3. これで、変更後のリクエスト・メッセージをサーバーに送信する準備が整いました。SOAP メッセージを選択し、「Transmit SOAP Request and Receive SOAP Response (SOAP リクエストの送信と SOAP レスポンスの受信)」をクリックしてください。

4. 「Transmit SOAP Request and Receive SOAP Response (SOAP リクエストの送信と SOAP レスポンスの受信)」ウィンドウの「Service Address (サービス・アドレス)」フィールドに、「http://localhost:9081/HelloWorldWSProject/DemoWebServiceService」 と入力します (サーバーが localhost:9081 にある場合)。
5. 「Content-Type (コンテンツ・タイプ)」として「text/html」を選択し、「OK」をクリックします。

今回は、期待通りの正常なレスポンスを受け取ります。

 
<?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/」に変更して保存します。

 
<?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>

2. リクエストをサーバーに送信します。

IOException として、「Server returned HTTP response code:500 for URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService」というメッセージが表示されます。

Web サービス・サーバーは IOException で応答しましたが、この情報だけでは何が問題なのかがわかりません。そこで、このツールを使ってメッセージを検証して、問題を解決するのに十分な情報を入手できるかどうかを調べてみましょう。

ツールを使用した場合には、「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. (無効な SOAP メッセージです: cvc-complex-type.2.4.a: 要素「ns0:hello」で始まる無効な内容が検出されました。「"http://demo/":hello」、「"http://demo/":helloResponse」の何れかで始まる必要があります。)」というメッセージが表示されます。

このメッセージは、「http://demo/」が要求されていることを指摘しています。これはまさに、HTTP レスポンス・コード 500 の代わりに知りたかった情報です。

上に戻る

暗号化された SOAP メッセージの検証

SOAP メッセージが暗号化されているとしても、鍵とパスワードを持っている限り、まったく問題ではありません。暗号化されていない他の SOAP メッセージの場合とまったく同じように、SOAP メッセージを選択して、「Validate (検証)」をクリックしてください。SOAP メッセージが暗号化されている場合には、以下のような入力画面が表示されます。

この記事を執筆している時点でサポートされている鍵ストアのタイプには、以下の 3 つがあります。

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

この画面で、鍵ストアに関する情報としてファイル名、ファイル・タイプ、およびパスワードを指定します。指定した情報が正しければ、次に鍵を選択してパスワードを入力する画面が表示されます。また、鍵ストアに関する情報と鍵ストアに含まれる鍵および証明書の一覧も表示されます。具体的には、鍵ストアのタイプ、プロバイダー名、プロバイダー・バージョン、プロバイダー情報、鍵のタイプ、作成日、証明書のタイプ、アルゴリズム、フォーマットです。

すべての情報が正しい場合、ツールは暗号化を解除した SOAP メッセージを自動的に生成し、そのメッセージを検証します。

現在、以下の暗号化アルゴリズムがサポートされています。

• 初期化ベクターを使用した CBC (Cipher Block Chaining) モードの AES (Advanced Encryption Standard) 鍵暗号化 (128/192/256 ビット)
• AES (Advanced Encryption Standard) 鍵暗号化 (128/192/256 ビット)
• triple-DES (Triple Data Encryption Algorithm Modes of Operation) 鍵暗号化
• CBC (Cipher Block Chaining) モードの triple-DES (Triple Data Encryption Algorithm Modes of Operation) 鍵暗号化
• RSA Cryptography Specifications バージョン 1.5
• マスク生成関数を使用した RSA OAEP (Optimal Asymmetric Encryption Padding) 方式

上に戻る

デジタル署名付き SOAP メッセージの検証

SOAP メッセージにデジタル署名が付いている場合には、SOAP メッセージを選択して「SOAP Message Digital Signature Verification (SOAP メッセージ・デジタル署名の検証)」をクリックしてください。

デジタル署名が有効であれば、以下の画面が表示されます。

デジタル署名が有効でない場合には、ツールによって署名が無効であることが通知されます。現在、以下のデジタル署名アルゴリズムと仕様がサポートされています。

• SHA-1 (Secure Hash Algorithm 1)
• HMAC (Hash Message Authentication Code)
• DSA (Digital Signature Algorithm)
• PKCS #1 (Public-Key Cryptography Standards)
• Secure Hash Algorithm (SHA-1) を使用した RSA 暗号化アルゴリズム
• Canonical XML バージョン 1.0 および 1.1
• XSLT (XSL Transformations) バージョン 1.0
• XPath (XML Path Language) バージョン 1.0
• Base64

上に戻る

SOAP メッセージを使用した米国国立気象局へのアクセス

これまでの手順で作成してテストした単純な Web サービスは、万事順調に運んでいますが、このツールは実際の環境でも使えるのでしょうか？ツールを本番 Web サービスで試してみる場合、米国国立海洋大気庁 (NOAA) の米国国立気象局が提供している Web サービスを利用することができます。

1. プロジェクトを作成します。

2. SOAP メッセージの XML ファイルを作成します。

米国国立気象局で運用している NDFD (National Digital Forecast Database) は、SOAP (Simple Object Access Protocol) Web サービスを使用して検索できるようになっています。その詳細は、http://www.weather.gov/forecasts/xml/ に記載されています。

この気象局が提供している Web サービスはさまざまにありますが、そのうち、NDFDgenByDay というサービスを試してみることができます。これは、緯度と経度で特定される指定の場所の天気予報を伝えるサービスです。

NDFDgenByDay にアクセスするには、以下の情報を提供する必要があります。

例えば、特定の場所 (LAT38.9,LON-77.01) について、2010年 7月 23日から 7 日分の天気予報を 24 時間形式で取得する 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>

上記のメッセージは名前空間を定義しなくても機能しましたが、名前空間に関する問題が生じた場合には、必ず名前空間を定義してください。

Web Services Validation Tool for WSDL and SOAP で、SOAP メッセージを選択して「Transmit SOAP Request and Receive SOAP Response (SOAP リクエストの送信と SOAP レスポンスの受信)」をクリックします。

米国国立気象局から、天気予報のデータが送られてきました！けれども受信したデータは、HTML の特殊なエンティティーのせいで容易に判読することができません。

ファイル拡張子を .html に変更してから Web ブラウザーで表示することで、HTML の特殊エンティティーを変換することができます。

HTML ファイルを Web ブラウザーで開きます。

これで XML 出力を見ることができます。けれども体裁が整えられていないため、読みづらい内容になっています。

そこで、そのままの内容をコピーして、体裁の整った新しい XML 文書を作成します。

新しい XML ファイルを作成し、コピーした内容を貼り付けて体裁を整えます。

これで、天気予報データは遥かに読み易くなります。

この方法は、あまり気に入らないと思った方は、独自の手法で HTML 出力の体裁を整えても構いません。ただし、ほとんどの Web サービスが提供するのは XML 出力なので、この作業を常に行わなければならないことはないはずです。

上に戻る

まとめ

この記事では、Web Services Validation Tool for WSDL and SOAP を使用して SOAP メッセージを作成、送信、受信、そして検証しました。ほとんどの Web サービス・サーバーが気付きもしない問題が、実際には深刻な事態をもたらす場合もあります。Web Services Validation Tool for WSDL and SOAP であれば、そのような問題を特定することができます。このツールを開発段階で使用すれば、本番環境で問題が発生したとしても、解決に要する時間を短縮できるはずです。

参考文献

学ぶために

• 著者の技術記事に関するページ
  
  
• Webcast replay: Simple Object Access Protocol Debugging
  
  
• Web Services Validation Tool for WSDL and SOAP
  
  
• Web Services Activity
  
  
• Web Services Architecture
  
  
• Web Services Description Language (WSDL)
  
  
• Extensible Markup Language (XML)
  
  
• Overview of SGML Resources
  
  
• JSR 105: XML Digital Signature APIs
  
  
• JSR 106: XML Digital Encryption APIs
  
  
• JSR 181: Web Services Metadata for the Java™ Platform
  
  
• Apache XML Security
  
  
• IBM developer kits
  
  
• U.S. National Digital Forecast Database (NDFD) Simple Object Access Protocol (SOAP) Web Service
  
  
• Federal Information Processing Standards Publications (FIPS PUB 161-2)
  
  
• developerWorks の SOA and Web エリアにアクセスして、スキル上達には欠かせないリソースを入手してください。
  
  
• Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  
  

製品や技術を入手するために

• IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
  
  

議論するために

• developerWorks blogs から developerWorks コミュニティーに加わってください。
  
  

著者について

Jinwoo Hwangは、ノースカロライナ州リサーチ・トライアングル・パーク所在の IBM WebSphere Application Server Technical に勤務するソフトウェア・エンジニア、発明家、著者、および技術リーダーとして、これまで IBM HeapAnalyzer (http://www.alphaworks.ibm.com/tech/heapanalyzer) やその他多くの技術を設計、作成してきました。著書には『C Programming for Novices』(ISBN:9788985553643、Yonam Press、1995年) がある他、ウェブキャストや記事 (http://jinwoohwang.sys-con.com) でも活躍しています。彼は IBM 認定ソリューション開発者、IBM 認定 WebSphere Application Server システム・アドミニストレーターであり、さらに Java プラットフォームの SUN 認定プログラマーの資格を持っています。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• Web サービスとは何か
• Java アプリケーションの作成
• Java アプリケーションのテスト
• Web サービスの作成
• WSDL の作成
• スキーマの作成
• Web Services Validation Tool for WSDL and SOAP の開始
• プロジェクトの作成
• WSDL とスキーマのインポート
• WSDL とスキーマの確認
• SOAP メッセージの作成
• SOAP メッセージの送信
• SOAP メッセージの受信
• SOAP メッセージの検証
• SOAP メッセージの編集
• 誤った名前空間の検出
• 暗号化された SOAP メッセージの検証
• デジタル署名付き SOAP メッセージの検証
• SOAP メッセージを使用した米国国立気象局へのアクセス
• まとめ
• 参考文献
• 著者について
• コメント