Fondamenti tecnici AEM

AEM è una piattaforma solida basata su tecnologie collaudate, scalabili e flessibili. Questo documento fornisce una panoramica dettagliata delle varie parti che compongono AEM ed è inteso come appendice tecnica per uno sviluppatore AEM pieno stack. Non è inteso come guida introduttiva. Se non hai dimestichezza con AEM sviluppo, consulta la Guida introduttiva allo sviluppo per AEM Sites - WKND Tutorial come primo passo.

SUGGERIMENTO

Prima di immergerti nelle tecnologie di base di AEM, Adobe consiglia di completare la Guida introduttiva allo sviluppo per AEM Sites - WKND Tutorial.

Nozioni fondamentali

In qualità di moderno sistema di gestione dei contenuti, AEM si basa sulle tecnologie web standard:

  • Ciclo request-response (XMLHttpRequest / XMLHttpResponse)
  • HTML
  • CSS
  • JavaScript

L’archivio dei contenuti sottostante e i livelli di logica di business sono costruiti intorno alle tecnologie Java:

  • JCR
  • Sling
  • OSGi

Java Content Repository

Lo standard Java Content Repository (JCR) JSR 283 specifica un modo indipendente dal fornitore e indipendente dall'implementazione per accedere al contenuto bidirezionale a un livello granulare all'interno di un archivio di contenuti. Il lead di specificazione è detenuto da Adobe Research (Switzerland) AG.

Il pacchetto JCR API 2.0 javax.jcr.* viene utilizzato per l’accesso diretto e la manipolazione del contenuto dell’archivio.

AEM è basato su un JCR.

Apache Jackrabbit Oak

Apache Jackrabbit Oakis implementa un archivio di contenuti gerarchici scalabile e ad alte prestazioni per l’utilizzo come base dei moderni siti web di livello mondiale e di altre applicazioni di contenuti esigenti, conforme allo standard JCR.

Jackrabbit Oak (detto anche semplicemente come Oak), è l'implementazione dello standard JCR su cui viene costruito AEM.

Elaborazione delle richieste Sling

AEM viene creato utilizzando Sling, un framework di applicazione web basato sui principi REST che fornisce un facile sviluppo di applicazioni orientate ai contenuti. Sling utilizza un archivio JCR, come Apache Jackrabbit Oak, come archivio dati. Sling è stato contribuito a Apache Software Foundation - ulteriori informazioni sono disponibili su Apache.

Introduzione a Sling

Utilizzando Sling, il tipo di contenuto di cui eseguire il rendering non è il primo aspetto di elaborazione. La considerazione principale è se l’URL viene risolto in un oggetto di contenuto per il quale è quindi possibile trovare uno script per eseguire il rendering. Questo offre un supporto eccellente agli autori di contenuti web per creare pagine facilmente personalizzate in base alle loro esigenze.

I vantaggi di questa flessibilità sono evidenti nelle applicazioni con una vasta gamma di elementi di contenuto diversi, o quando è necessario personalizzare pagine facilmente. In particolare, quando si implementa un sistema di gestione dei contenuti web come AEM.

Per i primi passaggi da sviluppare con Sling, consulta Scopri Sling in 15 minuti .

Il diagramma seguente spiega la risoluzione dello script Sling: mostra come passare dalla richiesta HTTP al nodo del contenuto, dal nodo del contenuto al tipo di risorsa, dal tipo di risorsa allo script e quali variabili di script sono disponibili.

Comprensione della risoluzione degli script Apache Sling

Il diagramma seguente illustra tutti i parametri di richiesta nascosti ma potenti che è possibile utilizzare quando si gestisce il SlingPostServlet, il gestore predefinito per tutte le richieste POST che offre infinite opzioni per la creazione, la modifica, l’eliminazione, la copia e lo spostamento dei nodi nell’archivio.

Utilizzo di SlingPostServlet

Sling è incentrato sul contenuto

Sling è incentrato sul contenuto. Ciò significa che l’elaborazione è incentrata sul contenuto, in quanto ogni richiesta (HTTP) viene mappata sul contenuto sotto forma di una risorsa JCR (un nodo di archivio):

  • Il primo target è la risorsa (nodo JCR) che contiene il contenuto
  • In secondo luogo, la rappresentazione, o script, si trova dalle proprietà della risorsa in combinazione con alcune parti della richiesta (ad esempio, selettori e/o estensione)

