## Arquitetura Dúvidas

1. **Somente conexão via Oracle dos sistemas legados?**
Existem também conexões com Postgre, na cloud Azure. O banco de dados do primeiro Sistema é em Dbu, consumido pelo Delphi, os sistemas de Weblogic no segundo momento são consumidos por Oracle.

2. **Quantos sistemas origens serão integrados?**

- O Sistema em Delphi no primeiro momento com as integrações em txt, csv, xml e json. O Segundo Momento que o sistema fala com a cloud alguns feitos em C# com a Azure, utlizando Service Bus da Azure para o envio de Mensagens para a visualiazação e consumo dos dados com C# com .net Core . Outros fazendo o consumo direto WebLogic/ Oracle/ Messageria com JMS

3. **A metodologia utilizada para os ritos poderá ser definida como Agile?**
- Sim de preferência o Scrum e o Kanban.

4. **Qual o sistema de Backoffice da CCR?**

5. **Qual a periodicidade da Base Histórica? Após esse periodo deve ser expurgado ou comprimido os dados?**
- **Requisitos de Negócios:** Avalie a frequência com que os dados históricos são acessados e utilizados para tomada de decisões. Algumas empresas podem precisar de acesso frequente a dados históricos, enquanto outras podem não.
**A utilização de microservices e a Centralização em Logs para o rastreamento de todas as transações e e disparos de mensagens, para o dia a dia de trabalho efetuando o controle de ocorrências nas empresas.**

- **Políticas de Retenção de Dados:** Verifique as políticas internas da empresa e os requisitos legais para retenção de dados. Alguns setores, como saúde e finanças, têm regulamentações específicas que determinam por quanto tempo os dados devem ser mantidos.
- **Capacidade de Armazenamento:** Considere a capacidade de armazenamento disponível. Dados históricos podem ocupar muito espaço, e manter tudo pode não ser viável a longo prazo.
- **A média de armazenamento hoje com imagens está entre 10tb mês devido a grande variedade e quantidade e imagens enviadas pelas camêras das rodovias.**

- **Desempenho do Sistema:** Grandes volumes de dados históricos podem afetar o desempenho do sistema. A compressão ou o expurgo podem ser necessários para manter a eficiência operacional.
-
- **Segurança e Privacidade:** Dados antigos podem incluir informações sensíveis. Manter esses dados por mais tempo do que o necessário pode aumentar o risco de violações de segurança e privacidade.
-
- **Backup e Recuperação:** Considere as estratégias de backup e recuperação ao decidir sobre o expurgo. Certifique-se de que os dados críticos sejam adequadamente respaldados antes de qualquer operação de expurgo.
- **Compressão vs. Expurgo:**
- **Compressão:** Reduz o espaço ocupado pelos dados sem eliminá-los completamente. É útil para dados que não são frequentemente acessados, mas que ainda podem ser necessários no futuro.
- **Expurgo:** Remove permanentemente os dados do sistema. Deve ser usado para dados que não são mais necessários ou que devem ser descartados por razões legais ou de política interna.
- **Frequência de Acesso:** Dados frequentemente acessados podem ser mantidos em uma forma mais acessível, enquanto dados raramente acessados podem ser arquivados ou comprimidos.
- **Análise de Custos-Benefícios:** Avalie o custo de armazenar dados históricos (incluindo segurança, armazenamento e gerenciamento) versus o benefício que eles oferecem.
- **Automatização do Processo:** Considere implementar soluções automatizadas para o gerenciamento do ciclo de vida dos dados, que podem determinar quando os dados devem ser comprimidos, movidos para armazenamento mais barato ou expurgados.

6. **Qual o formato e qualidade das imagens?**
- **Raster vs. Vetor:** Imagens raster (como JPEG, PNG, BMP) são baseadas em pixels e são ideais para renderizações fotorrealistas e detalhadas. Imagens vetoriais (como SVG, EPS) são baseadas em equações matemáticas e são melhores para diagramas escaláveis, como plantas e elevações.
- **Desde Arquivos em Servidores com Uploads de Imagens, Jpg, pngs e arquivoscom extensão pdf.**

