すべてのLiferay開発者が知っておくべき基本事項には、何があるでしょうか。
- Liferayはオープンソースであり、車輪の再発明に代わって、以下の標準に重点を置いています。
- そして、Java EEに基づいており、OSGiおよびJavaプラットフォーム用のその他の一般的なテクノロジーを大幅に活用しています。
- また、Liferayはモジュラーアーキテクチャに基づいており、独自のプロジェクトのモジュラー開発パラダイムに従うことが容易になります。
- その上に独自のWebアプリケーション、ポートレット、またはモバイルアプリを構築することができます。
- 依存性のない状態で成熟した開発ツールを提供しており、好みにあわせたツールを使用することができます。
- すべては、再利用と再利用可能なフレームワークとライブラリの提供、そして独自の作成を可能にすることにつながるのです。
詳細については、以下を参照してください。
オープンソースおよび標準準拠
Liferay DXPはオープンソースであり、共同開発モデルに従って構築されています。つまり、新しい開発が行われている段階で随時確認し、コメントし、貢献することができます。これをすべて実行するために使用できるツールを以下に示します。
-
チケットシステム: すべてのバグの修正や改善、新機能を含む製品のあらゆる変更は、JIRAで作成されたチケットから始まります。システム内にはプロジェクトがいくつかありますが、Liferay DXPの作業を追跡したり、発見したバグを報告(もちろん、できるだけ多くの詳細と再現手順を含めた状態で)したりするために使われている主要なものはLPSです。
-
GitHub: ソースコードのホーム。これを使用して、発生したコード変更を確認したり、プルリクエストを送信して改善したりできます。リポジトリも多数ありますが、主要なものはliferay-portalです。
-
Forums: コミュニティで集まり、アイデアを共有し、議論し、コラボレーションを行う場です。ぜひ、質問をしてみてください。他の人も質問がしやすくなることでしょう。
-
Blogs: 主要なコア開発者と最も活発なコミュニティメンバーからの最新ニュース、アドバイス、ベストプラクティスが確認できます。
-
Participate: 参加方法が学べます。あらゆるレベルの専門知識と時間の制約に対応するオプションがあります。
Liferayはオープンソースであることに加えて、標準にも大きく基づいています。 これによりLiferayでのロックインを大幅に削減できます。また、これによって常に改善が促されているのです。
Liferay DXPがサポートする主要な標準は、以下の通りです。
-
Portlets 1.0(JSR-168)およびPortlets 2.0(JSR-286): Liferay DXPは、これら2つのバージョンの仕様に従うすべてのポートレットを実行できます。Liferayは、Portlets 3.0の仕様にも深く関与しています。
-
JSF (JSR-127, JSR-314, JSR-344): コンポーネントベースのWebアプリケーションを構築するためのJava標準です。Liferayは、JSF-Portlet Bridgeの仕様の標準、およびリードに積極的に貢献しています。
-
EcmaScript 2015: JavaScript標準の最新のバージョンです。Liferayのツールは、Babel JSの統合により、最新のすべてのブラウザで使用することができます。
-
Content Management Interoperability Services (CMIS): Liferayのドキュメントとメディアは、この広く採用されている標準をサポートしている外部のドキュメントリポジトリのインターフェイスとして動作します。
-
Java Content Repository (JSR-170): Liferayのドキュメントとメディアの内部リポジトリに保存されているファイルは、 必要に応じてJSR-170の互換リポジトリに保存されるように設定できます。
-
WebDAV: Windows EexplorerやWebDAV固有のクライアントなど、WebDAVがサポートされている場所ならどこにでもドキュメントとメディアのフォルダをマウントすることができます。
-
SAMLおよびOAuth 1.1: これらは、SSOおよびアプリケーションサインインに最も広く採用されているセキュリティプロトコルであり、Liferayマーケットプレイスからインストールできる特定のアプリを通じてサポートされています。
-
JAX-WSおよびJAX-RS: Liferay 7以降、Webサービスを作成するための推奨ツールとして組み込まれました。
-
OSGi r6: Liferayは、独自の実装を通じて幅広いOSGiの標準をサポートし、Apache FelixおよびEclipse Equinoxプロジェクト(共同開発)の高品質な実装も統合します。 以下は、最も関連性が高いサポートされている標準の一部です。
- OSGi runtime: Liferay DXPでのOSGiモジュールの実行を許可します。
- 宣言型サービス: Liferay開発用の動的コンポーネントモデルをサポートします。
- Configuration Admin: すぐに再設定ができるように高度な設定ができるアプリケーションを作成できます。Liferayは自動作成されたUIを提供し、この標準を活用するコンポーネントの設定を変更します。
テクノロジー
Liferayは、他のオープンソースアプリケーションと同様に巨人の肩の上に立つことで構築されています。 プラットフォームを構築するテクノロジーを選択する際には、以下の特性が必要となります。
- 最新かつ、要求の厳しい重要なエンタープライズ環境に対応することができる十分に成熟しており、そのバランスがとれているものであること。
- 広く採用され、成熟したコミュニティを持っていること。
- 使用しているオープンソースプロジェクトに貢献できるように、貢献はできる限り簡単であること。
- 機能のすべてを必要としない場合は、必要なプロジェクトの一部のみを使用することが可能であること。これらを満たすことで、将来的によりうまく機能するものが見つかった場合に、その部分を交換するのが簡単になります。
もちろん、目標は開発者とユーザーにサービスを構築するための最新で使いやすく、かつ安定したプラットフォームを提供することです。
Liferayは基本的に、OSGiコンテナも含むJavaEEアプリケーションです。これにより、堅牢で機能が充実しているエンタープライズプラットフォームへのアクセスと、安定していて機能も充実しているモジュラーコンテナの利点の両方を提供します。つまり、エンタープライズ対応のスケーラブルなWebおよびモバイルベースのアプリケーションを動的なコンポーネントベースの環境で開発およびデプロイできるようになるのです。
スタックの最下部にJava EEとOSGiを配置し、コアの残りの部分はよく知られている製品、または広く使用されている製品で構築しています。
- トランザクションのためのSpring(およびコアのDependency Injection)
- データベースアクセスのためのHibernate(最適化されたクエリのための直接のJDBCアクセスと併せて)
- インデックスの作成と検索のためのElasticsearch
- キャッシュ用のEhcache
アプリケーション層では、開発者が慣れ親しんだ長年使用している、多数のライブラリにアクセスできます。
- Xalan
- Xerces
- Apache Commons
- Tika
- dom4j
カスタマイズを目的としてLiferay DXPを使用する場合、そこにあるツールは、全部ではなかったとしても、そのほとんどが馴染みのあるものだと思います。Liferayでアプリケーションを作成する場合、その可能性は無限大です。好きなWebフレームワークをなんでも使用することができ、サーブレットとポートレットベースのアプリケーションの両方を作成できます。ただし、もし推奨が知りたい場合は、MVCPortletフレームワークを使用してください。
フロントエンドでは、Liferayはこのポートレットフレームワークの最新の進歩に対応しているからです。過去にLiferayを使用したことがある場合は、もちろんLiferayでは馴染み深いAlloy UIを引き続き使用できます。また、以下にリストされているフロントエンドテクノロジーから一番気に入っているものを使用することもできます。
- Bootstrap
- SaSS
- EcmaScript 2015(Babel.jsを使用)
以下を含む、任意のJavaScriptライブラリを使用することもできます。
Liferay DXPは、Liferayのデザイナーが作成したLexicon Experience Languageというデザイン言語に従ってます。これは、WebをClayとして使用するために実装されています。
Clayは、CSSクラスとマークアップのセットを介して自動的に使用可能になりますが、タグライブラリを使用する方が簡単です。
テンプレートに関しては、Java EEのJSPもFreeMarkerと同様に使用されていますが、プラットフォームのモジュール性のおかげでGoogleのSoy(別名、Closure Templates)や他の任意のものも使用することができます。
また、Liferayではいかなる開発環境でも自由に使用できるビルドツールも選択しました。Gradleはbndと共に製品のビルドを強化しますが、プロジェクトのレイアウトは動的であるため、Liferayのアプリケーションをビルドするにあたって、MavenからAnt/Ivyまで何でも使用できます。
つまり、Liferayでは、ユーザーと開発者が最も広く使用されている堅牢なツールにアクセスできるようにするために、様々なことを行っているのです。Liferayは利用者の味方となり、可能な限り最も柔軟なテクノロジープラットフォームを提供するためにできる限りのことを行います。これまでに予想も想像もできなかったこのプラットフォームを使って、素晴らしいものを構築する自由が手に入るのです。
アーキテクチャ
当初から、Liferayの設計目標は、思い描いているWebプレゼンスを正確に作成するためのあらゆるツールを提供することでした。これを実現するには、製品は以下を行う必要があります。
-
使用可能なデフォルトの設定とインターフェースの提供。
-
サイトをすばやく構築するために使用できる最善のアプリの付属。
-
微調整から完全な置き換えまで、あらゆる詳細レベルでのUIのカスタマイズ。
-
任意の詳細レベルでのアプリのカスタマイズ。
-
新たな最善のアプリを構築して共有できる、堅牢な開発プラットフォームの提供。
ここれらの目標は、Liferayの歴史の中で今までにない範囲で達成されています。これは、すべて新しいモジュラーアーキテクチャによってもたらされた成果です。
すべての機能が独立したモジュールである環境を想像してみてください。モジュールは3つの重要なことを宣言します。
- モジュールが実装、または定義する機能
- 他のモジュールへの依存
- 機能に対する優先順位
この情報を使用して、コンテナは、定義、実装、依存関係、および優先順位を満たすモジュールを全て起動できます。
開発者がしたいことは、1つ以上のモジュールとして実装されます。それが新しいアプリケーションの場合は、アプリケーションは既存のモジュールに依存し、それらへの依存関係を定義できます。これにより、アプリ用に自分で書き直さなくても、既に存在する機能が使用できるのです。カスタマイズの場合は、多くの場合、既存の機能よりも高い優先度でカスタマイズを定義するだけで済みます。
これが、モジュラーアーキテクチャの威力です。
モジュール
Liferay上に構築されたすべての新しいアプリケーション、拡張機能、カスタマイズは、モジュール方式で構築されています。 モジュールとは、モジュラーアーキテクチャでのディストリビューションとデプロイによる単一ユニットです。
既存の標準に従うという精神のもとで、LiferayはOSGiという非常に強力な標準のセットを活用しました 。 とりわけ、OSGiはモジュールが互いに依存し、通信する方法を定義します。また、モジュールのパッケージ形式であるOSGiバンドルも定義しています。OSGiモジュールは、コンパイルされたコード、テンプレート、リソース、およびいくつかのメタ情報を含むZIPファイルとしてJava開発者になじみのある典型的なJARファイルです。
サービス
最新のソフトウェアのアーキテクチャの側面の一つに、「サービス」の概念があります。ここでのサービスとは、呼び出されたときに特定の機能を提供する独立して実行される、コードのことです。現実のサービスと同じように動作します。たとえば、芝生を刈るためにサービスを呼び出す場合があるとします。そのサービスを利用する人は、サービス(芝生刈り)を受けるためにサービスを呼び出す方法とサービスを受けるに当たって必要となるもの(お金)を渡す方法を理解しているはずです。 ソフトウェアベースのサービスも同じように機能します。
Liferayのサービスは、OSGi Allianceによって定義されている標準サービスです。 アプリケーションであれ、データベースへのインターフェースであれ、独自に定義した「サービス」であれ、作成したものはOSGiサービスとして簡単に実装できます。なぜなら、これらは信じられないほど強力であり、開発も容易だからです。Javaインターフェースとその実装方法(Javaの入門資料)を理解していれば、知っておくべきことの90%以上をすでに理解していることになります。まず最初に、インターフェイス、またはサービスのコントラクト(サービスが返すもの、返したものをまた返すために必要なもの)を定義します。次に、コントラクトを実装する実装クラスを定義します。
サービスモデルでは、クラスは必要な機能を提供するサービスを要求します。この機能には、適切な実装が自動的に提供されます(多くの場合、注入されます)。SpringやEJBに似ていますが、重要な点が1つあります。それは、システムを再起動することなく、実行時に実装を変更できる点です。これは、サービスがデプロイされると、LiferayのOSGiコンテナによって維持されるサービスレジストリの一部になるためです。コンテナはサービスのライフサイクルを動的に管理し、必要に応じてサービスを開始および停止できます。
サービスの真の力は、サービスが拡張されるときに分かります。既存の実装を置き換えたり、高度なユースケースの場合では、サービスの実装を複数持つこともできます。その後、開発者はすべての実装を呼び出すのか、優先度が一番高いもの(サービスランキングと呼ばれるもので指定されている)のみを呼び出すのかを選択します。つまり、Liferayに何かを行うサービスがある場合、そのインターフェイスを自分で実装し、元のサービスよりも高いランキングでデプロイすることで、そのサービスをカスタマイズまたはオーバーライドすることができるのです。 それから、コンテナはサービスが既存のコードによって呼び出されると、実装をインスタンス化します。このシンプルでクリーンな方法は、ほとんどのカスタマイズがLiferay 7に対して行われる際の方法です。
コンポーネント
OSGiでサービスを作成するにあたって最良かつ最も簡単な方法は、おそらく宣言型サービスを使用することです。宣言型サービス(別名DS)で、コンポーネントを作成します。コンポーネントはJavaクラス(@Component
アノテーションが付けられています)で、このクラスはサービスの実装(上記参照)を提供し、そのインスタンス化がDSによって自動的に処理されます。これは、Spring BeanまたはEJBを使用したことがある場合は、その際に行ったことと似ているかもしれません。また、DSはアノテーション(@Reference
)を使用した依存性注入も提供します。コンポーネントの「配線」はコンテナによって行われますが、サーバーの実行中に変更できるため(Springとは異なり)、便利です。
モジュールには、必要な数のサービス宣言とコンポーネントを含めることができます(もちろん、ゼロも可能です)。
ソフトウェアエンジニアリングの用語では、コンポーネントは大きなアプリケーションの最小の構成要素であり、そのアプリケーション自体は多数の小さなコンポーネントで構成されています。これにより、一度に処理するのは小さくて明確に定義された一口サイズのコードチャンクのみで済むため、アプリケーションの開発が容易になります。
モジュール開発での実際のメリット
なぜ、これが重要で、コンポーネントが必要になるのか、そして、何のために必要なのか疑問を持つかもしれません。
その答えは、カスタマイズタスクと本格的なアプリケーションという2つの一般的な開発シナリオを検証するのに役立つからです。たとえば、データベースのデータから、PDF形式のレポートを生成するシステムがあるとします。データは、Liferayで実行されているWebアプリケーションからキャプチャされます。朝、仕事に来たら、何か問題が起こりました。(それが何であるかは関係ありません。たとえそれがデータの破損であれ、会社の買収であれ、国家の緊急事態だとしてもです。)その際にしなければならないのは、新しいタイトルページを挿入したり、既存のタイトルページに警告を追加したりするために、レポートをできるだけ早く変更することです。
モノリシックモデルでは、アプリケーションを変更してレポートを変更する必要があり、その後、アプリケーション全体を再デプロイする必要があります。これが一時的な変更であった場合、アプリケーションを元の状態に戻すにはアプリケーションを再度変更して、再デプロイする必要があります。
モジュール式のコンポーネントベースのアプリケーションでは、必要な機能を提供するシンプルで小さなコンポーネント(おそらく1つのJavaクラス)を修正します。 そして、そのモジュールをサーバーにデプロイします。将来的にその変更をロールバックする必要がある場合は、同じことを逆の順番で行うだけです。いずれの場合も、アプリケーション全体ではなく、変更を必要とする機能の小さな部分を変更して、再デプロイするだけで済みます。アプリケーション全体を再デプロイしたり、サーバーを停止したりする必要はないのです。
本格的なアプリケーションの場合、そのメリットはさらに大きくなります。モジュラー開発は、以下の3つの重要な方法で開発者の効率を高めます。
- コンポーネントで構成されているアプリケーションは、異なるコンポーネントで作業する複数の開発者が並行して作成できます。
- さまざまな方法で機能を実装するための新しいコンポーネントを作成することにより、既存のアプリケーションを拡張できます。
- コンポーネントを有効または無効にできるため、管理者は本番環境で有効にする機能を選択できます。
たとえば、Liferayのドキュメントとメディアライブラリは、多くのバックエンドをサポートするファイルリポジトリです。それぞれのバックエンドは、さまざまな開発者によって管理することができるコンポーネントであり、これらはサーバーの実行中にオンザフライで追加および削除できます。
同様に、アプリケーションによって提供されるサービスは、フロントエンドテクノロジーから独立しています。実際に、Liferayが提供するWebベースのフロントエンドから、Webまたはモバイル用に開発する新しいフロントエンドまで、複数のフロントエンドが存在する可能性があります。
このように、LiferayのOSGiコンテナの内部で実行されている多くのコンポーネントは、補完的なサービスのエコシステムのようなものを形成しています。Liferayの機能の多くはコンポーネント内にあり、コードをデプロイするとLiferayと同じエコシステム内にあり、同じ拡張ポイントがあります。コンポーネントを記述して、新しいサービスを提供したり、既存のサービスを独自の実装でオーバーライドしたりすることができ、コンテナがすべてを管理します。つまり、Liferayは開発者の生産性をさらに向上できるプラットフォームなのです。