Arquitetura: Sistema de controle de tráfego em tempo real

Programação Arquitetura
#1

Prezados, boa tarde.
Estou começando a estudar java para desenvolver um sistema distribuído, porém, não tenho experiência com java, estou na busca de quebrar meus laços com o Delphi.
Pretendo buscar/ estudar java de acordo com a arquitetura do sistema que pretendo desenvolver.

O que preciso é uma arquitetura para resolver o seguinte problema:

Digamos que eu tenha 10 aviões, cada avião terá um sistema android onde o piloto irá informar sua matrícula e a atividade que ele está exercendo (exemplo: voando, abastecendo). O avião possui gps, logo o sistema android irá disponibilizar a posição (longitude e latitude) e velocidade do avião também.

Uma aplicação cliente poderá consultar as atividades que os aviões estão e suas posições atuais. Essa aplicação cliente (controlador de voo) irá gerar os locais de onde os aviões iram sair e para onde estão indo (saiu de SP está indo para RJ). Será possível consultar a origem e destino do voo tanto da aplicação cliente quanto de dentro do avião.

Por motivo de falha e comunicação cada sistema android terá um bando de dados (sqlite) interno e enviará as mensagens de forma assíncrona, um servidor de aplicação será responsável por receber essas informações e enviar para as aplicações clientes (controle de voo) e para os outros aviões (todos aviões devem saber as posições de todos).

Resumindo: Os aviões geram, enviam e recebem informações do servidor de aplicações.
As aplicações clientes geram, enviam e recebem informações do servidor de aplicações.
O servidor de aplicações, recebe e envia informações para os aviões e aplicações cliente (controle de voo).

O que já pensei:

  1. Aplicação cliente tanto faz a tecnologia ( talvez javafx)
  2. O servidor de aplicação pensei em algo como Active MQ (JMS) e bd postgres.
  3. E o sistema dos aviões em android e bd sqlite;

Espero que tenha sido claro e caso alguém possa me ajudar nas tecnologias que preciso estudar para alcançar esse objetivo fico grato.

Att,

#2

Acho que você começou pelo lado errado… Antes de você decidir quais produtos e tecnologias irá usar, você precisa pensar na arquitetura de sua aplicação de forma agnóstica a produtos e tecnologias.

Como esse servidor vai funcionar? Ele é multi-threaded ou single-threaded? Existem requisições prioritárias ou emergenciais? Quantos aviões ele precisa atender simultaneamente? O que acontece se o servidor cair? Os aviões mantém uma conexão aberta com o servidor ou abrem e fecham uma cada vez que vão enviar uma mensagem?

Acho que o menos importante é se você vai usar javafx, android, ActiveMQ, JMS, bd postgres… Sua arquitetura de aplicação não deve começar pela definição de componentes tecnológicos. Sua arquitetura de aplicação deve guiar a decisão de usar um determinado componente tecnológico.

#3

[quote=“esmiralha, post:2, topic:327952”]
Acho que você começou pelo lado errado… Antes de você decidir quais produtos e tecnologias irá usar, você precisa pensar na arquitetura de sua aplicação de forma agnóstica a produtos e tecnologias.[/quote]
Olá Esmiralha, muito obrigado pelo feedback.
Irei falar um pouco mais sobre esse arquitetura sem pensar em produtos ou tecnologias. Respondendo suas perguntas:

Como estou falando de um sistema em real-time, imagino que deverá ser um servidor multi-threaded, pois, não vejo outra forma de tratar persistência de dados de N aviões simultaneamente sem bloquear o servidor, o servidor deve continuar respondendo e enviando requisições para os aviões e aplicações clientes enquanto persiste dados.

Dois exemplo de comportamento:

a) A cada cinco (talvez menos) segundos o avião envia para o servidor uma mensagem com sua posição e velocidade.
b) O servidor deve persistir esses dados na base de produção e notificar o avião o recebimento da mensagem, então o avião irá deletar a mensagem; caso contrário o avião irá armazenar os dados e a cada cinco segundos irá tentar enviar os pacotes pendentes (como uma caixa-preta de avião, apenas com informações que o servidor não persistiu);
c) Por fim, o servidor deve dar um broadcast a cada 5 segundos e notificar a todos clientes e aviões as alterações persistidas (o servidor não precisa receber confirmação que todos recebem o broadcast);

  1. Quando um avião troca de atividade ou matrícula do piloto, todo o procedimento é o mesmo, a única diferença é que a mensagem deve ser enviada para o servidor imediatamente e não a cada cinco segundos; Por fim, caso uma aplicação cliente altere manualmente a atividade de um avião o fluxo de dados segue a mesma lógica;

No momento uns 10, mas daqui uns anos pode ser uns 200.

As instâncias (aplicações) clientes devem para de responder até que o servidor volte, já os aviões devem continuar funcionando normalmente, ou seja, armazenar suas atividades, posição e velocidade na base internar e depois enviar para o servidor persistir.

Eu imagino que seja melhor manter uma conexão sempre aberta para envio da mensagem padrão a cada cinco segundos e abrir um sempre que a atividade ou matrícula do piloto for alterada.
Ou talvez eu devesse padronizar e enviar tudo a cada dois (três) segundos.

Pelo que eu pude perceber o bom gerenciamento de uma pilha de mensagem será crucial para esse aplicação que basicamente é um monitoramento de aviões em tempo real.

Por esse motivo estou pesquisando sobre vários tecnologias/especificações/implementações/frameworks na medida que minha falta de conhecimento permite, tal como: JPA/Hibernate, JMS, ActiveMQ, GlassFish, Node.j, nosql/sqlite, sincronismo/ assincronismo.

Referências que estou analisando se pertencem ao mesmo modelo arquitetural que preciso:

  1. [Developing Real-Time Software with Java SE APIs: Part 1] (http://www.oracle.com/technetwork/articles/java/nilsen-realtime-pt1-2264405.html)
  2. WebTaxi: GPS Based Taxi Service

Espero ter sido claro e mais uma vez agradeço pela sua contribuição.

#4

Entendi que seu sistema deve suportar um ambiente onde os componentes possuem baixa disponibilidade. Leve isso em consideração na hora de definir o protocolo de comunicação entre os aviões e o servidor.

Outro ponto importante é determinar a criticidade de receber cada mensagem. É essencial garantir que todas as mensagens cheguem ao servidor e sejam replicadas aos outros aviões? Ou perder uma mensagem ou outra não compromete o resultado do sistema?

Se concentre em responder essas (e muitas outras perguntas) e depois você terá melhores condições apra decidir se vai usar JPA/Hibernate, JMS, XYZ, Autobots, etc.

Boa sorte!