- **Formatos Comuns:** Para renderizações e visualizações, formatos como JPEG (para imagens de menor tamanho de arquivo) e PNG (para melhor qualidade e fundo transparente) são comumente usados. TIFF é outra opção para alta qualidade, mas com tamanhos de arquivo maiores.
- **Formatos para Edição:** Para arquivos que podem necessitar de edições futuras, formatos como PSD (Photoshop) ou TIFF são preferidos, pois suportam camadas e outras funcionalidades de edição avançada.
- **Qualidade da Imagem:**
- **Resolução:** Imagens de alta resolução são essenciais, especialmente para apresentações impressas ou grandes formatos. Uma resolução de 300 dpi (dots per inch) é padrão para impressões de alta qualidade.
- **Compatibilidade com Dispositivos e Plataformas:** Considere a compatibilidade das imagens com diferentes dispositivos e plataformas, especialmente se elas serão visualizadas em dispositivos móveis ou através de websites.
- **Otimização para Apresentações e Portfólios:** Para apresentações online ou portfólios digitais, pode ser necessário otimizar as imagens para equilibrar qualidade e tamanho de arquivo, garantindo tempos de carregamento rápidos sem sacrificar demais a qualidade visual.

7. **Deve ser utilizado algum tagmeanto para relacionar as imagens (para uma possivel busca)?**

- Sim São utilizados sistemas de tags para as possíveis buscas, as cargas dos jpg e pdf ocorrem para

9. **Existe algum requisito específico sobre como a solução deve lidar com aumentos súbitos de carga e qual é a estratégia para dimensionar horizontalmente a infraestrutura em nuvem?**

## Soluções em Microservice Padrão Eda

- A solução deve ser capaz de escalar horizontalmente para atender a aumentos repentinos de tráfego. Isso pode ser feito usando uma variedade de técnicas, como:
* **Arquitetura baseada em microsserviços:** A arquitetura baseada em microsserviços permite que a solução seja dividida em componentes menores e independentes. Isso torna mais fácil escalar cada componente de forma independente, conforme necessário.
* **Autoscaling:** O autoscaling é uma técnica que permite que a solução seja dimensionada automaticamente conforme a demanda. Isso pode ser feito usando um serviço de autoscaling como o Amazon Elastic Kubernetes Service (EKS) ou o Google Kubernetes Engine (GKE) ou Azure EKS.
* **Load balancing:** O load balancing distribui o tráfego entre vários servidores. Isso pode ajudar a melhorar o desempenho e a disponibilidade da solução, mesmo sob carga pesada.
- **A estratégia para dimensionar horizontalmente a infraestrutura em nuvem**
- **Utilização de recursos de Microservices na programação com Saga com Orquestrador ou Coreografo**.
- **SideCar nas arquitetura de microservices permitindos os processos crescrerem em paralelos aos processos principais**
- **A solução deverá ser multiCloud Híbrida. utilizando ou aks ou eks utilizando como conteinerização como padrão kubernetes openshift, tendo a opção de utilizar o openshift cliente instalado na máquina do cliente, paas e o iaas.**
-
- **Utilização de Zipping para os tracking de rastreio na programação de miroservices**

#### Ponto de atenção o Eda para Messageria se adpta melhor com aplicações da programação Reativa. Mono e WebFlux, com Promises All, para o consumo assíncrono no Javascript dos envios de multi-thread não bloqueante. e no Envio do Java com Futures para trabalhar no modo Assíncrono na messageria e nos Gateways. Nesse Levantamento aqui é só um ponto de atenção. Esse padrão e utilizado nos setores de gateways e de messageria.

#### Ponto de atenção a mudança dos Bancos de Dados com ênfase no NOSQL, ou JDBC Reativo com banco de dados relaionais. Para a utilização dos dois serviços trabalhos mencionados é necessário uma grande amadurecimento na equipe de programadores de front e de back curva de aprendizagem alta.

Recomendações específicas para dimensionar horizontalmente a infraestrutura em nuvem para sua solução:
* Use uma arquitetura baseada em microsserviços. Isso tornará mais fácil escalar cada componente de forma independente.
* Configure o autoscaling para cada componente da solução. Isso garantirá que a solução seja dimensionada automaticamente conforme a demanda.
* Use um serviço de load balancing para distribuir o tráfego entre vários servidores. Isso ajudará a melhorar o desempenho e a disponibilidade da solução, mesmo sob carga pesada.

