連載「作る！SOAアプリケーション」：第1回　SOAのソフトウェア構造

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

米持 幸寿, テクノロジー・エバンジェリスト, IBM

2006年 9月 02日

この連載では、SOAを採用したアプリケーションをどのように構築していくか、ITの観点から具体的な例をあげて解説していきます。
ソフトウェア開発の内容ですので、少し難しいですが、プログラマの方ならきっと理解できる内容です。ぜひ読んでみてください。

本連載でのSOA

先に申し上げておきます。この連載では「SOAソフトウェア構造」を元に話を展開します。筆者はSOAの効果を最大限に発揮させるのはソフトウェア構造をSOAに合致したものにしないといけないと考えるからです。SOAの効果を最大限に発揮させるのは、SOAソフトウェア構造です。

SOA（Service-Oriented Architecture：サービス指向アーキテクチャー）という言葉の定義にはいろいろなものがあります。もともとは分散システムのソフトウェア構造を表すIT用語でした。しかし最近では、多くのベンダー、多くのエンジニア、コンサルタントなどがSOAを語るようになり、システム構造の思想から、ビジネス（企業）構造のありかた、というところまで発展してしまっています。

ソフトウェアをSOAの構造に対応させていかなければ、ビジネスのSOA化はありえません。ビジネス構造だけをSOAにしても、ITシステムはその期待に応えられません。逆に、ソフトウェアだけをSOA構造にしても、ビジネスでSOAを実現したり効果を発揮させることはできません。ソフトウェアとビジネスの両面でSOAにアプローチすべきです。

本連載は技術記事ですから、ソフトウェアの作り方について言及していきます。
ITシステム、とくにソフトウェアをSOA的に作るにはどういうことをすればいいか、なにに気をつけなければならないか、そういった「ITアーキテクト」的、あるいは「プログラマ」的な視点から、SOAの実践方法について解説したいと思います。SOAの非常に狭い範囲の「SOAを実現するソフトウェアとはこう作るのだ」ということを解説していきます。

ソフトウェアの構造論を語るといろいろな面で反論が起こります。内容は納得できるものもありますが、このソフトウェア構造を語る上で妨げになるため、本記事では「SOAソフトウェア構造」と呼ぶことにします。本連載は「SOAソフトウェア構造」を解説するものです。

上に戻る

SOAソフトウェア構造の概説

IT、とりわけアプリケーション・ソフトウェアの構造を表す「SOA」については、こちらに判りやすい解説がありますので、まずは読んでみてください。わたしの一番弟子のM氏が書きました。SOAを理解しているエンジニアの一人です。

SOA入門

さて、入門を読んでいただいたところで、再定義しておかなければならないでしょう。この連載では、「SOAソフトウェア構造」の話を進めます。それは、以下のようなものです。

• ソフトウェアの機能を独立性の高い状態で切り出す
• これをどこかのシステムで稼動させておき、いつでも呼び出せるようにする
• このソフトウェアには、「別のプログラムコードから呼び出せる」機能＝「インターフェース」が備わっている
• このインターフェースは、ソフトウェアの関数のようなものである
• この稼動している、インターフェースを持つ機能を「サービス」と呼ぶ
• 関数がどういう型になっているかは、記述言語と呼ばれるデータで表現できる
• このソフトウェアは、外部のプログラムコードから呼び出すとき、「プロキシーコード（あるいはスタブコード）」と呼ばれるしくみを経由して呼び出される
• サービスを呼び出す外部のプログラムコードを「コンシューマー」と呼ぶ
• プロキシーは、サービスを呼び出すための仲介機能を提供する
• プロキシーは記述言語を使うと自動生成できる
• プロキシーとサービスを結合するIT技術を「バインディング」という
• コンシューマーは、サービスにアクセスするときプロキシーコードのインターフェースにアクセスするだけである。通信プロトコルやミドルウェアに直接アクセスすることはない

この図は非常に横に長くなってしまうため、本連載では以下のように省略して書くこともあります。

SOAのソフトウェア構造を理解するには、カギカッコ「」のついた単語の関係をきちんと理解することが重要です。それは、サービス、インターフェース、記述言語、プロキシー、バインディング、コンシューマーです。

この構造は、分散プログラミングの技術であり、古くから使われてきたものです。EAIやEDIのような「稼動しているシステムを呼び出す」という特徴と、分散プログラム方式の技術を総動員して、SOAソフトウェア構造ができているということになります。

上に戻る

なぜ柔軟になるのか？

SOAを「どんな結合方法を使ってもいいから、とにかく機能を分離して稼動させておき、呼び出せる形で動かせば柔軟になる」というふうに考える向きもありますが、それでは旧来のEAIとなにもかわりません。EAIの基盤の上でSOA的に機能を定義しても、SOAの数%しか効果を得られないでしょう。いえ、すでにそういうデザインをしているシステムはたくさんあるはずです。なぜEAIが柔軟である、という代表にならず、SOAという言葉が流行しているかといえば、このSOAソフトウェア構造を採用するかどうかに大きな差が出るのです。SOAのシステムに「柔軟になる」という特徴を与えるのは、このSOAソフトウェア構造です。（ビジネスそのものが柔軟になる、という特徴を与えることはできませんので注意してください。）

