AEM 技術基盤

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

基本事項

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

• リクエスト応答（XMLHttpRequest／XMLHttpResponse）サイクル
• HTML
• CSS
• JavaScript

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

• JCR
• Sling
• OSGi

Java™ コンテンツリポジトリ

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

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

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

Apache Jackrabbit Oak

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

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

Sling のリクエスト処理

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

Sling の概要

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

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

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

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

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

Sling はコンテンツ中心型

Sling は コンテンツ中心の. つまり、(HTTP) 要求が JCR リソース（リポジトリノード）の形式でコンテンツにマッピングされるため、処理はコンテンツに焦点を当てます。

• 最初のターゲットは、コンテンツを保持しているリソース（JCR ノード）です
• 第 2 に、表現（スクリプト）は、リソースプロパティから配置され、リクエストの特定の部分（セレクターや拡張子など）が含まれます

RESTful Sling

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

• 表面だけではなく、RESTful も。リソースと表示域は、サーバー内で正しくモデル化されます
• 1 つ以上のデータモデルを削除します。
  • その他のコンテンツ管理フレームワークでは、リソースにアクセスするために URL 構造、ビジネスオブジェクト、DB スキーマが必要になる場合があります。
  • Sling を使用すると、次の目的で使用できます。URL = resource = JCR 構造

URL の分解

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

次の URL の分析：

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

次の複合部品に分割できます。

• プロトコル - HTTPS
• ホスト - サイトのドメイン
• コンテンツパス — レンダリングするコンテンツを指定するパス。拡張機能と共に使用されます。 この例では、を tools/spy.html
• セレクター — コンテンツをレンダリングする代替の方法に使用します。この例では、A4 形式のプリンターに適したバージョンです。
• 拡張子 - 拡張コンテンツの形式。これも、レンダリングに使用するスクリプトを指定します。
• サフィックス - 追加情報を指定するために使用できます。
• params — 動的コンテンツに必要なパラメーター

URL からコンテンツおよびスクリプトへ

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

• マッピングはリクエストから抽出されたコンテンツパスを使用してリソースを見つけます。
• 適切なリソースが見つかると、Sling リソースタイプが抽出され、コンテンツのレンダリングに使用するスクリプトを見つけるために使用されます。

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

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

リクエストのリソースへのマッピング

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

• 最初の Sling では、リクエストで指定されている場所（例：../content/corporate/jobs/developer.html）にノードが存在するかどうかを確認します。
• ノードが見つからない場合は、拡張子なしで検索を繰り返します（例：../content/corporate/jobs/developer）。
• ノードが見つからない場合、Sling は http コード 404(Not Found) を返します。

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

スクリプトの検索

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

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

• 絶対パス
• 設定パラメーターに対する相対パス

すべての Sling スクリプトは、次の /apps （可変、ユーザースクリプト）または /libs （不変、システムスクリプト）。この順序で検索されます。

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

• メソッド (GET、POST) が必要な場合は、HTTP の仕様に従って大文字で指定します。例： jobs.POST.esp
• 様々なスクリプトエンジンがサポートされていますが、一般的な推奨スクリプトは HTL と JavaScript です。

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

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

• .htmlで終わる GET/HEAD リクエストと URL（デフォルトのリクエストタイプ、デフォルトの形式）
  • スクリプトは /apps/hr/jobs/jobs.esp;の最後のセクション sling:resourceType はファイル名を形成します。
• POST リクエスト（GET／HEAD を除くすべてのリクエストタイプ。メソッド名は大文字にする必要があります）
  • スクリプト名には POST が使用されます。
  • スクリプトは /apps/hr/jobs/jobs.POST.esp です。
• .htmlで終わらない、他の形式の URL
  • 例：../content/corporate/jobs/developer.pdf
  • スクリプトは /apps/hr/jobs/jobs.pdf.esp;サフィックスがスクリプト名に追加されます。
• セレクターを含む URL
  • セレクターを使用して、同じコンテンツを別の形式で表示できます。例えば、プリンタに適したバージョン、RSS フィード、サマリなどです。
  • プリンターに適したバージョンでセレクターが print;次に示すように ../content/corporate/jobs/developer.print.html
  • スクリプトは /apps/hr/jobs/jobs.print.esp;セレクターがスクリプト名に追加されます。
• そうでない場合は、 sling:resourceType は次のように定義されます。
  • コンテンツパスは、適切なスクリプト（パスベースの場合）を検索するために使用されます ResourceTypeProvider がアクティブな場合 )。
  • 例えば、../content/corporate/jobs/developer.html のスクリプトは、/apps/content/corporate/jobs/ で検索を生成します。
  • プライマリノードタイプが使用されます。
• スクリプトが見つからない場合は、デフォルトのスクリプトが使用されます。
  • デフォルトのレンディションは、プレーンテキスト (.txt),HTML(.html)、および JSON (.json) に書き込まれます。これらすべてには、ノードのプロパティ（適切な形式）が一覧表示されます。 拡張子 .res のデフォルトのレンディション、または要求拡張子のない要求は、（可能な場合は）リソースをスプールします。
• HTTP エラー処理（コード 403 または 404）の場合、Sling は次のいずれかの場所でスクリプトを探します。
  • カスタマイズされたスクリプトの場所 /apps/sling/servlet/errorhandler
  • または標準スクリプトの場所 /libs/sling/servlet/errorhandler/404.jsp

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

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

• /content/corporate/jobs/developer.print.a4.html

タイプ

• sling:resourceType="hr/jobs"

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

1. GET.esp
2. jobs.esp
3. html.esp
4. print.esp
5. print.html.esp
6. print/a4.esp
7. print/a4/html.esp
8. print/a4.html.esp

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

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

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

• リソースの sling:resourceSuperType プロパティを使用。
• sling:resourceSuperType が示すノードの sling:resourceType プロパティを使用。

次に例を示します。

• /
  • a
  • b
    • sling:resourceSuperType = a
  • c
    • sling:resourceSuperType = b
  • x
    • sling:resourceType = c
  • y
    • sling:resourceType = c
    • sling:resourceSuperType = a

タイプの階層：

• /x
  • [ c, b, a, <default>] です
• 一方、/y では
  • [ c, a, <default>] です

理由は、 /y には sling:resourceSuperType プロパティは、一方で /x ではなく、したがって、そのスーパータイプがそのリソースタイプから取得されます。

Sling スクリプトを直接呼び出しできない

Sling 内では、REST サーバーの厳密な概念を破るので、スクリプトを直接呼び出すことはできません。リソースと表示域を混在させることができます。

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

• GET 以外の HTTP メソッドの自動処理。これには以下が含まれます。
  • POST、PUT、DELETE。Sling のデフォルト実装で処理されます。
  • sling:resourceType 内の POST.jsp スクリプト
• コードアーキテクチャに必要なクリーン性や明確な構造が失われます。これは大規模な開発では最も重要です。

Sling API

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

sling:include を使用した既存の要素の参照

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

より複雑なスクリプト（集計スクリプト）は、複数のリソース（ナビゲーション、サイドバー、フッター、リストの要素など）にアクセスし、 リソース.

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

OSGi

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

• コンテナ内に実装されているサービス
• コンテナとアプリケーションの間の契約

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

その後、OSGi フレームワークは、再起動を必要とせずに、これらのバンドルの動的な読み込み/アンロード、設定、制御を提供します。

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

この機能を使用すると、インストール内の任意のパッケージに対して、次の操作を実行できます。

• インストール
• 開始
• 停止
• アップデート
• アンインストール
• 最新のステータスを見る
• 特定のバンドルに関する詳細な情報（シンボリック名、バージョン、場所など）にアクセス

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

リポジトリ内の構造

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

• /apps - アプリケーション関連。Web サイトに固有のコンポーネント定義が含まれます。開発するコンポーネントは、/libs/core/wcm/components で提供されている標準搭載のコンポーネントに基づくことができます。
• /content -
  Web サイト用に作成されたコンテンツ。
• /etc
• /home - ユーザーおよびグループの情報。
• /libs - AEM のコアに属するライブラリと定義。のサブフォルダー /libs は、標準のAEM機能を表します。 /libs 内のコンテンツは変更できません。Web サイトに固有の機能は、/apps の下に作成する必要があります。
• /tmp - 一時作業領域。
• /var - システムによって変更および更新されるファイル監査ログ、統計、イベント処理など。

Business.Adobe.com リソース