Histórico da Página
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 | 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
Definir um padrão para que nossos serviços atendam às premissas de serviços SOA e as premissas definidas pela TOTVS.
(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:
- 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. - 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.
| Termo | Definiçã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ção | Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados. |
| Stateless | Nã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. |
| Provedor | O 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. |
| Descoberta | SOA 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. |
| Binding | A 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:
- O serviço deve ser stateless, hoje nossos DataServers dependem do contexto.
- O serviço deve ser auto documentável, portanto esperar somente o que precisa para execução, o RMSContext têm muito informação que pode ser dispensável para determinadas rotinas.
- Nenhuma informação deve ser enviada pelo header, pois dificulta a documentação e utilização.
O Controller genérico RMSDataServerController criado na WebAP 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.
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas