IT: 2009年11月アーカイブ

ＳＯＡなんか使えない、そんな声も聞く。ある意味でそれは正しい。なぜなら、ＳＯＡ化を成功させる要素がいくつか欠落しているからだ。ＳＯＡそのものの目的と自分たちの目標とするものが一致しているのかという根本論からはじまって、（必要最小限の）ＢＰＲの欠落、機能仕訳の甘さ・・・などなど。しかし、最も大きいのは、優良なサービス、つまりサーバサイドの部品の選択肢が少ないことだ。ＳＯＡの真価はサーバサイドの汎用化、部品化によるコストと工期の削減にある。しかも、たとえばより処理性能のいいサービスと入れ替えたとしても、フロントであるユーザインターフェイスへの影響は少ないし、ユーザにとっての使い勝手は変える必要がない。しかし、サービス、つまり、サーバ側の部品の選択肢が、少数のパッケージベンダが提供する独自仕様のサービスのみであったとしたら、苦労をしてＳＯＡ化する意味も薄れてしまう。こればかりはユーザがいくら頑張っても、解決は難しい。

ＳＯＡに至るシステムアーキテクチャの流れは、小さな湖でせき止められてしまうかに見えた。しかし、やがて、この流れも、あふれて大きな海に流れ込む。インターネットという大海にだ。そこで、他の水と混ざり合い、新たな命をはぐくむことになる。

こうして、インターネットという海は、すべてのＩＴの流れを受け止めて、大海となり、水はまた空に戻って雲となる。この雲の中には、すべての川の流れによって持ち込まれた水が混在している。いや、存在していなければならないのだと私は思う。次の章では、雲の成分について、少し詳しく考えてみよう。

（１章終り）

ソフトウエアの生産性を上げるための取り組みの流れをもう一度考え直してみよう。標準化にしても、構造化にしても、オブジェクト指向にしても、すべてプログラムの再利用もしくはもう一歩進めて汎用的な部品化を行うための考え方だと言える。このためには、似て非なる処理に共通した部分と違う部分を徹底的に洗い出し、分離することや、必要に応じて、プログラムの構造を、それに適した形に変えてやることが必要になる。

ビジネスロジックの部分でも、それは同じだ。後者がＢＰＲならば、前者はビジネスロジックの汎用化である。幹と枝葉をきちんと分離できれば、多くのビジネスロジックは共通化できる。これまでパッケージではこの作業が行われてきた。それにより、ユーザのカスタマイズ要求に対して、変更が必要な部分を局所化して、カスタマイズ作業の負荷を減らすことを目指してきたわけだ。ただ、パッケージという、ある意味で閉鎖的な環境の中では、この共通化という作業はそれ以上の意味をもたない。だから、案外、この仕分け作業は中途半端に終わってしまい、時にはユーザの要望に応じるために、本来共通化されているはずのロジックにも手をつけざるを得なくなってしまう。だから、こうした作業そのものが無意味だという極論を言う人もいるわけだが、むしろ、パッケージという閉じた世界では、無意味というよりもそれを徹底的にやるだけのメリットが、ベンダにはないのだろう。カスタマイズの余地が多いほど、そのパッケージを使ってカスタマイズする仕事が増えるからだ。つまりは、パッケージを担いでくれるＳＩ会社の仕事を増やすことにつながり、そのパッケージが好んで提案される理由となる。ユーザにとって使い勝手をよくするカスタマイズが柔軟に可能である・・・という理由が表向きの話だが。

これはベンダ目線にほかならない。ユーザ側から見れば、工期や工数を削減する目的でパッケージを選んでいるはずなのに、実際は、カスタマイズに大きな費用がかかり、工期もどんどん長くなる。ユーザから見れば、こんな馬鹿げた話はない。おまけにビジネス環境はめまぐるしく変わるのだから、それになかなか追い付いていけないＩＴは常に経営陣の悩みの種になってしまう。ユーザから見れば、最初の段階でシステムのそれぞれに機能に選択肢があり、それを組み合わせると必要なシステムが出来上がるような、いわば、システムのＢＴＯ（Build To Order）モデルがあるといいわけだ。パソコンのＢＴＯは、ＣＰＵ，メモリ容量、ＨＤＤの容量、周辺機器など、様々な仕様をユーザが指定したとおりに組み立てるものだが、必要なパーツは規格化、標準化されていて、メーカーはそれを組み合わせて組み立てるだけである。（厳密にいえば、これはＣＴＯ（Configure To Order）とも言えるが、CTOは標準製品の一部だけを別仕様に変える、もしくは選択する・・という意味のほうが強いのではないかと思うので、パッケージのカスタマイズに近い）　要するに、システムのＢＴO化が望まれるわけだが、残念ながら、情報システムのパーツは業界レベルでは標準化されておらず、ユーザにとって自由に選択できる状況には程遠い。たとえば、各パッケージベンダが自社のパッケージの一部分を標準化したいと思っても、意外と敷居が高い。記述されている言語も違えば、使っているデータベースも違う。たとえば、ユーザがＡ社の営業系パッケージとＢ社のＥＲＰパッケージの会計部分を組み合わせてシステムを作りたいと思っても、単純にそれを張り合わせることは不可能だ。こうした違いを乗り越える、新しいアーキテクチャが必要だ。

違う言語やデータベースを使って作られた「機能」をうまく連携させて使うにはどうしたらいいのか。こうした違いを超えて、互いにその機能を「呼び出せる」ようにできればいいのだが。たとえば、ネットワーク上のサービスとしてその機能が定義されていて、その呼び出しのインターフェイスも通信手順として標準化されていたなら・・・。

