Webサービスの動作を決めるスコープの謎パソコンで試してわかるWebサービス(4)(2/4 ページ)

» 2002年11月08日 00時00分 公開
[イチロー樋口研究室監修]

ネットワーク上のSOAPをとらえる〜TCPモニタ〜

 はじめにAxisの便利なツールを紹介します。Axisに付属しているTCPモニタ・ツールを使ってみます。これは、ネットワーク上に流れているSOAPデータを取り出して、どのようなデータがWebサービス・クライアントとWebサービスの間で流れているかを確認できるツールです。

 連載の第1回から利用している環境変数設定バッチファイルを起動した後、下記のコマンドを実行してください。このコマンドは<AXIS_HOME>で実行します。

> start java org.apache.axis.utils.tcpmon

 また、第1回で作成したクライアント用MS-DOSコマンドプロンプト環境設定バッチファイルを必ず実行しておいてください。この後、MS-DOSコマンドプロンプトによる作業では必ずこの環境設定が必要になります。

 すると次のような画面が起動します。この画面はTCPモニタの初期画面です。この画面では、どのアプリケーション・サーバに対してモニタリングするかを設定します。

 これまで使ってきたようにWebサービスはTomcat上で稼働しています。同一のPCであればホスト名(Target Hostname)が「localhost」、ポート番号(Target Port #)が「8080」です。これらをListenerのところに書き込みます。そして、上部の「Listen Port #」を「8081」とします。

画面1 TCPモニタの画面 画面1 TCPモニタの画面

 ここで、「Add」ボタンを押すと、次のような画面が生成されます。

画面2 強制的に8081を指定して実行可能になる 画面2 強制的に8081を指定して実行可能になる

 この画面が表示されれば、設定完了です。

 さて、このツールの動きですが、転送データをポート番号「8081」で待ち、そのデータを取得して、Tomcat側の「8080」に転送します。すなわち、TCPモニタがクライアントとサーバの間に入り込み、データを中継する仕組みになります。

 すなわち、クライアント側はこれまでポート番号「8080」を指定していましたが、強制的に「8081」を指定して実行します。すると、このTCPモニタを介してサーバにアクセスします。これにより、ネットワーク上のデータを見ることができるという仕掛けです。

TCPモニタでWebサービスをつかまえる

 さっそく、前回の自作Webサービスを実行してみましょう。TCPモニタを起動/設定した状態にして、<@WORK>ディレクトリで以下のコマンドを実行します。Webサービス・クライアントプログラムの第3の引数はWebサービスのエンドポイントを変更できるようにしてあります。今回はTCPモニタでモニタリングするために、強制的にポート番号「8081」を指定して実行することになります。

> java atmarkit.SimpleAddClient 1 5 http://localhost:8081/axis/servlet/AxisServlet
0
0

 結果は前回と同様になるはずです。実行後、TCPモニタを見てください。TCPモニタがネットワーク上のHTTPプロトコルをとらえているはずです。

画面3 HTTPプロトコルの内容が表示されたところ 画面3 HTTPプロトコルの内容が表示されたところ

 上部の「Done」と書いてある1行1行がHTTPの1回の要求(Request)/応答(Response)になります。下部の2つのウィンドウはその要求と応答のHTTPのデータを表示しています。どちらもHTTPのヘッダ情報とボディ情報があるだけでなく、HTTPボディの中には「SOAPエンベロープ」があり、さらにその中に「SOAPボディ」があるのが分かります。なお、ここでは「SOAPヘッダ」は利用されてないため含まれていませんが、SOAPヘッダを利用する場合はこの中にSOAPヘッダも表示されます。

 HTTPを通信プロトコルに使った場合のSOAPデータの構成は次のようになります。TCPモニタでとらえたデータがこのような形式になっているのが容易に理解できると思います。

図1 SOAPデータの構成 図1 SOAPデータの構成

TCPモニタで宿題プログラムを解析する

 では、早速前回の宿題プログラムをTCPモニタで解析してみましょう。画面の表示データは、複数行あるデータの最後のデータを表示しています。最後は実行結果のデータを取得する「getResultValue」メソッドを実行する部分です。

画面4  TCPモニタで解析すると……(クリックすると拡大します) 画面4  TCPモニタで解析すると……(クリックすると拡大します)

 このHTTP要求のSOAPボディの中をよく見ると、「SimpleAddService」サービスの「getResultValue」メソッドの起動要求が出ているのが分かります。また、HTTP応答のSOAPボディの中には、「getResultValueReturn」というタグの中にint型の「0」という数字が返ってきていることが分かります。すなわち、明らかにWebサービスから結果の値が「0」と返されていることが分かります。

 このようにSOAPでどのようなデータがやりとりされているかは、SOAPがXMLを利用しているために容易に理解することができます。これは、SOAPを利用するメリットの1つでもあります。

 ここで、もう1つ重要なことが分かります。1回の実行で何行ものデータが生成されています。前に書いたように1行1行が1回の要求/応答なので、宿題サンプルプログラム1度の実行で6回のSOAPのやりとりがされているということになります。この「6回」というのは、実はWebサービス・クライアントプログラムの「invoke」メソッドの回数になります。すなわち、「invoke」メソッドはSOAPの要求/応答を実行するメソッドということがはっきりと分かります。

 これで宿題の答えが分かった方はいらっしゃいますか? まだ分からないという方のために、もう1つ別の解析を行ってみましょう。

JavaBeansを書き換えて、動きを確認してみる

 宿題のヒントを覚えていますか? 宿題のヒントでは、「SimpleAddBeanのコンストラクタに何か標準出力文を入れてみる」とありましたね。これを実践してみましょう。

  ●SimpleAddBean.java
package atmarkit;

public class SimpleAddBean implements java.io.Serializable {

  private int resultValue;
  private int inputValue;

  public SimpleAddBean(){
    resultValue = 0;
    inputValue = 0;
    System.out.println("SimpleAddBeanがインスタンス化されました!");
}




 JavaBeansのコンストラクタに「System.out.println("......");」を書き込み、第3回と同じ手順でWebサービス化してください。なお、Webサービス・クライアント側は変更の必要はありません。

 JavaBeansの修正とWebサービスとしての配置が完了したら、Tomcatを再起動後に以下のコマンドを実行します。

> java atmarkit.SimpleAddClient 1 5 http://localhost:8081/axis/servlet/AxisServlet
0
0

 結果は同じで、TCPモニタにも同様のデータが捕獲できているはずです。ここでは、Tomcatの画面を確認してください。Tomcatの画面にはJavaBeansの標準出力が表示されています。次の画面のようになっているはずです。

画面5 JavaBeansが6回インスタンス化されている 画面5 JavaBeansが6回インスタンス化されている

 Tomcat画面には「インスタンス化されました!」が何行出力されていますか? これも6行出力されています。「インスタンス化されました!」の出力をしているのはJavaBeansのコンストラクタです。すなわちJavaBeansが6回インスタンス化(new)されていることにほかなりません。

 これを見れば「なぜ結果が0になるのか?」理解できたでしょう。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。