アーキテクチャについて

ポータルサーバーは一つのウェブアプリケーションです。 そのため、ポータルサーバーを動作させるためにはアプリケーションサーバーが必要になります。

ポートレットも同様に一つのウェブアプリケーションです。 ポートレットの配備はポータルサーバーに対して配備を実行しますが、最終的にはアプリケーションサーバー上に配備されることになります。 クライアントからのアクセスは、通常のウェブアプリケーションと同様にポータルサーバーにアクセスされた後に、ポータルサーバーからポートレットへのクロスコンテキストのアクセスにより、ポートレットのコンテンツを取得し、その結果を集約して、クライアントへ出力します。

ポータル内の処理

PALポータルは、コンポーネントのパイプライン処理に基づいて、ユーザーからのリクエストを処理します。

クライアントからのアクセスがあると、ポータルサーバー内ではそのリクエストを RequestContext というインスタンスとして扱います。 その RequestContext を Spring で設定したコンポーネントバルブに順に渡して処理していきます。 その中でポートレットコンテナを呼び出し、ポートレットを処理します。 処理の終了後、その結果を集約して、クライアントへ出力します。

構成コンポーネント

PALポータルのアーキテクチャは Martin Fowler によって以下のように定義されたコンポーネントアーキテクチャに基づいて構築されています。

コンポーネントという言葉は、変更なしに、コンポーネントの作者の管理から外れたアプリケーションとして使われることを意図したソフトウェア群を意味しています。 「変更なしに」という言葉は、ユーザーがコンポーネントの作者によって許された方法でコンポーネントを拡張し、その動作を変化させることはあるかもしれないけれども、アプリケーションを使う場合に、コンポーネントのソースコードを変えることなくアプリケーションを使うことを意味します。

PALポータルはプログラミングのデザインパターンと構造上のモデルとして、依存性注入を使います。 これは、公開されているインターフェースを通して抽象化のレベルを構築するためであり、そしてコンポーネントの実装における依存性をなくすためです。 この構造はコンポーネントがそれ自身とリンクしたり、お互いにリンクする構造でなく、コンポーネントと結合します。 依存性注入はオブジェクトの作成やオブジェクトのリンクの機能をオブジェクト自身から削除し、ファクトリへ移したパターンです。 それゆえ、依存性注入は明らかにオブジェクトの作成とリンクの制御を反転させており、Inversion of Controls(制御の反転, IOC) の形であると考えることができます。

engine = new JetspeedEngine(properties, applicationRoot, config,
    initializeComponentManager(config, applicationRoot, properties));