私の目線から見たＳＯＡ（Service Oriented Architecture）とは、このようなものだ。

（続く）

さて、このあたりからネットワークが重要な役割をはたしはじめる。イーサネットをはじめとする、データリンク層（いわゆるレイヤ２）のプロトコルや物理層としての伝送メディア規格（レイヤ１）は早い段階で標準化はされていたが、いわゆるネットワークを作るためにはこれだけでは不十分だ。レイヤ３から上の層のプロトコルが必要である。しかし、最初の段階で、コンピュータ間通信のプロトコルは、そのOSやネットワークソフトウエアベンダに固有のものだった。一方で、国際的な標準化の動きも出てきたが、様々な利害がからんで遅々として進まなかった。その筆頭格であるOSIは、具体的なプロトコルの定義に入ったところで、事実上挫折してしまう。ただ、OSIがプロトコルを定義するために作った７階層の参照モデルは広く使われて、その後のプロトコルモデルの事実上標準となった。これはなんとなく皮肉な話かもしれない。一方、UNIX系のネットワークは米国を中心とした、政府、軍、教育機関などを繋ぐネットワークとしてどんどん普及していき、現在のインターネットの原型となった。もちろん、プロトコルはTCP/IPである。しかし、OSIの７レイヤモデルで見ると、TCP/IPとして総称されるプロトコル群、つまりレイヤ３のIPプロトコルとその補助的な役割をするICMPプロトコル、レイヤ４での確実な接続を保証するTCPと、同じくレイヤ４で軽量なデータグラム通信を行うUDPは、コンピュータ上のプロセスが１対１もしくは１対Nで通信をするための仕組みまでしか提供しない。OSIでいうところのレイヤ５（セッションの管理）とレイヤ６（交換されるデータの表現方式の互換性保障）、そしてレイヤ７（特定のアプリケーション間で行われる通信の約束事）は、まとめてTCP/IPの上で動くアプリケーションにゆだねられている。完璧にレイヤ７まで定義しようとしたOSIに対してTCP/IPのこの緩さが勝ったという見方もできるだろう。

いずれにせよ、やがてPCの世界もTCP/IPが主流になる。これまで独自のプロトコルを使ってきた各OSベンダは、レイヤ４以下でTCP/IPを使うモデルに移行しはじめた。また、UNIX系で使われているtelnet, ftpをはじめとする各種のアプリケーションもPCに実装され、PCとUNIXの世界がネットワークを介して接続されるようになった。当時は、UNIX系の処理能力がPCに勝っていたため、UNIX系を核としてPCを接続するようなモデルが広まりはじめる。PCが能力を持つことで、これまでメインフレームに集中していた処理をPCに分散することが可能になり、金食い虫のメインフレームを排除できるかもしれないと、PCやワークステーションメーカーは期待した。しかし、それはなかなか簡単ではなかった。個々のPCで処理を行っても、データをうまく共有できなければ、システムとしては成り立たない。つまり、少なくともデータは集中的に管理できる形が必要だった。そこで、能力に勝るUNIX機をデータ共有・管理のためのサーバとして使い、PCでそのデータを処理させる、初期のクライアント・サーバモデルが出来上がったわけだ。元来、技術計算用のワークステーションを作ってきたメーカーの多くが、サーバ用の高性能、高信頼性、大容量の機種を作り始める。しかし、このモデルでは、データのみをサーバに集め、ビジネスロジックは、そのほとんどをクライアント側で処理するという形であったため、アプリケーションを大量のPCにばらまく必要があり、その管理や保守コストの増大を招いてしまう。また、アプリケーションはOSやPCのアーキテクチャに依存してしまうため、たとえばWindowsとMacでは、同じことをするために違うプリケーションを作らなければならない。まんまとメインフレームを駆逐しつつあったクライアント・サーバモデルだったが、システム導入のイニシャルコストが大幅に下がった一方、保守・運用コストが著しく増加するという問題を招いてしまったのだ。

ここからの流れは、ほとんどの人が知っているはずだ。ハードウエア、ソフトウエア、ネットワークという大きな３つの流れは、インターネットという大きな海にたどりつく。この海を渡るための船がWebブラウザだ。一方、船がたどりつく先の港（Webサーバ）側では、船の乗客に対して魅力的なサービスを競って提供するようになる。それにつれて、船も大きく進化し、港もまた利便性に富んだものとなっていく。ブラウザの高機能化、様々なプラグインツール、これらを使って、使い勝手の「悪くない」サービスを提供できるようになると、アプリケーションは次第に、サーバ側に戻り始める。最初は、クライアントの使い勝手や互換性向上を目的に作られたJAVAは、クライアント側での処理系の重さや、目的とはちぐはぐな実行系の仕様変更などにより、バージョン依存などの問題が激しく、なかなか使い物にはならなかった。一方、サーバ側でも、Web用のアプリケーションを記述するためにJAVAを含む、様々な言語が使われはじめると、クライアント・サーバモデルは、あっけなく「ブラウザ・Webサーバ」モデル、すなわち結局、昔のメインフレーム＋ちょっとインテリジェントな端末のモデルとほとんど変わらない形に戻ってしまったのだ。これで保守・運用コストはとりあえず低減できたのだが、今度は、時代の流れとともにアプリケーションの肥大化に悩まされることになる。

（続く）