Jetspeed 1 ユーザに関して

Jetspeed 2 は新規のプロジェクトで、新たに書き直され、Jetspeed 1 への依存性はありません。 Jetspeed 2 は業界標準に基づき、大規模な企業ポータルアプリケーション用にデザインされています。 一番の違いは、Jetspeed コンポーネント指向アーキテクチャです。すべては、Spring で組み合わされます。 コンポーネントは、Turbine のサービスを標準化されたコンポーネントモデルに置き換えています。 Jetspeed 1 では完全にかけていた、新しいポートレットアプリケーションの配備は、 ポートレット API 仕様に実装されました。プロパティによる Turbine のファイルベース設定は、 管理されたコンポーネントに置き換えられています。 Jetspeed 2 では、Jetspeed 1 アーキテクチャに結びついたレガシーなプロジェクトから完全に切り離されました。

Jetspeed 2では何が新しくなったか

  • 1. Java ポートレット API 標準に完全準拠
  • 2. ポータルからポートレットアプリケーションの分離
  • 3. ポートレットアプリケーションおよびポータルレイアウトの動的な配備モデル
  • 4. Spring コンポーネントベースのアーキテクチャ
  • 5. マルチスレッド化されたポートレット集約エンジン
  • 6. 拡張可能なアーキテクチャ
  • 7. パイプラインベースのリクエスト処理
  • 8. JAAS セキュリティ
  • 9. Struts, JSF, PHP, Perl, Velocity のブリッジを統合
  • 19. CMS ベースのサイトナビゲーション

Jetspeed 2 で同じものはなにか

ほとんどありません。

実際に、Jetspeed 2 は Jetspeed 1 のどんなコードも再利用していません。 いくつかの概念は、Jetspeed 2 でもそのままですが、新しいデザインと実装をしています。 以下の表は、Jetspeed 1 から Jetspeed 2 で継続されているいくつかの概念です。 その概念は継続されていますが、その中のいくつかは、完全に異なるので注意してください。

  • 1. PSML - ポートレット構造化マークアップ言語 (Portlet Structured Markup Language) ページ上でポートレットのレイアウトを定義します。 その目的は同じですが、XML フォーマットは変更されています。 移行は可能で、移行ツールが必要になります。 現在、PSML はページタイプのリソースとしての Jetspeed ナビゲーションサイトに適合しています。 現在、PSML 移行ツールはありません。しかし、XSLT 変換で行うのが良い選択かもしれません。
  • 2. ポータル全体のセキュリティポリシーと制約 - Jetspeed 2 は 2 種類のセキュリティ機構を持ちます。 JAAS ベースのセキュリティポリシーと、Jetspeed 1 のような宣言的セキュリティ制限です。 Jetspeed 1 の制約は PSML に対して制限するものでしたが、Jetspeed 2 の宣言的セキュリティ制約は、 それに加えてフォルダやリンクに対しても適用されます。
  • 3. ポートレット - ポートレットは新しいポートレット API に従わなければなりません。 移行ツールは現在ありません。 Jetspeed 1 ポートレット API は Jetspeed 2 では利用できません。
  • 4. Turbine サービス (Fulcrum) はなくなりました。Jetspeed 2 は Spring コンポーネントベースです。
  • 5. レジストリ - Jetspeed 1 レジストリは Jetspeed 2 で廃止されました。 すべてのポートレットは Jetspeed 2 のレジストリデータベース内に保存されます。 移行ツールは現在ありません。 ご利用のポートレットは、JSR 168 ポートレットへ変換して、すべてのポートレットを 1 つのポートレットアプリケーションにパッケージングして、 標準の WAR ファイルとして配備することをおすすめします。 そのほかのレジストリは、すべて廃止しています。
  • 6. JSP および Velocity テンプレート - テンプレートはいくつかの拡張として再利用できます。 RunData またはその他の Turbine や Jetspeed ツール、タグなどへの参照は、 変換する必要があります。
  • 7. 制御とコントローラ - これらの概念は変更され、デコレータおよびレイアウトと現在呼ばれています。 制御とコントローラの Turbine モジュールの概念は、サポートされていません。 レイアウトとデコレータはポートレットとして実装されています。 つまり、簡単なマークアップになっています。レイアウトとテンプレートは、 配備可能な単位としてポータルへ配備することができます。
  • 8. Jetspeed の設定と Jetspeed コンポーネントアセンブリはプロパティーファイルを置き換えます。 コンポーネント (サービス) は、プロパティファイルで定義されるのではなく、組み立てられます。 Jetspeed 1 の多くの機能は、Jetspeed 1 の静的なプロパティファイルで読み込みのみ可のプロパティとして表現されています。 Jetspeed 2 コンポーネントは、JMX を用いて、構成することができます。