なぜSOAソフトウェア構造を採用すると、システムを柔軟にできるのでしょうか？

ソフトウェアを「サービス」と「コンシューマー」に分けたとき、この二つを結合する方法はたくさんあります。表1と表2を見てください。二つのソフトウェアを結びつける方法をいくつかまとめています。

この二つの表の違いは、記述言語を使うか使わないかです。
表1にリストされている方法は記述言語を使わない（あるいは、使うことを前提としない）方式です。多くの場合、コンシューマーコードには、結合技術にアクセスするコードを記述しなければなりません。
表2にリストされている方式は、なんらかの形でインターフェースの型を記述しています。機能を提供する側のプログラムコードを呼び出すためにどういうデータを渡せばよいか、どういうデータが戻ってくるか、コンピューター処理できる方式でコンピューター上にデータを持っています。
ペイロードとは、関数を示す情報、関数の引数と戻り値などを運ぶために使われる入れ物の種類を表しています。

この二つの表に表されている技術を使ったシステムに旧来から存在するアプリケーション・コードの多くは、高い確率でSOAに参加させることができます。しかし、表1の技術をそのまま使っていたのでは、表2の技術ほどは柔軟にならないでしょう。これは、結合をどれだけ自動化できるか、にかかっています。

SOAを実現する大きな目的は「アプリケーションの柔軟性」です。アプリケーションの柔軟性とは、「かんたんに形を変化させられる」ということです。アプリケーションを変化させるために重要なのは、結合技術が「簡単に再結合できる」ということにつきます。これを自動化できてこそ、意味があります。

表1の技術だけでは、再結合が柔軟にはできません。なぜなら、結合のためのプログラムコードの多くがコンシューマーソフトウェアに記述されてしまっているからです。これによって、SOAに相反する、次の特徴が生まれてしまいます。

プロトコルに依存する

表1の技術では、特定のプロトコルを呼び出すコードをプログラミングしている部分が多く、他のプロトコルに再結合することが容易でありません。

プラットフォームに依存する可能性がある

データをペイロード（入れ物）に載せる際に、データを直列化（シリアライズ、あるいはマーシャリング）する処理を独自方式で行っている場合、他のシステムへ渡すのが困難な場合があります。データの構造やデータの型、ビット並びなどが他のシステムと違う場合、それをいちいち変換しないと他のシステムでそのまま使えないからです。

「そんなことはない、ｘｘｘをして、ｘｘｘをして、ｘｘｘすれば、他のプロトコルにも、他のプラットフォームにもつながる」という反論が聞こえてきそうですが、それは「つながらないから」やるのであって、標準ではできないということなのです。ツールやミドルウェアによって自動的にできてこそ、SOAの真価が発揮できます。「データ構造はちゃんと定義されている」とワープロファイルを持ってこられても、それをインプットにしてプロキシーを自動生成することはできません。

このような理由で表1のシステムで作られたアプリケーションの多くは、SOAに参加させるためにラッピングを行う必要があります。ラッピングとは、既存のアプリケーションコードなどを修正せずに、外からは別の形のものとして扱えるようなソフトウェアコードを作ることを言います。そうして、SOAソフトウェア構造を持たないアプリケーションのインターフェースをSOAソフトウェア構造のインターフェースに変換するのです。IBMではこの部分を「サービスレイヤー（層）」と呼んでおり、多くの製品を提供しています。この具体的な方法については別の回に解説します。

筆者はSOAの特徴によく出てくる「プロトコルに依存しない」というのは、表2のような範囲で言われていると理解しています。表1のものはラッピングして初めてその仲間に入ります。

この二つの表を見ると、あることに気がつきます。それは、表1に比べて表2は「関数やメソッドの形式になっている」という点です。
今日、SOAで使われる記述言語は、関数形式になっているもののみが定義できるというの能力的な制限があります。この制限は、まだ当分なくなりそうにありませんので、今SOAソフトウェア構造を活用するには、記述言語で定義できる範囲でインターフェースを持つ必要があるのです。将来は表1の技術でもそのまま使える記述言語が登場する可能性があるとしても、今では関数の形式を持っているものこそがSOAソフトウェア構造を持ちやすいというのは言うまでもありません。

ただし早合点しないでください。関数はすべてサービスになるか、というとそうではありません。ほとんどの関数はサービスになりません。サービスとして利用できる関数や関数のセットの特徴、作るときの注意点などは、あとの回で触れます。

今回は、SOAソフトウェア構造の簡単な解説となぜ柔軟になるか、というお話をしました。次回から、SOAソフトウェア構造を詳しく説明していきます。

著者について

		1987年に日本アイ・ビー・エム入社。メインフレームOS、ミドルウェアの障害対応、障害解析ソフトウェアの開発、ワークフローシステム開発、オブジェクト指向開発、Web開発など経験。2000年より、ソフトウェアのテクノロジーエバンジェリストとして活動中。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る