AEM への貢献 contributing-to-aem

開発方法 development-methodology

AEM は、大規模なオープンソースのプロジェクトで一般的に実施される、実績ある方法に従って開発されます。AEM のテクノロジースタックの多くのコア要素は、実際は Sling や Jackrabbit のようなアクティブなオープンソースプロジェクトとして保守され、Apache Software Foundation に貢献しました。AEM に存在するこの精神における重要な側面は、利用可能なメーリングリストやオンラインフォーラムを活用した開発チームとの直接のやり取りが奨励されているということです。

AEM のコンポーネントに貢献する場合は、オープンソースプロジェクトに貢献する場合と同様に AEM に関する知識を深め、このようなプロジェクトに貢献しようとする場合と同様に既存のコアチームとコミュニケーションを取ります。

必要な経験 required-experience

ハイパーテキストトランスファープロトコル（HTTP）は、すべての作業の中心となります。したがって、AEM に貢献する前に、HTTP について深く理解する必要があります。スレッドプーリングを使用してマルチスレッド HTTP サーバーの Java™ 実装を独自で記述できるレベルが理想です。また、HTTP/1.1 のキープアライブ動作についても理解する必要があり、JavaScript によるサーバー／クライアント側のインタラクション、特に、AJAX によって表現される非同期スタイルのインタラクションに関する深い知識も必要です。

ページダイナミズムとインタラクティブなコンテンツが WM 体験では重要なので、ドキュメントオブジェクトモデルについて、またこれを使用してイベントに対する応答をプログラムによって操作する可能性についても、かなり深く理解しておくことが不可欠です。例えば、リアルタイムの DOM 操作や、複数のブラウザードキュメントにまたがったドラッグ＆ドロップ動作（iframe を使用するなど）についても、ある程度の知識が必要です。

最高レベルでは、以下について確実に理解する必要があります。

Adobe Experience Manager のテクノロジースタックは、Apache Felix OSGI コンテナと Apache Sling web フレームワークに基づいており、Java コンテンツリポジトリ（JCR）を、Apache Jackrabbit に基づいて埋め込みます。これらの個々のプロジェクト、および貢献する領域で使用されるその他のオープンソースコンポーネント（Apache Lucene など）に関して熟知しておいてください。

業界知識 tribal-knowledge

一定の概念や指針は、以前の Day 社の文化に深く根ざしています。ここでは、「DNA に深く埋め込まれている」問題の中で注意すべきものをいくつか示します。

すべてがコンテンツである everything-is-content

コンテンツに含まれるのは、web アプリケーションで保持されるすべてのデータだけではありません。あらゆる種類のプログラムコード、ライブラリ、スクリプト、テンプレート、HTML、CSS、画像およびアーティファクトが、どれもすべてコンテンツリポジトリ内に保持され、パッケージマネージャーおよび Package Share 経由で、パッケージの形式で読み込みおよび書き出しされます。

David's Model david-s-model

Java™ コンテンツリポジトリでコンテンツをモデル化する場合は、リレーショナルな世界でのデータのモデル化に関するソフトウェア業界の一般的な考え方とはまったく異なる方法が必要です。JCR を使用したコンテンツ管理が初めての方必読のドキュメントは、David's Model：A guide for content modeling です。

RESTful であること restfulness

REST アプローチは、作業内容に深く根ざしています。つまり、何よりも、ステートフルなインタラクションを回避すること、また、URI がコンテンツおよびサービスの確定的なアドレスであることを心に留めておくことです。

REST（REpresentational State Transfer）は、World Wide Web の基礎となっているソフトウェアアーキテクチャスタイルを示します。Web を機能させるための重要な要素について説明するものであり、web ベースのソフトウェアの設計方法について一連の原則を提供します。したがって、web 経由で使用する API を設計するときは、これらの「ベストプラクティス」を順守することが合理的です。

REST は非常に多くの作業の背景に指針となる考え方を提供するので、RESTful な設計の教義を熟知しておくことが不可欠と考える必要があります。手始めとしてふさわしいのは、Roy Fielding 氏の論文です。

Sling のリクエスト解決 sling-request-resolution

AEM について理解する上で重要な点は、受信リクエストがコンテンツおよびアプリケーションの動作とどのように関連付けられるか、コンテンツリポジトリでのコンテンツの構造、およびリクエスト処理のためのアプリケーションロジックを AEM がどこで検索するかです。Apache Sling URL の分解について、また、REST アーキテクチャスタイルおよびそのステートレスでキャッシュ可能な階層化システムの制約を実施する方法について学習してください。

Apache Sling のリクエスト解決に関しては、コンテンツリポジトリの特定のリソースにリクエストが最初にマッピングする方法、コンテンツをレンダリングする際にどのアプリケーションコードを呼び出すかをリクエストする追加プロパティとこれらのコンテンツオブジェクトのプロパティによって決定する方法、および /apps 内のコードで /libs 内のコードを上書きする方法を理解することが重要です。

クイックスタート quickstart

手順 3 がない：インストールして実行するには、クイックスタート JAR ファイルをダウンロードしてダブルクリックするだけです。手順 3 はありません。オプションの機能を追加する場合も、Package Share から該当するパッケージをインストールするだけです。

小さなクイックスタートサイズ：クイックスタート JAR ファイルのサイズを最小限に維持します。ライブラリを要領よく最適に使用して、オプションの機能を Package Share に移動します。

起動時間が短い：起動時間に影響する可能性のある変更を行う場合は、長くなるのではなく、短くなるようにします。

無駄なくすっきり lean-and-mean

アドビでは、軽量でサイズが小さく、高速かつ洗練されたコードやプロジェクトを優先します。「十分に良い」では本当に十分ではありません。

コードの再利用：OSGi ベースの製品アーキテクチャと「すべてがコンテンツである」という考え方は、コードおよびアーティファクトを再利用する、いつにない好機が与えられているということを意味します。アドビでは、この事実を可能な限り利用して、無駄なくすっきりした機能を維持しようとしています。

疎結合：アドビでは、厳密な依存関係や「不要な密接さ」よりも、疎結合のインタラクションを優先します。疎結合により、より多くのコードの再利用も可能になります。

デモを中断しない don-t-break-the-demo

デモスクリプトや、デモで最も頻繁に示される製品機能の知識を深めてください。少なくとも、「デモスクリプト」の機能を無効にする処理は行ってはならないことを理解してください。コア製品は、開発中であっても、いつでもデモが見られる状態である必要があります。

信頼できる設計 design-for-reliability

（例えば）単一の DOM 要素に問題があってもページ全体がレンダリングされないように、フェイルソフト方式で機能のデザインとコード化を行うよう努めています。 つまり、致命的とするべきことは致命的とし、その他はすべて存続可能にして、製品を「寛容に」するということです。

異常は新たな正常 abnormal-is-the-new-normal

シャットダウンフックに依存せず、起動時に必ずクリーンアップします。 異常終了は正常な終了です。

shutdown == kill -9 == power outage

弾性クラスター化に備える be-ready-for-elastic-clustering

常に弾性クラスター化に備え、常にクラスター化が存在すると想定してください。一般的に、すべてをコンテンツリポジトリ内に存在させることは、組み込みのクラスター化サポートを意味します。

下位互換性に対応する設計 design-for-backward-compatibility

お客様の古いコードを壊すようなことはありません。 アップグレード時に更新可能なプロダクトコードを含むのは、/libs のみとお考えください。リポジトリの /apps セクションはプロジェクトコードで、/etc セクションには、保存する必要があるカスタム設定が含まれています。通常、/apps、/content、/home 内では何も上書きしません。アップグレード後も、古いプロジェクトコード、設定およびコンテンツは、アップグレード前と同様に引き続き機能します。

また、後方互換性を考慮した設計により、アップグレード時の操作性が初期導入時のシンプルさと同等になるように配慮しています。単純に AEM を停止し、クイックスタート JAR ファイルを置き換え、AEM を再度起動するだけです。インストールベースが急速に拡大しているため、アップグレードの効率性はますます大きなメリットとなっています。

より新しく、より高度な機能に置き換えられると、既存の API は廃止とマークを付けることができ、またそうする必要がありますが、以前の 5.x リリースで公開された API はすべて、カスタムアプリケーションコードで使用される可能性があるので、引き続き機能する必要があります。そのような API は削除しないでください。

後方互換性は、コンテンツ構造とユーザーエクスペリエンスの全体的な一貫性という意味でも、心に留めておく必要があります。

中心概念 core-concepts

オーサーインスタンス - 通常、セキュリティやガバナンスなどの理由で、実稼動サイトでは AEM のインスタンスがオーサーインスタンスとパブリッシュインスタンスに分割されます。デプロイメントアーキテクチャ（オーサー／パブリッシュインスタンスを含む）について詳しくは、AEM インスタンスに関するドキュメントを参照してください。

キャッシュ、フライング、ベーキング - 従来、ベーキングとフライングの概念は、異なる web コンテンツ管理システムを区別する上で重要です。CMS の用語では、「ベイキング」とは、公開時にデータを静的ファイルにコミットする概念を指し、「フライング」とは、リクエスト時（即時）に最終的なプレゼンテーション用のデータを処理する概念を指します。

