現在表示中:

開発方法

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

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

必要な経験

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

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

 

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

  • HTTP/1.1 プロトコル
  • HTML(HTML5 が望ましい)
  • カスケーディングスタイルシート
  • Extensible Markup Language(XML)
  • Asynchronous JavaScript and XML(AJAX)設計パターン
  • JavaScript Object Notation(JSON)
  • Document Object Model
  • ステートフルインタラクションとステートレスインタラクション
  • Uniform Resource Identifier
  • ブラウザーの cookie
  • その他の最新の Web 開発概念

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

業界知識

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

すべてがコンテンツである

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

David's Model

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

RESTful であること

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

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

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

Sling の要求解決

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

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

 

クイックスタート

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

クイックスタートのサイズが小さい:クイックスタート JAR ファイルのサイズを最小限に維持します。ライブラリを要領よく最適に使用して、オプションの機能をパッケージ共有に移動します。

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

無駄なくすっきり

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

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

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

デモを無効にしない

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

信頼できる設計

アドビでは、フェイルソフトな方法で機能を設計およびコード化するよう努めています。これにより、例えば 1 つの DOM 要素の問題が原因でページ全体がレンダリングされなくなることはありません。つまり、致命的とするべきことは致命的とし、その他はすべて存続可能にして、製品を「寛容に」するということです。

異常は新たな正常

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

shutdown == kill -9 == power outage

弾性クラスター化に備える

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

下位互換性に対応する設計

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

下位互換性に対応する設計により、アップグレードも初期インストールと同様に簡単になります。単純に AEM を停止し、クイックスタート JAR ファイルを置き換えて、AEM を再度起動するだけで十分です。インストール基盤が急速に拡大するなか、アップグレードの効率の良さは、ますます大きなメリットとなっています。

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

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

中心概念

オーサーインスタンス

通常、セキュリティやガバナンスおよびその他の理由で、本番サイトでは AEM のインスタンスがオーサーインスタンスとパブリッシュインスタンスに分離されます。デプロイメントアーキテクチャ(オーサー/パブリッシュインスタンスを含む)について詳しくは、AEM のインスタンスに関するドキュメントを参照してください。

キャッシュ、フライング、ベーキング

従来、ベーキングとフライングの概念は、異なる Web コンテンツ管理システムを区別する上で重要です。CMS の業界用語で、「ベーキング」は公開時にデータを静的ファイルにコミットする概念を指し、「フライング」は要求時に(ジャストインタイムで)最終的に提示するデータを処理する概念を指します。

クラスター化とロードバランシング

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

コンテンツリポジトリの複数のインスタンスを組み合わせて高可用性 JCR ソリューションを作成することもできます。これをさらに AEM ソリューションと統合すると、ハードウェアおよびソフトウェアの障害に対する保護を最大限に高めることができます。このようなクラスターは、様々な永続性マネージャー向けにサポートされています。詳しくは、クラスター化に関するドキュメントを参照してください。

コンポーネント

AEM では、コンポーネントはオブジェクトタイプの 1 つであり、そのインスタンスは通常、サイドキックなどからドラッグ&ドロップすることによって作成できます。例えば、AEM に付属のそのまま使用できるコンポーネントには、テキスト、タイトル、タグクラウド、カルーセル、画像およびリストの各コンポーネントが含まれていて、すべて実行時にサイドキックから利用できます。

コンテンツファインダー

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

デジタルアセット

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

ディスパッチャー

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

JCR、Java コンテンツリポジトリ

Java コンテンツリポジトリの仕様(JSR-283)では、抽象データモデルとアプリケーションプログラミングインターフェイスの両方が提供されており、これによって、ファイルシステムとオブジェクトデータベースの機能を組み合わせた大いに拡張可能な NoSQL データリポジトリを実現できます。JSR-283 については、細部まで理解する必要はありませんが、JCR およびその基になるデータモデルの基礎については、時間をかけて知識を深める必要があります。なぜなら、JCR こそが、AEM の「すべてがコンテンツである」という考え方を可能にするものだからです。

本質的に、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 は、単一の「クイックスタート」という自己解凍の JAR ファイルを使用してインストールします。JAR ファイルを初めてダブルクリックすると、必要なものがすべて自動的にインストールされます。クイックスタート JAR には、CRX リポジトリに必要なすべてのファイル(管理機能を含む)、仮想リポジトリサービス、インデックスおよび検索サービス、ワークフローサービス、セキュリティおよび Web サーバー、さらに CQ Servlet Engine(CQSE)と AEM のすべてのサービスが含まれています。他にインストールするファイルはありません。クイックスタートだけですべてが足ります。

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

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

java -jar <quickstartfilename>.jar –help

レプリケーションエージェント

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

基礎モード

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

セグメント化

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

サイドキック

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

Site Catalyst

SiteCatalyst を使用すると、マーケティング担当者は、すべてのオンラインイニシアチブからの、複数のマーケティングチャネルにまたがる統合されたデータを、1 か所で測定、分析および最適化できます。Adobe SiteCatalyst を使用すると、AEM Web サイトのデータを分析できます。

Tar ストレージ(TarMK)

TarMK は、AEM のデフォルトの永続化システムです。AEM は、異なる永続化システム(MongoDB など)を使用するように設定できますが、TarMK には、一般的な JCR の使用例向けにパフォーマンスが最適化されており(そのため、非常に高速)、業界標準のデータ形式を使用し、すばやく簡単にバックアップできるという点で明白なメリットがあります。詳しくは、こちらを参照してください。

テンプレート

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

ワークフロー

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

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー