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.
(Obrigatório)
Definição da Regra de Negócio
Cenário atual:
Todos os nossos serviços até o momento eram expostos através de webService(SOAP / HTTP) com autenticação HttpBasic.
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 chamado(ReadView,ReadRecord,etc).
Quando era uma chamada Client x Server, a Lib , se encarregada se encarregava de recuperar o RMSContext e entregar para o serviço, desta forma permitiu que os DataServers de produto fossem herdados do RMSDataServer, e as informações de contexto ficassem disponíveis nos serviços chamados. , vamos ver mais à frente que isso vai contra há alguns fundamentos de SOA.
Com a chegada do FrameHTML(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 serviços nossos.nossos serviços.
Para tornar o desenvolvimento produtivo no primeiro momento, criamos um serviço RMSDataServerController que recebe o nome do dataServer como o parâmetro, e para entregar ao DataServer em questão o contexto da aplicação o FrameHTML têm um interceptor que resgata o contexto (está armazenado no currentContext no escopo do angular) e adiciona todas as propriedades do contexto no header da requisição, por sua vez o RMSDataServerController resgata o contexto no header e entrega ao DataServer em questão, veremos mais à frente que isso vai contra há alguns fundamentos SOA
O exposto acima reforça a necessidade da nossa solução ser 100% SOA(Arquitetura Orientada a Serviços), antes de continuarmos, vamos ver termos utilizamos na arquitetura SOA que estão diretamente relacionados às nossas mudanças.
| 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. |
Nossa solução começou a construir um novo portal, porém como o FrameHTML é baseado em HTML e javascript não temos um conceito de
Novo cenário:
<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.
Exemplo de Aplicação:
- Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
- Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades como a referência mínima para calcular o débito total do aluno.
- Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
- O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.
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