クラスタリングとロードバランシング - 可用性を向上し、実稼動環境のパフォーマンスを改善するために、通常は、オーサーインスタンスとパブリッシュインスタンスのいずれかまたは両方を複数組み合わせてクラスターを作成します。その際、これらのインスタンスを別のユーザーグループが使用できるようにするか、Dispatcher 設定の背後でロードバランシングを行うのが一般的です。

また、コンテンツリポジトリの複数のインスタンスを組み合わせて、高可用性 ​の JCR ソリューションを作成することができます。さらに、このソリューションを AEM ソリューションに統合することで、ハードウェアおよびソフトウェアの障害に対して最大限の保護を実現できます。詳しくは、推奨されるデプロイメントを参照してください。

コンポーネント - AEMでは、コンポーネントはオブジェクトタイプで、そのインスタンスは通常、サイドキックなどからドラッグ＆ドロップすることで作成できます。例えば、AEM に同梱されている標準のコンポーネントには、テキスト、タイトル、タグクラウド、カルーセル、画像、リストの各コンポーネントが含まれ、これらのすべては実行時に Sidekick からで使用できます。

コンテンツファインダー - オーサリングモードでは、コンテンツファインダーはページの左側にある特殊なパネル（フレーム）であり、上部で選択するタブによって、画像、ドキュメント、Flash アセット、ページ、段落、リポジトリリソースのいずれかのリストが表示されます。これらを、コンテンツファインダーから作業中のページ（右側）にドラッグ＆ドロップできます。

デジタルアセット - AEM では、デジタルアセットは（通常）画像とリッチメディアファイルです。詳しくは、「DAM でのデジタルアセットの操作」を参照してください。

Dispatcher - Dispatcher は、キャッシュおよびロードバランシングツールであると同時に、特定のセキュリティ保護機能を提供します。

ExtJS ウィジェット - AEM のほとんどのユーザーインターフェイス要素は、ExtJS を使用しています。ExtJS は、JavaScript で書かれたサードパーティのウィジェットライブラリです。ExtJS は、高パフォーマンスでカスタマイズ可能な UI ウィジェットと、適切にデザインされた拡張可能なコンポーネントモデルを備えています。

JCR、Java™ コンテンツリポジトリ - Java™ コンテンツリポジトリ仕様（JSR-283）は、抽象データモデルとアプリケーションプログラミングインターフェイスの両方を提供します。ファイルシステムとオブジェクトデータベースの機能を組み合わせた、非常にスケーラブルな NoSQL データリポジトリを実現します。JSR-283 を詳細に理解する必要はありませんが、JCR は AEM の「すべてがコンテンツ」という理念を可能にするものなので、JCR の基本機能とその基礎となるデータモデルについて時間をかけて理解する必要があります。

本質的に、JCR はノードとプロパティのシステムであり、ノードは他のノードからの継承が可能で、すべてのコンテンツはプロパティの​ 値 ​として格納されます。通常の継承に加えて、JCR は「mixin」ノードの概念に対応しており、複数の継承をモデル化できます。

JCR には事前定義されたノードタイプとプロパティタイプが多数含まれていますが、一般的に型指定システムは柔軟です。実際に、JCR の長所の 1 つは、構造化コンテンツも非構造化コンテンツも同じくらい簡単に格納および管理できることです。つまり、JCR には高度に構造化されたデータを含めることができますが、任意の動的データ構造もスキーマ制約なしで含めることができます。

JCR の Java™ API に関する JavaDoc は、こちらを参照してください。

JavaDoc または JCR の仕様自体を読む前に、Adobe Experience Services によって実装された JCR の概要にも目を通しておくことをお勧めします。

マルチサイトマネージャー（MSM） - AEM のMSM 機能は、多言語、多国籍のコンテンツを処理する際に役立ち、一元管理されたブランディングとローカライズされたコンテンツのバランスを取ることができます。

OSGi - OSGi は、AEM でモジュール化された Java™ 開発の基盤となる、サービスベースのランタイムテクノロジーです。これは、コードリソース（バンドルと呼ばれる）の非常に動的（かつ安全な）クラスの読み込みと実行環境を提供するだけでなく、バンドルによって公開される様々なサービスの可視性とライフサイクルを完全に制御するフレームワークです。 サービスレジストリは、ライフサイクルダイナミクス（およびバージョン要件）を考慮に入れたバンドルの協調モデルを提供します。 OSGi は、アプリケーションサーバーが解決しようとした問題の多くを解決しますが、軽量で非常に動的な方法で解決し、例えば、サービスのホットデプロイ（サーバーを再起動せずに新しいコードをすぐに使用可能にする）を可能にします。

Parsys、 段落システム - 段落システム（parsys）は、作成者が様々なタイプのコンポーネントをページに追加することができ、他の段落コンポーネントを含む複合コンポーネントです。各段落タイプは、コンポーネントとして表されます。段落システム自体もコンポーネントであり、他の段落コンポーネントが含まれます。

マイクロカーネル - リポジトリ内の各ワークスペースは、特定のマイクロカーネル（データの読み取りと書き込みを管理するクラス）を通してデータを保存するように、個別に設定できます。同様に、リポジトリレベルのバージョンストアも、特定のマイクロカーネルを使用するように、個別に設定できます。使用できるマイクロカーネルは多数あり、様々なファイル形式やリレーショナルデータベースへのデータ保存に対応できます。（例えば、MongoDB、DB2® または Oracle 用の永続性マネージャーがあります）。AEM 用のデフォルトのマイクロカーネルは TarMK です（後述）。

パブリッシュインスタンス - セキュリティやガバナンスなどの理由で、実稼動サイトでは通常、AEM のインスタンスをオーサーインスタンスとパブリッシュインスタンスに分割します。デプロイメントアーキテクチャ（オーサー／パブリッシュインスタンスを含む）について詳しくは、AEM インスタンスに関するドキュメントを参照してください。

クイックスタート - 他の多くのプログラムとは異なり、AEM をインストールするには、1 つの「クイックスタート」自己解凍 JAR ファイルを使用します。JAR ファイルを初めてダブルクリックすると、必要なものがすべて自動的にインストールされます。クイックスタート JAR には、CRX リポジトリ（管理施設を含む）、仮想リポジトリサービス、インデックスと検索サービス、ワークフローサービス、セキュリティ、Web サーバー、および CQ サーブレットエンジン (CQSE) とすべての AEM サービスに必要なすべてのファイルが含まれます。 他にインストールするファイルはありません。クイックスタートは自己完結型です。

クイックスタートを初めて起動すると、JCR 対応のリポジトリ全体がバックグランドで作成されます。この処理には数分かかる場合があります。この初期起動が完了すると、リポジトリのインフラストラクチャは既に設定されているので、その後の起動処理はごく短時間で済みます。

多くの起動オプション（アクティブなポート番号、問題の AEM インスタンスをパブリッシュインスタンスにするかオーサーインスタンスにするかなど）は、クイックスタートファイルの名前を適宜変更することで制御できます。この点に関するオプションのリストを確認するには、次のように、コマンドラインで「-help」を付けて JAR を実行します。

java -jar <quickstartfilename>.jar -help

レプリケーションエージェント - レプリケーションエージェントは、AEM の中心的なメカニズムであり、オーサー環境からパブリッシュ環境へコンテンツを公開（アクティベート）したり、Dispatcher キャッシュからコンテンツをフラッシュしたり、ユーザーが生成したコンテンツ（フォーム入力など）をパブリッシュ環境からオーサー環境に返したりするために使用されます。

基礎モード - 基礎モードを使用すると、ページに必要な構造を反映したフィールドを使用したフォーム（基礎）を作成し、このフォームを使用して必要な構造に基づいたページを簡単に作成できます。

セグメント化 - サイトにアクセスする訪問者は、様々な関心と目的を持っています。訪問者の目的を理解し、期待に応えることが、オンラインマーケティングを成功させるための重要な要因となります。セグメント化によって訪問者の詳細を分析し、特徴付けることが成功の実現に役立ちます。

サイドキック - サイドキックは、編集可能なページに表示される、パレット状のフローティングウィンドウです。ここから、新しいコンポーネントをドラッグしたり、ページに適用するアクションを実行したりできます。

Site Catalyst - SiteCatalyst は、複数のマーケティングチャネルにわたるすべてのオンライン施策の統合データを測定、分析、最適化するための場所をマーケターに提供します。Adobe SiteCatalyst を使用して、AEM web サイトのデータを分析できます。

Tar ストレージ (TarMK) - TarMK は AEM のデフォルトの永続性システムです。 AEM は、異なる永続化システム（MongoDB など）を使用するように設定できますが、TarMK には、一般的な JCR のユースケース向けにパフォーマンスが最適化され（そのため、高速）、業界標準のデータ形式を使用し、迅速かつ簡単にバックアップできるという点でメリットがあります。

テンプレート - AEM では、テンプレートはページの特殊なタイプを指定するものです。ページの構造を定義します（一方で、通常はサムネール画像や様々なプロパティも指定します）。 例えば、製品ページ、サイトマップおよび問い合わせ先に、それぞれ別のテンプレートを使用することができます。

ワークフロー - AEM のワークフローシステムを使用すると、ページやアセットを扱う自動化プロセスを作成できます。