SOAと「つなぐ」技術 第4回:SOAをとりまく「つなぐ技術」 - Webサービス

Avatar
dstn

アプレッソ、マーケティング企画部の渡辺です。
開発部から所属が変わりました、今後ともよろしくお願いします。

今回からは、SOAや「つなぐ技術」に関連した個別の技術などについて、毎回一つのテーマを取り上げて連載を行う予定です。

まず最初の今回は「Webサービス」をテーマとして取り上げたいと思います。

SOAにとっては、WebサービスによりSOAをめぐる状況が変わったことがポイントだと思いますので、Webサービス登場前後の状況と併せての説明をします。

どうやって外部から呼ぶか?

SOAの基本的な考え方は以下のようなものでした。 

  • 業務システムの構成要素を「サービス」として部品化する 
  • 各サービスには「標準化されたインタフェース」があり、外部から呼び出すことが出来る 
  • 上記のようなサービスを組み合わせ、業務に必要なアプリケーションを作り上げる 

「部品化」をするためには、適切なサイズでリソースをブラックボックス化してサービスとし、そのサービスを外部から呼び出して利用できるようにしなければなりません。そのための手段は様々にありますが、SOAでは「Webサービス」が良く使われています。そのため、SOAとはWebサービスを使うことである、と思っている人もおられるかもしれません。 

しかし、SOAという言葉が最初に公式に使われたのではないかと言われているGartnerのレポートが書かれたのは1996年で、1996年にはまだ Webサービスもないどころか、XMLそのものが未完成でした(WebサービスはXMLを利用する技術です)。つまり、少なくとも最初のSOAにおいては、Webサービスは使われていなかったのです。 

では、当初はどのようにしていたのでしょうか? 

既存技術:外部から機能を呼び出したい、外部と連携させたい

外部から機能を呼び出したり、外部とデータを連携させること自体は、特に目新しい考え方ではありません。外部から機能を呼び出せるようにする仕組みや、データを連携させる仕組みは昔からありました。 

例えば、メインフレームの時代から RPC(リモートプロシージャコール)と呼ぶ、別のマシン上にある機能(サブルーチンなど)を呼び出す技術がありました。 

また、ごく簡単な技術による連携の実現も可能でした。例えばファイルをインタフェースとして使い、ファイル転送によってもSOAは実現可能です。 

※SOAは「考え方」が肝心ですので、簡単な手段でも実現できるのです。 

さらに、オブジェクト指向言語によりアプリケーションが作られるようになると、別のマシンで実行されているプログラム上のオブジェクトを呼び出せるようにする技術、分散オブジェクト技術が登場します。 

つまり様々な手段による実現が可能でした。しかし、それぞれの手段に長所と短所があり、決定打となるような手段はなかったのが、Webサービス登場以前の状況でした。 

RPCなど:利用が煩雑 

RPCやファイル転送など昔から使われている接続方法では、十分に高度な機能が無い傾向があります。またインタフェースの仕様、すなわち呼び出し先マシンはどこにあり、どのようにして呼び出せばいいのか、バラメータはどうやって渡すのか、パラメータはどのようなものなのか・・などについて人がインタフェースの仕様を理解し、呼び出すためのコードを書く手間が大抵の場合は必要でした。

同じプログラム内にある機能を呼び出す場合にはここまで面倒なことをする必要がないことと比較すると、煩雑さはイメージできると思います。

分散オブジェクト技術:特定技術に依存してしまう

分散オブジェクト技術は、当時広く利用されるようになりつつあったオブジェクト指向言語で、別のマシン上にあるオブジェクトを呼び出したり参照したりする技術でした。いわば、別のマシン上で動作中の他のプログラムの中身を直接覗けるような便利な技術でした。

高度な機能を利用できることが多く、簡単に外部のマシンに接続し、簡単に別のマシン上のオブジェクトを自分のマシン上のものと区別なく利用できるなど、優れた技術が登場するようになります。

しかし別の問題がありました、例えばJavaのこのような機能(Java RMI)はJavaだけを使っているうちは便利に使えますが、Java以外と組み合わせて利用する際には不便を強いられました。

そのような問題を解消できる技術も作られていました。特定の技術に依存せずにオブジェクトの呼び出しを行えるようにする取り組みがあり、例えばCORBAという標準規格の取り組みがありました。しかし、複雑で利用しにくい技術となってしまったこともあり、広く利用されるようにはなりませんでした。 

Webサービス

そのような状況で登場し、期待されるようになったのがWebサービスでした。

ちょうど当時、インターネット(Web)が広く使われるようになりつつありました。Webサービスはこの状況をうまく利用しました。これにより、SOAの「つなぐ手段」の本命となります。

Webサービスは、Web(インターネット)で広く利用されている標準技術の通信方法と通信基盤を利用し、離れたところにあるサービスを呼び出せるようにする技術でした。

具体的には、通信をHTTPプロトコルなどWebで広く使われる手段で行い、データの受け渡しについてもXMLなど標準的な技術を用いました。また、分散オブジェクト技術が備えていたような、高度で便利な機能の整備も進み、難しいことが簡単にできる環境も整いはじめます。

また何より、Webの技術は分散オブジェクト技術と違って、特定の何かに依存していない標準技術である点が新しいところでした。標準技術を基盤とすることにより、異なる環境や異なる開発言語間の接続であっても同じようにつなぐことが出来るようになり、今後も特定の何かにロックインされにくいことが期待できました。 

SOAブームとその後

SOAはWebサービスの登場によりブームとなります。 

「つなぐ手段」の本命がなかったところに有望な技術が登場したことから、さらに、当時それ自体が大ブームだった「インターネット」の波にも乗ることにもなりました。 

さらに、標準技術で構成される「つなぐ手段」の上で、サービス自体の高度な標準化がなされれば、大きな変化が起こりうると期待されブームが過熱します。以下、その当時の「大きな期待」の一部を紹介します。

SOAはサービスとして部品化を行い、これを組み立てて必要なアプリケーションを作りますが、基本的に部品を利用/再利用する範囲は同一組織内です。しかしもし仮に、サービス自体の高度な標準化がなされた場合、「部品」は特定の会社向けのものではなくなり、世界共通部品になります。もし仮にそうなると、Webサービスの共通基盤の上で、買ってきた「世界共通部品」を組み立てて業務システムが実現できるようになります。 

また、人がいちいちサービスを組み合わせるのではなく、人が「何をしてほしいか」を示すと、自動的に必要なサービスが世界中から自動的に探しだされて組み合わされて組み立てられる、という夢のようなプランもありました。 

しかし少なくとも現在までのところ、そのような夢の未来は実現していません。そのこともあって過剰な期待はしぼみ、結果的にSOAのブームは収束します。 

しかし、SOAの「つなぐ手段」の本命としてWebサービスが登場して状況が変わったこと、また、SOAが求められる業務システムをめぐる数々の状況まで覆ったわけではありません。さらにはクラウド時代になり、クラウドを超えて「つなぐ」手段の必要性はむしろ高まっています。 

これからもWebサービスはSOAや「つなぐ技術」における重要な「つなぐ手段」として利用され続けることでしょう。 

次回は

次回は、Webサービスでの主流なスタイルになりつつある「REST」についての記事を書く予定です。

コメント

ログインしてコメントを残してください。

Powered by Zendesk