広がる環 - 真に生まれ出づるときを待つSOA

もう何年も前から、業界はSOAという新たに浮上した抽象レイヤをもてあましてきた……。それはかなりの時間をかけて生まれ出ようとしている。

SOAはどこかW.B.イェイツの詩「再臨」を思い出させる。「荒々しい野獣が、ついにそのときが来て」というくだりだ。

企業の内部は「砕け散り」、ものの見事に「中心は保たれない」。そもそも中心とは何だろう? 企業内アプリケーション? SAP? Oracle? メインフレーム? IBM? デスクトップ? Microsoft? データセンタ? HP?

Javaはコアの部分では1つのシステムをなしていて、それはエレガントなものだった。純粋主義者たちはJavaがなしてきた妥協のすべてを非難するだろう。けれどもそこには、数多くの「エレガントな妥協」があった。こう言うと矛盾のように聞こえるだろうけれど、企業というのは本来、妥協する生き物なのだ。Javaの何が興味深いかというと、それが示していた若干の認識だ。つまり、仮想マシンの導入でスピードこそ犠牲にしたものの、それまでCやC++を用いていた人々にとって馴染みやすく、また生産的でもあるような言語になることで、その犠牲を補ったのだ。人間のスピードを、マシンのスピードよりも重視したのだ。強い型付けがなされているため企業の構造化データにも対応でき、一方で遅延バインディングであるため柔軟かつ動的でもあった。

けれども、当然ながら市場は代替品にすら代替品を求める。Javaの代替品として挙げられるのは明らかに.NETだが、ひとたび当初の一枚岩にひびが入ると、当然そこから数多くの亜流が出てくるようにもなる。Bill Gatesが、分野ごとの専用の言語まで含めて「多数の言語」と述べたのは、間違いなく正しい言い方だったと思う。言語は「ユーザインタフェース」の一部なのであり、言語が違えば得意とする表現内容も違ってくるわけだから。けれどもJVMのバイトコードはチューリング完全だ(チューリング機械と同等の計算能力がある)。そんなわけで、PHP、Ruby、Groovyなど、ほかのどんなものでもバイトコードにすることができた。ちょうどVisucal BasicやC#その他を、CLR用のILにできるように。

広がる環は、回りに回る。
鷹は鷹匠に従わない。
なにもかもが砕け散り、中心は保たれない。
世界に放たれるのは無秩序だけ。
血の色をした濁流が押し寄せ、あらゆる場所で
純白のセレモニーは水に没する。
最良のものはあらゆる信頼を失い、最悪のものは
激情に満ちあふれる。
確かに、なんらかの啓示が迫っている。
確かに、再臨のときが迫っている。
再臨! そうした言葉が発せられるや否や、
世界の霊魂から出でる巨大な像が
わたしの視覚を乱してくる。どこか砂漠の砂の中で
獅子の体躯と人の頭をもったものが、
太陽のように虚ろで容赦のない視線を投げかけ、
ゆっくりとその腿部を動かし、そのまわりには
獰猛な砂漠の鳥たちの影が輪をなす。
再び闇の帳が降りる。けれども今や私は知る。
20もの世紀におよぶ石のような眠りは
揺りかごに揺られ悪夢と化したことを。
いったいいかなる荒々しい野獣が、ついにそのときが来て、
ベツレヘムの方角に身をかがめ、生まれ出ようとするのだろう?

ボストンで私は、SOAに懐疑的な、451グループのレイチェル・チャルマーズと話をした。彼女の考え方には私も大いに賛同した。それはたぶん、彼女が歴史を踏まえているからだろう。技術革新は普通、企業の外からもたらされ広がっていく、と彼女は言う。クライアント/サーバ、Webアプリケーションサーバ、モバイル技術、ソーシャルソフトウェア、クラウドアプリ、SaaSなど、いずれも革新の起源は企業の外にあった。クラウドの中でエレガントなWebアプリを構築できるときに、複雑なSOAPで手を煩わそうなどとどうして思うだろう? スケーラビリティは無償で手に入る。アベイラビリティも同様だ(と願いたい)。今週起きたGoogleアプリの不具合は、アベイラビリティは無償ではないことを示したけれども、そのアベイラビリティ自体はなかなか優れていて、確実に大半の企業アプリと同等かそれ以上だ。

彼女の異論は、SOAPには当初から欠陥があり、皆でRESTを採用すべきだというものだった。将来的にこれは正しい判断となるだろう。RESTに対してSOAPのスタイルが好まれる背景には、リソースは限定的なので統制されなくてはならない、という世界観がある。リソースが無限で無償だ、などという世界観ではない。WebではGoogleのスタイルが、システムはつねにスケーラブル、つねにアベイラブル、かつ無償だとの認識の上に立っている。

企業の中枢には、財務報告や会計、サプライチェーン、人的資源などを管理する古めかしいシステムがある。SAPやOracleのようなパッケージアプリの場合もあれば、IBMのメインフレームアプリのようなカスタムアプリの場合もある。これまでのところ、企業の中枢に位置するそれらコアシステムを廃止し置き換えようという試みは、ことごとく失敗してきた。企業のパラダイムは、そうしたシステムの安全、信頼性の確保、スケーラビリティの検証と調整、可能な場合にはインターオペラビリティの実現など、さまざまな要求に満ちている。SOAPのヘッダが登場するとすぐに、それまで内部システムで扱われていたそれらの複雑な案件や、そこに密接に結びついていたレガシーアプリは、そのヘッダへと一気に逆流し始め、WS標準がエンドレスに生まれるサイクルが始まった。

正直なところ、これは見ていて美しい光景ではない。SOAPはエレガントさに欠け、結局かなり大きな負担と厄介なヘッダに苦しめられることにもなりうる。企業から外に出る場合、デリバリーシステムが必ずしもヘッダを完全にサポートするとは限らない。

けれども先に述べたように、コアシステムを放棄できないために、企業は行き詰まってしまう。おそらく、そうしたレガシーシステムを引きずるための費用は相当に大きく、大企業は打つ手がなくなり、より効率性に優れた中小企業の波に飲み込まれていくのだろう。そうした中小企業なら、財務から取引処理、カスタムアプリ、クラウドでのビジネスプロセスなど、すべてをこなせる。おそらくは。

けれども、そうなるのはまだまだ先だ。歴史的にもあまり前例がない(だからといって、将来そうならないとは限らないのだが)。歴史からすれば、大企業はますます大きくなり、レガシーだらけになったのだが。

とりあえずそれまでは、SOAはベツレヘムの方角に身を屈め、生まれるときを待ち続けるだろう。

(翻訳: 嶋崎正樹 / イラスト: ひのみえ)