* **Identificação de possíveis falhas ou interrupções:** O plano deve identificar os possíveis pontos de falha ou interrupção no sistema de messageria. Isso pode incluir falhas de hardware, falhas de software, ataques cibernéticos ou problemas de conectividade.

- **A Falta de escalabilidade e os projetos de integração saindo do padrão de RabbitMq ou Event Bus da Microsoft para ida de todas essas mensagens para o Kafka Cluster com Producers/Consumers no Mínimo serão feitas as integrações e comunicações por esse setor de Messageria ou setor de BROKERS**

## 10.1 Kafka com Event Hub
## Integração ao Sistema de Hoje de Event Hubs

| Kafka Producer envia mensagens | Azure Event Hubs | recebe as mensagens Kafka Consumer |
| -------- | -------- | -------- |
|**1. O Kafka Producer envia mensagens para o Azure Event Hubs.A conexão utiliza a API do Kafka, mas aponta para o endpoint do Event Hubs.** | utilização de endpoint do Event Hubs | **2. o Kafka consumers via api recebe os dados, Essa leitura também utiliza a API do Kafka**
| |**3. O Azure Event Hubs pode ser configurado para capturar dados e armazená-los no Azure Storage (Blobs, Tables, Queues)** |
| |**4. O Azure Event Hubs pode integrar-se com outros serviços Azure, como Azure Functions, Azure Logic Apps, ou Azure Stream Analytics para processamento adicional, análises em tempo real ou integrações de workflow** |


## Funcionamento Detalhado Apache Kafka com Event Hubs

1. **Envio de Mensagens (do Kafka Producer para o Azure Ev ent Hubs)**

2. **O Kafka Producer envia mensagens para o Azure Event Hubs. A conexão utiliza a API do Kafka, mas aponta para o endpoint do Event Hubs.
Leitura de Mensagens (do Azure Event Hubs para o Kafka Consumer)**

3. **O Kafka Consumer lê as mensagens do Azure Event Hubs. Essa leitura também utiliza a API do Kafka. Armazenamento de Dados (do Azure Event Hubs para o Azure Storage)**

4. **O Azure Event Hubs pode ser configurado para capturar dados e armazená-los no Azure Storage (Blobs, Tables, Queues). Isso é útil para armazenamento de longo prazo, análise de dados, ou para cenários de recuperação de dados.Integração com Outros Serviços Azure.
O Azure Event Hubs pode integrar-se com outros serviços Azure, como Azure Functions, Azure Logic Apps, ou Azure Stream Analytics para processamento adicional, análises em tempo real ou integrações de workflow.**

## Kafka Stream

## 10.2 Para Integrar o Apache Kafka com JMS

**JMS é um modelo de programação de mensagens, enquanto Apache Kafka é uma plataforma de streaming de dados. Isso significa que JMS fornece uma API para que os aplicativos possam enviar e receber mensagens, enquanto Apache Kafka fornece um conjunto de recursos para processar dados de streaming.**
**JMS é projetado para ser um sistema de mensagens simples e eficiente. Ele é adequado para uma variedade de aplicativos, desde aplicativos de linha de negócios até aplicativos de Internet of Things.**

- **A migração da uma arquitetura mais distribuída para uma abordagem dados e processamento de fluxo em tempo real, "eliminando abordagens anteriormente monolíticas a esses problemas".**

- **O Kafka é bem adotado hoje dentro do ecossistema de produtos da Apache Software Foundation e é particularmente útil na arquitetura orientada a eventos.**

- **Utilizando Clusters Apache Kakfka Consumer/Producers para ligar os Exhanges e Queues para os Consumers**

## 10.2.1 (kafka Stream) com **JMS Sink**

KafkaStreams streams = new KafkaStreams(
    new StreamsBuilder()
        .stream("my-topic")
        .mapValues(value -> new MyMessage(value))
        .to(KafkaStreamsJmsSource.builder()
            .destination("my-destination")
            .messageClass(MyMessage.class)
            .build()));

- Para usar o Kafka Streams **JMS Sink**, você precisa criar um objeto Kafka Streams e configurar o sink. O sink deve ser configurado com as seguintes informações:

- O nome do tópico do Kafka para o qual você deseja enviar dados.
- A classe de mensagem que você deseja enviar.
Por exemplo, o seguinte código configura um Kafka Streams JMS Sink para enviar dados para o tópico my-topic na classe de mensagem MyMessage:

KafkaStreams streams = new KafkaStreams(
    new StreamsBuilder()
        .stream("my-source")
        .mapValues(value -> new MyMessage(value))
        .to(KafkaStreamsJmsSink.builder()
            .destination("my-destination")
            .messageClass(MyMessage.class)
            .build()));

.
.
.
## 10.2.2 (Kafka com Jms) Outra Opção para integração do kafka Stream com o JMS do Java é usar o **Apache Camel**

- O Apache Camel é uma ferramenta de integração de middleware que fornece uma API para conectar diferentes sistemas e serviços.

- O Apache Camel fornece um componente kafka que permite que você se conecte ao Kafka Stream. Você pode usar esse componente para enviar e receber dados do Kafka Stream usando a API JMS.

- Por exemplo, o seguinte código usa o Apache Camel para enviar dados do Kafka Stream para um tópico JMS:

from("kafka:my-topic")
    .to("jms:my-destination");

- O Apache Camel também fornece um componente jms que permite que você se conecte a um broker JMS. Você pode usar esse componente para enviar e receber dados do broker JMS usando a API JMS.
Por exemplo, o seguinte código usa o Apache Camel para receber dados de um tópico JMS e enviá-los para o Kafka Stream:

from("jms:my-destination")
    .to("kafka:my-topic");

## 10.2.3 Cenário integração entre Apache Kafka Producer e Consumer por meio de Bridges, Kafka Source Topic


- Kafka Source Topic: Tópico de origem no Kafka onde os dados brutos são armazenados.
- Apache Kafka Streams: Processa e transforma os dados de acordo com a lógica de negócios.
- Aplicação Bridge: Aplicação que consome as mensagens processadas pelo Kafka Streams e as envia para uma fila ou tópico JMS no WebLogic.
- WebLogic JMS Queue/Topic: Destino das mensagens processadas no servidor WebLogic.

## 10.2.4 WebLogic JMS Queue/Topic

### **WebLogic JMS Queue/Topic**:
### Descrição:
- **WebLogic JMS Queue/Topic: Fila ou tópico JMS no WebLogic onde os dados de entrada são recebidos**.

- Aplicação Bridge: Aplicação que lê mensagens da fila JMS do WebLogic e as publica em um tópico Kafka.
- Kafka Sink Topic: Tópico de destino no Kafka onde os dados são armazenados para processamento.

- Apache Kafka Streams: Processa e transforma os dados recebidos do tópico Kafka.
Esses diagramas representam uma visão geral da arquitetura de integração entre o Kafka Streams e o JMS do WebLogic


## 10.2.5 Kafka com OpenShift Streamzi no OpenShift

### Kafka Strimzi

1. Instalar e Configurar o Strimzi no OpenShift
**Instalação do Strimzi: Primeiro, você precisa instalar o Strimzi no seu cluster OpenShift. Isso geralmente é feito através do Operator Hub no OpenShift**.
- **Criar um Kafka Cluster**: Após a instalação, você pode criar um cluster Kafka usando os recursos Custom Resource Definitions (CRDs) fornecidos pelo Strimzi. Isso é feito criando um arquivo YAML de configuração para o cluster Kafka e aplicando-o no OpenShift.

2.**Configurar Kafka Producers e Consumers** :
Credenciais e Endereços: Obtenha as credenciais necessárias (como certificados para TLS, se necessário) e os endereços dos brokers Kafka do cluster criado pelo Strimzi.

- Desenvolvimento de Produtores e Consumidores: Desenvolva seus produtores e consumidores Kafka usando as bibliotecas cliente do Kafka em Java, Python, ou outra linguagem de sua escolha, configurando-os para se conectar ao cluster Kafka do Strimzi com as credenciais e endereços corretos.

3.**Configurações de Segurança e Rede**
**Segurança: Se você estiver usando a criptografia TLS ou a autenticação SASL, configure seus produtores e consumidores para usar os certificados e as configurações corretas.**

- **Rede:** **Certifique-se de que os produtores e consumidores possam se conectar ao cluster Kafka no OpenShift. Isso pode envolver a configuração de regras de rede, como ingressos ou rotas no OpenShift**.

#### Criar um Kafka Cluster: Após a instalação, você pode criar um cluster Kafka usando os recursos Custom Resource Definitions (CRDs) fornecidos pelo Strimzi. Isso é feito criando um arquivo YAML de configuração para o cluster Kafka e aplicando-o no OpenShift.

