システム構築の実践から学ぶSOAの基礎と本当のメリット SPECIAL FEATURE 1 基本はXMLによるサービス連携

本パートでは、SOA（サービス指向アーキテクチャ）について解説する。まず、「SOAとは何か」「なぜ注目されるのか」といった基本事項を説明し、さらに実際にSOAでシステムを構築する手順と作成するコードの具体例を示しながら、SOAが現場のエンジニアにとってどのようなメリットをもたらすのかを解説してみたいと思う。

なぜSOAなのか

SOAはここ最近で、最も注目を浴びているITキーワードの1つである。その一方で、現場のエンジニアにとって最も理解しがたいものの1つでもある。その理由は大きく2つあると思う。

1つは禅問答のような概念的な説明ばかりで、実装されるコードの実体のイメージにまで落ちないこと、もう1つは、Webサービスとの違いが分からないことである。さらには「SOAではサービスを組み合わせるだけなので、技術を知らない人でもシステムが作れるようになる」といったうさん臭い話まで聞こえてくる。読者の中には、これまでの経験から、「怪しいキーワードは無視していればすぐに消えてしまう」と考えていたところが、SOAは逆に勢いを増している状況に、落ち着かない気持ちを抱いている方も少なくないのではないだろうか。

そこで本パートでは、最低限押さえておくべきSOAの基礎知識と、具体的なビジネスシーンを想定したシステム構築にSOAを適用する例を解説する。

SOAのIT視点とビジネス視点

SOAの概念が分かりにくいのは、システムを作る「開発者側」とシステムを導入する「経営者側」の間を取り持つためのキーワードとして使われるためである。両者の視点が微妙に交じり合うために混乱が生じるのだ。

IT の観点では、SOAは「ソフトウェアをネットワーク上の配置や実装に依存しない"サービス"という単位で用意しておき、それらの連携によってより高次の処理を行なうソフトウェア設計の考え方」である（図1）。この考え方は古くからあり、そう難しくはないものだ。Webサービスはその最新の実現方法と考えれば良い。

一方、ビジネスの観点で考えた場合、経営者はシステムを使うユーザーではないということに注意が必要である。企業の経営者にとって重要な関心事は、「システムを使うことでどんなに便利になるのか」ではなく「ビジネスにどんなインパクトがあるか」だ。経営者が「サービス」と聞いたときには、各企業が行なっている「商品を販売する」といった、いわゆるビジネス上のサービスが連想される。さらには「バリューチェーン」と呼ばれる、ビジネスを行なうために企業内の各部門が実行する商品の「仕入」「販売」「配送」といった業務プロセスの連鎖までが自然に連想される。

一方で、IT技術の発展により、サービスの実現方法としてWebサービスのようなマシン可読のインターフェイスによって、実装に依存しない形で機能を提供できるようになった。これらのサービスは疎結合でネットワークに分散され、組み合わせて実行することが可能である。

ここで、ビジネスの観点から、これらのITの特徴にどのような意味があるのかを考えてみよう。まず、「配置や実装に依存しない」という特徴は、過去のシステム資産の有効活用を可能にすることに加え、ビジネス上の業務プロセスを電子化した上でアウトソーシングできるという発想につながる。また、「組み換え可能」という特徴は、ビジネス環境の変化への対応に必要となる業務プロセスの変更に合わせ、柔軟に機能を組み換えることのできるシステムインフラへの期待につながっていくのだ。

SOAを実現する技術

SOAを実現する手段は、IT観点の定義から必ずしもWebサービスである必要はなく、CORBA（注1）を用いた分散オブジェクトシステムをSOAと呼んでも良い。一方で、ビジネス観点からの期待を考えると、サービスの粒度は業務プロセスの粒度に近いものであることが望ましい。

こうした観点から、企業システムをSOAで開発する場合、実装への非依存と組み換え可能という2つの主要な特徴は、以下の技術により実現されるべきであろう。

XMLメッセージ送受信

XMLメッセージの送受信により、サービスが疎結合で連携可能になる。WebサービスではSOAP（注2）を使って実現される。B2Bと呼ばれる企業間電子商取引では、「ebXML MS」（注3）といったプロトコルも有力な選択肢である。

XMLでのインターフェイス記述

コンピュータが解釈可能な形でインターフェイスを記述する必要がある。WebサービスではWSDL（注4）というXMLベースの記述が用いられる。

サービスの組み合わせ

サービスは組み合わされ、連携させることで、より高次のサービスを提供できるものでなければならない。この組み合わせは、開発時に全体設計を行なう時点で決められ、実行時には決まった組み合わせでサービスが実行されると考えて良い。Webサービスでは、実行時にUDDI（注5）を用いて動的にサービスを探索し構成するというコンセプトをあまりにも強調しすぎたために、逆に現実感を失うことになってしまった。信頼性の高いシステムを実現するためには、信頼できるサービスを想定された枠内で組み合わせることが必須である。サービスの組み合わせはB P E L 4 W S などで記述され、B P M（Business Process Management）機能を持つミドルウェアにより実行される。

SOAによる設計手順

SOAによるシステム設計においては、どのような粒度で、どのようなサービスを抽出してデプロイするのかを決めることが最も重要なポイントである。その設計手順は、大きく「トップダウン」と「ボトムアップ」の2つのアプローチに分かれる。

トップダウンアプローチは、ビジネス上のプロセスの観点から業務分析を行ない、サービスを切り出していくやり方である。新しいビジネスのためのサービス群を用意する際に特に有効である。

