Page  1  2  3  4 

システム構築の実践から学ぶSOAの基礎と本当のメリット
SPECIAL FEATURE 1 基本はXMLによるサービス連携
翔泳社 DBマガジン 2005年4月号に掲載
(林浩一/村上歴/柴田正弘)

(3)メッセージモデリング

次に、それぞれのサービスについてもう少し細かく見ていくと、それぞれのサービスには図5に示すような情報が必要だと分かる。このように、サービス提供に必要な情報を整理することを「メッセージモデリング」と呼ぶ。メッセージモデリングがデータベースモデリングと異なるのは、1つのメッセージ内に必要な情報がすべて含まれていなければならないという点だ。

データベース中心のシステムの場合は、あるテーブルに存在しない情報でもほかのテーブルから取得できる。これに対して、サービス中心のシステムの場合は、サービスが受け取った情報はそれだけで完結していなければならないのだ。もちろん、サービスを受け取る側が事前に知っていることが確実な情報は、わざわざ受け渡しに含める必要はない。

例えば、企業コードさえあれば企業名はいつでも求められる、というのはデータベース中心の考え方だが、サービス中心の場合は企業コードだけでなく企業名も入っていないと、意図しない企業名でサービスが実行(例えば、伝票に印刷)される可能性もある

(4)WSDLの作成

それでは、図5を元に各サービスを実際に設計してみたい。

今回はWe b サービスを用いるため、WSDLでサービスを定義する。WSDLの仕様はそれほど複雑ではないものの、ゼロから人手で記述するには少々荷が重い。しかし、作成支援ツールも手に入るので、必要に応じてそれらを利用すれば良いだろう。今回は、GUIベースのJava開発環境「WebLogicWorkshop」(日本BEAシステムズ)を用いて、JavaコードからWSDLを生成した。

ただし、自動生成されたWSDLは人手で修正を加えたほうが良い場合が多いことに注意が必要である。ツールのクセが型定義に現われてしまうことがあるからだ。実は、これがWebサービスの互換性を妨げる最大の要因になっている。WSDLはサービス仕様の要となるものであるため、UDDI経由であれ関係者へのドキュメント配布であれ、一度公開してしまうと変更したときの影響が大きい。WSDLを公開する前に、想定するサービスの呼び出し元環境(.NETなど)から利用できるかどうか、単体テストを行なっておくべきである。

実際の開発手順は以下のようになる(在庫照会サービスの例)

(1)WebLogic Workshopを起動する
(2)新規のアプリケーションを作成する。ここでは「StockoutApp」という名称にする
(3) StockoutApp配下に、新規の「Webサービスプロジェクト」を作成する。ここでは「Services」という名称にする
(4) Services配下に、新規のWebサービスとして、照会サービスのための「Inventoryサービス」を生成する
(5)生成されたInventoryサービスのソース「Inventory.jws」に、図5を基にしてサービス呼び出し、および結果として必要なパラメータを記述する(LIST1)
(6) GUIツールを使ってWSDLの生成を実行する
(7)生成されたWSDLを編集する(LIST2)

ここで作成したWSDLを基に、今度は各サービスを実装していくことになる。以降では、ほかのサービスを呼び出す例として欠品対応サービス、既存システムをサービス化する例として在庫照会サービスの2つに絞って、その実装方法を詳しく説明する。

サービスの実装 (WebLogic Integrationの例)

欠品対応サービスは、プロセス定義に従って、順次ほかのサービスを利用する。構築ツールとしては、先ほどと同様にWebLogicWorkshopを、プロセスを実行するエンジンとして「WebLogic Integration」(日本BEAシステムズ)を利用する。

プロセスの生成手順は以下のようになる。

(1)先ほど作成したStockoutAppの中に、プロセスを定義するプロジェクトとして「StockoutProc」というプロセスプロジェクトを作成する
(2)「process.jpd」というプロセスが生成されるので、この中に部品を配置していく
(3)Webサービスの呼び出しには、「Webサービスコンポーネント」を追加する(コンポーネント追加時にWSDLファイルのURLを入力するよう求められる)
(4)各サービスとプロセスの間におけるデータの受け渡しを記述する。これにはいくつか方法があるが、ここではプロセス全体で共有できる「プロセス変数」を通じて受け渡しを行なう。呼び出すサービスが必要とする値とプロセス変数との対応関係は、GUIツールで対応付けられる(画面1)

最終的に作成されたプロセスが画面2だ。図5の欠品対応サービスのフローと同じ構造になっていることが確認いただけるだろうか。

このようにして作成したプロセスは、1つのWebサービスアプリケーションとしてear形式にまとめられる。これをアプリケーションサーバーに配備することで、欠品対応サービスが利用可能になる。

より詳しい開発手順については、日本BEAシステムズのWebサイトよりWebLogicPlatformの評価版とともに入手できるチュートリアルを参照されたい。

Page  1  2  3  4 

このサイトについてプライバシーポリシーサイトマップ

お問合わせ

Copyright (C) 2000-2011 UL Systems, Inc. All Rights Reserved.