- O produtor Kafka envia mensagens para o tópico Kafka.
- O WebLogic JMS recebe mensagens do tópico Kafka e as converte em mensagens JMS.
- O WebLogic JMS envia as mensagens JMS para o destino JMS.

1.**O produtor Kafka é a fonte de dados. Ele envia mensagens para o tópico Kafka.**

2. **Processador de dados:   O WebLogic JMS é o processador de dados. Ele recebe mensagens do tópico Kafka e as converte em mensagens JMS.**

3. **Destino de dados: O WebLogic JMS é também o destino de dados. Ele envia as mensagens JMS para o destino JMS.**

### A arquitetura de fluxo de dados para integrar um produtor Kafka com o WebLogic JMS usando o Strimzi é a seguinte:

Claro, posso te ajudar com isso.

O padrão Bridge Strimzi com WebLogic é um padrão de arquitetura que permite a comunicação entre um cluster Kafka e um servidor WebLogic JMS. O padrão usa um bridge para encaminhar mensagens entre os dois sistemas.

O bridge é um componente de software que recebe mensagens de um sistema e as envia para outro sistema. No caso do padrão Bridge Strimzi com WebLogic, o bridge é implementado usando um Kafka Connect.

O Kafka Connect é um framework de integração que pode ser usado para conectar diferentes sistemas a um cluster Kafka. O Kafka Connect fornece uma variedade de conectores que podem ser usados para conectar a uma variedade de sistemas, incluindo o WebLogic JMS.

Para implementar o padrão Bridge Strimzi com WebLogic:

#  Instale o Strimzi no seu cluster OpenShift
oc apply -f https://strimzi.io/install/latest/cluster-operator.yaml.

# Crie um cluster Kafka usando o Strimz
oc apply -f https://strimzi.io/install/latest/kafka-cluster.yaml.

oc apply -f https://strimzi.io/install/latest/topic.yaml.

oc apply -f https://strimzi.io/install/latest/connector-jms.yaml.

**Após concluir essas etapas, você terá um bridge implantado no seu cluster OpenShift. O bridge irá encaminhar mensagens do tópico Kafka para o servidor WebLogic JMS.**

**Aqui está um exemplo de arquivo connector-jms.yaml que você pode usar para criar um conector Kafka Connect para o WebLogic JMS**:
conector-jms.yaml

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnector
metadata:
  name: my-jms-connector
spec:
  class: org.apache.kafka.connect.jms.JmsSinkConnector
  tasksMax: 1
  config:
    bootstrap.servers: my-kafka-cluster-kafka-bootstrap:9092
    jms.connection.url: tcp://my-jms-server:7676
    jms.destination.type: queue
    jms.destination.name: my-queue

Este arquivo cria um conector Kafka Connect chamado my-jms-connector. O conector usa a classe org.apache.kafka.connect.jms.JmsSinkConnector para encaminhar mensagens para o servidor WebLogic JMS. O conector tem uma tarefa e as configurações do conector são as seguintes:

bootstrap.servers: O endereço do cluster Kafka.
jms.connection.url: O endereço do servidor WebLogic JMS.
jms.destination.type: O tipo de destino JMS.
jms.destination.name: O nome do destino JMS.
Depois de criar o conector Kafka Connect, você pode começar a enviar mensagens para o cluster Kafka. As mensagens serão encaminhadas para o servidor WebLogic JMS.

Aqui está um exemplo de código que você pode usar para enviar uma mensagem para o cluster Kafka:

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;

public class Producer {

    public static void main(String[] args) throws Exception {
        // Criar um produtor Kafka
        KafkaProducer<String, String> producer = new KafkaProducer<>(
            new ProducerConfig(
                new Properties()
            )
        );

        // Criar uma mensagem
        String key = "key";
        String value = "value";
        ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", key, value);

        // Enviar a mensagem
        producer.send(record);

        // Fechar o produtor
        producer.close();
    }
}

- Este código cria um produtor Kafka e envia uma mensagem para o tópico my-topic. A mensagem tem a chave key e o valor value.

