Nos posts anteriores, falamos sobre a arquitetura de soluções WEB/Enterprise (corporativas) com o uniPaaS e também sobre instalação e configuração.
Vamos retomar agora este tema, falando a respeito das aplicações/soluções que podem ser criadas com o uniPaaS nesta arquitetura.
São basicamente três tipos de soluções: Request/Response, BrowserClient e RichClient.
É muito importante observar que estas características (RR, BC ou RC) estão relacionadas aos programas contidos na aplicação, e não à aplicação propriamente dita. Isso quer dizer que: uma única aplicação uniPaaS (um mesmo arquivo .ecf) pode conter os três tipos de programas e fazer os três papéis ao mesmo tempo. Se a necessidade for criar duas ou três destas soluções, não é obrigatório fazê-las em projetos separados (mas é possível, se desejar).
REQUEST / RESPONSE (ou MERGE)
Este é provavelmente o tipo mais comum de solução criada com o uniPaaS Enterprise.
Popularmente, ela é chamada/conhecida como: Aplicação MERGE. Isso porque o recurso de “MERGE”, que possibilita mesclar dados com um modelo/template de documento e gerar outro documento (final), é bastante presente nestas aplicações. Especialmente para WEB, onde se utiliza muito o “MERGE” para criar os resultados HTML (páginas) que retornarão aos clients (browsers). Uma coisa leva à outra, e daí o nome se popularizou.
Contudo, vale ressaltar que usar “MERGE” não é pré-requisito destas soluções. Elas podem não conter nenhuma operação “MERGE”, se for o caso.
Isso esclarecido, você é livre para usar o nome que desejar 🙂
Este tipo de programa é, sempre, um programa batch no uniPaaS:
com um nome público definido, e a opção ‘External’ assinalada:
Este tipo de configuração cria o que comumente se chama de: serviço (ou rotina). Numa arquitetura SOA o normal é chamar de serviço.
Este programa não possui nada de especial em relação aos demais programas existentes e conhecidos nas aplicações On-Line (Desktop) do uniPaaS: ele pode executar as mesmas operações, tem acesso aos mesmos tipos de recursos e pode chamar outros programas ou subtarefas (desde que sejam também do tipo ‘batch’).
Estes programas serão, sempre, acionados através de algum dos requesters do uniPaaS (relembre sobre os requesters aqui). É o único meio de invocá-los.
Dependendo o tipo de client que está acionando o requester para invocar o serviço (rotina/programa), muda o tipo de solução que estamos criando.
Por exemplo:
- Se o client do processo for um web Browser, invocando o serviço através dos requesters HTTP (ISAPI ou CGI), a solução criada foi uma Aplicação WEB (ou Aplicação Internet).
- Se o client do processo não for um web Browser, mas invocar o serviço através dos requesters HTTP, nós teremos um AppServer via HTTP (ou outro nome que desejar).
- Se o client do processo não for um web Browser, mas invocar o serviço através dos requesters HTTP e enviar requisições em formato SOAP, nós teremos um Provedor WebService:
- Se o client do processo invocar o serviço através do requester COM, nós teremos um AppServer COM:
- Se o client do processo invocar o serviço através do requester EJB, nós teremos um AppServer JAVA:
- Se o client do processo invocar o serviço através do requester OS Shell, nós teremos criado um simples AppServer.
Observe que mudam as interfaces, os nomes das soluções, mas o programa (serviço) continua sempre do mesmo jeito.
Esta é uma característica do uniPaaS: paradigma único de desenvolvimento e arquitetura para diferentes tipos de soluções.
Uma ótima característica 🙂
Um programa request/reponse (ou serviço) precisa obrigatoriamente retornar um resultado para o client que o invocou.
Este retorno varia conforme abaixo:
A) Nos exemplos de soluções #1, #2 e #6, o retorno do serviço é definido pela operação FormOutput na mídia Requester:
B) Nos demais casos (#3, #4 e #5), o retorno do serviço é definido pelo ‘Return Value’ do programa:
Para finalizar: a invocação (chamada externa através dos requesters) de programas request/reponse (ou serviços) só será possível se o AppServer uniPaaS possuir licença MGENT1 ou MGENT2 (relembre sobre as licenças aqui).
Em próximos posts, abordaremos os programas BrowserClient e RichClient.
Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil