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・リサーチ( SWIS . S)が保有する。

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

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

Apache Jackrabbit Oak を基盤として構築されています。

Apache Jackrabbit Oakisは、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を使用した開発の最初の手順については、Discover Slingを15分後に参照してください。

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

Apache Slingスクリプトの解決について

次の図は、SlingPostServletを扱う際に使用できるすべての非表示で強力なリクエストパラメータを説明しています。このリクエストパラメータは、リポジトリ内のノードの作成、変更、削除、コピー、移動に関する無限のオプションを提供します。

SlingPostServletの使用

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:// myhost / tools/spy .printable.a4. html / a/b ? x=12
  • protocol - HTTPS
  • host — サイトのドメイン
  • content path — レンダリングするコンテンツを指定し、拡張子と組み合わせて使用するパス。この例では、 tools/spy.html
  • selector(s) — コンテンツをレンダリングする別の方法で使用します。この例では、A4形式のプリンターに適したバージョンです。
  • extension — コンテンツ形式;レンダリングに使用するスクリプトも指定します
  • suffix — 追加情報を指定するために使用できます。
  • param(s) — 動的コンテンツに必要なパラメーター

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

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

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

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

URLマッピングメカニズム

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

リソースへの要求のマッピング

リクエストは分解され、必要な情報が抽出されます。リポジトリで、リクエストされたリソース(コンテンツノード)の検索がおこなわれます。

  • First Slingは、要求で指定された場所にノードが存在するかどうかを確認します。例えば../content/corporate/jobs/developer.html
  • ノードが見つからない場合、拡張子は削除され、検索が繰り返されます。例えば../content/corporate/jobs/developer
  • ノードが見つからない場合、Slingはhttpコード404(見つかりません)を返します。

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

スクリプトの検索

適切なリソース(コンテンツノード)が見つかると、sling リソースタイプ​が抽出されます。これは、コンテンツのレンダリングに使用するスクリプトを見つけるパスです。

sling:resourceTypeで指定するパスは、次のいずれかになります。

  • 絶対
  • 設定パラメーターに対する相対
ヒント

移植性を高めるため、相対パスはAdobeが推奨します。

すべてのSlingスクリプトは、/apps (mutable、user scripts)または/libs (immutable、system scripts)のサブフォルダに格納され、この順序で検索されます。

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

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

AEMの特定のインスタンスでサポートされるスクリプトエンジンのリストが、Felix Management Console(http://<host>:<port>/system/console/slingscripting)に一覧表示されます。

前述の例を使用して、sling:resourceTypehr/jobsの場合は、次の処理が行われます。

  • .htmlで終わるGET/HEADリクエストとURL(デフォルトのリクエストタイプ、デフォルトの形式)
    • スクリプトは/apps/hr/jobs/jobs.espです。sling:resourceTypeの最後のセクションがファイル名になります。
  • POST要求(GET/HEADを除くすべての要求タイプ。メソッド名は大文字にする必要があります)
    • スクリプト名にPOSTが使用されます。
    • スクリプトは/apps/hr/jobs/jobs.POST.espになります。
  • 他の形式のURL(.htmlで終わらない)
    • 例:../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:resourceTypeが指すノードのsling:resourceSuperTypeプロパティに置き換えます。

次に例を示します。

  • /
    • 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>]です

これは、/ysling:resourceSuperTypeプロパティを持つのに対し、/xは持たないので、スーパータイプはそのリソースタイプから取られるからです。

Slingスクリプトを直接呼び出すことはできません

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

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

  • GET以外のhttpメソッドの自動処理:
    • Sling のデフォルトの実装で処理される POST、PUT、DELETE
    • sling:resourceTypeの場所のPOST.jspスクリプト
  • あなたのコードアーキテクチャはもはやクリーンでなく、あるべき構造であるほど明確ではありません。大規模開発にとって最も重要である

Sling API

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

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

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

より複雑なスクリプト(スクリプトを集約する)は、複数のリソース(ナビゲーション、サイドバー、フッター、リストの要素など)にアクセスし、リソース​を含める必要がある場合があります。

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

OSGi

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

  • コンテナ内で実装されるサービス
  • コンテナと申し込みの間の契約

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

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

メモ

OSGi技術に関する詳細は、OSGiのWebサイトを参照してください。

特に、基礎教育に関するページには、プレゼンテーションやチュートリアルのコレクションが収められています。

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

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

  • インストール
  • 開始
  • 停止
  • 更新
  • アンインストール
  • 現在のステータスの確認
  • 特定のバンドルに関する詳細な情報(シンボリック名、バージョン、場所など)にアクセス

詳しくは、AEM用のOSGiをCloud Serviceとして設定するを参照してください。

リポジトリ内の構造

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

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

この構造、またはその中のファイルの変更は、注意しておこなう必要があります。変更が及ぼす影響を十分に理解しておく必要があります。

/libs パス内の設定は一切変更しないでください。設定やその他の変更の場合は、項目を/libsから/appsにコピーし、/apps内で変更を行います。

このページ