[For Jetspeed-1 Users]Jetspeed 1 ユーザに関して

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 アーキテクチャに結びついたレガシーなプロジェクトから完全に切り離されました。

[Whats New in Jetspeed-2]Jetspeed 2では何が新しくなったか

  • 1. Fully Compliant with Java Portlet API Standard
  • 2. Separation of Portlet Applications From Portal
  • 3. Live Deployment Model for Portlet Applications and Portal Layouts
  • 4. Spring Component Based Architecture
  • 5. Multi-threaded Portlet Aggregation Engine
  • 6. Scalable Architecture
  • 7. Pipeline-based Request Processing
  • 8. JAAS Security
  • 9. Bridges Integration with Struts, JSF, PHP, Perl, Velocity
  • 19. CMS-based Site Navigations
  • 1. Java ポートレット API 標準に完全準拠
  • 2. ポータルからポートレットアプリケーションの分離
  • 3. ポートレットアプリケーションおよびポータルレイアウトの動的な配備モデル
  • 4. Spring コンポーネントベースのアーキテクチャ
  • 5. マルチスレッド化されたポートレット集約エンジン
  • 6. 拡張可能なアーキテクチャ
  • 7. パイプラインベースのリクエスト処理
  • 8. JAAS セキュリティ
  • 9. Struts, JSF, PHP, Perl, Velocity のブリッジを統合
  • 19. CMS ベースのサイトナビゲーション

[Whats the same in Jetspeed-2]Jetspeed 2 で同じものはなにか

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 で継続されているいくつかの概念です。 その概念は継続されていますが、その中のいくつかは、完全に異なるので注意してください。

  • 1. PSML - Portlet Structured Markup Language. Defines the layout of portlets on a page. While the purpose is still the same, the XML format has changed. Porting is possible, requires a migration tool. PSML now fits into an overall Jetspeed Navigation Site as a page-type resource. No PSML porting tool is currently available. However, an XSLT transform could be a good choice.
  • 2. Portal Wide Security Policy and Constraints - Jetspeed-2 has two kinds of security mechanisms: JAAS-based security policies, and declarative security constraints much like Jetspeed-1 constraints. Where as Jetspeed-1 constraints were limited to PSML, Jetspeed-2 declarative security constraints are also applied to folders and links.
  • 3. Portlets - Portlets now must adhere to the new Portlet API. No porting tool is currently available. The Jetspeed-1 Portlet API will not be continued in Jetspeed-2.
  • 4. Turbine Services are out (Fulcrum). Jetspeed-2 is based on Spring components.
  • 5. Registries - The Jetspeed-1 Registries are discontinued in Jetspeed-2. All portlets are now stored in a Registry database in Jetspeed-2. No porting tool is available. Recommend converting your portlets to JSR-168 portlets, packaging all portlets in a portlet application, and deploying as standard WAR file. Other registries are all deprecated.
  • 6. JSP and Velocity Templates - Templates can be re-used to some extend. Any references to Rundata or any other Turbine or Jetspeed-1 tools or tags must be converted.
  • 7. Controls and Controllers - These concepts have changed, and are now called decorators and layouts. The Turbine module concept, which backed controls and controllers, is no longer supported. Layouts and decorators are now only implemented as portlets, or as just plain markup. Layouts and templates can be deployed to the portal as a deployable unit.
  • 8. Jetspeed Configurations and Jetspeed Component Assemblies replace Property Files. Component (services) should be assembled, not defined in property files. Many of the features in Jetspeed-1 were represented as read-only properties in the Jetspeed-1 static property files. Jetspeed-2 components can be configured with JMX.
  • 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 Gone]Turbine は利用していません

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 フレームワークを持っています。

[RunData No More]RunData はもうない

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-1Jetspeed-2
Run DataPortlet API: Portlet Request and Portlet Response
Portlet Aggregation Engine (ECS)Jetspeed-2 Multi-threaded Portlet Container Engine
Turbine Service ArchitectureJetspeed-2 Components
Property Configuration FilesSpring Configurations, JMX
Turbine Modules (Actions)Portlet API Actions
Jetspeed 1Jetspeed 2
Run Dataポートレット API: ポートレットリクエストおよびポートレットレスポンス
ポートレット集約エンジン (ECS)Jetspeed 2 マルチスレッドポートレットコンテナエンジン
Turbine サービスアーキテクチャJetspeed 2 コンポーネント
プロパティ設定ファイルSpring の設定、JMX
Turbine モジュール (アクション)ポートレット API のアクション

[Pluto is the Portlet Container]Pluto はポートレットコンテナです

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 コンテナは、ポータル用のポートレットとのすべての通信を処理します。

[Aggregating, Isnt It?]集約しているでしょ?

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 のストリームおよび読み込み部分の上にその集約エンジンを構成しています。

[State and Life Cycle]状態とライフサイクル

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 では明確に定義されていませんでした。

[Actions]アクション

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 では、アクションはポートレット上のメソッドです。 アクションイベント処理と順序は、仕様で明確に定義されています。

[Standard Deployment]標準による配備

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 の明確な利点は、標準形式でポートレットアプリケーションをサーバへ動的配備が可能なことです。

[Resources and Deployment]リソースと配備

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

[the Standard]標準

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 のゴールは、以下のことです。

  • Define common Portal metaphor
  • Define a standard Portlet Java API
  • Ensure interoperability and portability
  • Enable multiple markups support
  • Ensure compatibility with other technologies
  • 共通のポータル隠喩の定義
  • 標準のポートレット Java API の定義
  • 相互運用性と移植性の確認
  • 複数のマークアップサポートが可能
  • ほかの技術のと互換性の確認

The Jetspeed-2 Portlet Server supports the JSR 168 standard. This is an important initiative, introducing true portlet portability.

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