オブジェクト指向の終えんとサービス指向の台頭 吉松 史彰 2003/08/09

---

　オブジェクト指向プログラミングが実システムの開発に利用されるようになってずいぶんたつ。オブジェクト指向プログラミングの隆盛と同じような時間軸で、システムの高度化と分散化も一般的になってきた。すると当然の帰結として、オブジェクト指向プログラミングが分散システム環境にも持ち込まれるようになった。オブジェクト指向プログラミングは当初から、プログラムをコンピュータの考え方、つまり命令を順番に実行するという手続き型ではなく、プログラムを人間の考え方、つまりインテリジェンスを持つ「モノ」に対して要求を伝えることでコンピューティングを実現するという考え方に基づいている。つまりカプセル化とポリモーフィズムである。これらは、分散オブジェクト環境に必要な「位置透過性」を最初からプログラミング環境に提供できるというメリットになった。オブジェクトがどこにあろうと、それにメッセージを伝えられれば処理が行えるというわけである。

　そこで、メッセージを伝えるという、オブジェクト指向プログラミングにおけるインフラ部分を提供する環境がいくつか登場した。CORBA、DCOM、Java RMIが代表的であり、現在も実システムで使われている。これらの環境は、要するに1台のコンピュータのメモリ上でオブジェクトが出現し、オブジェクト同士がインメモリでメッセージを送りあって動作するという従来のオブジェクト指向プログラミング環境を、そのままネットワークに持ち込むものである。PCの筐体のふたを開いてのぞきこめば、マザーボードを走り回る「バス」が見えるだろう。当初はこのバスを行き来していたオブジェクト間のメッセージが、いまやカテゴリ5のケーブルとRJ-45のソケットでつながれたネットワークを行き来するようになったのである。

　分散オブジェクト環境は、システムのモジュール化を促進するためシステムの大規模化によるメンテナンスの複雑化に対応しやすく、さらに分散配置を通じてパフォーマンスを上げやすいというメリットが喧伝された。しかも従来のプログラミング環境がそのまま使えるので、開発者は自分のスキルをスムーズに移行できた。

　しかし、実際に分散システムを稼働してみると、大きな問題があることが分かってきた。例えば、インメモリの世界では問題にならなかったセキュリティが分散環境では問題になる。また、パフォーマンスの問題もある。オブジェクト指向プログラミングはコードの再利用を促進するという宣伝文句があったおかげで、設計されたオブジェクトのコードを再利用しやすいように、1つ1つの処理の粒度は小さくなる傾向がある。粒度が小さい処理をいくつか続けて呼び出すことで実際に行いたい作業を実現するという考え方は、インメモリでは問題にはならないが、分散環境において遠く100Base-Tの先にあるオブジェクトを呼び出すにはパフォーマンスが悪くなりすぎる。

　また、オブジェクト指向とは、振る舞いと状態をカプセル化しているオブジェクトにメッセージを送って処理を依頼するというパラダイムである。1つのオブジェクトにさまざまな処理を依頼したい場合、オブジェクトが状態管理をしているので、何度もメッセージを送ってその状態を利用することになる。だが、マシンが分散している環境では、あるメッセージを送信した後、次のメッセージを送信するまでの間に、送信先のマシンでオブジェクトが破棄されたり、マシンがダウンしたりすることがあり得る。しかも「位置透過性」を実現するメカニズムのおかげで、メッセージの送信元はそれに気付かないケースが多い。

　このような問題に対処するため、分散オブジェクトを利用するシステムではいくつかの「ベストプラクティス」が存在する。例えば、オブジェクトが状態を保持していることを仮定すると、システムの負荷を分散しづらくなったり、システムダウンに伴う復帰が困難になったりするため、オブジェクトはステートレス（状態を維持しない）として設計することが勧められている。また、複雑な処理を実行するために何度もメッセージを送信するとパフォーマンスに悪影響があるので、できるだけ処理の粒度を大きくすることも求められている。これらの要件は、分散オブジェクト設計における常識である。

　だがこれらの常識は、そもそものオブジェクト指向プログラミングと相いれない。振る舞いと状態をカプセル化するのがオブジェクトであったはずなのに、分散オブジェクトには振る舞いしかない。振る舞いの実装コードを再利用しやすくするために振る舞いの定義を細かく分けていたはずなのに、分散オブジェクトにはある業務に特化した、巨大で、再利用不可能な振る舞いの定義しかできない。

