Liferay 7.0はLiferayプラットフォームの新しいメジャーバージョンであったため、以前のバージョンに比べて多くの改善が行われました。 とはいえ、学習してきたLiferay Portal 6の特徴のほとんどは保持されており、わずかに変更されているか、もしくはまったく変更されていません。 Liferayの経験豊富な開発者であれば、既存の知識のほとんどをLiferay DXP 7.1の開発に適用できます。
それでは、どのような点が変更されていないのでしょうか。 Liferay 7には多くの改良点がありますが、以前のバージョンから維持されている多くの優れた便利な側面もあります。 最も関連性の高いものを次に示します。
-
Portalコアと各Liferayアプリケーションは、プレゼンテーション、サービス、永続性の3層アーキテクチャを引き続き使用します。 プレゼンテーション層は独立したモジュールとして常に提供されるようになり、必要に応じて別のプレゼンテーションに簡単に置き換えることができます。
-
ポートレット(JSR-168、JSR-286)、CMIS、WebDAV、LDAP、JCP(JSR-170)などの以前にサポートされていた標準のサポートは残ります。
-
モジュール化の取り組みの一環として、クラスの多くが新しいパッケージに移行した場合でも、ほとんどのLiferay APIは6.2のAPIと機能的に類似したままです。
-
ニーズに最適なツールを自由に使用できますが、Liferay Dev Studio DXPは、Liferay用に開発するための推奨ツールです。
-
Service Builderおよびその他の開発者ツールとライブラリは、6.2と同様に引き続き機能します。
-
ポートレットおよびフック用の従来のプラグインは(Liferay DXP 7.1のAPIに適合したら)、互換性レイヤーを介して引き続き機能します。
以下は、既存のLiferay開発者にとって重要な変更点です。
-
モジュールとして多くの機能の抽出:これまで、大規模なWebアプリケーションとしてLiferayを使用することに順応してきましたが、そのすべてをデプロイする必要があったか、もしくはまったくデプロイする必要がありませんでした。 Liferay DXP 7.1では、すぐに使用できる多くのポートレット、機能、および関連するAPIが、OSGiモジュールとして展開されています。 デプロイして使用するものを選択できます。
-
最新のOSGi標準の採用:OSGiはモジュラーシステムを構築するための一連の基準です。 それは非常に強力です。 以前は学習と使用が困難でしたが、宣言型サービスなどの最新の基準により、学習と使用がはるかに簡単になりました。
-
コアパブリックAPIは、ポータルカーネル(旧ポータルサービス)を介して提供されます。他のすべてのパブリックAPIは、独自のモジュールによって提供されます。
-
モジュールとライブラリを再利用し、それらの間の依存関係を管理できます。
-
拡張ポイントを実装するクラスの登録がより簡単になり、一貫性が向上しました。
portal.properties
またはportlet.xml
の宣言ではなく、標準の@Component
アノテーションに基づいています。 可能な場合、以前の登録メカニズムは保持されていることを覚えておいてください。 記事Breaking Changesを参照して、後方互換性を維持していない拡張機能と設定について確認してください。 -
サードパーティの拡張機能とアプリケーションは、現在第一級オブジェクトです。 従来のプラグインには、コアで(またはExtプラグインとして)行われた開発にはない制限がいくつかありました。 モジュールにはこれらの制限はなく、プラグインがこれまでよりもはるかに強力です。
-
MavenおよびGradle内のLiferay固有のツール(Service Builderなど)の統合を完了します。 さらに、bndなどの新しいツールを採用しました。
-
プラグインSDKは利用できなくなりました。 プラグインSDKの削除については、記事Deprecated Apps in 7.1: What To Doで詳細をご覧ください。 Liferay Workspaceは、現在Liferayの定評ある開発環境です。
Liferay Webアプリケーションのモジュール化は、開発者にとって最も関わりのある変更です。その変更についてと、それがLiferayのアーキテクチャにどのように影響するかについてをより詳しく見ていきしょう。
モジュラーアーキテクチャの採用
Liferayのアーキテクチャの最大の改善点は、モジュラー開発パラダイムの採用です。 Liferayの各モジュール(またはアプリケーションを形成するモジュールのグループ)内、およびLiferayのコアとして残っているもの内では、Liferayの以前のバージョンの既存の優れた特性が優先されます。
階層型アーキテクチャ
Liferay Portal 6のアーキテクチャダイアグラムは、多くの場合、フロントエンド、サービスレイヤー(ビジネスロジック用)、および永続レイヤー(主にService Builderによって自動生成される)の層に焦点を当てています。 これらの層はまだ存在しており、モジュール化の取り組み全体で採用されています。
このアーキテクチャに対する最も重要な変更(および改善)は、ポータルが単一の大きなJava EE Webアプリケーションではなくなったことです。 Liferay Portalは、モジュラー開発パラダイムの利点を得るために、多くのモジュールに分割されています。 これらの利点については、次のセクションで説明します。 多くの場合、モジュールはアプリケーション(Wikiやメッセージボードなど)にグループ化され、メインアプリケーションはスイート(Web Experience、Collaboration、Forms & Workflowなど)にグループ化されます。
モジュラーアーキテクチャ
以下の図は、構造的な観点からLiferay DXP 7.1のアーキテクチャを表しています。
Liferayコア
その名前が示すように、Liferay DXP 7.1の中心的で最も重要な部分です。 Liferayコアは、システムのブートストラップおよびすべてのリクエストの受信と委任を管理するJava EEアプリケーションです。 また、LiferayのOSGiエンジンが含まれており、その上にすべてのアプリケーションが実行されます。
Foundation
Foundationスイートはコアの上に位置し、管理インターフェイスと使いやすい開発ビルディングブロックを提供します。 これには、ユーザーとロールの管理、LDAP統合、認証、ライセンス、アップグレード、クラスター、DAO、およびテーマ用の主要なフロントエンド、CSS、taglib、およびJavaScriptのモジュールが含まれます。 Foundationスイートのモジュールは、すべてのアプリ・スイートおよび非コアモジュールと同様に、Liferayコアに依存しています。
すでにご存知のアプリケーション、フレームワーク、およびAPIのほとんどは、アプリ・スイートに集約されています。 スイートはLiferayバンドルで、およびMarketplaceでも入手できます。 さまざまなアプリ・スイートを次に示します。
Liferay Web Experience
Webコンテンツおよびサイト管理、Webコンテンツの表示、アセットパブリッシャー、パンくずなどのアプリケーションと、アプリケーション表示テンプレート、タグ、ごみ箱などの機能とフレームワークが含まれています。
Liferay Collaboration
Liferayのソーシャルアプリケーションと、メッセージボード、Wiki、ブログなどのコラボレーションアプリケーションで構成されています。 Liferayのドキュメント& メディアライブラリーも含まれています。
Liferay Forms and Workflow
フォーム(新規\)、動的データリスト、Kaleoワークフロー、カレンダーなどのアプリケーションを提供します。 また、Webコンテンツおよびドキュメント& メディアで使用される動的データマッピングフレームワークを含んでおり、カスタムフォームとテンプレート機能を提供します。
独立したアプリケーション
最後になりましたが、Liferayの独立したアプリケーションとモジュールも役割を果たします。 独自の機能を提供し、それぞれに機能します。それらのいずれかを特定のスイートに追加するのは不自然です。 Liferay Sync、Marketplace Client、Knowledge Baseなどのアプリケーションや、Marketplaceで利用できるその他のアプリは、独立したLiferayのアプリケーションです。
Liferayエコシステムの利点は、互いに依存し、互いに通信するシンプルで使いやすいモジュールで構成されていることです。 また、サードパーティの開発者は、独自のモジュールを作成してミックスにデプロイできます。
Liferay用の従来のWARスタイルのアプリケーションの開発を続けることもできます。 Portlet互換性レイヤーは、各プラグインWARをモジュールであるWebアプリケーションバンドル(WAB)に変換します。
次に、Liferay DXPモジュラーアプリケーションの構造について考えてみましょう。
モジュラーアプリケーションの構造
前述したように、各アプリケーションは1つ以上のモジュールで構成できます。 このセクションでは、アプリケーションを構成する最も一般的な方法について説明します。
アプリケーションを構造化するためのベストプラクティスは、いくつかのモジュールにあります。 特に、次のモジュールは多くの場合において、アプリケーションを構築するうえでの最良の方法です。
-
サービス:サービス(ビジネスロジック)および永続化の実装が含まれます。
-
API:アプリケーションのパブリックAPIが含まれます。 サービスから分離することにより、APIを使用するモジュールに影響を与えることなく、実装の新しいバージョンをより簡単かつ迅速にデプロイできます。 また、APIのバージョン管理とは無関係に、実装のバージョン管理を変更することもできます。
-
Web:プレゼンテーション層、そして多くの場合、このアプリケーションによって提供されるポートレットが含まれます。
-
テスト:テストが含まれています。 これらは本番用のアプリケーションには含まれていません。
-
特定の目的のモジュール:他のモジュールも、特定の目的のために、またはアプリケーションの機能の一部の代替実装を提供するために作成されることがよくあります。 たとえば、Wikiアプリケーションには、サポートされているWikiエンジンごとに1つのモジュールがあります。
通常アプリケーション内のすべてのモジュールは、それらの参照を容易にするために、ソース内の隣り合うフォルダに配置されます。
本番環境にデプロイするために、LiferayはLPKGパッケージ化形式を提供します。これにより、モジュールのセットを単一のファイルにバンドルし、それに関する追加のメタデータを追加できます。 この形式は、 LiferayのMarketplaceにアプリケーションをアップロードするためにも使用できます。
これで、Liferay 7で導入されたアーキテクチャの変更の基本を理解し、Liferayのアプリケーションで使用されている新しい構造について詳しく知ることができました。 ここまでLiferay Portal 6開発者にとって新しい重要な概念をいくつか学び、そしてLiferay 7に搭載された以前のLiferayリリースでも使用した開発者機能についてを確認しました。
次に、これらの新しい概念と新しいモジュラーアーキテクチャが、開発者にとってどのように役立つかについてを探ります。