Child pages
  • Desenvolvimento de Comunicação entre Sistemas Externos e um Desktop CSBASE
Skip to end of metadata
Go to start of metadata

Reunião de Arquitetura em 29 de setembro de 2016

Reunião de Revisão da Solução do Protótipo do Cenário A em 5 de outubro de 2016

Premissas Básicas

  • O cliente CSBASE fornece um único servidor HTTP que atenderá a todas as requisições;
  • O servidor HTTP do cliente deverá oferecer mecanismos para ser ativado sob demanda;
  • A API REST do cliente permitirá recursos inerentes ao desktop CSBASE, específicas do desktop do sistema e específicas de aplicações;
  • As integrações que envolvem aplicações envolvem o uso de recursos oferecidos pelo CSDK (contextos, etc);
  • Foram colocados dois cenários: 
    • a) o desktop é lançado a partir do sistema externo 
    • b) o desktop já está lançado.

Itens da Solução

  • Existe um módulo csbase-cliente, denominado "rest-controller" que é encarregado de gerenciar o HTTP-server interno do cliente. Este controller oferece recursos para que cada sistema oferte seus recursos. Por default, o CSBASE oferece funcionalidades básicas como: consulta do projeto corrente, versão, disparo de aplicações etc. Cada sistema pode ampliar os recursos ofertados usando este controller.
  • O controller pode ser ajustado pelo sistema para subir o http-server em determinada porta. É importante que a infraestrutura do CSBASE ofereça recursos para que os sistemas externos consigam localizar adequadamente o desktop. A resolução de que porta o http-server deve entrar pode envolver chamadas as servidor, parametrização externa etc.

Cenário A: Assume que o sistema externo (ex: V3O2) dispara o cliente desktop CSBase (ex: WebSintesi) programaticamente

Passo 1:

V3O2 se autentica na API REST do servidor WS.
HTTP Request:
login=tester&password=1234
HTTP Response:
HTTP/1.1 200 OK
Token: 
  - O token de acesso criado pelo WS
  - O tipo do token
  - Os dados do usuário autenticado (ex: login, nome, email)
Comentários:  
O acesso ao servidor WS pelo usuário que está trabalhando no V3O2 precisa ser autenticado.
Para isso, o V3O2 precisa requisitar um login e senha referente a autenticação no servidor WS. Esse procedimento não é o ideal, pois o código do V3O2 passa a ter acesso a essas informações mas por enquanto, faremos assim. Futuramente, o melhor seria um modelo similar ao adotado em aplicações web.
O servidor WS gera um token de acesso mediante a verificação do login e senha do usuário.
Passo 2:
V3O2 requisita ao servidor do WS uma URL para iniciar um desktop cliente do WS
HTTP Request:
GET  http://websintesi:8010/v1/client/launcher
HTTP Response:
HTTP/1.1 200 OK
Comentários: 
Essa requisição precisa estar autenticada, ou seja, o servidor WS espera que o header da requisição possua um token de acesso (vide passo 1). Essa requisição gera uma URL que possui o próprio token de acesso como parâmetro nessa URL, bem como outros argumentos necessários para iniciar o cliente desktop do WS.
O servidor WS usa o próprio token de acesso para fazer um pré-login do usuário. Esse procedimento é o mesmo que hoje já é feito pelo WIO. A diferença é que esse pré-login passa a usar o próprio token de acesso que o usuário já possui ao invés de gerar um token próprio para esse pré-login. Esse é um ponto que a Isabella vai verificar. Discutimos sobre a opção de gerar um token próprio para essa finalidade, com características e atributos específicos. Já usamos essa abordagem em outros serviços REST atualmente (por exemplo, de upload de arquivos, modificação de senha, criação de usuário guest, etc) onde um token específico é criado e retornado como parte de uma URL que o cliente utiliza em outra chamada. Nesse caso, o token é parte da URL e a requisição que recebe o token se encarrega de tratar a validade e a existência de atributos próprios. Nesse tipo de requisição, onde o token faz parte da URL, a requisição não exige uma autenticação (ou seja, não valida se o header tem um token de acesso).
Passo 3:
V3O2 abre a URL recebida para disparo de um cliente Desktop WS.

Passo 4:
WS inicia o cliente desktop com pré-login

Comentários:
O módulo cliente do WS, iniciado via java WebStart, chama o ServerEntryPoint do servidor WS para confirmar o pré-login, iniciado no passo 2.
O procedimento é similar ao que já é feito atualmente com o token do WIO. 
Passo 5:
WS registra no seu servidor a URI para iniciar suas aplicações 

RMI Request: 
RestService.registerClientHttpServer(String token, String httpServerURL)

RMI Response:

void

Comentários:
Ao iniciar o servidor HTTP no cliente, o WS publica no seu servidor a URI de "Open Application", que fica associada ao token de acesso (ou do usuário autenticado na sessão de login do desktop) usado na autenticação.
Essa chamada ao servidor WS é feita por RMI.
Fica a critério do WS registrar quais aplicações terão seu acesso concedido dessa forma e, portanto, quantas URIs forem necessárias. (Atualmente somente uma URI é registrada, umas URI que é a raiz de todos os serviços disponíveis no cliente, mas pretendemos registrar os serviços disponíveis separadamente).
O servidor HTTP que atende às requisições das aplicações está executando na máquina do cliente, em host e porta configurados.
A URI registrada é para uma requisição POST e seu formato seria, por exemplo "http://client-websintesi:8020/v1/applications/{ap-id}"
Passo 6:
V3O2 requisita ao servidor WS a URI de início de uma aplicação do desktop

HTTP Request:
GET  http://websintesi:8010/v1/client/applications
appId=segy-view (opcional)
HTTP Response:
HTTP/1.1 200 OK
URL de iniciar uma (ou mais) aplicações: http://client-websintesi:8020/v1/applications/{ap-id}

Comentários:

Essa requisição precisa estar autenticada, ou seja, o servidor WS espera que o header da requisição possua um token de acesso válido. 
O servidor do WS procura as URIs registradas pelo WS e associadas ao usuário do token de acesso. Esse registro foi feito pelo passo 5.
Pode ser que, futuramente, seja necessário que o V3O2 registre uma URI de callback que seja chamada sempre que um novo cliente (com o mesmo token ou talvez associado ao mesmo usuário de autenticação) inicie e, consequentemente, disponibilize suas aplicações via http.

Obs: O Passo 6 ainda não foi implementado desta forma. Por enquanto é feito um request para http://websintesi:8010/v1/client/rest/{token} e se obtém uma única URL de entrada para a API rest do cliente.

 

Passo 7:
V3O2 solicita ao desktop WS iniciar uma aplicação

HTTP Request:
POST  http://client-websintesi:8020/v1/applications/{ap-id}
HTTP Response:
HTTP/1.1 200 OK

Note que essa requisição é feita agora ao servidor HTTP do desktop do WS.
A resposta dessa requisição seriam as URIs com as ações válidas para a aplicação iniciada?
Posteriormente, pode ser necessário que essa requisição informe ao desktop WS a URI de callback do V3O2 para que seja chamada de volta quando a aplicação iniciar.
Assim como em qualquer outra requisição ao desktop WS, essa requisição precisa estar autenticada. Podemos tratar que o token vem no  header ou que o token seja parte da própria requisição e, nesse caso, o passo 6 já teria retornado a URI nesse formato (ex:  http://client-websintesi:8020/v1/applications/{ap-id}/{token}

Cenário B: Assume que o cliente desktop já esteja executando ou que inicie sem usar o serviço de disparo. O sistema que demanda a colaboração (ex: V3O2) teria a opção de decidir com qual deles quer interagir.


Passo 1: Igual ao cenário A.
V3O2 se autentica na API REST do servidor WS.
Passo 2: Não precisa nesse cenário B.
V3O2 requisita ao servidor do WS uma URL para iniciar um desktop cliente do WS
Passo 3: Não precisa nesse cenário B.
V3O2 abre a URL recebida para disparo de um cliente Desktop WS.
Passo 4: Sim, mas usando o login e senha ao invés do processo de pré-login.
WS inicia o cliente desktop.
Passo 5: Sim, já que o WS colocaria a disposição as aplicações que podem ser iniciadas por HTTP.
WS registra no seu servidor a URI para iniciar suas aplicações 
Passo 6: Sim. Nesse caso o V3O2 receberia as URIs associadas ao usuário autenticado que seria o mesmo que está executando as instâncias do WS (independente de ter se autenticado com login e senha ou um um token de pré-login). Se registrar uma URI de callback, o V3O2 seria informado caso outros desktops iniciem do mesmo usuário.
V3O2 requisita ao servidor WS a URI de início de uma aplicação do desktop
Passo 7: Sim, caso já não esteja iniciada.
V3O2 solicita ao desktop WS iniciar uma aplicação

Uso de aplicações CSDK

Conforme debatido de início, é importante que a comunicação possa ser feita também com aplicativos específicos dentro do CSBase. Essa comunicação deve ser bidirecional; ou seja, tanto o sistema externo quanto o aplicativo podem chamar e ser chamados (ofertar recursos e usar recursos). Inicialmente, estes dois casos são tratados da seguinte forma:

  1. Sistema externo chamando aplicativo - Deve existir uma API rest no desktop (já que só temos um HTTP server) que permita o envio de uma requisição específica para uma instância de aplicativo;
  2. Aplicativo chamando sistema externo - O aplicativo pode fazer requisições diretamente (com bibliotecas auxiliares ou utilitárias) ao HTTP server do sistema externo;

 

Concepção Inicial em 07 de setembro de 2016

Andre Luiz Clinio

Isabella Almeida da Silva

Caso 1 - Sistema externo chamando aplicativo

Atualmente, estão sendo feitos ensaios (spikes de implementação) para verificar formas que atendam minimamente os requisitos.

Ensaio A: Utilizando o mecanismo de mensagens

Oferecer na API REST do desktop, um mecanismo para envio de mensagens para instâncias de aplicativos. Neste caso, as mensagens tem um par tag/valor combinado entre as partes; em analogia ao que já é feito internamente ao CSDK pelo método Application.onMessageReceived().

Exemplo (ainda em esboço):

 

HTTP Request:
PUT  http://client-websintesi:15000/v1/applications/{ap-instance-id}/message/
(conteúdo da mensagem dento do campo data ainda não especificado)
HTTP Response:
HTTP/1.1 200 OK

 

Ensaio B: Utilizando código "Jersey" da aplicação para registrar recursos no HTTPd Cliente

Problema detectado: as classes oferecidas pela aplicação não seriam conhecidas pelo desktop pois o classloader dos aplicativos e do desktop são diferentes.

Pesquisar soluções que não burocratizem excessivamente ou que impeçam de deploy das aplicações em uma mesma versão do sistema.

Caso 2 - Aplicativo chamando V3O2

Ferramentas para análise:

 

 

 

 

 

 

 

  • No labels