A mensagem será encaminhada para o servidor WebLogic JMS. Você pode usar o WebLogic JMS para receber a mensagem.
timizado para GraalVM e HotSpot: O Quarkus foi projetado para trabalhar eficientemente tanto com a GraalVM quanto com a JVM HotSpot tradicional, oferecendo tempos de inicialização rápidos e menor utilização de memória.

Desenvolvimento de Aplicações Nativas e JVM: Quarkus permite a criação de aplicações que podem ser compiladas em código nativo, além do modelo tradicional baseado em JVM. Isso resulta em aplicações que têm um footprint (pegada) muito pequeno e são extremamente rápidas para iniciar, o que é ideal para ambientes de nuvem e de microserviços.

Foco em Microserviços: O Quarkus foi criado com o desenvolvimento de microserviços em mente, facilitando a criação de arquiteturas distribuídas e escaláveis.

Integração com Tecnologias Modernas: Oferece suporte a uma ampla gama de tecnologias modernas e frameworks, incluindo Eclipse MicroProfile, Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Spring, Infinispan, Camel, e mais.

Modelo de Programação Imperativo e Reativo: Quarkus suporta tanto o modelo de programação imperativo tradicional quanto o modelo reativo, oferecendo flexibilidade para os desenvolvedores.

Desenvolvimento com Live Coding: Uma das características mais notáveis do Quarkus é a sua capacidade de "live coding", permitindo aos desenvolvedores ver as mudanças no código em tempo real sem a necessidade de reiniciar a aplicação.
##

## JBOSS Wildifly/RED HAT, ou mantém o próprio Java com 
 WebLogic migrando aos poucos para microservice, sabendo que a esteira terá o openshift.
     
  Recomendo o  strimzi connectors como   nos conectores do openshift. 
 
   JBoss EAP/Wildfly com uma migração aos poucos para o quarkus estará dentro de pouco tempo  nos padrões de  miroservice, convertendo devagar um arquitetura orientada a componentes para microservices.

 O quarkus é uma arquitetura voltada para microservice e a Red Hat, está entrando na empresa.   

## Conectores WebLogic
Os conectores de versão prévia não têm suporte no momento e nem são recomendados para uso em produção.

O conector Kafka Connect WebLogic JMS Source é usado para ler mensagens de um servidor Oracle WebLogic JMS e gravá-las em um tópico Apache Kafka.

## Observação
## JMS Source geral para o Confluent Platform que usa um mecanismo baseado em JNDI para conectar-se ao broker JMS, O conector WebLogic também se conecta usando JNDI, mas inclui suporte especial para assinaturas compartilhadas JMS 2.0
Entrada com Service Bus

1.**O produtor Kafka é a fonte de dados. Ele envia mensagens para o tópico Kafka.**

2. **Processador de dados: O WebLogic JMS é o processador de dados. Ele recebe mensagens do tópico Kafka e as converte em mensagens JMS.**

3. **Destino de dados: O WebLogic JMS é também o destino de dados. Ele envia as mensagens JMS para o destino JMS.**

11. **Seria possível compartilhar este plano?**
A segurança é um aspecto crítico em sistemas de mensageria. É necessário detalhar os requisitos específicos de segurança, como autenticação, autorização e criptografia. Utilizando também serviços de api om autenticação e token oauth2.0, registrando logs nos acessos, nas transações e nos processos realizados pelas filas do kafka.

12. **Qual o ambiente Cloud utilizado?**
**Hoje a CCR utiliza o OpenShift, Azure e a AWS, algumas soluções onPremises.**

13. **Existe arquitetura já definida a ser compartilhada?**
**A arquitetura definida era centralizada em banco de dados Oracle, utilizando integrações com legados, com Sistemas Saps, escalando para utilização em Cloud Azure com o trabalho de rastreamento de logs. tendo início as Sistemas Monolitos feitos em Back End como no C# e no Front-End utilização do Angular 14, Ionics para a visualização dos dados no celular em algumas aplicações**

14. **As atividades poderão ser desenvolvidas remotamente?**
**Sim, toda a infra estrtura com base em kubernetes openshift e multi-cloud pode ser toda gerenciada de forma remota.**

15. **Qual a volumetria do Apache Kafka tráfego, armazenamento dos dados?**
**A volumetria do projeto kafka será com base de 1.300.000 a 2.000.000 normalmente, podendo escalar no mínimo 2.000.000 até 5.000.000 de carros por dia carros por dia, armazenamento de dados 5 tb por mês. volume de Logs 1400.000 mensagens por dia escalando, progressivamente 2000.000 mensagens dia.** **