Turbine は利用していません

Jetspeed 1 は Turbine の MVC-2 フレームワークと強く結びつき、この結びつきが、Jetspeed API の多くの箇所に及んでいます。 Jetspeed 2 では、MVC-2 コントローラとしての Turbine に依存しません。 それに代わり、関連するパターンを分離して、1 つのことを実行し、かつ、それをうまく動かすことに集中します。 つまり、ポータルの実装をすることです。一方、Jetspeed 1 は MVC コントローラ、ポータルエンジン、ポートレットコンテナ、などすべてがサーブレットに強く結びついた1カ所に結びついています。 Jetspeed 2 は、そのアーキテクチャの中で、これらの関連することを明確に分けています。 ポータルエンジンは、Jetspeed 2 です。それは、ページ集約用の MVC で、作業を振り分けるサーブレットアーキテクチャの特性を利用し、ポートレットの実際の描画をポートレットアプリケーションに委譲します。 これらのポートレットアプリケーションでもやはり、Struts ポートレットアプリケーション、JSF ポートレットアプリケーション、または、Turbine ポートレットアプリケーションフレームワークのような、独自の MVC フレームワークを持っています。

RunData はもうない

ポートレット API ポートレットからもっとも顕著に欠けているものは、RunData クラスです。 Jetspeed 1 API は、偏在的に RunData クラスを使用して、サーブレットリクエストとサーブレットレスポンスの両方へのラッパーとして働いています。 Turbine への他の依存関係は、ポートレットアクション、ポートレット集約エンジン (ECS)、サービスアーキテクチャ、設定および Turbine モジュールが含まれます。 これらの依存関係は、新しいバージョンではありません。

Jetspeed 1Jetspeed 2
Run Dataポートレット API: ポートレットリクエストおよびポートレットレスポンス
ポートレット集約エンジン (ECS)Jetspeed 2 マルチスレッドポートレットコンテナエンジン
Turbine サービスアーキテクチャJetspeed 2 コンポーネント
プロパティ設定ファイルSpring の設定、JMX
Turbine モジュール (アクション)ポートレット API のアクション

Pluto はポートレットコンテナです

Jetspeed 2 ポータルは、ポートレットコンテナを実装していません。 Pluto は、ポータル内で実行するポートレット用の JSR 168 インターフェース規約を実装しています。 Pluto コンテナは、ポータル用のポートレットとのすべての通信を処理します。

集約しているでしょ?

集約エンジンおよび Jetspeed 1 ポートレット API は、廃止された Jakarta パッケージの ECS (Element Construction Set) と結びついています。 ECS は、Java コードを用いて HTML を生成し、HTML をサーブレット出力ストリームへ送り出す前に、一時的な Java オブジェクト内にコンテンツを保存します。 この Java オブジェクトの無駄な使用は、メモリ上の断片化、短期間でのガーベッジコレクション、大容量サイトでのページングを引き起こします。 サーブレット API は、ポートレットコンテンツ出力ストリーム用のコンテンツストリームを提供します。 Jetspeed 2 は、コンテンツ描画用のストリームベースのサーブレットに類似している、ポートレット API のストリームおよび読み込み部分の上にその集約エンジンを構成しています。

