Web2.0時代の必要技術　～　SOA 再入門

中山 幹敏

第一部：SOA―フラット化する世界でのシステム開発

　2006年に注目された本の中に、トーマス・フリードマンの『フラット化する世界－経済の大転換と人間の未来』（伏見威蕃訳、日本経済新聞社、2006年）がある。フリードマンはニューヨーク・タイムズ紙のコラムニストであり、グローバリゼーションを論じた『レクサスとオリーブの木』などの著作のあるノンフィクション・ライターである。

フリードマンは『フラット化する世界』の中で、コロンブスの時代に「地球は丸い」という発見があったが、現在では、地球はその状態から「平ら（フラット）」に向かっているという逆説的な見解を、豊富な事例を元に披露している。フラット化とは、フリードマンが「グローバリゼーション3.0」と名づけた世界的な現象であり、世界の各国が、いわば「フラットな競技場」での共同作業や競争が可能になった状態をいう。インドなどへの国境を越えた業務のアウトソーシング、中国などへのオフショアリング、Web2.0の普及などは、フラット化の要因であると共に、フラット化が現実であることの事例となっている。

　『フラット化する世界』は、これまで漠然と「IT革命」と呼ばれていたものに、より具体的なイメージを与える「フラット化」という表現を用いて、IT革命の本質や、社会や経済への影響、雇用や教育に及ぼす影響を鮮明に描き出した点でたいへん優れている。
それでは、このように「フラット化」しつつある時代を反映した、ソフトウェア開発のアーキテクチャやモデルは、どのようなものだろうか。私見ではあるが、その一つがSOA（サービス指向アーキテクチャ、Service-Oriented Architecture）である。

SOAとは何か

　まず、「SOAとは何か」について整理してみよう。
SOAは字義どおりには、「サービス指向」の「アーキテクチャ」つまり「基本構造」である。端的に言えば、中心概念は「サービス（Service）」である。この場合の「サービス」とは、意味あるまとまりとして提供されるソフトウェアの機能のことである。SOAは、独立して稼動するサービスというソフトウェアの機能をベースに、システムを構築していくコンセプトである。（図１）

たとえば、ネットでの物品販売サイトのシステムをSOAにしたがって構築する場合を考えてみよう。どんな機能が必要となるだろうか。利用者がクレジットカードでの決済ができるように、クレジットカードの与信や決済の機能がなければならないし、また、注文品の在庫確認や発送などの機能も必要である。すべてを自前で最初から開発するとなると、確かに膨大なコストと時間がかかる。それでは、もしクレジットカードの与信や決済を代行してくれる会社があり、それを処理するソフトウェアのインターフェイスを提供しているとしたら、どうだろうか。また在庫管理から発送までを代行してくれる会社があったらどうだろうか。そうした会社に業務の一部をアウトソーシングするなら、スピーディーに物品販売サイトを立ち上げることができるだろう。

　では、ソフトウェアの一部として、外部にすでにある機能を利用することに決めたとしよう。物品販売サイトの処理の流れはどんなイメージになるだろうか。
この物品販売サイトでは、クレジットカードの決済が必要な場合は、A社の提供する「クレジットカード決済サービス」というソフトウェア機能を呼び出し、在庫の確認をして発送する場合はB社の提供する倉庫の「在庫確認サービス」と「発送サービス」を呼び出して処理を進めればよいのである。この場合、サービスの利用という形で、ソフトウェア機能とそれに付随する実務のアウトソーシングをしていることになる。まさにクレジット会社とのやり取りや在庫管理業務や発送業務まで依頼できるのである。（図2）

では、外部にあるソフトウェア機能は、具体的にどのように呼び出せるのだろうか。

従来であれば、その会社が提供するモジュールを自社のプログラムに組み込んだり、提供されるライブラリにあるプログラムを呼び出すという方式を取ったかもしれない。しかし、これはSOAのやり方ではない。
繰り返しになるが、SOAの場合は、サービスという単位のソフトウェア機能を呼び出す。サービスの呼び出し側は、呼び出されるサービスを提供するプログラムの実体が、どのような形で存在するかはまったく知らないし、それには関与しなくてもよい。サービス提供側に不具合があって、プログラムを改修しないといけない場合でも、サービス利用側では、インターフェイスが変更されない限り、プログラムの修正は必要ない。

利用側から見れば、サービスとのインターフェイスは、サービスの「呼び出し」と、サービスからの「応答」の受け取りである。そしてSOAでは、一般に、「Webサービス」のインターフェイスを使用する。具体的にいえば、SOAP（Simple Object Access Protocol）のインターフェイスである。SOAPによる通信はインターネット経由でも行えるので、論理的にはサービス提供側の実体は地球のどこにあってもよいことになる。（図3）

では、SOAPとはどのようなものだろうか。

SOAPはXMLデータを封筒構造で囲んだXMLメッセージ（XML文書）である。封筒部分には、サービスのあて先などが書かれている。サービス提供側には、封筒の中に入っているXMLデータが渡される。サービス提供側でXMLデータを処理したなら、返信が、やはり封筒構造のXMLメッセージとして戻ってくる。封筒の中に入っているのは、処理結果である。

したがって、SOAのサービスにおいて、インターフェイスを定義する場合は、どのサービスにどんなXMLデータを渡せば、どんなXMLデータが返ってくるかを規定しなければならない。そしてWebサービスのインターフェイスを定義したものを、WSDL（Web Services Description Language）という。これもXML形式の言語である。WSDLはXMLで記述されているので、プログラムが読んで処理できるようになっている。
これで一般的なSOAの、主な構成要素が登場した。（図4）

1. ◆ サービス利用側（コンシューマ）
2. ◆ サービス提供側（プロバイダ）
3. ◆ Webサービス

　◇SOAP（サービスとのインターフェイス）
　◇ WSDL（インターフェイスの定義言語）

これを見て分かるように、SOAの基本構造は比較的シンプルである。
それでは、サービス呼び出しの基本的な流れを確認してみよう。次のようになる。

1. サービス利用側は、サービス提供側が用意するWSDLに準拠したサービス（Webサービス）をSOAP形式で呼び出す。
2. サービス提供側は受け取ったXMLデータを処理して、やはりSOAP形式でサービス利用側に戻す。
3. サービス利用側は、戻されたXMLデータを読んでサービスの利用結果を確認する。

SOAは基本的に、サービスの呼び出しを繰り返すことで処理を進めていく。たとえば、先ほどの物品販売サイトの場合、サイトでお客様の注文があった場合、まず「在庫確認サービス」で在庫の有無を問い合わせる、「クレジットカード決済サービス」を呼び出して決済を行う、そして「発送サービス」を呼び出して発送処理を依頼する、というような流れになる。

SOAの特徴

次に、SOAの基本的な特徴について考察してみよう。

SOAの特徴のひとつは「柔軟性」である。まず、SOAはプラットホームや言語を選ばない。Windowsでも、Linuxでも、他のOSでも、またそれらが混在するシステムでも、実装可能である。実装する言語については、Javaでも、C#でも、PL/IやCOBOLでもよく、特に規定はない。ただし、Webサービス（SOAPとXML）をサポートしている環境でなければならない。（図5）

また、SOAは既存のシステム（レガシー・システム）をサービスとして取り込む面でも「柔軟」である。既存のシステムはバグが枯れており、各社固有のノウハウが詰まっている場合が多い。それに、既存のシステムの移行や移植はたいへんな作業である。新たなシステムを構築する場合に、既存システムの一部の機能を利用したいなら、既存のシステムにSOAPインターフェイスを追加して、外部に対してサービスを提供するようにできるかもしれない。いわばSOAのインターフェイスで既存システムを包み込んでしまうのである。それにより、既存システムはサービス提供側として、SOAの世界に取り込まれる。

さらに、SOAは機能追加の面や保守の面でも「柔軟」である。新たな機能を追加しようとする場合には、新たなサービスを作成して、サービス利用側に提供する形で対応できる。また、既存のサービスに新機能を追加する場合でも、追加のインターフェイスを定義して、サービス利用側に公開すればよい。シンプルな変更であるし、テストもある程度、独立して行うことができる。また保守はサービス単位で行うことができる。したがって、発展性や拡張可能性の点で、SOAは柔軟性を持っているといえる。

このようなSOAの「柔軟性」の背景には、「疎結合」というSOAの特徴が関係している。「疎結合」とは、文字どおり、ゆるい形での結合形態である。反意語は「密結合」といえるだろう。SOAのサービス利用側とサービス提供側は、SOAP形式のXMLメッセージによって結び付けられているだけである。その意味において、確かにゆるやかな結合状態にある。サービスはシステムとして協働しているが、それでも、ひとつのプログラムとして物理的に結合しているわけではない。こうした、ゆるやかな結合関係、別の言い方をすれば、各サービスの独立性が、これまでにない、SOAのシステム面の特徴となっている。（図6）

「疎結合」を処理や資源の観点から見ると、SOAは「非集中化」を実現しているといえる。しかし、「分散」処理を実現しているわけではない。分散処理は特定の処理を複数の資源を使って処理することである。たとえば、点在するPCサーバーをつないで巨大な仮想コンピュータとして使おうとする「グリッド・コンピューティング」は分散処理の典型である（グリッド・コンピューティングについては、本誌27号（2006年）のp.10-15にある日本オラクルの鈴木俊宏氏のインタビューを参照していただきたい）。

SOAは、独立したサービスを必要に応じて呼び出すことで、システム機能を実現しているため、分散というよりは、「非集中」という表現のほうが正確である。各サービスは、SOAに準拠する別のシステムからも利用されることがある。サービスを利用する側から見ると、「非集中」であるが、サービスを提供する側から見ると、処理と資源の面での、業務の「集約」である。