## Respostas das Perguntas Técnicas

2)
3) resposta do questionário ?

Não é necessário o Nosql desde que utilize uma instancia do Próprio Jdbc como reativa, o dynamo Db e o comsmos Db nosql ajudam muito no caso do EDA, para o recebimento de o disparo de uma fila, mas adotaremos o oracle, de acordo com a cloud o nosql para gestão de um segundo database nsql, mas de preferência utilizar oracle com os drivers reativos

4) Resposta do Questionário questionário?
Responsabilidade da Cloud e dos containers parte dela o gerenciamento dos cluster e criação da esteira será feito pela CCR. Com Open Shift

5) Resposta da Pergunta 5
Na seção "3.1.8. Suporte à integração dos sistemas legados" existe um pedido para
construção de adaptadores Kafka Connect aos sistemas legados. A dúvida é se precisamos
prever suporte aos times dos sistemas legados construírem os seus próprios Kafka
Connectors ou se devemos prever a construção dos conectores entre Kafka e BD Oracle
dos legados no escopo da proposta.

**Com certeza esse trabalho será feito os conectores do Kafka em 4 vias, CCR por parte das Pocs feitas pelo time do Kafka e a contratada, os testes serão realizados na estrutura preparada onpremisses/aws da própria CCR com a contratada .**

6. Apache Cluster do Apache Kafka
**A utilização de Cluster do Apache Kafka com Conexão ao Weblogic pode ser desenolvido pelo time, mas a CCR estará dando suporte e acompanhamento com o time de projeto.**

**As Osas Continuam com JMS, só principais mensagems, principalmente as referentes a integração, as messagerias que irão integrar com outros projetos, para o disparo das mesmas, tendo como meta ou base, fazer todos os disparos de mensagens para atingirmos o objetivo de Utilizarmos WebLogic com Jms e Kafka para o envio e consumo dos dados das apis de integração**

Segue uma arquitetura feito pelo time da Oracle para o disparo e envio de mensagens.

## Inbound

## Outbound

9) Nenhum sistema legado precisará de integração baseada em arquivo para se integrar
ao Kafka? O sistema de Cancela atualmente tem integração baseada em arquivo será
modificado para BD Oracle ou ficará fora do escopo?

**"Resposta na medida que formos integrando os principais serviços de integrações, a ideia é que com tempo façamos essas evoluções."**

# As tecnologias pré determinadas hoje por parte da CCR, Aws open shift e para algumas soluções kafka on Premises. Iremos fazer vários testes de integrações em parcerias com os times de desenvolvimento do free flow, por parte da Messageria Apache Kafka.

11) A atual solução Weblogic possui monitores web para acompanhamento e visualização. Devemos prever a reconstrução ou adaptação dele no escopo da proposta técnica? Se sim, poderiam compartilhar detalhes dos requisitos?

**Não precisa o retrabalho quando já está funcionando o sistema de forma adequada. A ideia jamais é mexer em sistemas que estão funcionando, tendo uma grande performace, se isso acontecer como no caso exclusivamente do WebLogic para não impactar na aplicação e programação devemos estabelecer, alguns ajustes nas messagerias para as integrações de alto volume e para atingir uma baixa latência. somente algumas que elencarmos os serviços e nas determinações da arquitetura que seriam Aws com openshift multicloud.**

11) Poderiam confirmar se os tipos de servidores JMS das OSA's são Wildfly, HornetQe
Weblogic?

JMS confirmado, Weblogic Confirmado, Wildifly hoje pertencendo a Hed Hat empresa para o qual estamos como parceiros sem problemas. HornetQ se for mensagens que não impactam o projeto sem problemas, mas vamos tentar sempre deixar pontos de atenção no futuro, quando o apache kafka escalar, com certeza poderemos em alguns casos, que tanto a arquitura de vocês e a da CCR poderemos scalar para Apache Kafka

HornetQ: Ideal para cenários onde a comunicação confiável, as transações e o processamento de mensagens tradicional .

Kafka: Melhor para cenários que exigem processamento de grandes volumes de dados, alta disponibilidade, e onde é necessária a capacidade de reprocessar mensagens (graças ao seu modelo de log distribuído).