SOAについて知るべきことはすべてLinuxから学んだ
前述のような出版物による行き過ぎた宣伝攻勢をなんとか免れた人々は、SOAを最近のIT業界を襲った過度の流行と捉えている。皮肉な見方をするIT業界関係者の中には、SOAをベンダが高価な“SOA対応”製品を無知なITマネージャに売りつけるためのマーケティング用語と考えている人もいる（私自身もそうだ）。SOAは業界用語としての確固たる地位を確立する一方で、その概念はきちんとした実体を伴っている。SOAという用語に統一された定義は存在しないが、大半の定義ではソフトウェアサービスを使って柔軟なアーキテクチャを生み出すという点に重きが置かれている。
たとえば、Burton GroupのAnn Thomas Manes氏はSOAを次のように説明している。「統合と柔軟な適用を努めて容易にしようとする設計のスタイル。SOAでは、アプリケーションの機能が再利用可能な共有サービスとして設計される。サービスとは抽象インタフェースを通じて公開されるアプリケーション機能であり、抽象インタフェースによってサービスの実装の内部構造は隠蔽される」
この定義は、SOAの重要な利点を強調したものになっている。企業は新たなコーディングを行わずにサービス（すなわちソフトウェアコンポーネント）を再利用することでコストを削減し、既存ソフトウェアを別の目的に転向させることで新しいビジネスニーズに適応することができる。こうした話のすべてに聞き覚えがあるとすれば、それはUNIXベースのオペレーティングシステムおよびオープンソースソフトウェアの主な利点に通じるものがあるからだろう。これは決して偶然の一致ではない。というのも、Linuxに大きな成功をもたらしたのと同じアーキテクチャ上の原則がSOAを支えているからだ。
Linuxの設計原則の多くはUNIXのものに由来している。したがって、Linuxがその成功で得た評判はUNIXと分かち合わなければならない。UNIXのパイプの概念を発明したDoug Mcllroy氏は、UNIX哲学の最も単純かつ簡潔な説明の1つを次のようにまとめている。「1つのことだけをうまくやるプログラムを書く。互いに連携して機能できるプログラムを書く。テキストストリームを扱えるプログラムを書く。なぜなら、それが普遍的なインタフェースだからだ」
Eric Raymond氏はこれらの基本原則を『The Art of Unix Programming』（邦題同じ）で発展させている。この本の中で彼はUNIXの哲学に丸々1つの章を割き、ソフトウェア開発の指針となる17項目の設計原則を掲げている。ソフトウェアの設計者および開発者は、優れた設計によるSOAの構築を目指して、これらの原則を利用することができる。
SOAを手がけるアーキテクトは、以下に示す5つの重要な原則をLinuxおよびOSSコミュニティから学ぶことができる。
やることは1つに絞って上手くやる ― これは最も単純なデザインパターンの1つであり、プロプライエタリなベンダがほとんどの場合に勘違いしている点でもある。彼らは設計を単純化して1つのことをうまくやる小さなプログラムを作るのではなく、ほとんど使われることのない機能を詰め込んだ巨大なプログラムを設計している。この教訓は、既存のソフトウェアコンポーネントをサービスとして公開したい人々や新しいサービスを開発しようとしている人々にも当てはまる。公開対象のサービスでは、ただ1つの単純な機能に注力すべきである。一般に新たな機能を加える場合は、既存のサービスを拡張するのではなく新しいサービスを作るようにすることだ。
プログラムどうしの連携を考えた設計を行う ― コマンドラインインタフェースはSOAを具現化したものといえる。ユーザは、シンプルで目的が1つに絞られたプログラム（しばしば“サービス”と呼ばれる）を実行時に組み合わせて複雑な作業を実行している。Linuxユーザはプログラムどうしを連携させるための高価なオーケストレーション・エンジンを必要とせず、むしろスクリプト言語やシェルスクリプトのような手段を使って同様のことを行う。この設計原則のおかげで、Linuxはわざわざコードを書き直さなくても幅広いタスクの実行に対応できる。
削除ファイルの復旧作業における私の経験は、単純なプログラムの組み合わせで複雑なタスクが行えることを裏付けている。ファイルの復旧処理の途中で私が書いたシェルスクリプトは、JPEGファイルのEXIFタグから情報を読み取り、そのタグの情報に基づいてファイル名を変更して、これらのファイルをEXIFタグの日付順にソートするためのフォルダを自動的に作成できるというものだった。だが、商用のツールにはこれと同じ機能を単独で実行できるものはなかった。
SOAの実装に使われるテクノロジとは関係なく、明確でわかりやすくて安定したインタフェースを設計することは、サービスどうしを連携させるうえで非常に重要である。インタフェースが安定していれば、基本的なソフトウェアアーキテクチャを変更しても外部のサービスに影響が及ばないことが保証される。あらかじめ時間を取って、開発対象のサービスがどのように外部のサービスとやりとりを行うかを考慮してインタフェースを設計すること。インタフェース設計を念入りに行えば、後々起こり得る大幅な変更を防ぐことができる。
SOAの場合、テクノロジの面で健全なオープンなインタフェース規格が存在するなら、自作せずにそれらを利用すべきである。POSIX（Portable Operating System Interface）は、オペレーティングシステム間でのアプリケーション互換性を実現できる標準化された一連のインタフェース規格である。プログラマが各種UNIXアプリケーションをほかのUNIX互換のプラットフォームに移植できるのは、こうした標準化されたインタフェースのおかげだ。Linuxも標準のUNIXインタフェースを実装しているため、開発者はLinuxにUNIXアプリケーションを簡単に移植できる。開発者がプロプライエタリなUNIXプラットフォームからオープンソースのプラットフォームへと移行できたのは、インタフェースに互換性があったからである。オープンインタフェースの利用を考えないプログラマは、ベンダ固有のテクノロジに頼ることになり、SOAの恩恵を受けられない可能性が高い。
正しい方法は1つだけではない ― 誰でもいいのでLinux愛好家にお気に入りのディストリビューション、デスクトップ環境、コマンドシェル、あるいはスクリプト言語について尋ねてみよう。きっと時間をかけて熱心に答えてくれるはずだ。Linuxは、同じことをするにも競合する多くの方法を用意することで高い順応性を獲得している。たとえば、デスクトップ環境の選択肢の多さゆえに、Linuxは低スペックのデスクトップマシンでも、最新のド派手なグラフィカル・アイキャンディで飾られたハイエンドなワークステーションでも動作させることができる。
同様に、SOAの実装方法についても互いに矛盾する多くの考え方が存在する。SOAPを使うのがサービスを公開する正しい方法だと言う人がいる。一方で、サービスの方針としてRuby On RailsのようなREST（Representational State Transfer）の原則の利用を提唱する人もいる。どちらの実装方法にも一長一短あり、それらが功を奏するアプリケーションもあれば相性の悪いアプリケーションもある。誰であれSOAの実装方法は1つしかないなどとのたまう者を信じてはならない。SOAの実装は、SOAベンダの製品にではなく、個々の組織のニーズに合わせて適宜変えることだ。
共有は皆のためになる ― 実は、私がこの教訓を学んだのは幼稚園にいたときでLinuxから学んだわけではないのだが、それでも優れた考え方であることに変わりはない。Linuxの成功は、サービス（ソフトウェアコンポーネント）とその背後にあるソースコードのどちらが対象であっても共有によって恩恵が得られることを実証している。
サービスレジストリはサービスを見つけ出すための不可欠な手段だが、必ずしも完成されたソリューションではない。公表されているサービスの提供と管理をサービスプロバイダに頼っているからだ。ときには、レジストリに公表されているサービスが、ほとんどサポートのない“ホビーショップ”プロジェクトにすぎないこともある。
集中型のソースコードリポジトリはサービスレジストリをもっと強化したもので、サービスの再利用だけでなくコードの再利用も促進されるというメリットがある。そうしたソースコードリポジトリには、開発チームのニーズに合わせてサービスの変更や導入が行えるという柔軟性がある。現在、多くのソースコードリポジトリが利用可能であり、その中には有名なSourceForgeリポジトリのエンタープライズ規模版も含まれている。
結局、共有は文化的な問題であって技術的な問題ではないため、共有を成功させるにはあらゆる層の管理職に働きかける必要がある。一部の企業が外部に自社のソフトウェアやコードを公開したがらないのはわかるが、内部的にはコードとサービスの再利用を奨励するべきだろう。
開発者を信頼する ― SOAの世界には、トップダウン、ミドルアウト、ボトムアップというSOAに関する3つの考え方が存在する。トップダウンSOAでは、経営上層部が設計上の重要な決定を行い、全体のプロセスを主導する。ボトムアップSOAでは、個々の開発チームが公開するサービスとその公開方法を決定する。ミドルアウトSOAはトップダウンとボトムアップの両方のアプローチを融合したもので、重要な基準の決定は管理職が行うが、設計上の決定は開発チームに委ねられる。
Linuxは開発者主導色の強いアーキテクチャの例であり、一方Microsoftはトップダウンアプローチをことさらに強調している。Microsoftの元社員Moishe Lettvin氏は「丸1年かけてある機能の設計に取り組んだが、その実装とテストは1週間で終わった」という話をしてくれた。遅れやコードの書き直しが生じる主な原因は階層の多すぎる官僚的組織構造にある、と彼は言う。Lettvin氏の体験は、トップダウンアプローチを優先した設計や実装の危険性を物語っている。
LinuxおよびOSSコミュニティ以外では、Googleが開発者主導の体制を実現している企業の例として最も良く知られている。Googleでは、社員が就業時間の2割を自分自身のプロジェクトに割り当てることができる、という方針を取っている。Google NewsやGoogle Suggestなど、Googleの成功したプロダクトの多くは、こうした開発者主導型の取り組みの成果である。
組織的な統治（governance）はSOAの成功にとって重要だが、技術的な詳細を理解していない者による統治は、SOAの実装の成功を妨げる可能性こそあれ、役に立つことはない。Linuxを統治するための全体的な手法は存在しないが、Linuxはこれまでに開発されたオペレーティングシステムの中で最も柔軟性に富んだものの1つである。これは、テクノロジを理解していない者ではなく開発者によって実装上の決定が行われていることに起因している。どんな統治手法でも、基本となるテクノロジを十分に理解している人々からの意見を大いに採り入れる必要があるのだ。
ITアーキテクトは、自分たちのシステムアーキテクチャを単に流行に迎合したものに終わらせないために、エンジニアリングに関する正しい原則を求めている。オールインワンソリューションを謳うベンダの高価なSOA製品に資金を投じるのではなく、以前から有効性が実証されている設計原則を適用する必要がある。ともすれば忘れがちなことだが、最も大切な教えは最初の頃に学んだ基本事項にあるのだ。
Shawn Hermansはグローバル戦略立案および技術コンサルティング会社Booz Allen Hamiltonでコンサルタントを務めている。
ITManagersJournal.com 原文