状態とライフサイクル

ポートレット API は、ポートレットのライフサイクル、アクションのイベント処理手順、および、コンテナがどのようにポートレットからコンテンツをキャッシュできるかを定義しています。 ポートレットのライフサイクルは、Jetspeed 1 では明確に定義されていませんでした。 ポートレット API ではポートレットの1つのインスタンスだけがコンテナ内のメモリに存在することを明記してあります。 ポートレットの状態は、現在のユーザセッションに関するサーブレットの状態に直接関連しています。 これは明確であるかもしれませんが、ポートレットの状態とライフサイクルは Jetspeed 1 では明確に定義されていませんでした。

アクション

バージョン 1 では、アクションは Turbine に結びついていて、適切にポートレットのクラスには統合されていませんでした。 実際に、アクションは、ポートレットから分けられたオブジェクトでした。ポートレット API では、アクションはポートレット上のメソッドです。 アクションイベント処理と順序は、仕様で明確に定義されています。

標準による配備

Jetspeed 1 は、一般的なポートレットアプリケーションとしてのポートレットの配備や、それらをサポートするファイルに関する標準的な方法がありませんでした。 アプリケーションをインポートするために、開発者は、Jetspeed ウェブアプリケーション形式に合うように、レジストリファイル、クラスや JAR ファイル、PSML やテンプレートなどをパッケージ化しなければなりません。

Jetspeed 2 では、ポートレット API が Jetspeed にポータルアプリケーションを配備するために、標準の配備記述子を定義しています。 ポータルアプリケーションは、ポータルへ配備されます。 ウェブアプリケーション (WAR) 配備モデルでパッケージ化されたサーブレットに似て、ポータルはポートレットアプリケーション配備モデルでパッケージ化されたポートレットをサポートします。 ポータルアプリケーションアーカイブは、追加のポートレット配備記述子ファイルを含め、サーブレット仕様で定義された WAR 形式と同じフォーマットに従います。 Jetspeed 2 の明確な利点は、標準形式でポートレットアプリケーションをサーバへ動的配備が可能なことです。

リソースと配備

ポータルテンプレート、画像、スキン、コントローラ、制御などの Jetspeed 1 のリソースは、配備モデルのない 1 つの Jetspeed ウェブアプリケーションに統合されました。 たとえば、標準のスキンや上部のバナーを上書きするには、リソースファイルをポータルディレクトリ上にコピーして、適切なファイルを新しいリソースとして更新し、サーバを再起動する必要があります。 これは、プロパティやファイルを統合するプロセスなどの、Jetspeed 1 を実際の本稼働ポータルに仕上げるプロセスに有効です。 実際に Jetspeed 1 では、今、Jetspeed 1 ポータル本体から本稼働ポータルを分けて管理するために Maven プラグイン持っています。 この手のツールの必要性は、困難なポータルメンテナンス処理が必要とされる、ポータルリソース用の有用な配備モデルを Jetspeed 1 が持っていないという事実を取り繕うことから来ます。

Jetspeed 2 本稼働用ポータルについては、ポータルリソースは Jetspeed 固有のアーカイブフォーマットでパッケージ化します。 つまり、ポータルリソース (上部のバナー、スキン、画像、スタイルシート) は、実行時に動的にポータルを調整するためにすべて配備することができます。

標準

JSR168 はポートレットの仕様で、ポートレットとポータル間の相互運用性を実現します。 この仕様は、ポートレットの集約、パーソナライズ、表示およびセキュリティの標準に関する API 群を定義しています。 JSR168 のゴールは、以下のことです。

  • 共通のポータル隠喩の定義
  • 標準のポートレット Java API の定義
  • 相互運用性と移植性の確認
  • 複数のマークアップサポートが可能
  • ほかの技術のと互換性の確認

Jetspeed 2 ポータルサーバは JSR 168 標準をサポートします。 これは、真のポートレット移植性を導入するための、重要な第一歩です。