システム構築の実践から学ぶSOAの基礎と本当のメリット
|
サービスの実装 （.NET＋Oracleの例）
次に、既存システムの機能をサービス化する方法を紹介する。在庫照会サービスは、各物流センターにおける在庫管理システムをWebサービス化して実現される。物流センターBでは、Windows上の独自アプリケーションとして在庫管理システムが稼動している。このシステムの構成は、図6に示すようにVB.NETによる在庫管理サーバーと、在庫データを格納するOracleデータベースからなるシンプルなものである。在庫照会サービスは、このOracleデータベースへの在庫照会処理を以下の手順でWebサービス化することにより実現する。
（1）サービス実装方式の決定
今回は、既存の在庫管理システムの在庫量取得メソッド（LIST4）を利用して在庫照会サービスを実現するため、在庫照会サービスのデータ取得の流れは次のようになる（図7）
（1）在庫照会サービスは、図7に示す照会ID、移動先物流センターコード、商品コードなどの引数と共に本部の欠品対応サービスより呼び出される
（2）呼び出された在庫照会サービスは、受け取った商品コードを元に、既存システムで利用されている在庫量取得メソッドを使用してデータベースより出荷可能バラ数量を取得する
（3）最後に、在庫照会サービスは、取得した出荷可能バラ数量などの値を元に戻り値を格納する構造体（LIST3）にコピーして本部に返信する
（2）サービス実装環境の準備
VB.NETとOracleデータベースを利用してWebサービスを作成するために、次のツールをインストールする。
・Visual Studio .NET
・Oracle Data Access Software Release10.1.0.3 for Microsoft Windows（ODAC10103.exe注9）（注9）
（3）サービス実装クラスの作成
まず、公開されているWSDLを元に在庫照会サービス用のクラスを作成する。VisualStudio.NET（以下、VS.NET）を用いて、WSDLファイルを基にWebサービス（WebMethod）を含むクラスを自動生成できる。ここでは、すでにWebLogic Workshopで生成されたWSDLを元にしてInventoryという実装クラスを生成した。
なお、WSDLはツールによって生成されるものが若干異なるため、エラーとなって自動生成できない場合がある。その場合は、公開されたWSDLを自分で解読し、Webサービス（WebMethod）を含むクラスを作成しなければならない。
コーディングは、主にInventoryクラス内のWebサービスを実現するWebMethod（）メソッドに行なう。戻り値となる構造体に必要なデータを詰めていくことを意識しつつ値をセットしていけばサービス実装クラスは完成だ（LIST3）。なお、データベースからのデータ取得に関しては、既存の在庫管理システムの在庫量取得メソッド（LIST4）を利用するため、そのメソッドの呼び出しを行なうだけで良い。
（4）サービスのデプロイ
次に、作成したクラスを.NETサーバー上にデプロイする。.NETを初めて扱うとき、デプロイ方法が分からずにつまずくことがあるが、以下の手順を実行すれば良い。
（1） VS.NETで「新しいプロジェクト」をクリックする
（2）セットアップ／デプロイメントプロジェクトの「セットアップウィザード」を選択する
（3）ウィザードに従ってインストーラを作成する
（4）デプロイサーバーにてインストーラを起動する
（5）サービスの単体テスト
最後に、実際にサービスを呼び出して、Webサービスの戻り値にOracleデータベースから取得したデータが適切にマッピングされているかを確認する。
VS.NETでは、デバッグを実行するとローカルにWeb画面が表示される。Webサービスに引数がある場合は、その表示されたWeb画面にパラメータ値を入力するためのテキストボックスが表示されるので、入力後［起動］ボタンをクリックすると、呼び出し前後のSOAPが表示され、在庫の照会結果が正しく格納されているかどうかを確認できる。
結合テスト
ここまで、欠品対応サービスおよび在庫照会サービスの実装について説明した。同様に、移動元決定サービスや在庫移動サービスなど、すべてのサービスの実装が完了したら、欠品対応サービス全体の結合テストを行なうことになる。具体的には、欠品対応サービスをデプロイした後、WebLogic Workshopより実行を指定するだけでテストブラウザが起動し、欠品対応サービスを呼び出すための画面が表示されるので、在庫照会サービスのときと同様に値を入力してサービス実行を指示することになる。
SOAでも通常の開発と変わらず、単体テストや結合テストを行なう必要があることに変わりはない。結合テストが完了すれば、欠品対応サービスは完成である。
おわりに
SOAというキーワードへの注目は、ビジネスからのIT業界への期待の表われであり、今後のIT技術の方向性を暗示するものでもある。企業は、時間が来れば必ず陳腐化すると分かっていても、システムをできるだけ長く使いたいという一方で、絶えず変化するビジネス環境に素早く対応できるシステム環境をも求めている。これに呼応するIT技術の進歩により、サービス実装手段への依存度はますます低くなり、サービスの組み合わせによる高機能システムの構築が簡単に実現できるようになっていくだろう。
では、「サービス実装手段への依存度は低くなる」ことで、ITエンジニアが重要な役割を果たさなくなるのかと言うと、決してそんなことはない。本稿でも示したように、システム全体の設計に始まり、開発、テストまでを行なう工程はSOAでも従来の開発でも変わらない。サービスのインターフェイス設計やメッセージモデリングといった特徴的な設計工程も、オブジェクト指向設計の技法がベースになる。また、本稿では触れなかったが、サービスを組み合わせて実現できることと、それが十分な性能で動作することはまったく別の話である。システム全体のパフォーマンスを考慮しながらサービスインターフェイスやメッセージの構造を決めていくには、データベースのチューニングに共通するシステムの動作原理に関わる深い知識が必要である。
もちろん、SOAにより変わる面もある。システム全体のトータルな設計能力、ビジネスの側面からの技術を捉える視点が今まで以上に求められるようになるはずだ。ひょっとすると、SOAというキーワードは数年後には残っていないかもしれない。しかし、本稿で示したSOA開発に必要なアプローチやスキルが、ますます重視されるようになるのは間違いないだろう。
非同期サービスについて
Web サービスの例としてよく見られるものは、実は「同期型サービス」が多い。同期型サービスとは、「サービスの応答が返ってくるまで呼び出し側が待ち続ける」というものである。
一方、実際の業務を考えた場合、サービスを依頼してから結果が返ってくるまで待ち続けることはあまりない。結果が返ってこない場合もあるし、結果を待っている途中で日が変わることもある。メールやFAX を送信して結果が返ってくるまではほかの仕事をする、または別のメールやFAXを送信するという状況は、通常の業務の姿として容易に想像できるだろう。このような業務をサービス化する場合は、「非同期型サービス」を作成することになる。SOAは業務のプロセスと同じ粒度でサービスを定義できるため、サービスを設計する際にはこのような非同期サービスとなる可能性を考えておくべきである。
非同期型サービスの設計／実装では、同期型サービスに比べて検討しなければならない事項が多い。トランザクション管理をはじめ、結果を受け取るためのポーリングや結果が返ってくるまでデータベースにプロセスの処理状況を永続化して待機する、結果が一定時間を越えても返らない場合は警告するなど、かなり複雑な仕組みが必要になる。このような仕組みは独自に開発するのではなく、ミドルウェアに任せてしまうこともできる。ESB やBPMといった製品は、このような要件にも対応すべく機能拡張してきている。
（注9）.NETとOracleデータベースをつなぐアダプタ。