Webサービスにも必要なセッション管理：パソコンで試してわかるWebサービス（5）（4/5 ページ）

[イチロー，樋口研究室監修]

SessionスコープをTCPモニタで再確認

　さて、もう一度TCPモニタで確認してみましょう。

　　　　　●1回目の実行

画面3　Webサービス側からセッションIDがセットされる

　最初に「Set-Cookie」で設定されたセッションIDが2回目以降の要求では「Cookie」としてAxisエンジンに送信されています。これにより、Axisエンジンは1回目から6回目までが１つのセッションであることを認識します。

　　　　　●2回目の実行

画面4　「Set-Cookie」で設定されたセッションIDが2回目以降の要求では「Cookie」としてAxisエンジンに送信される

　1つのセッションとして認識したAxisエンジンは、セッション内ではJavaBeansのインスタンスを保持します。そのため、宿題プログラム1回の実行につき1つのJavaBeansがインスタンス化され、利用されることになります。Tomcatの画面を見ても、1回の宿題プログラムの実行につき、1つのJavaBeansがインスタンス化されていることが分かるはずです。これらの動きはapplicationスコープとも動きが違うことが分かっていただけるでしょう。

セッション管理の難しさ

　これまで、スコープについて取り上げてきましたが、ここまできたところで注意があります。それは、「スコープはSOAPに定められた機能ではない」ということです。

　SOAPの仕様書を見てみると、スコープやセッション管理については述べられていないことが分かります。これはAxis上にスコープを設定するのも「配置記述子」というAxis独自のファイルにて行っていたことからも理解できます。また、sessionスコープに至っては、セッションを管理するためにHTTPの補完機能（なお、CookieもHTTPの標準仕様ではありません）を使っています。これもSOAPでは通信を行うのにHTTPを指定しているわけではなく、さまざまなプロトコルで利用できることからもセッション管理がSOAPの仕様でないことが分かります。

　今回のようにWebサービス／Webサービス・クライアントの両方にJavaを利用し、Axisという同じAPIにて実装されている場合は、このようなセッション管理が成り立ちますが、SOAPの特徴である異機種間通信になった場合は、標準化されていないことからも成り立つ保証がありません。

　このように書くと「Webサービスの将来は駄目なんじゃないか？」と思われるかもしれませんが、そんなことはありません。最近の新しいWebサービス関連の技術によりこれらは解決される方向にあります。単なるセッション管理だけでなく、Webサービスにおける「トランザクション管理」「セキュリティ」「ワークフロー」などの技術が多くのベンダによって構築されてきています。これらが自由に利用できるようになった際には、Webサービスの中の「標準的な方法」によってWebサービス／Webサービス・クライアントが利用できるようになるはずでしょうし、異機種間の互換性（Interoperability）も十分なものになっていくはずです。これらの技術の進展はWebサービスが今後主流の技術になっていくための必要条件ともいえるでしょう。