Arquitetura do ZK

Neste artigo, irei abordar sobre a arquitetura do ZK. Mas antes disso, gostaria de falar sobre alguns conceitos importantes:

1.  POJO(Plain Old Java Objects) - São objetos Java que não dependem da herança de interfaces ou classes de frameworks externos. Outro link.
2. JavaScript - Linguagem de script interpretada pelo borwser.
3. DOM(Document Object Model) - Convenção criada peloa w3school, independente de plataforma e linguagem, para acessarem e manipularem elementos XML, HTML e XHTML através de objetos.
4. AJAX(Asynchronous Javascript And XML) - Significa o uso de tecnologias como JavaScript e XML, providenciadas pelo navegador, para tornar as páginas Web mais interativas com os usuários, através de requisições assícronas.

Esse artigo foi baseado no texto do site do ZK: http://books.zkoss.org/wiki/ZK_Developer's_Reference/Architecture_Overview

Será abordado 2 perspectivas sobre o ZK: Aplicação e Componente. A primeira mostra uma visão a nível de aplicação, a segunda mostra uma visão a nível de componente.

Visão geral da arquitetura:

Visão do desenvolvedor da aplicação:

O ZK possui uma arquitetura server-centric(centrada no servidor), isso quer dizer que a aplicação ZK roda no servidor. Ela pode acessar os recursos backend, montar a interface com os componentes, ouvir a atividades do usuário, e então manipular componentes para atualizar a interface. Tudo é feito no lado do servidor. A sincronização dos estados dos componetes entre o browser e o servidor é feito automaticamente pelo ZK, e transparente pela aplicação.

Quando executada no servidor, a aplicação pode acessar a stack completa da tecnologia Java. Atividades do usuário são, incluindo AJAX e Server Push, abstraidas para objetos de eventos. A interface são compostas por componentes tipos POJO. Essa é a abordagem mais produtiva para desenvolver uma moderna aplicação web.

A partir do ZK 5, foi introduzido uma mundaça na arquitetura chamada de Server+Client Fusion. Assim a sua aplicação não para no servidor. É possível melhorar a interatividade de sua aplicação através da adição opicional de funcionalidades do lado do cliente(client-side), como o tratamento de evento pelo lado do cliente, efeitos visuais customizados, e até mesmo compor interfaces sem a codificação no lado do servidor. A versão 5 permite a fusão perfeita do servidor e cliente.Assim, voce pode ter o melhor dos 2 mundos: produtividade e flexibilidade.

Um artigo serã escrito mais tarde abordando o Server+Client Fusion.

Visão do desenvolvedor de componente:

Cada objeto de interface no ZK consiste de um componente e um widget. Um componente é um objeto Java sendo executando no servidor o qual representa um objeto de interface o qual pode ser manipulado por uma aplicação Java. Um componente possui todos os comportamentes de objeto de interface exceto a parte visual. Um widget é um objeto Javascript sendo executado no cliente. Esse objeto representa o objeto de interface o qual interage com o usuário. Por isso, um widget geralmente poussi uma aparencia visual, e manipula eventos ocorridos no cliente.

O relacionamento entre um componete e um widget é um um-pra-um. Mas, se um componente não é anexado a uma página, ele não possuirá um widgt correspondente no cliente. Por outro lado, é permitada a aplicação instanciar widgets no cliente diretamente sem o componente correspondente.

É função do componente sincronizar os estados e distribuir a carga. O ZK Client Engine and update Engine trabalham juntos para propocionar um elegante e robusto canal para simplificar a implementação.

Por exemplo, assuma que voce queira implementar um componente que permite o usuário clicar sobre um elemento DOM para mostrar alguma informação detalhada de um componente. Existe pelo menos 2 abordagens para essa implementação. Primeiro, nós podemos carregar a informação detalhada para o cliente quando o widget é instanciado, e então mostrar o detalhe via código client-side. Alternativamente, nós podemos preferir não carregar a informação do detalhe logo de começo, e então enviar uma requisição de volta ao servidor para preencher o detalhe quando o usuário clicar.

Obviamente, a primeira abordagem requer mais largura de banda para a requisição inicial mas possui uma resposta rápida quando o usuário clicar. Porém, isso é geralmente transparente para o desenvolvedor da apicação, e a implementação do componente pode ser aperfeiçoada conforme a fase de desenvolvimento da aplicação.

