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

なぜ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つのアプローチに分かれる。

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

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

（注1） Common Object Request Broker Architecture。オブジェクト指向技術の標準化団体OMGが定めた分散オブジェクト技術の仕様。分散オブジェクト技術では、ネットワーク上にある複数のコンピュータにオブジェクト（ソフトウェア）を配置し、それらを連携させてシステム構築を行なう。

（注2） Simple Object Access Protocol。ネットワーク上のほかのコンピュータにあるデータを呼び出す際のプロトコル。データやリクエスト、結果などをすべてXMLで表現する。

（注3）X M L 関連の標準化団体O A S I S と国連機関のUN/CEFACTが中心となって、国際的な電子商取引の標準策定を行なう団体ebXMLが策定した、XMLによる企業間電子商取引の国際標準仕様。

（注4）Web Services Description Language。Webサービスが提供する機能と、その機能を使用するためのパラメータなどを記述する言語仕様。

（注5）Universal Description, Discovery and Integration。SOAPを使用してWebサービスに関連する情報をインターネット上で広く公開し、Webサービスが提供する機能などを検索可能にするための仕組み。