Fundamentos técnicos do AEM

O AEM é uma plataforma robusta criada com tecnologias comprovadas, escaláveis e flexíveis. Este documento fornece uma visão geral detalhada das várias partes que compõem o AEM e serve como um apêndice técnico para um desenvolvedor de AEM de pilha completa. Não se destina a ser um guia de introdução. Se você é novo no desenvolvimento do AEM, consulte o Introdução ao desenvolvimento do AEM Sites - Tutorial do WKND como um primeiro passo.

Fundamentos

Como um sistema moderno de gerenciamento de conteúdo, o AEM depende de tecnologias padrão da Web:

• O ciclo solicitação-resposta (XMLHttpRequest / XMLHttpResponse)
• HTML
• CSS
• JavaScript

O repositório de conteúdo subjacente e as camadas de lógica de negócios são criados com base em tecnologias Java:

• JCR
• Sling
• OSGi

Repositório de conteúdo Java

O padrão Java Content Repository (JCR), JSR 283, especifica uma maneira independente de fornecedor e de implementação para acessar o conteúdo de forma bidirecional em nível granular em um repositório de conteúdo. O líder da especificação é da Adobe Research (Switzerland) AG.

A variável API JCR 2.0 pacote, javax.jcr.* O é usado para o acesso direto e manipulação de conteúdo do repositório.

O AEM é baseado em um JCR.

Apache Jackrabbit Oak

Apache Jackrabbit Oak O é uma implementação de um repositório de conteúdo hierárquico dimensionável e de alto desempenho para uso como base de sites modernos de classe mundial e outros aplicativos de conteúdo exigentes, em conformidade com o padrão JCR.

Jackrabbit Oak (também conhecido simplesmente como Oak), é a implementação do padrão JCR sobre o qual o AEM é construído.

Processamento de solicitação do Sling

O AEM é construído usando Sling, uma estrutura de aplicativo web baseada em princípios REST que fornece desenvolvimento fácil de aplicativos orientados a conteúdo. O Sling usa um repositório JCR, como o Apache Jackrabbit Oak, como seu armazenamento de dados. O Sling contribuiu para a Apache Software Foundation - mais informações podem ser encontradas na Apache.

Introdução ao Sling

Usando o Sling, o tipo de conteúdo a ser renderizado não é a primeira consideração de processamento. Em vez disso, a principal consideração é se o URL resolve um objeto de conteúdo para o qual um script pode ser encontrado para executar a renderização. Isso fornece excelente suporte para que os autores de conteúdo da Web criem páginas que são facilmente personalizadas de acordo com suas necessidades.

As vantagens dessa flexibilidade são evidentes em aplicativos com uma grande variedade de elementos de conteúdo diferentes, ou quando você precisa de páginas que possam ser facilmente personalizadas. Especificamente, ao implementar um sistema de Gerenciamento de conteúdo da Web como o AEM.

Consulte Descubra o Sling em 15 minutos para conhecer as primeiras etapas de desenvolvimento com o Sling.

O diagrama a seguir explica a resolução do script Sling: ele mostra como ir da solicitação HTTP para o nó de conteúdo, do nó de conteúdo para o tipo de recurso, do tipo de recurso para o script e quais variáveis de script estão disponíveis.

O diagrama a seguir explica todos os parâmetros de solicitação ocultos, mas avançados, que podem ser usados ao lidar com o SlingPostServlet, o manipulador padrão para todas as solicitações do POST que oferece opções infinitas para criar, modificar, excluir, copiar e mover nós no repositório.

O Sling é centrado no conteúdo

O Sling está centrado no conteúdo. Isso significa que o processamento está focado no conteúdo conforme cada solicitação (HTTP) é mapeada no conteúdo na forma de um recurso JCR (um nó de repositório):

• O primeiro destino é o recurso (nó JCR) que contém o conteúdo
• Em segundo lugar, a representação, ou script, está localizada nas propriedades do recurso em combinação com determinadas partes da solicitação (por exemplo, seletores e/ou a extensão)

Sling RESTful

Devido à sua filosofia centrada no conteúdo, o Sling implementa um servidor orientado para REST e, portanto, apresenta um novo conceito em estruturas de aplicações Web. As vantagens são:

• Muito RESTful, não apenas na superfície; os recursos e as representações são modelados corretamente dentro do servidor
• Remove um ou mais modelos de dados
  • Outras estruturas de gerenciamento de conteúdo podem exigir estrutura de URL, objetos de negócios e esquema de banco de dados para acessar um recurso.
  • Usando o Sling, isso é reduzido a: URL = resource = JCR structure

Decomposição de URL

No Sling, o processamento é orientado pelo URL da solicitação do usuário. Isso define o conteúdo a ser exibido pelos scripts apropriados. Para fazer isso, as informações são extraídas do URL.

Se analisarmos o seguinte URL:

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

Podemos dividi-la em suas partes compostas:

• protocolo - HTTPS
• host - Domínio do site
• caminho do conteúdo - Caminho que especifica o conteúdo a ser renderizado e usado em combinação com a extensão; neste exemplo, eles traduzem para tools/spy.html
• seletor(es) - Usado para métodos alternativos de renderização do conteúdo; neste exemplo, uma versão para impressão em formato A4
• extensão - Formato de conteúdo; também especifica o script a ser usado para renderização
• sufixo - Pode ser usado para especificar informações adicionais
• parâmetro(s) - Quaisquer parâmetros necessários para o conteúdo dinâmico

Do URL ao conteúdo e scripts

Usando os princípios de decomposição de URL:

• O mapeamento usa o caminho de conteúdo extraído da solicitação para localizar o recurso.
• Quando o recurso apropriado é localizado, o tipo de recurso do sling é extraído e usado para localizar o script a ser usado para renderizar o conteúdo.

A figura a seguir ilustra o mecanismo usado, que será discutido com mais detalhes nas seções a seguir.

Com o Sling, você especifica qual script renderiza uma determinada entidade (definindo o sling:resourceType no nó JCR). Este mecanismo oferece mais liberdade do que um em que o script acessa as entidades de dados (como uma instrução SQL em um script PHP faria) como um recurso pode ter várias representações.

Mapeamento de solicitações para recursos

O pedido é detalhado e as informações necessárias são extraídas. O repositório é pesquisado para o recurso solicitado (nó de conteúdo):

• O First Sling verifica se um nó existe no local especificado na solicitação; por exemplo, ../content/corporate/jobs/developer.html
• Se nenhum nó for encontrado, a extensão será descartada e a pesquisa repetida; por exemplo, ../content/corporate/jobs/developer
• Se nenhum nó for encontrado, o Sling retornará o código http 404 (Não encontrado).

O Sling também permite que outros nós, além dos JCR, sejam recursos, mas esse é um recurso avançado.

Localização do script

Quando o recurso apropriado (nó de conteúdo) for localizado, a variável tipo de recurso sling é extraído. Esse é um caminho que localiza o script a ser usado para renderizar o conteúdo.

O caminho especificado pelo sling:resourceType pode ser:

• Absoluto
• Relativo a um parâmetro de configuração

Todos os scripts Sling são armazenados em subpastas de /apps (mutável, scripts do usuário) ou /libs (imutável, scripts de sistema), que serão pesquisados nesta ordem.

Alguns outros pontos a observar são:

• Quando o método (GET, POST) for necessário, ele será especificado em maiúsculas, de acordo com a especificação HTTP, por exemplo, jobs.POST.esp
• Vários mecanismos de script são compatíveis, mas os scripts comuns recomendados são HTL e JavaScript.

A lista de mecanismos de script compatíveis com determinada instância do AEM está listada no Felix Management Console ( http://<host>:<port>/system/console/slingscripting).

Usando o exemplo anterior, se a variável sling:resourceType é hr/jobs depois para:

• Solicitações GET/HEAD e URLs terminando em .html (tipos de solicitação padrão, formato padrão)
  • O script será /apps/hr/jobs/jobs.esp; a última seção do sling:resourceType forma o nome do arquivo.
• solicitações POST (todos os tipos de solicitação, exceto GET/HEAD, o nome do método deve estar em maiúsculas)
  • POST será usado no nome do script.
  • O script será /apps/hr/jobs/jobs.POST.esp.
• URLs em outros formatos, não terminando com .html
  • Por exemplo ../content/corporate/jobs/developer.pdf
  • O script será /apps/hr/jobs/jobs.pdf.esp; o sufixo é adicionado ao nome do script.
• URLs com seletores
  • Seletores podem ser usados para exibir o mesmo conteúdo em um formato alternativo. Por exemplo, uma versão para impressão, um feed RSS ou um resumo.
  • Se observarmos uma versão compatível com a impressora em que o seletor possa ser print; como em ../content/corporate/jobs/developer.print.html
  • O script será /apps/hr/jobs/jobs.print.esp; o seletor é adicionado ao nome do script.
• Se não sling:resourceType foi definido, então:
  • O caminho do conteúdo será usado para procurar um script apropriado (se o caminho se basear em ResourceTypeProvider está ativo).
  • Por exemplo, o script para ../content/corporate/jobs/developer.html geraria uma pesquisa em /apps/content/corporate/jobs/.
  • O tipo de nó primário será usado.
• Se nenhum script for encontrado, o script padrão será usado.
  • Atualmente, a representação padrão é aceita como texto sem formatação (.txt), HTML (.html) e JSON (.json), que listará as propriedades do nó (adequadamente formatadas). A representação padrão da extensão .res, ou solicitações sem uma extensão de solicitação, é fazer spool do recurso (quando possível).
• Para o tratamento de erros http (códigos 403 ou 404), o Sling procurará um script em:
  • A localização /apps/sling/servlet/errorhandler para scripts personalizados
  • Ou o local do script padrão /libs/sling/servlet/errorhandler/404.jsp

Se vários scripts se aplicarem a uma determinada solicitação, o script com a melhor correspondência será selecionado. Quanto mais específica for uma correspondência, melhor ela será; em outras palavras, quanto mais o seletor corresponder melhor, independentemente de qualquer correspondência de extensão de solicitação ou nome de método.

Por exemplo, considere uma solicitação para acessar o recurso

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

do tipo

• sling:resourceType="hr/jobs"

Supondo que temos a seguinte lista de scripts no local correto:

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

Em seguida, a ordem de preferência seria (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).

Além dos tipos de recursos (definidos principalmente pelo sling:resourceType propriedade) também há o supertipo de recurso. Isso é geralmente indicado pelo sling:resourceSuperType propriedade. Esses supertipos também são considerados ao tentar encontrar um script. A vantagem dos supertipos de recursos é que eles podem formar uma hierarquia de recursos em que o tipo de recurso default sling/servlet/default (usado pelos servlets padrão) é efetivamente a raiz.

O supertipo de recurso de um recurso pode ser definido de duas maneiras:

• pela sling:resourceSuperType propriedade do recurso.
• pela sling:resourceSuperType propriedade do nó para o qual a variável sling:resourceType pontos.

Por exemplo:

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

A hierarquia de tipo de:

• /x
  • É [ c, b, a, <default>]
• Enquanto para /y
  • A hierarquia é [ c, a, <default>]

Isso ocorre porque /y tem o sling:resourceSuperType propriedade, enquanto /x não faz e, portanto, seu supertipo é retirado de seu tipo de recurso.

Os scripts do Sling não podem ser chamados diretamente

No Sling, os scripts não podem ser chamados diretamente, pois isso quebraria o conceito estrito de um servidor REST; você misturaria recursos e representações.

Se você chamar a representação (o script) diretamente, ocultará o recurso dentro do script para que a estrutura (Sling) não saiba mais sobre ela. Dessa forma, você perde determinados recursos:

• Manuseio automático de métodos http diferentes do GET, incluindo:
  • POST, PUT, DELETE que são manipulados com uma implementação padrão do sling
  • A variável POST.jsp script em seu sling:resourceType localização
• Sua arquitetura de código não é mais tão limpa nem tão claramente estruturada como deveria ser; de importância primordial para o desenvolvimento em larga escala

API Sling

Usa o pacote da API Sling, org.apache.sling.*e bibliotecas de tags.

Referência a elementos existentes usando sling:include

Uma consideração final é a necessidade de fazer referência aos elementos existentes nos scripts.

Scripts mais complexos (agregação de scripts) podem precisar acessar vários recursos (por exemplo, navegação, barra lateral, rodapé, elementos de uma lista) e fazer isso incluindo o recurso.

Para fazer isso, você pode usar o sling:include("/<path>/<resource>") comando. Isso incluirá efetivamente a definição do recurso referenciado.

OSGi

O OSGi (Open Services Gateway Initiative) define uma arquitetura para desenvolver e implantar aplicativos e bibliotecas modulares (também é conhecido como Sistema de Módulo Dinâmico para Java). Os contêineres OSGi permitem dividir o aplicativo em módulos individuais (são arquivos jar com informações meta adicionais e chamados de pacotes na terminologia OSGi) e gerenciar as dependências cruzadas entre eles com:

• Serviços implementados no container
• Um contrato entre o contêiner e seu aplicativo

Esses serviços e contratos fornecem uma arquitetura que permite que elementos individuais descubram dinamicamente uns aos outros para colaboração.

Uma estrutura OSGi oferece carregamento/descarregamento dinâmico, configuração e controle desses pacotes, sem exigir reinicializações.

Essa arquitetura permite estender o Sling com módulos específicos do aplicativo. O Sling e, portanto, o AEM, usam o Apache Felix implementação do OSGi. Ambas as coleções de pacotes OSGi são executadas em uma estrutura OSGi.

Isso permite executar as seguintes ações em qualquer um dos pacotes da sua instalação:

• Instalar
• Início
• Parar
• Atualizar o
• Desinstalar
• Ver o status atual
• Acessar informações mais detalhadas (por exemplo, nome simbólico, versão, local etc.) sobre os pacotes específicos

Consulte Configuração do OSGi para o AEM as a Cloud Service para obter mais informações.

Estrutura no repositório

A lista a seguir fornece uma visão geral da estrutura que você verá no repositório.

• /apps - Relacionado ao aplicativo; inclui definições de componentes específicas do site. Os componentes que você desenvolve podem ser baseados nos componentes prontos para uso disponíveis em /libs/core/wcm/components.
• /content - Conteúdo criado para o seu site.
• /etc
• /home - Informações de usuários e grupos.
• /libs - Bibliotecas e definições que pertencem ao núcleo do AEM. As subpastas em /libs representam os recursos de AEM prontos para uso. O conteúdo em /libs não pode ser modificado. Os recursos específicos do seu site devem ser feitos em /apps.
• /tmp - Espaço de trabalho temporário.
• /var - Arquivos que são alterados e atualizados pelo sistema, como registros de auditoria, estatísticas, manipulação de eventos.

Recursos do Business.Adobe.com