この「コンポーネントベース開発のススメ」の連載は、実際に行われているコンポーネントベース開発（以降、ＣＢＤ）の情報をお伝えするのが主旨ですが、まずその前に、昨今話題になる事が多いＳＯＡについて書いておきたいと思います。

なぜＣＢＤの情報を伝えるのにＳＯＡを知る必要があるのか。それは、以降を読んでいただければ納得いただけるのではないかと思います。

ＣＢＤを考える上で、ＳＯＡは避けては通れません。なぜならＣＢＤとＳＯＡは非常に似通ったものだからです。 ＳＯＡはコンポーネントベース開発と同じだと考えている人もいます。また、まったく違うものだと考えている人もいます。 私は最近まではＳＯＡはＣＢＤの中の一つの形態だと思っていました。しかし、どうも昨今語られるＳＯＡの話を聞いていると、そうとは言えない気がしています。

今回は、ＣＢＤとＳＯＡの同じところ、違うところを見ていく事で、あるべきＣＢＤとＳＯＡを考えていきます。

ＣＢＤとＳＯＡを考える前に、コンポーネントとは何かをはっきりさせる必要があります。まず、ＵＭＬ２．０のコンポーネント図を見てみます。

コンポーネント図でのコンポーネントの表現は非常にシンプルで、コンポーネント名以外にあるのは「提供インタフェース」と「要求インタフェース」だけです。つまりコンポーネントとは外部に提供するインタフェースと外部に要求するインタフェースを持つソフトウェアの単位になります。

しかし、これだけではどんなソフトウェアもコンポーネントといえるでしょう。コンポーネントには好ましくない構成、構造があります。それが図３になります。

これらの好ましくない構成、構造を含まないように設計されたのが本来のコンポーネントといえます。

また、コンポーネントは他から利用されるのが前提であるため、仕様を明示していることも重要な条件になります。いくらコンポーネントになっていても、それを利用するためのコンポーネントの仕様（特にインタフェースの仕様）が公開されていなければ、それはコンポーネントとは言えません。

これらからコンポーネントは以下のように定義できます。

コンポーネントは定義しました。それではＣＢＤとはどのような開発なのでしょうか。私は単純に次のように考えています。

今までコンポーネントを使った開発というと、次にような開発を考えられる方が多くおられました。

• 一部で再利用コンポーネントを使用した開発
• フレームワークやシステム機能コンポーネントは使用しているが、ビジネスロジックはコンポーネント化されていない開発

これらはコンポーネント再利用とは言えますが、コンポーネントベース開発とは言えません。以前は「コンポーネント＝コンポーネント再利用」であったため、このように認識される事が多かったのだと思います。しかし、上記の２つのパターンではコンポーネント再利用に限界がある事は明白です。したがって、コンポーネント再利用以上に、ビジネスロジックを含めてコンポーネントとして設計、開発する事が注目されています。そのような開発がコンポーネントベース開発なのです。

それでは、コンポーネントベース開発では再利用は行わないのでしょうか。コンポーネントベース開発における再利用の考え方には次の３つの考え方があります。

• 再利用は考えていない
• ユーザ社内での再利用（共有）を考えている
• 開発会社内での再利用を考えている

以前はコンポーネント再利用といえば３つ目の開発会社内での再利用の事でした。しかし、ビジネスロジックのコンポーネントに関しては、ほどんどの会社が成功しませんでした。そのため「再利用はしないコンポーネントベース開発」と「ユーザ社内で再利用（共有）するコンポーネントベース開発」にメリットがあるのではないかと期待されています。特に後者の「ユーザ社内での再利用（共有）」は、ＳＯＡという形で大きな広がりを見せようとしています。

それでは、ＳＯＡはどのようなものでしょうか。ＳＯＡでは、システムが必要な機能をサービスと呼ばれるインタフェースとして提供し、そのサービスをビジネスプロセスにしたがって実行するというアーキテクチャです。この時、サービスのインタフェースの汎用化と集約化のためにＥＳＢが使われ、サービスをビジネスプロセスにしたがって実行するためにＢＰＥＬが使われる場合が多くなります。

ＳＯＡのメリットは、ビジネスプロセスの変更時への対応が簡単である事と、サービスを多くのシステムが利用するため、重複開発がなくなる事で無駄なシステム開発を避ける事ができる事です。また、サービス変更時もインタフェースさえ同じにしておけば変更が容易である事もメリットになります。

しかし、ＥＳＢとＢＰＥＬの使用はＳＯＡの必須条件ではありません。

ここまでを読んでいただいた方は、コンポーネントとサービスの違いに気づいていただけたのではないでしょうか。良くサービスとコンポーネントの違いとして「粒度」という言葉がでてきますが、これは違っています。図２のコンポーネント図を見ていただくと判りますが、コンポーネントとはいくつかの提供インタフェースを保持するソフトウェアの単位であり、サービスとはその提供インタフェースのことです。そのため、ＳＯＡではコンポーネントの事をサービスコンポーネントと言う場合もあります。

なぜＳＯＡではコンポーネントではなくサービスが注目されたのか。これは、ＢＰＥＬなどのビジネスプロセスを実行する時に必要なのは、あくまでインタフェースであって、そのインタフェースがどのコンポーネントであるかを知る必要がなかったからです。また、既存のシステムにインタフェースを作ってアクセスする事もあるため、そのためにはコンポーネント化する必要が無い事も一因となっています。そのため、ＳＯＡでは、コンポーネント設計が適切に行われない場合があります。

さてこれまでの説明をまとめると、ＳＯＡとＣＢＤの位置づけは次のようになっています。

まず、ＳＯＡとＣＢＤは多くの部分で重なっています。しかし、ＳＯＡ特有な部分があります。それは、サービスだけ抽出されコンポーネント設計、コンポーネントによる実装が行われない場合です。既存システムへの接続だけが目的であればこれでも問題ありませんが、実際には新しいサービスの構築は必要ですのでコンポーネント化は実施されるべきです。

次に、ＣＢＤ特有な部分は再利用しない場合や開発会社内での再利用だけを行う場合です。しかし、これらが有効に行われている事は少ない状況ですので、ＣＢＤのメリットを活かすためにはユーザ会社での再利用を推進すべきです。

このように、ＣＢＤとＳＯＡの重なる部分が、両者の良い点を併せ持ったシステム開発です。コンポーネントベース開発を視野に入れている方は、ユーザ会社での再利用を主眼に置いたコンポーネントベース開発を、ＳＯＡを主眼にしている方は、コンポーネント設計を考慮したＳＯＡを、ぜひ推進していただきたいと思います。

次回からは、このような前提でＣＢＤそしてＳＯＡをまとめていきます。

株式会社コンポーネントスクエア ディレクター 技術担当 中台高宏 日立ソフトウェアエンジニアリング（株）にて、エキスパートシステムやWebアプリケーションの開発に従事し、2001年のコンポーネントスクエアの設立時より、技術担当ディレクターとして参加し、今に至る。EJBコンソーシアムでは公開情報部会の副主査を務め、公開情報規約の策定に関わる。