AEM 技術基盤 aem-technical-foundations

AEM は、拡張性が高く柔軟なテクノロジーに基づいて構築された実証済みの堅牢なプラットフォームです。このドキュメントは、AEM を構成する様々な部分の詳細な概要を説明し、フルスタック AEM 開発者向けの技術的な付録として作成されています。はじめる前のガイドとしての意図はありません。AEM を初めて開発する場合は、最初の手順としてAEM Sites の開発の手引き - WKND チュートリアルを参照してください。

基本事項 fundamentals

最新のコンテンツ管理システムである AEM は次の標準的な Web テクノロジーに依存しています。

基盤となるコンテンツリポジトリとビジネスロジックレイヤーは、Java™ テクノロジーに基づいて構築されています。

Java™ コンテンツリポジトリ java-content-repository

Java™ コンテンツリポジトリ（JCR）の規格である JSR 283 では、コンテンツリポジトリ内で、任意の精度レベルでコンテンツに双方向アクセスするための、ベンダーにも実装にも依存しない方法が指定されています。仕様を主導しているのは、Adobe Research（スイス）AG です。

JCR API 2.0 パッケージである javax.jcr.* が、リポジトリーコンテンツの直接アクセスと操作に使用されます。

AEM は JCR 上に構築されています。

Apache Jackrabbit Oak jackrabbit-oak

Apache Jackrabbit Oak は、JCR 標準に準拠した最新のワールドクラスの Web サイトやその他の要求の厳しいコンテンツアプリケーションの基盤として使用する、スケーラブルで高パフォーマンスの階層コンテンツリポジトリーの実装です。

Jackrabbit Oak（単に Oak とも呼ばれる）は、AEM を構築する JCR 標準の実装です。

Sling のリクエスト処理 sling-request-processing

AEM は、コンテンツ指向アプリケーションの開発を容易にする REST 原則に基づく Web アプリケーションフレームワーク Sling を使用して構築されています。Sling は、Apache Jackrabbit Oak などの JCR リポジトリーをデータストアとして使用します。Sling は Apache Software Foundation に貢献してきました。詳しい情報は Apache にあります。

Sling の概要 introduction-to-sling

Sling を使用する場合、レンダリングされるコンテンツのタイプは、処理に関する第一の考慮事項ではありません。代わりに、主な考慮事項は、URL がコンテンツオブジェクトに解決され、そのオブジェクトに対してレンダリングを実行するスクリプトが見つかるかどうかです。このプロセスは、web コンテンツ作成者が要件に合わせて容易にカスタマイズ可能なページを作成する上で、優れたサポートを提供します。

この柔軟性の利点は、様々なコンテンツ要素を持つアプリ、または容易にカスタマイズできるページが必要な場合に明らかです。特に、AEM などの Web コンテンツ管理システムを実装する場合です。

Sling を使用した開発の概要について詳しくは、『15 分間でわかる Sling』を参照してください。

次の図は、Sling のスクリプト解決の説明です。HTTP リクエストからコンテンツノード、コンテンツノードからリソースタイプ、リソースタイプからスクリプトを得る方法と、使用可能なスクリプト変数を示しています。

次の図は、すべての POST リクエストのデフォルトハンドラーである SlingPostServlet で使用できる、非表示で強力なリクエストパラメーターを示しています。ハンドラーは、リポジトリ内でノードを作成、変更、削除、コピーおよび移動するための無限のオプションを用意しています。

Sling はコンテンツ中心型 sling-is-content-centric

Sling は​ コンテンツ中心型 ​です。（HTTP）リクエストがそれぞれ JCR リソース（リポジトリノード）の形式でコンテンツにマッピングされるので、コンテンツに焦点を当てた処理が行われます。

RESTful Sling restful-sling

コンテンツ中心型の原理により、Sling は REST 指向のサーバーを実装するので、Web アプリケーションフレームワークの新しい概念を特徴としています。メリットは次のとおりです。

URL の分解 url-decomposition

Sling では、処理はユーザーリクエストの URL によって実行されます。適切なスクリプトで表示するコンテンツを定義し、URL から情報を抽出します。

次の URL を分析します。

https://myhost/tools/spy.printable.a4.html/a/b?x=12

次のように複合的な部分に分解できます。

URL からコンテンツおよびスクリプトへ from-url-to-content-and-scripts

URL 分解の原則を使用します。

下の図は、使用するメカニズムを示し、これについて詳しくは、次の節で説明します。

Sling を使用して、特定のエンティティをレンダリングするスクリプトを指定します（JCR ノードで sling:resourceType プロパティを設定します）。このメカニズムは、リソースが複数のレンディションを持つことができるため、スクリプトがデータエンティティにアクセスするメカニズム（PHP スクリプトの SQL 文のように）よりも自由度が高くなります。

