Estamos iniciando uma sequência de quatro posts sobre como criar soluções WEB/Enterprise (corporativas) com o uniPaaS, a fim de cobrir todos os aspectos deste tipo de desenvolvimento: arquitetura, instalação, configuração e o desenvolvimento propriamente dito.
Nesta primeira publicação abordaremos os aspectos da arquitetura.
Arquitetura
O desenvolvimento de uma solução WEB/Enterprise com o uniPaaS está baseado na premissa de que existirá um Enterprise Server (ou Application Server), servindo requisições (solicitações) vindas de outros aplicativos (clients) através da WEB (protocolo HTTP).
A primeira observação é que: WEB/Enterprise, aqui, significa tanto internet quanto intranet (visto que a comunicação está baseada no protocolo HTTP).
Agora, observe os elementos da arquitetura:
AppServers = São os deployments (runtimes) do uniPaaS em execução, num determinado servidor. Podem coexistir ‘n’ AppServers na mesma arquitetura. Cada um possui um projeto/solução (.ecf) aberto, que é a aplicação que está sendo servida.
Broker = É o módulo distribuidor das requisições recebidas. Não é possível acessar as aplicações servidas pelos AppServers, sem passar pelo Broker. Além de distribuir as requisições recebidas, o Broker também controla o balanceamento de carga entre os vários AppServers que possam estar servindo a mesma aplicação.
Requester = Os clients não podem também se conectar diretamente ao Broker. Eles conectam-se aos Requesters, e estes retransmitem as solicitações ao Broker. O uniPaaS fornece requesters em diversas tecnologias, ampliando a oferta de conexões aos mais variados tipos de clients.
- ISAPI = Este requester é para uso em webServers que suportam módulos ISAPI, como por exemplo, o MS-IIS. Este requester é disponibilizado durante a instalação.
- CGI = Este requester é para uso em webServers que suportam módulos CGI, como por exemplo, o Apache. Este requester é disponibilizado durante a instalação.
- OS SHEL = Este requester é um programa de linha de comando, que monta requisições para o Broker e pode retornar os resultados no console ou arquivo. Este requester é disponibilizado durante a instalação. Neste tipo de requester não existirá o canal HTTP entre ele o client. O client faz uma chamada (shell) diretamente a este programa.
- EJB = Este requester é um módulo EJB (Java .jar). Este requester não é disponibilizado durante a instalação. Ele é gerado sob demanda pelo desenvolvedor, através de assistentes do uniPaaS Studio. Este tipo de requester também pode ser chamado de módulo/classe proxy. Na verdade, o requester estará embutido dentro da classe. Neste tipo de requester não existirá o canal HTTP entre ele o client. O client incorpora-o diretamente como um módulo seu.
- OCX = Este requester é um módulo COM (.dll). Este requester não é disponibilizado durante a instalação. Ele é gerado sob demanda pelo desenvolvedor, através de assistentes do uniPaaS Studio. Este tipo de requester também pode ser chamado de módulo/classe proxy. Na verdade, o requester estará embutido dentro da classe. Neste tipo de requester não existirá o canal HTTP entre ele o client. O client incorpora-o diretamente como um módulo seu.
Clients = Os clients são qualquer aplicativo, em qualquer dispositivo, que suporte algumas das tecnologias em que os requesters são disponibilizados: HTTP Request (ISAPI ou CGI), EJB, OCX ou OS Shell.
Por esta arquitetura abranger também a intranet, as soluções uniPaaS podem muitas vezes ser também vistas como soluções Enterprise (corporativas) ao invés de WEB, mas isto é apenas questão de nomenclatura. Seja na internet ou na intranet, qual for o client envolvido, ou qual tecnologia ele utilizou para conectar-se ao AppServer uniPaaS, a arquitetura não muda.
Esta arquitetura adotada pelo uniPaaS é escalável, pois aumentando-se a oferta de AppServers, ou de filas de processamento por AppServer, aumenta-se a capacidade de resposta aos clients. Ela também é distribuída, pois considerando os pontos de conectividade (tcp e http), podemos ter até quatro diferentes servidores (locais ou remotos) envolvidos no processamento de uma solicitação de serviço (requisição):
Client <==> Requester <==> Broker/App Server <==> Database Server
Resumindo de uma forma simples: Em uma solução WEB/Enterprise uniPaaS teremos:
Um client solicitando um serviço (requisição) a um requester uniPaaS, que a retransmite a um broker uniPaaS, que a distribui a um AppServer uniPaaS. Este AppServer processa a requisição e retorna um resultado (sempre), que faz o caminho inverso até chegar ao client que originou a solicitação.
No próximo post abordaremos as questões de instalação e configuração desta arquitetura.
Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil