ソフトウェアコンポーネント

ソフトウェア開発を、コードを丹念に作成する作業から、コンポーネントを単純に組み立てることで強力なシステムを構築する作業へ転換するという概念は、私がこの業界に入って以来、ずっと目標とされてきました。その目標は垣間見えることはあっても、本当に達成されることはありませんでした。ただし、多くの技術が産業における再利用というニンジンをぶら下げてきました。

ソフトウェアコンポーネントについて議論するとき、多くの場合最も難しい作業はその定義について説明することです。私の最も好きな定義は、今でも次のものです。

コンポーネントはテクノロジーではありません。テクノロジー分野の人たちには、これが理解しづらいようです。コンポーネントとは、顧客がソフトウェアを利用する方法のことです。顧客はソフトウェアを一度に一部ずつ購入して、ステレオをアップグレードするときのようにアップグレードできることを望んでいます。古いパーツと新しいパーツがシームレスに連携し、メーカーのスケジュールではなく、独自のスケジュールでアップグレードできることを望んでいます。さまざまなメーカーのパーツを自由に組み合わせて使用したいと考えています。これは非常に合理的な要求です。ただ、満たすのが難しいのです。

-- ラルフ・ジョンソン

私はこれを、ソフトウェアコンポーネントとは、個別に交換およびアップグレード可能なものであると言っています。

現在のコンポーネントは、ライブラリとサービスの2種類があると考えています。ライブラリは、実行時にプロセスにリンクされ、クライアントプロセスの1部となるコードで構成されています。例として、Javaのjar、C#のアセンブリ、Rubyのgem、JavaScriptのモジュールがあります。適切なコンポーネントになるためには、ライブラリのユーザーは、サプライヤのライブラリのアップグレードの有無と時期を決定する必要があります。そのため、6か月前の古いバージョンを使用することを選択した場合、それは私の自由です。

サービスは、独自のプロセスに存在するコンポーネントです。[1]クライアントはRPC、HTTPを介したRESTful呼び出し、メッセージングなど、プロセス間通信メカニズムを介してサービスと通信します。サービスは、クライアントと連携することなく、独自のタイムテーブルでアップグレードできますが、そうするために、既存のクライアント契約を保持する必要があります。そのため、クライアントはサービスの使用をアップグレードする時期を選択できます。サービスがコンポーネントである場合、あるサービスのアップグレードを別のサービスと連携する必要は決してありません。

私はコンポーネントをモジュールの特定の形式と見なしています。モジュールを、システムの1部を理解するだけでシステムを変更できるソフトウェアシステムの区分けと定義しています。この場合、モジュールはよく定義されたサブセットです。コンポーネントはモジュールの形式で、独立した置換という追加のプロパティを備えています。