リクエストのリソースへのマッピング mapping-requests-to-resources

リクエストを分解し、必要な情報を抽出します。リポジトリーで、リクエストされたリソース（コンテンツノード）を検索します。

Sling では JCR ノード以外のものをリソースとすることもできますが、これは高度な機能です。

スクリプトの検索 locating-the-script

適切なリソース（コンテンツノード）が見つかったら、Sling リソースタイプ ​が抽出されます。このパスは、コンテンツのレンダリングに使用するスクリプトを探します。

sling:resourceType によって指定されるパスは、次のいずれかです。

すべての Sling スクリプトは、/apps（可変、ユーザースクリプト）または /libs（不可変、システムスクリプト）のサブフォルダーに格納され、この順序で検索されます。

その他の注意点は次のとおりです。

AEM の特定のインスタンスでサポートされているスクリプトエンジンのリストは、Felix Management Console（http://<host>:<port>/system/console/slingscripting）にあります。

以前の例を使用すると、sling:resourceType が hr/jobs の場合は、次のようになります。

特定のリクエストに複数のスクリプトが該当する場合は、一致率が最も高いスクリプトが選択されます。一致は具体的であるほど良くなります。つまり、リクエスト拡張子であれ、メソッド名の一致であれ、セレクターの一致が多いほど良くなります。

例えば、次のリソースにアクセスするためのリクエストについて考えます。

タイプ

次のスクリプトのリストが正しい場所にあると仮定します。

この場合、優先順位は (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1) となります。

リソースタイプ（主に sling:resourceType プロパティで定義）に加えて、リソーススーパータイプもあります。これは通常、sling:resourceSuperType プロパティで示されます。これらのスーパータイプは、スクリプトを検索する際にも検討されます。リソーススーパータイプの利点は、（デフォルトのサーブレットで使用される）デフォルトのリソースタイプ sling/servlet/default が事実上のルートになるリソースの階層を形成できる点です。

リソースのリソーススーパータイプは次の 2 つの方法で定義できます。

次に例を示します。

タイプの階層：

これは、/y には sling:resourceSuperType プロパティがあるのに対して、/x にはなく、スーパータイプがリソースタイプから継承されているからです。

Sling スクリプトを直接呼び出しできない sling-scripts-cannot-be-called-directly

Sling 内では、スクリプトを直接呼び出しできません。REST サーバーの厳格な概念に違反して、リソースと表現を混在させることになるからです。

表現（スクリプト）を直接呼び出す場合、リソースがスクリプト内に隠蔽されるので、フレームワーク（Sling）では認識できなくなります。これにより、次のような機能が失われます。

Sling API sling-api

Sling API パッケージ、org.apache.sling.* およびタグライブラリを使用します。

sling:include を使用した既存の要素の参照 referencing-existing-elements-using-sling-include

最後の考慮事項は、スクリプト内にある既存の要素の参照の必要性です。

より複雑なスクリプト（集計スクリプト）は、リソース ​を含めることによって、複数のリソース（ナビゲーション、サイドバー、フッター、リストの要素など）にアクセスします。

この場合、sling:include("/<path>/<resource>") コマンドを使用します。参照されるリソースの定義が効果的に含まれます。

OSGi osgi

OSGi（Open Services Gateway Initiative）は、モジュラー型アプリケーションとライブラリを開発およびデプロイするためのアーキテクチャを定義します（Java™ 用 Dynamic Module System とも呼ばれます）。OSGi コンテナを使用すると、アプリケーションを個々のモジュール（追加のメタ情報を含む jar ファイルで、OSGi 用語でバンドルと呼ばれます）に分割し、それらの間の相互依存関係を次の機能で管理できます。

これらのサービスおよび契約によって提供されるアーキテクチャでは、コラボレーションのために個々の要素が相互に動的に検出し合うことができます。

その後、OSGi フレームワークによって、これらのバンドルの動的な読み込み／読み込み解除、設定および制御が可能になります。再起動は不要です。

このアーキテクチャを使用すると、Sling をアプリケーション固有のモジュールで拡張できます。Sling、つまり AEM は、OSGi の Apache Felix 実装を使用します。どちらも、OSGi フレームワーク内で実行される OSGi バンドルの集まりです。

この機能により、インストール内のどのパッケージでも、次のアクションを実行できます。

詳しくは、「AEM as a Cloud Service の OSGI の設定」を参照してください。

リポジトリ内の構造 structure-within-the-repository

以下のリストは、リポジトリ内で見られる構造の概要を示しています。