Rubem Azenha wrote:Eu tenho péssima experiências com integração via banco de dados! Depende de cara projeto, mas eu geralmente sou contra.

Eu acho muito problemático ter várias aplicações lendo uma mesma base de dados, pior ainda várias aplicações alterando a mesma base de dados. É muito fácil a situação ficar caótica e você não conseguir enchergar que aplicação altera que dado em que tabela. Sem falar na duplicação de códigos entre aplicações para interpretar o que cada dado significa, validações, etc e todos so problemas que essa duplicação de código traz.

O pior é tratar os eventos que devem acontecer quando um dado é inserido ou alterado... numa aplicação que eu trabalhei no ano retrasado, várias aplicações liam e alteravam os dados dos funcionários. Isso era um problema por que existia uma necessidade de executar um processo de uma das aplicação cada vez que um funcionário era demitido ou entrava de férias... No fim acabamos fazendo uma aplicação só pra cuidar do cadastro dos funcionários, todas as outras aplicações que precisavam acessar ou alterar dados dos funcionários passaram a utilizar essa aplicação e tinhamos mecanismos que permitiam trabalhar melhor com notificações de eventos (nada muito sofisticado, tinha muito espaço para melhoras, mas é melhor que usar trigger).

Enfim, acho que o banco de dados deve ser utilizado por apenas um sistema, os outros sistemas não devem acessar direto o banco de dados e sim usar algum outro mecanismo de integração (queue, WS, EJB...)

Luiz Aguiar wrote:

Luca wrote:Olá

Como engenheiro acho o Project excelente para gerenciar obras ou projetos de engenharia. Na área de TI nunca vi dar certo.
Luca

++

xdraculax wrote:Ok:

Segurança:

Todos os dados devem ser enviados para a central criptografados. Usando uma chave de tamanho variável (ou seja, para alguns contratos posso utilizar uma chave de 128 bits, e em outro uma de 1024 bits).

xdraculax wrote:
Performance

Alguns contratos possuem restrições de tempo de envio. Por exemplo, a mensagem deve sair do equipamento para a central de 2 seg. Se você imaginar isso isoladamente, é perfeitamente possível usar SOAP, mas no momento de enviar essa mensagem eu posso estar enviando um arquivo de 300MB, e mais n mensagens com outras finalidades. Como, com SOAP isso seria tratado?

xdraculax wrote:
Escalabilidade

Novamente a variação por contrato. Em alguns eu posso ter 30 equipamentos em campo, e em outro eu posso ter 500. Uma central para suportar os 500 equipamentos, certamente não será uma máquina só.

xdraculax wrote:

Emerson Macedo wrote:Ao invés de ter 1 máquina com socket, uma opção é ter uma farm com 2 ou 3 máquinas respondendo HTTP (REST, SOAP, POX). Conforme a necessidade você coloca mais máquinas

A aplicação tem outros requisitos de Segurança e Performance; onde a performance afeta diretamente essa comunicação feita entre os equipamentos em campo e a central. Acredito que REST e SOAP não são boas opções para uma performance alta. Outra questão que não deve ser fácil com relação a SOAP e REST é Segurança.
Como eu disse tudo é criptografado e SOAP não se adequaria bem a esse requisito.

xdraculax wrote:

Emerson Macedo wrote:
Se você adorat a idéia que coloquei acima, esse problema vai ser minimizado no ponto de entrada. O Servidor de mensageria também não deveria funcionar com somente uma instância, pra evitar justamente o que você falou. Nesse ponto, você vai ter consumidores dessa mensagens e pode dosar esse processamento como convir para evitar a saturação do sistema, e trabalhar em cima do tempo de resposta, como o Luca já havia explicado.

Tudo bem, entendi. Mas imaginemos o seguinte (um exemplo bem bobo, mas é só pra ter certeza que estamos compreendendo a mesma coisa):

Você tem sua fábrica de carros com
1 linha de produção e
1 porta pequena (meu socket - coisa estranha, "meu socket"), que recebe uma pequena quantidade de peças.

De repente sua demanda aumenta 200%, e você coloca mais 2 linhas de produção, mas sua porta continua a mesma; ou seja, você possui o mesmo ponto de entrada limitado, que em nosso caso é o socket. E agora você tem capacidade de produção mas sua porta não dá vazão a essa quantidade de peças que chegam.

xdraculax wrote:
Meu problema é exatamente essa porta. Eu quero uma forma de tornar essa porta mais escalar, segura e rápida (quer nada ein ^^).

xdraculax wrote:
Na central que recebe esses dados, temos um Socket (1 socket mesmo); essa central recebe esses dados, persiste em banco, processa, envia alertas, etc.
Problema é que vai chegar um ponto, que 1 socket (ou a largura de banda) não vai dar vazão a quantidade de informação, ou a capacidade de processamento dessa central não vai ser suficiente (por mais que você coloque uma máquina super potente, vai chegar uma hora que não vai mais poder aumentar sua capacidade).

xdraculax wrote:
Criar uma máquina que simplesmente enfileira os recebimentos de informações e vai passando para outras máquinas processarem - o problema dessa abordagem, é que a se a máquina de faixada cair, o sistema todo cai.