　また、分散オブジェクト環境にはそれ特有の問題もある。開発者がオブジェクト指向プログラミングのスキルをそのまま応用できるようにするために、インメモリの世界では単なる関数呼び出しにすぎなかったメッセージの伝達処理が、ネットワーク環境に対応するために非常に高度に発達しているのである。オブジェクトのアイデンティティの管理、システムのセキュリティ・コンテキストの維持、システムダウンの検出と復帰など、その仕組みは高度に発達し、これらの処理を隠ぺいするためにはブラックボックス化するしかなかった。ブラックボックスであるため、ベンダ間の互換性や相互運用性は皆無に等しい。CORBAはこの問題を解決するための仕様だったはずだが、そのもくろみが完全に成功したとはいいにくい。一度何らかの分散オブジェクト環境でシステムを作ってしまったが最後、もう一度スクラップ＆ビルドをするためのお金がたまるまでは、ひたすらその環境でシステムを作り続ける以外にないのである。

　最近では、実ビジネスの環境は、システムをスクラップ＆ビルドするためにかかる時間よりも早く変化する。ビジネスを支援するためのITであるためには、既存のシステムを部分的に開発、拡張、運用できる仕組みがどうしても必要である。残念ながら、既存の分散オブジェクト環境では、本来の目的だったはずのオブジェクト指向プログラミングの流用という考え方を無視しない限り、この要件は実現できない。つまり、分散オブジェクト環境が実現するシステムにおいては、オブジェクト指向プログラミングはもはや適用できないのである。

　分散オブジェクト環境という言葉では、どうしてもオブジェクト指向と切り離すのが難しいため、IT業界はまたしても得意技を繰り出した。それが「サービス指向アーキテクチャ（Service Oriented Architecture：SOA）」という3文字言葉の創造である。

　SOAでは、オブジェクトではなくサービスに着目する。サービスとは、ビジネスにおいて競争の単位となる機能であると位置付けられる。例えば宅配業界を考えてみると、荷物の集荷から配送までの機能が他社との競争単位の1つであり、それがサービスである。集荷におけるオプションが豊富である、あるいは配送が迅速である、などの機能を持つビジネスが生き残る。小売業界を考えてみると、例えば中元の受注から先様への配送までが競争の単位となる。受注できる商品が豊富、価格が安いというビジネスが生き残る。このとき、小売業のサービスには配送業のサービスが包含されていることに注目してほしい。従って、小売ビジネスが生き残るためには、アウトソースする配送サービスをいかに正しく選択するかということが重要になってくる。場合によっては、一度選択した配送業者を、別の業者と取り替えなければならない場面もあるかもしれない。こうしてサービス同士の確実かつ安価な連携機能が求められるようになった。プロプライエタリな分散オブジェクト技術では、この要件は満たせない。この要件を満たせるのは、だれもが自由に利用でき、技術的に安定していて、ベンダに依存しない技術だけである。データ表現としてのXML 1.0、データ転送プロトコルとしてのHTTPはその有力候補である。

　だが、XML 1.0＋HTTPだけでは、分散オブジェクトで実現できていた数々の機能のうちのごく一部しか実現できない。セキュリティ機能を持たせるにはSSLだけでは不足だし、メッセージの確実な送受信を保証するにはHTTPでは無理だ。HTTPだけでは、メッセージングのパターンのうちリクエスト・レスポンスしか実現できない。そこで、これらのコンテキスト情報を含む自己記述的なメッセージを作成するために、SOAPが使われることになる。かくして、Webサービスが分散オブジェクトに取って代わることになるのである。SOAは、少なくともいまのところは、Webサービスを前提に成り立つ考え方である。WebサービスがSOAのインフラに相当する。

　オブジェクト指向プログラミングは、サービスを開発するために、サービスの内部で今後も利用されるだろう。だが、オブジェクト指向プログラミングは、あくまでも「プログラミング」のパラダイムである。サービス指向アーキテクチャは、プログラミングのパラダイムではない。ビジネスが行うサービスをどのようにシステマチックに構成するかという「アーキテクチャ」のパラダイムである。分散オブジェクトはプログラミングのパラダイムであったオブジェクト指向をアーキテクチャのパラダイムにまで昇華させようとしたが、残念ながら失敗した。しかしその志は、サービス指向アーキテクチャに受け継がれている。

　いまはサービス指向アーキテクチャが試練を乗り越えなければならない時期であると筆者は考える。分散オブジェクト「アーキテクチャ」には最初から実装方式が存在した。だがサービス指向アーキテクチャにはまだ確固たる実装が伴っていない。実装の伴わないアーキテクチャがIT業界で成功したためしはない。SOAは果たして離陸できるだろうか。

---

吉松 史彰（よしまつ ふみあき）
.NET FrameworkやXMLを中心に、開発、コンサルティング、執筆、講演活動を行っている独立コンサルタント。連絡先はfumiakiy@luckypines.com。

「Insider.NET - Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）