Sling REST

Grazie alla sua filosofia incentrata sui contenuti, Sling implementa un server orientato al REST e quindi presenta un nuovo concetto nei framework delle applicazioni web. I vantaggi sono:

  • Molto RESTful, non solo sulla superficie; le risorse e le rappresentazioni vengono modellate correttamente all’interno del server
  • Rimuove uno o più modelli di dati
    • Altri framework di gestione dei contenuti potrebbero richiedere struttura URL, oggetti aziendali, schema DB per accedere a una risorsa.
    • Utilizzando Sling, questo viene ridotto a: URL = resource = JCR structure

Decomposizione URL

In Sling, l'elaborazione è guidata dall'URL della richiesta dell'utente. Definisce il contenuto da visualizzare dagli script appropriati. A questo scopo, le informazioni vengono estratte dall’URL.

Se analizziamo il seguente URL:

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

Possiamo suddividerlo nelle sue parti composite:

protocollo host percorso del contenuto selettori estensione suffisso param(i)
https:// myhost / tools/spy .printable.a4. html / a/b ? x=12
  • protocollo - HTTPS
  • host - Dominio del sito
  • percorso del contenuto : percorso che specifica il contenuto di cui eseguire il rendering e che viene utilizzato in combinazione con l’estensione; in questo esempio si traducono in tools/spy.html
  • selettori: utilizzati per metodi alternativi di rendering del contenuto; in questo esempio una versione compatibile con la stampante in formato A4
  • estensione - Formato del contenuto; specifica anche lo script da utilizzare per il rendering
  • suffisso : può essere utilizzato per specificare informazioni aggiuntive
  • param(s) - Qualsiasi parametro richiesto per il contenuto dinamico

Dall’URL al contenuto e agli script

Utilizzando i principi di decomposizione URL:

  • La mappatura utilizza il percorso del contenuto estratto dalla richiesta per individuare la risorsa.
  • Quando si trova la risorsa appropriata, viene estratto il tipo di risorsa sling e utilizzato per individuare lo script da utilizzare per il rendering del contenuto.

La figura seguente illustra il meccanismo utilizzato, che sarà discusso più dettagliatamente nelle sezioni seguenti.

Meccanismo di mappatura URL

