サービスの呼び出し側を確認する
では、サービス側を実行します。サーバを立ち上げると、致命的なエラーは無くなったようですが、まだ警告が出てきます(図6)。警告といえども無視することはできません。言語のコンパイルに慣れすぎると少々の警告は無視してもいいような感覚になってしまいがちですが、サーバ立ち上げ時の警告は見逃さないようにしましょう。
警告を無視して実行し、画面表示した結果が図7です。送料と合計金額が表示されていません。要するに、CalcChargeコンポーネントが呼び出されていないのです。
幸い、この警告の意味は分かりやすくすぐに理解できます。「CalcChargeサービスのバインディングにマッチするcalcChargeを参照するコンポーネントにバインディングがない」というものです。大文字小文字の区別に注意すればcalcChargeを参照するコンポーネントとはBasketコンポーネントということが分かります。つまり、ワイヤリングは両方のコンポーネントでバインディングの指定をしないとうまくいかないのです。修正したコンポジットの抜粋が図8です。CalcChargeのサービス要素の子要素にbinding.ws
要素を追加しています。
この状態で実行した結果のログが図9です。警告も致命的なエラーも無くなっています。
画面を確認しましょう。先ほど表示されていなかった、送料と合計金額が正しく表示されています。これで、BasketとCalcChargeはWebサービスでワイヤリングされました。
皆さんお気づきになったでしょうか? 実はAtomやJSONRPCの場合、頭にTuscanyの名前空間であるt
が付いているのですが、今回のWebサービスには付いていません。実は第1回で紹介しているのですが、AtomやJSONRPCはSCAで標準化されているわけではありません。Tuscany独自の実装のためTuscanyの名前空間であるt
を付けているのです。それではWebサービスを表すbinding.wsにt
を付けたらエラーになるのでしょうか。実はTuscany自身の実装も存在するためt
を付けても正常に動作します。当連載ではTuscanyという実装を扱っているため、これ以降はWebサービスの場合も頭にt
を付けます。
警告を少しずつ修正していくことで、Webサービスでのワイヤリングには何が必要かを理解していただけたでしょうか。図2では次のようなクラスが水面下で動いていることが分かります。
- CompositeBindingURIBuilderImpl
- BindingWSDLGenerator
- ComponentReferenceWireBuilderImpl
JavaからWSDLを生成してくれるクラスや、コンポーネントのワイヤリングに必要なクラスが動いているのが確認できます。もし、最初から動くサンプルを示していたら、図9のようにこれらのクラスを知ることもなかったでしょう。皆さんもすんなり成功するより失敗から学ぶことの方が多いことに気づかれていると思います。筆者の場合も、何かを学習するときは、なるべくサンプルプログラムが付属しているものを選び、サンプルプログラムを変更したり、削除したりして、何のためにあるのか分からないクラスやメソッドの役割を調べたりします。少し脱線しましたが、今回のサンプルプログラムも分からない部分は変更を加えたり、削除したりしてその役割を理解していただければと思います。
ここまでWebサービスによるワイヤリングを説明してきましたが、本当にWebサービスが使用されているのかと信じられない方も多いと思います。図11はWSDLファイルですが、Javaコードから自動的に生成されたものです。ファイルの中をよく見ると、RPCベースのSOAPではなくドキュメントベースのSOAPであることが分かります。