Jetspeed 2 企業ポータル
Jetspeed-2 is a new project, written from groundup and does not have any dependencies on Jetspeed-1. Jetspeed-2 is based on industry standards, designed for high-volume enterprise portals applications. The foremost difference is Jetspeeds Component Oriented Architecture, all assembled together with Spring. Components replace Turbine services with a standardized component model. Deployment of new portlet applications, which was completely missing in Jetspeed-1, is implemented to the Portlet API specification. Turbines file-based configuration for properties are replaced managed components. Jetspeed-2 is fully decoupled from the legacy projects that were intertwined in the Jetspeed-1 architecture.
Jetspeed 2 は新規のプロジェクトで、新たに書き直され、Jetspeed 1 への依存性はありません。 Jetspeed 2 は業界標準に基づき、大規模な企業ポータルアプリケーション用にデザインされています。 一番の違いは、Jetspeed コンポーネント指向アーキテクチャです。すべては、Spring で組み合わされます。 コンポーネントは、Turbine のサービスを標準化されたコンポーネントモデルに置き換えています。 Jetspeed 1 では完全にかけていた、新しいポートレットアプリケーションの配備は、 ポートレット API 仕様に実装されました。プロパティによる Turbine のファイルベース設定は、 管理されたコンポーネントに置き換えられています。 Jetspeed 2 では、Jetspeed 1 アーキテクチャに結びついたレガシーなプロジェクトから完全に切り離されました。
Not much.
ほとんどありません。
In fact Jetspeed-2 does not re-use any of the code in Jetspeed-1. Some concepts are continued in Jetspeed-2, but with new design and implementations. The table below shows some of the concepts continued in Jetspeed-2 from Jetspeed-1. Note that even though the concepts are continued, they are have changed, in some cases significantly:
実際に、Jetspeed 2 は Jetspeed 1 のどんなコードも再利用していません。 いくつかの概念は、Jetspeed 2 でもそのままですが、新しいデザインと実装をしています。 以下の表は、Jetspeed 1 から Jetspeed 2 で継続されているいくつかの概念です。 その概念は継続されていますが、その中のいくつかは、完全に異なるので注意してください。
Jetspeed-1 is tightly coupled to the Turbine MVC-2 framework, and this coupling permeates many areas of the Jetspeed API. Jetspeed-2 does not rely on Turbine as the MVC-2 controller. Instead, we follow the separation of concerns pattern, and concentrates on doing one thing and doing it well. That is, implementing a portal. Where as Jetspeed-1 coupled MVC Controller, portal engine, and portlet container all into one deeply coupled servlet, Jetspeed-2 separates these concerns clearly in its architecture. The portal engine is Jetspeed-2. It is the MVC for page aggregation, leveraging the dispatching nature of the servlet architecture, and delegating the actual rendering of portlets to portlet application frameworks. These portlet applications can in turn have their own MVC frameworks, such as Struts portlet applications, JSF portlet applications, or Turbine portlet application frameworks.
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 フレームワークを持っています。
Most notably missing from Portlet API portlets is the RunData class. The Jetspeed-1 API uses the RunData class ubiquitously, serving as a wrapper for both the servlet request and response. Other dependencies on Turbine include Portlet Actions, Portlet Aggregation Engine (ECS), the Service Architecture, Configuration and Turbine Modules. None of these exist in the newer version.
ポートレット API ポートレットからもっとも顕著に欠けているものは、RunData クラスです。 Jetspeed 1 API は、偏在的に RunData クラスを使用して、サーブレットリクエストとサーブレットレスポンスの両方へのラッパーとして働いています。 Turbine への他の依存関係は、ポートレットアクション、ポートレット集約エンジン (ECS)、サービスアーキテクチャ、設定および Turbine モジュールが含まれます。 これらの依存関係は、新しいバージョンではありません。
| Jetspeed-1 | Jetspeed-2 |
|---|---|
| Run Data | Portlet API: Portlet Request and Portlet Response |
| Portlet Aggregation Engine (ECS) | Jetspeed-2 Multi-threaded Portlet Container Engine |
| Turbine Service Architecture | Jetspeed-2 Components |
| Property Configuration Files | Spring Configurations, JMX |
| Turbine Modules (Actions) | Portlet API Actions |
| Jetspeed 1 | Jetspeed 2 |
|---|---|
| Run Data | ポートレット API: ポートレットリクエストおよびポートレットレスポンス |
| ポートレット集約エンジン (ECS) | Jetspeed 2 マルチスレッドポートレットコンテナエンジン |
| Turbine サービスアーキテクチャ | Jetspeed 2 コンポーネント |
| プロパティ設定ファイル | Spring の設定、JMX |
| Turbine モジュール (アクション) | ポートレット API のアクション |
The Jetspeed-2 portal does not implement the Portlet container. Pluto implements the JSR 168 interface contract for portlets running inside our portal. The Pluto container handles all communication with portlets for the portal.
Jetspeed 2 ポータルは、ポートレットコンテナを実装していません。 Pluto は、ポータル内で実行するポートレット用の JSR 168 インターフェース規約を実装しています。 Pluto コンテナは、ポータル用のポートレットとのすべての通信を処理します。
The aggregation engine and the Jetspeed-1 Portlet API are both coupled to a deprecated Jakarta package ECS (Element Construction Set). ECS generates HTML with Java code, storing the content in temporary Java objects before sending the HTML out to the servlet output stream. This wasteful use of Java objects leads to fragmentation on memory, accelerated garbage collection, and paging in high volume sites. The servlet API clearly provides a content stream for streaming out portlet content. Jetspeed-2 models its aggregation engine upon the Portlet APIs streams and readers, analogous to the stream-based Servlet API for rendering content.
集約エンジンおよび Jetspeed 1 ポートレット API は、廃止された Jakarta パッケージの ECS (Element Construction Set) と結びついています。 ECS は、Java コードを用いて HTML を生成し、HTML をサーブレット出力ストリームへ送り出す前に、一時的な Java オブジェクト内にコンテンツを保存します。 この Java オブジェクトの無駄な使用は、メモリ上の断片化、短期間でのガーベッジコレクション、大容量サイトでのページングを引き起こします。 サーブレット API は、ポートレットコンテンツ出力ストリーム用のコンテンツストリームを提供します。 Jetspeed 2 は、コンテンツ描画用のストリームベースのサーブレットに類似している、ポートレット API のストリームおよび読み込み部分の上にその集約エンジンを構成しています。
The Portlet API clearly defines the lifecycle of a portlet, the event sequences for actions, and how the container can cache content from a portlet. The Portlet Lifecycle was not clearly defined in Jetspeed-1. The portlet API clearly states that only one instance of a portlet will reside in memory inside a container. The state of the portlet is directly related to the servlet state for the current user session. While this may seem obvious, portlet state and lifetime was not clearly defined in Jetspeed-1.
ポートレット API は、ポートレットのライフサイクル、アクションのイベント処理手順、および、コンテナがどのようにポートレットからコンテンツをキャッシュできるかを定義しています。 ポートレットのライフサイクルは、Jetspeed 1 では明確に定義されていませんでした。 ポートレット API ではポートレットの1つのインスタンスだけがコンテナ内のメモリに存在することを明記してあります。 ポートレットの状態は、現在のユーザセッションに関するサーブレットの状態に直接関連しています。 これは明確であるかもしれませんが、ポートレットの状態とライフサイクルは Jetspeed 1 では明確に定義されていませんでした。
In version 1, actions were coupled to Turbine and not properly integrated into the Portlet class. In fact, actions were separate objects from portlets. In the Portlet API, actions are methods on the portlet. Action event handling and sequencing is clearly defined in the specification.
バージョン 1 では、アクションは Turbine に結びついていて、適切にポートレットのクラスには統合されていませんでした。 実際に、アクションは、ポートレットから分けられたオブジェクトでした。ポートレット API では、アクションはポートレット上のメソッドです。 アクションイベント処理と順序は、仕様で明確に定義されています。
Jetspeed-1 does not have a standardized method of deploying portlets and their supporting files, commonly referred to as portlet applications. In order to import an application, one must package registry files, class and jar files, PSML and templates so that they match the Jetspeed web application format.
Jetspeed 1 は、一般的なポートレットアプリケーションとしてのポートレットの配備や、それらをサポートするファイルに関する標準的な方法がありませんでした。 アプリケーションをインポートするために、開発者は、Jetspeed ウェブアプリケーション形式に合うように、レジストリファイル、クラスや JAR ファイル、PSML やテンプレートなどをパッケージ化しなければなりません。
In Jetspeed-2, the Portlet API defines a standard deployment descriptor for deploying Portal Applications into Jetspeed. Portal applications must be deployed to the portal. Analogous to the servlets packaged in a web-application (WAR) deployment model, portals support portlets packaged in a portal-application deployment model. The Portal Application archive follows the same format as the WAR format defined in the Servlet specification with an additional Portlet deployment descriptor file. The clear advantage in Jetspeed-2 is the ability to deploy live portlet applications to the server in a standardized format.
Jetspeed 2 では、ポートレット API が Jetspeed にポータルアプリケーションを配備するために、標準の配備記述子を定義しています。 ポータルアプリケーションは、ポータルへ配備されます。 ウェブアプリケーション (WAR) 配備モデルでパッケージ化されたサーブレットに似て、ポータルはポートレットアプリケーション配備モデルでパッケージ化されたポートレットをサポートします。 ポータルアプリケーションアーカイブは、追加のポートレット配備記述子ファイルを含め、サーブレット仕様で定義された WAR 形式と同じフォーマットに従います。 Jetspeed 2 の明確な利点は、標準形式でポートレットアプリケーションをサーバへ動的配備が可能なことです。
Jetspeed-1 resources such as portal templates, images, skins, controllers, controls, are all merged into the single Jetspeed web application with no deployment model. For example, to override the default skin or top banner, the resource files are copied into the portal directory, property files updated to point to the new resources, and the server must be restarted. This made for the process of tailoring Jetspeed-1 portals to real production portals a process of property and file merging. In fact Jetspeed-1 now has a Maven plug-in to manage production portals separately from the core Jetspeed-1 portal. The need for this kind of tool covers up the fact that Jetspeed-1 is missing a good deployment model for portal resources, requiring difficult portal maintenance procedures.
ポータルテンプレート、画像、スキン、コントローラ、制御などの Jetspeed 1 のリソースは、配備モデルのない 1 つの Jetspeed ウェブアプリケーションに統合されました。 たとえば、標準のスキンや上部のバナーを上書きするには、リソースファイルをポータルディレクトリ上にコピーして、適切なファイルを新しいリソースとして更新し、サーバを再起動する必要があります。 これは、プロパティやファイルを統合するプロセスなどの、Jetspeed 1 を実際の本稼働ポータルに仕上げるプロセスに有効です。 実際に Jetspeed 1 では、今、Jetspeed 1 ポータル本体から本稼働ポータルを分けて管理するために Maven プラグイン持っています。 この手のツールの必要性は、困難なポータルメンテナンス処理が必要とされる、ポータルリソース用の有用な配備モデルを Jetspeed 1 が持っていないという事実を取り繕うことから来ます。
For a Jetspeed-2 production portal, portal resources are packaged in a Jetspeed-specific archive format. Thus portal resources (top banners, skins, images, style sheets) can all be deployed to dynamically tailor the portal at runtime.
Jetspeed 2 本稼働用ポータルについては、ポータルリソースは Jetspeed 固有のアーカイブフォーマットでパッケージ化します。 つまり、ポータルリソース (上部のバナー、スキン、画像、スタイルシート) は、実行時に動的にポータルを調整するためにすべて配備することができます。
JSR168 is the Portlet specification enables interoperability between Portlets and Portals. The specification defines a set of APIs that addresses standardization of portlet aggregation, personalization, presentation and security. The goals of JSR168 are to:
JSR168 はポートレットの仕様で、ポートレットとポータル間の相互運用性を実現します。 この仕様は、ポートレットの集約、パーソナライズ、表示およびセキュリティの標準に関する API 群を定義しています。 JSR168 のゴールは、以下のことです。
The Jetspeed-2 Portlet Server supports the JSR 168 standard. This is an important initiative, introducing true portlet portability.
Jetspeed 2 ポータルサーバは JSR 168 標準をサポートします。 これは、真のポートレット移植性を導入するための、重要な第一歩です。