Con Sling, si specifica quale script esegue il rendering di una determinata entità (impostando la proprietà sling:resourceType nel nodo JCR). Questo meccanismo offre più libertà di una in cui lo script accede alle entità dati (come farebbe un'istruzione SQL in uno script PHP) in quanto una risorsa può avere diverse rappresentazioni.

Mappatura delle richieste alle risorse

La richiesta è suddivisa ed estrae le informazioni necessarie. Nell’archivio viene eseguita la ricerca della risorsa richiesta (nodo di contenuto):

  • Il primo Sling controlla se un nodo esiste nella posizione specificata nella richiesta; ad esempio ../content/corporate/jobs/developer.html
  • Se non viene trovato alcun nodo, l'estensione viene eliminata e la ricerca viene ripetuta; ad esempio ../content/corporate/jobs/developer
  • Se non viene trovato alcun nodo, Sling restituirà il codice http 404 (Non trovato).

Sling consente anche di usare risorse diverse dai nodi JCR, ma questa è una funzione avanzata.

Individuazione dello script

Quando si trova la risorsa appropriata (nodo di contenuto), viene estratto il tipo di risorsa sling. Si tratta di un percorso che individua lo script da utilizzare per il rendering del contenuto.

Il percorso specificato da sling:resourceType può essere:

  • Assoluto
  • Relativo a un parametro di configurazione
SUGGERIMENTO

I percorsi relativi sono consigliati per Adobe in quanto aumentano la portabilità.

Tutti gli script Sling sono memorizzati in sottocartelle di /apps (mutable, user scripts) o /libs (immutabili, script di sistema), che verranno cercate in questo ordine.

Alcuni altri punti da sottolineare sono:

  • Quando il metodo (GET, POST) è obbligatorio, viene specificato in maiuscolo come in base alle specifiche HTTP, ad esempio jobs.POST.esp
  • Sono supportati diversi motori di script, ma gli script comuni consigliati sono HTL e JavaScript.

L'elenco dei motori di script supportati dalla data istanza di AEM è elencato nella console di gestione Felix ( http://<host>:<port>/system/console/slingscripting).

Utilizzando l’esempio precedente, se il valore sling:resourceType è hr/jobs, verrà utilizzato per:

  • Richieste e URL GET/HEAD che terminano in .html (tipi di richiesta predefiniti, formato predefinito)
    • Lo script sarà /apps/hr/jobs/jobs.esp; l'ultima sezione del sling:resourceType forma il nome del file.
  • Richieste POST (tutti i tipi di richiesta ad eccezione di GET/HEAD, il nome del metodo deve essere maiuscolo)
    • POST verrà utilizzato nel nome dello script.
    • Lo script sarà /apps/hr/jobs/jobs.POST.esp.
  • URL in altri formati che non terminano con .html
    • Esempio ../content/corporate/jobs/developer.pdf
    • Lo script sarà /apps/hr/jobs/jobs.pdf.esp; il suffisso viene aggiunto al nome dello script.
  • URL con selettori
    • I selettori possono essere utilizzati per visualizzare lo stesso contenuto in un formato alternativo. Ad esempio, una versione compatibile con la stampante, un feed rss o un riepilogo.
    • Se si considera una versione adatta alla stampante in cui il selettore potrebbe essere print; come in ../content/corporate/jobs/developer.print.html
    • Lo script sarà /apps/hr/jobs/jobs.print.esp; il selettore viene aggiunto al nome dello script.
  • Se non è stato definito nessun sling:resourceType, allora:
    • Il percorso del contenuto verrà utilizzato per cercare uno script appropriato (se il percorso basato su ResourceTypeProvider è attivo).
    • Ad esempio, lo script per ../content/corporate/jobs/developer.html genererebbe una ricerca in /apps/content/corporate/jobs/.
    • Verrà utilizzato il tipo di nodo principale.
  • Se non viene trovato alcuno script, verrà utilizzato lo script predefinito.
    • Il rendering predefinito è attualmente supportato come testo normale (.txt), HTML (.html) e JSON (.json), tutti in cui verranno elencate le proprietà del nodo (formattate in modo appropriato). Il rendering predefinito per l’estensione .res, o le richieste senza estensione di richiesta, consiste nello spool della risorsa (dove possibile).
  • Per la gestione degli errori http (codici 403 o 404) Sling cerca uno script in:
    • Posizione /apps/sling/servlet/errorhandler per gli script personalizzati
    • Oppure la posizione dello script standard /libs/sling/servlet/errorhandler/404.jsp

Se per una determinata richiesta sono validi più script, viene selezionato lo script con la migliore corrispondenza. Più una partita è specifica, meglio è. in altre parole, più il selettore corrisponde meglio, indipendentemente da eventuali estensioni di richiesta o dalla corrispondenza del nome del metodo.

Ad esempio, considera una richiesta per accedere alla risorsa

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

di tipo

  • sling:resourceType="hr/jobs"

Presupponendo che il seguente elenco di script sia nella posizione corretta:

  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

Quindi l'ordine di preferenza sarebbe (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).

Oltre ai tipi di risorse (definiti principalmente dalla proprietà sling:resourceType ), è presente anche il super tipo di risorsa. Questo è generalmente indicato dalla proprietà sling:resourceSuperType . Questi super tipi vengono considerati anche quando si cerca di trovare uno script. I super tipi di risorse possono essere costituiti da una gerarchia di risorse in cui il tipo di risorsa predefinito sling/servlet/default (utilizzato dai servlet predefiniti) è effettivamente la radice.

Il super tipo di risorsa può essere definito in due modi:

  • dalla proprietà sling:resourceSuperType della risorsa.
  • dalla proprietà sling:resourceSuperType del nodo a cui punta sling:resourceType.

Esempio:

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

La gerarchia dei tipi di:

  • /x
    • Is [ c, b, a, <default>]
  • while for /y
    • La gerarchia è [ c, a, <default>]

Questo perché /y dispone della proprietà sling:resourceSuperType , mentre /x non lo fa e quindi il relativo supertipo viene prelevato dal relativo tipo di risorsa.

Gli script Sling non possono essere chiamati direttamente

All’interno di Sling, gli script non possono essere chiamati direttamente in quanto ciò violerebbe il concetto rigoroso di server REST; puoi combinare risorse e rappresentazioni.

Se chiami direttamente la rappresentazione (lo script), nascondi la risorsa all’interno dello script, in modo che il framework (Sling) non ne sia più a conoscenza. Così si perdono alcune caratteristiche:

  • Gestione automatica dei metodi http diversi da GET, compresi:
    • POST, PUT, DELETE che vengono gestiti con un’implementazione predefinita sling
    • Lo script POST.jsp nella posizione sling:resourceType
  • L'architettura del codice non è più pulita né strutturata come dovrebbe; di importanza primaria per lo sviluppo su larga scala

API Sling

Questo utilizza il pacchetto API Sling, org.apache.sling.* e le librerie di tag.

Riferimento a elementi esistenti utilizzando sling:include

Una considerazione finale è la necessità di fare riferimento agli elementi esistenti all'interno degli script.

Gli script più complessi (aggregazione degli script) potrebbero dover accedere a più risorse (ad esempio navigazione, barra laterale, piè di pagina, elementi di un elenco) e farlo includendo la risorsa.

A questo scopo è possibile utilizzare il comando sling:include("/<path>/<resource>"). Ciò includerà in modo efficace la definizione della risorsa a cui si fa riferimento.

OSGi

OSGi (Open Services Gateway Initiative) definisce un'architettura per lo sviluppo e la distribuzione di applicazioni e librerie modulari (nota anche come Dynamic Module System for Java). I contenitori OSGi ti consentono di suddividere l’applicazione in singoli moduli (sono file jar con metadati aggiuntivi e chiamati bundle nella terminologia OSGi) e di gestire le dipendenze trasversali tra di loro con:

  • Servizi implementati all’interno del contenitore
  • Un contratto tra il contenitore e l’applicazione

Questi servizi e contratti offrono un'architettura che consente ai singoli elementi di scoprirsi l'un l'altro in modo dinamico per la collaborazione.

Un framework OSGi ti offre quindi il caricamento/scaricamento dinamico, la configurazione e il controllo di questi bundle, senza dover riavviare.

NOTA

Informazioni complete sulla tecnologia OSGi sono disponibili sul sito web OSGi.

In particolare, la pagina Basic Education contiene una raccolta di presentazioni ed esercitazioni.

Questa architettura consente di estendere Sling con moduli specifici per le applicazioni. Sling, e quindi AEM, utilizza l'implementazione Apache Felix di OSGi. Sono entrambe raccolte di bundle OSGi in esecuzione all'interno di un framework OSGi.

Questo consente di eseguire le seguenti azioni su uno qualsiasi dei pacchetti all’interno dell’installazione:

  • Installare la versione
  • Avvia
  • Arresta
  • Aggiorna
  • Disinstalla
  • Vedi lo stato corrente
  • Accedi a informazioni più dettagliate (ad esempio nome simbolico, versione, posizione, ecc.) sui bundle specifici

Per ulteriori informazioni, consulta Configurazione di OSGi per AEM come Cloud Service .

Struttura all'interno dell'archivio

L’elenco seguente fornisce una panoramica della struttura che verrà visualizzata all’interno dell’archivio.

  • /apps - Applicazione correlata; include definizioni di componenti specifiche del sito web. I componenti sviluppati possono essere basati sui componenti predefiniti disponibili in /libs/core/wcm/components.
  • /content - Contenuto creato per il sito web.
  • /etc
  • /home - Informazioni utente e gruppo.
  • /libs - Librerie e definizioni che appartengono al nucleo di AEM. Le sottocartelle in /libs rappresentano le funzioni predefinite AEM . È possibile che il contenuto in /libs non venga modificato. Le funzioni specifiche del sito web devono essere eseguite in /apps.
  • /tmp - Area di lavoro temporanea.
  • /var - i file che cambiano e vengono aggiornati dal sistema; come i registri di controllo, le statistiche, la gestione degli eventi.
ATTENZIONE

Le modifiche a questa struttura, o ai relativi file, devono essere effettuate con attenzione. Assicurati di comprendere appieno le implicazioni di eventuali modifiche apportate.

Non è necessario modificare nulla nel percorso /libs. Per la configurazione e altre modifiche, copia l’elemento da /libs a /apps e apporta eventuali modifiche all’interno di /apps.

In questa pagina