SOAについて知るべきことはすべてLinuxから学んだ：Beginner's Guide（1/2 ページ）

SOAがよく分からないとお考えのあなた、心配することはない。SOAについて知るべきことはすべて、Linuxおよびオープンソースソフトウェアの運動から学べるのだ。

[Shawn-Hermans，Open Tech Press]

　サービス指向アーキテクチャ（SOA：Service Oriented Architecture）について書かれたオンラインマガジン、ブログ、業界誌、書籍は数多くあるが、SOAについて知るべきことはすべて、すでにわたしがLinuxおよびオープンソースソフトウェアの運動から学んでいたことだった。

　前述のような出版物による行き過ぎた宣伝攻勢をなんとか免れた人々は、SOAを最近のIT業界を襲った過度の流行ととらえている。皮肉な見方をするIT業界関係者の中には、SOAをベンダーが高価な“SOA対応”製品を無知なITマネジャーに売りつけるためのマーケティング用語と考えている人もいる（わたし自身もそうだ）。SOAは業界用語としての確固たる地位を確立する一方で、その概念はきちんとした実体を伴っている。SOAという用語に統一された定義は存在しないが、大半の定義ではソフトウェアサービスを使って柔軟なアーキテクチャを生み出すという点に重きが置かれている。

　例えば、Burton Groupのアン・トーマス・マネス氏はSOAを次のように説明している。「統合と柔軟な適用を努めて容易にしようとする設計のスタイル。SOAでは、アプリケーションの機能が再利用可能な共有サービスとして設計される。サービスとは抽象インタフェースを通じて公開されるアプリケーション機能であり、抽象インタフェースによってサービスの実装の内部構造は隠蔽される」

　この定義は、SOAの重要な利点を強調したものになっている。企業は新たなコーディングを行わずにサービス（すなわちソフトウェアコンポーネント）を再利用することでコストを削減し、既存ソフトウェアを別の目的に転向させることで新しいビジネスニーズに適応できる。こうした話のすべてに聞き覚えがあるとすれば、それはUNIXベースのOSおよびオープンソースソフトウェアの主な利点に通じるものがあるからだろう。これは決して偶然の一致ではない。というのも、Linuxに大きな成功をもたらしたのと同じアーキテクチャ上の原則がSOAを支えているからだ。

　Linuxの設計原則の多くはUNIXのものに由来している。従って、Linuxがその成功で得た評判はUNIXと分かち合わなければならない。UNIXのパイプの概念を発明したドン・マクロイ氏は、UNIX哲学の最も単純かつ簡潔な説明の1つを次のようにまとめている。「1つのことだけをうまくやるプログラムを書く。互いに連携して機能できるプログラムを書く。テキストストリームを扱えるプログラムを書く。なぜなら、それが普遍的なインタフェースだからだ」

　エリック・レイモンド氏はこれらの基本原則を『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）は、OS間でのアプリケーション互換性を実現できる標準化された一連のインタフェース規格である。プログラマーが各種UNIXアプリケーションをほかのUNIX互換のプラットフォームに移植できるのは、こうした標準化されたインタフェースのおかげだ。Linuxも標準のUNIXインタフェースを実装しているため、開発者はLinuxにUNIXアプリケーションを簡単に移植できる。開発者がプロプライエタリなUNIXプラットフォームからオープンソースのプラットフォームへと移行できたのは、インタフェースに互換性があったからである。オープンインタフェースの利用を考えないプログラマーは、ベンダー固有のテクノロジーに頼ることになり、SOAの恩恵を受けられない可能性が高い。