Fluxo de Execução do carregamento de uma página:

1. Quando um usuário digita uma URL ou clica num link no browser, uma requisição é enviada para o servidor web. Se a URL requisitada corresponde ao padrão de URL configurado do ZK(isso pode ser customizado), o ZK loader é então invocado para servir a essa requisiçáo.
2. O ZK loader carrega a página especificada e interpreta-a para criar os componentes especificos de acordo com a página.
3. Depois de interpretar a página toda, o ZK loader renderiza o resultado em uma página HTML. A página HTML é então enviada de volta ao browser acompanhada do ZK Client Engine.
4. O ZK Client Engine renderiza os widgets em elementos DOM e insere os elementos DOM na árvore DOM do borwser para torná-los visíveis ao usuário.
5. Logo, o ZK Client Engine fica no browser para servir as requisições feitas pelo usuário. Se ele vai para outra página, o fluxo de execução começa novamente. Se ele vai enviar uma requisição AJAX de volta, outro fluxo de execução começa conforme descito no próximo item.

O ZK Client Engine é escrito em JavaScript. Browsers irão fazer cache do Z Client Engine, logo ele é geralmente enviado apenas uma vez no primeiro acesso.

Fluxo de Execução ao servir uma requisição AJAX:

1. O fluxo de execução é iniciado pelo widget ou pela aplicação; geralmente causado por uma atividade do usuário(ou requisitos da aplicação). Isso é geralmente feito por enviar uma evento do lado do cliente(Event) para um widget (Widget.fire(Event, int)).
2. O evento é então propagado ao pai do widget, ao pai do pai, e finalmente ao ZK Client Engine(Um widget pode escolher parar essa propagação através de Event.stop(Map)).
3. Se necessário, o ZK Client Engine envia uma requisição AJAX para o ZK Update engine no servidor( Do ponto de vista do servidor, uma requisição AJAX é apenas outra requisição HTTP).
4. Ao receber uma requisição AJAX, o ZK Update Engine invoca o ComponentCtrl.service(AuRequest, boolean) para o tratamento da requisição.
5. A manipulação é com o componente. Mas, geralmente é feita a atualização dos estados, se necessário, e então notifica a aplicação enviando eventos( Events.postEvent(Event)).
6. Se algum evento for enviado, o ZK Update Engine processará eles um-por-um invocando os events listeners, se houver.
7. O event listener, provido por uma aplicação, pode escolher atualizar os recursos de backend, atualizar os componentes ou postar outros eventos.
8. Finalmente, o ZK Update Engine recolhe todas as atualizações de componentes, incluindo mudanças nos estados, attachment e detachment. Otimizá-os, e depois envia de volta uma coleção de comandos de volta ao cliente.
9. O ZK Client Engine avalia cada um desses comandos para atualizar o widget de acordo com cada um. E, os widgets atualizarão a árvore DOM do browser para torná-los disponíveis para o usuário.

Quando enviar uma requisição AJAX:

Quando o ZK Client Engine recebe um evento propagado pelo lado do cliente(Event), ele decidirá se e quando enviar o mesmo de volta ao servidor para processamento adicional.

1. Se existe um event listener não adiável(deferrable) registrado no servidor, o pedido é enviado imediatamente. Um event listener não adiável é um event listener (EventListener) que não implementa Deferrable. Por padrão, (sem implementar Deferrable) todo o evento é enviado imediatamente ao servidor quando ele é acionado no cliente.
2. Se existe um event listener adiável registrado no servidor, a requisição será colocado numa fila no cliente e será enviada quando outro evento for acionado e um event listener não adiável for registrado por ele. Para tornar um listener adiável, voce deve implementar Deferrable e retornar true para isDeferrable().
3. Se o widget declarar o evento o evento como importante(ComponentCtrl.CE_IMPORTANT), o evento será adicionado na fila para ser enviado depois também.
4. Se não for nenhum dos casos acima ou o widget não tem nenhum componente corresponde no servidor, o evento é cancelado.

Os eventos adiáveis são usados para melhorar o desempenho, minimizando o tráfego entre o cliente e o servidor. É comumente usado por events listener que mantém estados da aplicação, ao invés de gerar respostas visuais.

Bem galera é essa é uma breve visão da arquitetura do ZK.. No próximo artigo irei falar de mais alguns conceitos importantes.