一方、ボトムアップアプローチは、既存システムの機能をサービスという形でラップ（隠蔽）して、ほかのシステムから容易に利用できるようにしていくやり方である。既存システムの機能を最大限に活用することを求める際に有効である。なお、ビジネス観点からの期待に応えるためには、トップダウンでビジネス上のプロセスを俯瞰するアプローチのほうが望ましい。ボトムアップで既存機能のサービス化を行なう場合でも、俯瞰的なサービス配置の整理はできるだけ行なっておきたい。

SOAの実践

ここからは、具体的なビジネスシーンを想定して、システム構築にSOAを適用する例を解説しよう。

適用シナリオ

今回は、例として卸売業の物流システムを取り上げることにする。大手卸売業のX社は、ここ数年、企業規模拡大のためのシステム統合を繰り返してきた。そのため、X社の物流センターはそれぞれが独自のシステム構成になっている（図2）。本部システムと各物流システムとの連携はX社の社内ネットワークを通じて行なっているが、日次バッチでの連携なので、本部への反映は一日遅れである。

ここで、「各物流センターの欠品対応の業務を効率化したい」という要求が高まってきた。欠品対応とは、得意先からの発注に対する在庫がない場合に、ほかの物流センターから在庫の移動が可能かどうかを照会し、その結果を元に在庫を移動して欠品を解消する業務である。X社の欠品対応業務はシステム化されていないため、電話およびFAXによる照会を中心としている。

現状では、電話による照会に時間がかかり、各物流センターの情報を十分に集められないため、最適な在庫の移動ができないという問題がある。X社本部のシステム部はこの問題に対応するため、SOAを適用したリアルタイムの欠品対応サービスを開発することにした。

サービスの設計

サービスの設計は、トップダウンアプローチで行なうことにする。このフェーズでは

（1）業務分析、（2）サービス抽出、（3）メッセージモデリング、（4）WSDLの作成の順に行なう。

（1）業務分析

まず、システム化を行なう前に、現状の業務をどのように改善すべきかを検討する。現状の欠品対応業務の流れは以下のようになる（図3）。

1：欠品通知

物流センターAのシステムが欠品の発生を検出し、担当者に通知する。

2b～2d：在庫照会

担当者は近隣の物流センターB、C、Dに電話で在庫状況を照会する。

2b'～2d'：在庫照会（物流センター内）

各物流センターの担当者は在庫の照会依頼を受け、結果を回答する。物流センターB、Cは担当者が直接システムを操作して照会し、物流センターDではオペレータを通じて他社に委託している物流システムに対して照会を行なっている。

3：移動元決定

物流センターAの担当者は、回答結果を元にどの物流センターからいくつを自分の物流センターに向けて移動してもらうかを決定する。

4b～4d：移動指示

決定内容に従って、物流センターAの担当者が各物流センターにFAXで在庫の移動指示を送付する。

今回の例では、電話での照会やFAXでの指示を自動化することで業務効率を改善することを考える。そのために、現状業務フローを元にして必要な部分のサービス化を検討する。

（2）サービスの抽出

現状の業務を分解すると、大きく以下の要素からできていることが分かる。これがサービス化する業務の候補になる（図4）。

1. 欠品の通知を受け対応する
2. 在庫を照会する
3. 移動元を決定する
4. 在庫を移動する

これらのサービスについて、どこに配備されるべきかを考える。(2)(4)は物流センターで提供するべきものだ。(1)は各物流センターへの照会を同じ手順で実施できるところ、ということで本部に配置する。(3)も同様に本部に配置されるが、現時点では移動元の決定はまだ担当者の経験に頼っていて自動化できないため、各物流センターの担当者が処理を行なうサービスになる。

SOAの考え方によれば、サービスの提供元はコンピュータであることにはしばられない。サービスを提供する人は、ほかのサービスからの要求を受けて、意思決定の結果をシステムに返さなければいけないので、ここでは本部のシステムにWebアプリケーションを1つ作り、そのWebアプリケーションを通じて結果をシステムへ伝えることにする。

（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）

画面1

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

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

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

画面2

サービスの実装　（.NET＋Oracleの例）

次に、既存システムの機能をサービス化する方法を紹介する。在庫照会サービスは、各物流センターにおける在庫管理システムをWebサービス化して実現される。物流センターBでは、Windows上の独自アプリケーションとして在庫管理システムが稼動している。このシステムの構成は、図6に示すようにVB.NETによる在庫管理サーバーと、在庫データを格納するOracleデータベースからなるシンプルなものである。在庫照会サービスは、このOracleデータベースへの在庫照会処理を以下の手順でWebサービス化することにより実現する。

図6：物流センターBの在庫管理システムに在庫照会サービスを追加

（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）

（3）サービス実装クラスの作成

まず、公開されているWSDLを元に在庫照会サービス用のクラスを作成する。VisualStudio.NET（以下、VS.NET）を用いて、WSDLファイルを基にWebサービス（WebMethod）を含むクラスを自動生成できる。ここでは、すでにWebLogic Workshopで生成されたWSDLを元にしてInventoryという実装クラスを生成した。

なお、WSDLはツールによって生成されるものが若干異なるため、エラーとなって自動生成できない場合がある。その場合は、公開されたWSDLを自分で解読し、Webサービス（WebMethod）を含むクラスを作成しなければならない。

コーディングは、主にInventoryクラス内のWebサービスを実現するWebMethod（）メソッドに行なう。戻り値となる構造体に必要なデータを詰めていくことを意識しつつ値をセットしていけばサービス実装クラスは完成だ（LIST3）。なお、データベースからのデータ取得に関しては、既存の在庫管理システムの在庫量取得メソッド（LIST4）を利用するため、そのメソッドの呼び出しを行なうだけで良い。

リスト3

リスト4

（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といった製品は、このような要件にも対応すべく機能拡張してきている。