話題のSOAについて考える : その1 SOAって、ナンだろう?：エヴァンジェリスト・コラム（2/2 ページ）

[米持幸寿/日本IBM，ITmedia]

代理コードとは何か

　さて、次に代理コードについて説明しましょう。先ほどの＜プログラムコード1＞を、＜ソースコード2＞のように書き換えてみます。

　重要なことは、先ほどと違い、左側のプログラムは中央のコードを経由して右側のコードを呼び出している、ということです。この中央のコードが、代理コード（プロキシ）です。

　代理コードを仲介させる目的は、結合方法（バインド方法=バインディング）を変更しやすくするということです。

　先ほどのadd2zipはデータベースを使う関数ですから、中央に「郵便番号データベース」が存在し、集中管理したほうがよいというアイデアが浮かんだとします。この時、関数を「中央のコンピュータで稼働させておく」場合、どのようにすべきでしょう

　今日では、ネットワークの先にあるプログラムコードを結合（バインド）する方法はたくさんあります。シリアル・パラレル・インターフェイス、ネットワークパイプ、IPソケットなどのレガシーな方法、EDI技術、EAI技術、ファイル転送などの汎用的な方法、DCERPC、CORBA、Java-RMI、EJB、COM/DCOMなどの分散オブジェクト、Web サービスなどです。

　これらの技術を使うためのミドルウェアやライブラリも複数ありますが、それぞれコーディング方法が違います。しかも多くの技術は、ネットワークに流すデータを自分のプログラムコードで組み立てる（マーシャリングする）必要があります。

　＜ソースコード1＞のようなコードだと、分散した時に使ったコードをアプリケーション中に書き込む必要があります。しかし、一度書き込んでしまうとその技術や分散した相手側のシステムの技術に依存したソフトウェアコードなってしまいます。

　どんな技術を使って呼び出すとしても、ある特定のインターフェイス（add2zipなど）にアクセスするなら、呼び出し側（コンシューマ）は同じプログラミングで済ませられるようにするため、プロキシが存在します。

　技術に依存したプログラムコードはプロキシに書き込みます。そうすることでアプリケーションコードはそのときの結合技術（多くの場合ネットワークプロトコル）に依存しないプログラムになるのです。

インターフェイス情報と記述言語

　さて、ネットワークプロトコルに依存するコードをプロキシに書くことで、アプリケーションコード（コンシューマ）がネットワークプロトコルに依存しないことが分かりました。ですが、これではコード量が増えるだけで、あまり効率的な作業はできません。

　しかし、ここで重要なのは「プロキシ（スタブ）コードは自動生成できる」という点です。

　先ほど列挙したレガシーな分散技術のいくつかは、プロキシ（スタブ）を利用します。これらの言語は「インターフェイス定義言語（IDL）」という技術を使ってプロキシ（スタブ）を自動生成します。そのため、ネットワークにアクセスして関数名、引数、戻り値などをやりとりするためのプログラムコードをコーディングする必要はありません（図2）。

　SOAを採用する上で重要な点は、記述言語で表現可能なインターフェイスを持ち、無理なくインターフェイスを定義言語で定義するということです。バイナリフォーマットのEDI、EAI、ファイル転送などの多くに、今日の定義言語は対応できていません。

　さて、今回の解説をまとめると、以下のようになります。

　SOAは、「呼び出し可能」な、そして「記述可能」な「インターフェイス」を持った「関数」を「稼働させて」おき、外部のプログラム（コンシューマ）から「プロキシ」を経由して「呼び出す」ソフトウェア構造です。プロキシは「記述言語」を利用して自動生成できます。

　今回はソフトウェアの作り方がSOAであるということがどういうことか、とても細かい部分でお話をしてみました。「そういう構造のことを指しているということは分かった。でもどうしてこんなに騒がれているの?」と疑問に思われたことでしょう。次回は、SOAを実現するために今日使われるようになったいくつかの技術、そしてそれらを使うことによって得られる効果について解説します。