Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             

  

(Obrigatório)

Informações Gerais

 

Especificação

Produto

Framework

Módulo

Globais

Segmento Executor

 

Projeto1

 

IRM1

 

Requisito1

FRW_FRW002-32

Subtarefa1

FRW_FRW002-80

Chamado2

 

País

( X ) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Outros

<Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>.

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo


         Em consonância com o mercado e com a estratégia da TOTVS, estamos expondo nossos serviços para consumo externo em um padrão rest, inclusive os DataServers.

         O FrameHTML por ser tratar de uma aplicação baseada em javascript e HTML irá usufruir dessa infra estrutura criada.

        Diante disso surge algumas definições e mudanças necessárias para que sejamos 100% SOA e consequentemente tenhamos nossos serviços prontos para serem consumidos por qualquer aplicativo.

 

(Obrigatório)

Definição da Regra de Negócio


         Nossa arquitetura está preparada para ser 100% SOA, porém precisamos pensar como os nossos DataServers funcionam para então perceber as deficiências do mesmo e tratá-las.

Cenário atual:

Temos duas formas de chamadas de serviços no RM.Host, são elas:

  1. Chamada Client(Winforms/WebForms)

    Neste caso a Lib  se encarrega de recuperar o RMSContext que está no contexto da aplicação cliente(WinForms/WebForms), e entregar para o serviço no server(RM.Host), desta forma permitiu que os DataServers de produto fossem herdados do RMSDataServer, e as informações de contexto ficassem disponíveis nos serviços(ReadView, ReadRecord,etc) executados.


  2. Chamada WebService(SOAP/REST)

         Para expor nossos DataServers, foi criado um WebService genérico que recebe como parâmetro o nome do DataServer, o contexto(coligada,sistema,usuário,etc) e demais parâmetros pertinentes ao serviço executado(ReadView,ReadRecord,etc), com isso o DataServer do produto recebe o contexto que ele precisa para ser executado.

 

          Com a chegada do FrameHTML( 100% html e javascript), nossa arquitetura sofreu uma evolução para expor nossos serviços, hoje temos uma camada que expõe nossos serviços em HTTP (rest / json ou xml) utilizando WebAPI 2.0, com isso qualquer aplicação,inclusive o FrameHTML podem chamar nossos serviços, porém como vimos nossos DataServers dependem de um contexto de excução(RMSContext), porém o RMSContext traz consigo muitas informações que podem ou não ser uteis à execução do DataServer em questão.

          No primeiro momento para tornar o desenvolvimento produtivo, criamos um serviço RMSDataServerController que recebe o nome do dataServer como o parâmetro, para entregar ao DataServer em questão o contexto da aplicação o FrameHTML têm um interceptor que resgata o contexto (está armazenado em uma variável chamada currentContext no escopo do angular) e adiciona todas as propriedades do contexto no header da requisição, e o RMSDataServerController resgata o contexto no header e entrega ao DataServer em questão.

            Como podemos notar o nosso serviço depende de informações de contexto e são trafegadas no header da requisição, neste ponto precisamos entender alguns termos utilizados na arquitetura SOA que estão diretamente relacionamos às mudanças que teremos.

TermoDefinição / Comentário
ServiçoÉ uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.
OrquestraçãoProcesso de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.
StatelessNão depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
ProvedorO recurso que executa o serviço em resposta a uma requisição de um consumidor.
ConsumidorÉ quem consome ou pede o resultado de um serviço fornecido por um provedor.
DescobertaSOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.
BindingA relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através de um mecanismo de binding.

 

              Ao confrontarmos os conceitos SOA e as definições da TOTVS com o que está implementado hoje, vemos que precisamos das seguintes mudanças:

 

  1. O serviço deve ser stateless, hoje nossos DataServers dependem do contexto.
  2. O serviço deve ser auto documentável, portanto esperar somente o que precisa para execução, o RMSContext têm muita informação que pode ser dispensável para determinadas rotinas.
  3. Nenhuma informação deve ser enviada pelo header, pois dificulta a documentação e utilização.

 

        O Controller genérico RMSDataServerController criado na WebAPI juntamente com o intercepctor criado no FrameHTML permanecerá funcionando para manter compatibilidade. Porém é expressamente recomentado que as novas funcionalidades migradas para o FrameHTML nasçam respeitando todas as premissas apontadas acima.

 

         Veja o desenho simplificado da nossa nova estrutura.

                                                                                                                  

 

 

      Outro ponto importante que devemos tratar é a segurança das informações armazenadas no client.

      Vamos nos ater a falar na aplicação web(Portal), hoje grande parte das informações armazenadas no lado cliente como por exemplo o contexto da aplicação(RMSContext) está na session do Asp.Net e consequentemente protegidas. Já no FrameHTML por se tratar de uma aplicação feita em HTML e javascript não possui o conceito de session, portanto deve-se observar quais informações estão sendo armazenadas no lado cliente, e criar mecanismos de proteção do lado server, para impedir que essas informações sejam alteradas. Veja o exemplo abaixo:

      O usuário(XXX) loga e acessa a funcionalidade de histórico salarial, considere que o DataServer de histórico salarial utilize o usuário do contexto para filtrar o retorno dos dados, ou a segurança da informação. Neste ponto temos a seguinte diferença entre o Portal e o FrameHTML

       Portal:

                O RMSContext está na session do asp.net que por sua vez protegida, portanto podemos confiar na informação setada no RMSContext.

       FrameHTML:

                O RMSContext está no escopo do angular na aplicação, e totalmente vulnerável à intervenção do usuário, portanto neste caso ele poderia alterar o usuário do RMSContext que acessar o histórico salarial de um usuário diferente do usuário logado.

 

         Outro exemplo seria uma chamada de WebService, logando com um usuário e passando o usuário do Contexto qualquer usuário que desejar.

 

       Diante do exposto é expressamente recomendado que os serviços utilizem o usuário do principal(carteirinha), pois esse a Lib garante, já o usuário do RMSContext não é garantido pela Lib e o exemplo acima é apenas um de várias formas que temos de enviar um usuário logado diferente do usuário do contexto.

 

 

 

 

 

 

 

 



 

 

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.