Arquitetura de Asset Compute Service

O Asset Compute Service é criado sobre a plataforma sem servidor Adobe I/O Runtime. Ela oferece suporte a serviços de conteúdo da Adobe Sensei para ativos. O cliente que invoca (somente Experience Manager como Cloud Service é suportado) é fornecido com as informações geradas pela Adobe Sensei que ele buscou para o ativo. As informações retornadas estão no formato JSON.

Asset Compute Service pode ser estendida ao criar aplicativos personalizados com base em Project Firefly. Esses aplicativos personalizados são Project Firefly aplicativos sem periféricos e fazem tarefas como adicionar ferramentas de conversão personalizadas ou chamar APIs externas para executar operações de imagem.

Project Firefly O é uma estrutura para criar e implantar aplicativos Web personalizados no Adobe I/O tempo de execução. Para criar aplicativos personalizados, os desenvolvedores podem aproveitar React Spectrum (kit de ferramentas da interface do usuário do Adobe), criar microsserviços, criar eventos personalizados e orquestrar APIs. Consulte a documentação do Project Firefly.

A base na qual a arquitetura se baseia inclui:

  • A modularidade de aplicativos - contendo apenas o que é necessário para uma determinada tarefa - permite dissociar os aplicativos uns dos outros e mantê-los leves.

  • O conceito sem servidor de Adobe I/O Tempo de execução gera vários benefícios: processamento assíncrono, altamente escalável, isolado e baseado em tarefas, que é a opção perfeita para o processamento de ativos.

  • O armazenamento em nuvem binário fornece os recursos necessários para armazenar e acessar arquivos de ativos e representações individualmente, sem exigir permissões de acesso total ao armazenamento, usando referências de URL pré-assinadas. Aceleração de transferência, armazenamento em cache de CDN e co-localização de aplicativos de computação com armazenamento em nuvem permitem acesso ideal a conteúdo de baixa latência. As nuvens do AWS e do Azure são compatíveis.

Arquitetura do serviço Asset compute

Figura: Arquitetura Asset Compute Service e como ela se integra ao aplicativo de Experience Manager, armazenamento e processamento.

A arquitetura consiste nas seguintes partes:

  • Uma camada de API e orquestração recebe solicitações (em formato JSON) que instruem o serviço a transformar um ativo de origem em várias representações. As solicitações são assíncronas e retornam com uma ID de ativação, ou seja, uma ID de trabalho. As instruções são meramente declarativas e, para todo o trabalho de processamento padrão (por exemplo, geração de miniaturas, extração de texto), os consumidores especificam apenas o resultado desejado, mas não os aplicativos que manipulam determinadas representações. Recursos genéricos da API, como autenticação, análise, limitação de taxa, são manipulados usando o Gateway da API do Adobe na frente do serviço e gerencia todas as solicitações em Adobe I/O Tempo de execução. O roteamento do aplicativo é feito dinamicamente pela camada de orquestração. O aplicativo personalizado pode ser especificado pelos clientes para representações específicas e incluir parâmetros personalizados. A execução do aplicativo pode ser totalmente paralelizada, pois são funções sem servidor separadas em Adobe I/O Tempo de execução.

  • Aplicativos para processar ativos especializados em determinados tipos de formatos de arquivo ou renderizações de destino. Conceitualmente, um aplicativo é como o conceito de pipe Unix: um arquivo de entrada é transformado em um ou mais arquivos de saída.

  • Uma biblioteca de aplicativos comum lida com tarefas comuns, como baixar o arquivo de origem, carregar as representações, relatar erros, enviar e monitorar eventos. Isso é projetado para que o desenvolvimento de um aplicativo seja o mais simples possível, seguindo a ideia sem servidor, e possa ser restrito às interações locais do sistema de arquivos.

Nesta página