レベル: 初級 米持 幸寿, テクノロジー・エバンジェリスト, IBM
2006年 1月 13日 ライブがあったため、少しお休みしましたが、連載を再開したいと思います。今回から、実際にインターフェースを決め、定義していきます。
全体から考えるか？部分から考えるか？
インターフェースを決める方法には大きくわけると二つの方法があります。ひとつは、「なにをやりたいか」から考える「トップダウン」アプローチで、もうひとつは、旧来から存在するシステムの機能や、別の用途で設計されたシステムの機能を切り出してサービス化する「ボトムアップ」アプローチです。システムの構造をSOA的に考えてインターフェースを決めるのは、全体構造から入ることが多いと思いますので、トップダウンに分類しておきましょう。
一般的にSOAを取り入れるためにはトップダウン・アプローチが効果的であるといわれています。SOAを採用したことによるメリットを十分に享受するには、そのシステムの上で実行する業務そのものを柔軟なものにしていかなければならないからです。
サービス指向のインターフェースを考えるとき、どういう視点から考えていくかは、人によって違うでしょうし、その時々のシチュエーションによっても変わります。複数の登場人物（システム）のやり取り（インターラクション）から考えることもあるでしょうし、データの構造やデータの変化から考えることもあるでしょうし、処理手順から考えることもあるでしょう。一度作ったインターフェースはなかなか変更できなくなりますし、再利用性が高いものを最初から定義しなければならないでしょう。
こういったことから「インターフェースを決めるのは難しい」とか言われがちで、コンサルティングなどが盛んに行われています。しかし、まずは案ずるより産むが易しの精神でやってみましょう。
インターフェースを洗練する作業
ここでは、筆者の著書で登場した「書籍検索」のインターフェースについて考えてみます。どの部分がサービスとして切り出せるかを実際に業務に関わっている人と中身を確認しながら進めていくことになります。このとき、図を使う必要があるわけです。実際に、どのようにしてインターフェースを確定していくか、かいまみていただきましょう。
一人ですべて決めて作っていくなら、これらの図を頭の中で考えてインターフェースをいきなり決めていくかもしれません。あるいは、作ったものを図にして整理するのに役立ててください。
これはOO（オブジェクト指向）モデリングに似ています。このとき、もっとも標準的に使うべき表記法はUMLです。UMLがわかりにくい人もいるでしょうから、すこしわかりやすくするためにアレンジしてもかまわないと思います。要は、全員が同じ図を見て、同じ理解になることが重要です。
たとえば、書籍をカテゴリーから検索して発注する流れを考えましょう。カテゴリーの一覧を取得する、カテゴリーを選択して検索する、検索した書籍の詳細な情報を取得する、などを繰り返したあと、注文する書籍のISBN番号と冊数を含めた機能を定義していくことになります。
ここでは、登場人物（システム）として書籍を買う人「BookBuyer」、書籍情報システム「BookSearcher」、書店システム「BookStore」を考えます。
ごく簡単に考えると、カテゴリーの文字列をキーワードとして渡し、検索することで得られた書籍をいくつか選択して注文データを組み立ててBookStoreに送信する、と考えられます。筆者はよくシーケンス図を使って、これを表現して考えます。（図1）
図1.単純な書籍検索
もちろんこれは一つの例にすぎません。コラボレーション図やアクティビティー図、あるいは、最新のビジネス・モデリング・ツールでBPMN（Business Process Modeling Notation）などを使って考えてもいいと思います。
さて、ここで、すこし困りごとが起こります。それは、BookBuyerが「どのようなカテゴリーがあるか」を事前に知っておかなければならないことです。書籍のカテゴリーは年々増えていくようなものです。列挙として定義しておくわけにもいかず、だからといってなにを渡してもいいわけではありません。
そこで、カテゴリーはBookSearcherシステムから取得できるようにします。（図2）このように、事前に必要な情報から徐々にデータを掘り込むように取得していくような機能を持たせるデザインを「ドリルダウン」といいます。
図2.カテゴリー一覧を取得できるようにする
さて、データの構造を考えましょう。注文を行うには、だれが注文しているのか、という情報と、どの本を何冊購入するのか、という情報が必要です。購入者の情報を「Customer」、書籍詳細情報を「BookInfo」、書籍注文明細行を「BookOrderItem」、書籍注文を「BookOrder」として定義したデータモデルが図3です。
図3. XSDデータモデル
技術的な要素を加味する
さて、ビジネス的に処理のやりとりだけを考えてみると、ここまでのインターフェースでよさそうな気がしてしまいますが、このデザインでは実用的なシステムが作れません。さらに、このシステムが「分散されるかもしれない」という制約を加味して考えてみましょう。SOAのサービスは、システムとして構築されたときに実用的でなければいけません。
今の状態では、カテゴリーで検索されたときに、1000冊もの書籍が見つかったときに、1000冊分の書籍情報が一度に戻ってきてしまいます。これでは実用的なシステムにならないでしょう。HTTPで通信するWebサービスではタイムアウトが起こるでしょうし、安全な転送を行うシステムでも、時間がかかり過ぎます。これは、検索結果一覧を取得するインターフェースではよく起こることです。
そこで、二つの変更を加えます。それは、次のことです。
- 検索時には、検索結果のみがわかるサブセット情報のみが戻る（ここでは、ISBN番号、書籍タイトル、著者のみ）ようにし、のちにISBN番号から詳細情報を再取得する。
- さらに、検索結果は一度に戻らず、検索結果のうち指定位置から指定冊数のみが戻るようにする。（たとえば、1000冊検索された場合、11冊めから10冊分の結果のみが返る。このため、検索条件に開始位置と冊数を指定できるようにする。検索結果には、全体数、検索結果の位置番号が含まれる。
検索のインターフェースも変化します。カテゴリーは文字列一覧でいいでしょう。検索には、カテゴリーのみではなく、開始位置と冊数が指定されます。カテゴリーも一度にいくつか渡せてもいいかもしれません。また注文にも書籍情報は必要ありません。ISBNさえあればいいはずです。
図4.分散を加味したシーケンス図
図5.分散を考慮したXSDデータモデル
こうやって、インターフェースを洗練させていきます。今回の例では、インターフェースを以下の点において洗練させるところをご覧いただきました。
- 呼び出し側が、ある操作の呼び出しに対して事前に必要な情報を入手するためのデータを入手するための操作を追加する。（ドリルダウン）
- 分散時のデータのサイズを気にしてみる
次回は、このインターフェースをWebSphereツールを使ってSOAインターフェースとして定義する手順を説明します。
著者について  | | | 1987年に日本アイ・ビー・エム入社。メインフレームOS、ミドルウェアの障害対応、障害解析ソフトウェアの開発、ワークフローシステム開発、オブジェクト指向開発、Web開発など経験。2000年より、ソフトウェアのテクノロジーエバンジェリストとして活動中。 |
記事の評価
| 
