Como comunicar um sistema Desktop em rede de lojas

A legislação baseada no convênio PAF/ECF exige que o programa dependa, única e exclusivamente, do equipamento onde está instalado para ser executado, logo, base de dados remota não seria permitido.
Dê uma olhada na legislação, precisa ver se o que pretende fazer é permitido e pode ser homologada.
Há algumas opções para o que quer:

• Socket
• EJB
• Sincronização via banco de dados

Bom, acho que já é hora de pensar na escalabilidade do seu sistema.

Acho que a solução mais simples é centralizar o banco de dados em uma das lojas e montar uma VPN entre as duas redes. Assim, a não ser que você tenha chapado o endereço do banco no código, você praticamente não alterara a sua aplicação.

Porém, acho que o principal você não disse: quanto o seu cliente está disposto a investir ? Essa pergunta é o cerne de toda a questão, porque na prática é o que define como você vai montar a infra-estrutura necessária para suportar o negócio. Na minha opinião, o esforço maior é de infra-estrutura, e não de aplicação. Pois além de montar o acesso, há toda uma questão de segurança que você precisa se preocupar agora: configurar firewall, restringir acesso, etc.

drsmachado:

A legislação baseada no convênio PAF/ECF exige que o programa dependa, única e exclusivamente, do equipamento onde está instalado para ser executado, logo, base de dados remota não seria permitido.
Dê uma olhada na legislação, precisa ver se o que pretende fazer é permitido e pode ser homologada.
Há algumas opções para o que quer:

• Socket
• EJB
• Sincronização via banco de dados

Mas isso se aplica somente às frentes de caixas, ou o software específico que se comunica com impressoras fiscais. Se for esse o caso, talvez seja necessário separar a frente de caixa do back-office.

Estive dando uma olhada nesse esquema do VPN…vou dar uma pesquisada…pois não entendi muito bem esse esquema… seria como uma sub-rede na net…estou certo ou viajei…?

É exatamente isso. VPN=Virtual Private Network.

RMI.

Como o colega ai em cima disse,
vc deve estar atento à legislação, que
proibe bufferização de dados.

Mas o estoque vc pode centralizar em uma
das lojas fazendo o acesso pela web,
ou por uma vpn. (pela web seria praticamente de graça, usando
no-ip, acessando o banco pela url. Cuidados com segurança devem
ser feitos).

Como ja foi dito, separar os modulos é uma
boa pra não ter problemas com a fiscalização.

Na minha opinião, independente de legislação, se o seu sistema for para venda direta, tipo caixa de supermercado, recomendo que ele trabalhe com uma base de dados local e que tenha um mecanismo de sincronização com uma de base centralizada. Uma vez estava no Livraria Cultura e caiu a comunicação com o servidor. Os caixas chavearam para um modo “standalone”, podendo continuar com as vendas. A única crítica que faço neste esquema da Cultura é que demorou mais de meia hora até o caixa entrar neste modo standalone.

E se a empresa onde você for instalar este seu sistema usar links diretos não dedicados (via internet), a recomendação aumenta mais ainda, pois o risco de instabilidade na rede vai ser grande.

Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.

Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.

petter:

Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.

Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.

O convênio PAF/ECF e a legislação correspondente não deixam claro o que é um sistema de frente de caixa e qual é um sistema de gerenciamento de emissão de cupons fiscais, pelo que li, ele considera ambos a mesma coisa.

A solução mais comum é manter o frente de caixa como sendo o gerenciador do emissor de cupom fiscal (ECF - impressora) rodando com uma base de dados local que, a cada período de tempo, é sincronizada a uma remota (seja na lan ou em algum lugar do mundo).

Na verdade o sistema não seria para PAF-ECF… seria mais a parte gerencial, quando citei vendas, quis dizer uma tela de consultas das vendas realizadas…o módulo do paf, eu tenho separado… meu problema seria a comunicação entre os sistemas gerenciais…pois achando uma maneira de fazer isso, todo o resto estaria resolvido…

petter:

Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.

Seria uma opção…sincronização de tempos em tempos… a questão seria…
1-em que momento seria sincronizado…
2-O que seria sincronizado, (criar flags na base para saber o que foi modificado, incluído ou deletado???) pois se de tempos em tempos mandar por exemplo todos os produtos e clientes vai ocorrer uma grande perda de desempenho

Concordo plenamente…já tinha pensado nisso e já estava me planejando para isso, porém ainda não sobrou um tempo pra isso, meus planos é migrar tudo para Web… mas esse sistema está pronto pra desktop e tenho um prazo pequeno no qual não conseguiria implementar o todo ele para Web (pelo menos para este cliente)…então decidi fazer este módulo de comunicação entre lojas…

drsmachado:

petter:

Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.

Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.

Até onde eu me lembro, o convênio PAF/ECF proíbe sistemas web, justamente por não dependerem exclusivamente do próprio ambiente(?).

O convênio PAF/ECF e a legislação correspondente não deixam claro o que é um sistema de frente de caixa e qual é um sistema de gerenciamento de emissão de cupons fiscais, pelo que li, ele considera ambos a mesma coisa.

A solução mais comum é manter o frente de caixa como sendo o gerenciador do emissor de cupom fiscal (ECF - impressora) rodando com uma base de dados local que, a cada período de tempo, é sincronizada a uma remota (seja na lan ou em algum lugar do mundo).

sim, eu sei que o convênio é cheio de regras, mas quando falei em solução Web não foi todo o ERP, casos como frente de loja podem atuar stand alone desde que preparados para uma interface com o restante do ERP, assim é mais fácil obter escalabilidade e a agregação de novas filiais se torna muito mais transparente.

leopoldof:

petter:

Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.

Seria uma opção…sincronização de tempos em tempos… a questão seria…
1-em que momento seria sincronizado…
2-O que seria sincronizado, (criar flags na base para saber o que foi modificado, incluído ou deletado???) pois se de tempos em tempos mandar por exemplo todos os produtos e clientes vai ocorrer uma grande perda de desempenho

Concordo plenamente…já tinha pensado nisso e já estava me planejando para isso, porém ainda não sobrou um tempo pra isso, meus planos é migrar tudo para Web… mas esse sistema está pronto pra desktop e tenho um prazo pequeno no qual não conseguiria implementar o todo ele para Web (pelo menos para este cliente)…então decidi fazer este módulo de comunicação entre lojas…

Seguinte, além de Java tenho experiência com Oracle, esse sincronismo poderia ser acertado via o próprio BD e não pela aplicação, o que seria sincronizado é uma decisão pertinente de uma análise profunda dos processos empresariais e processos sistêmicos.

Cara, tenta o mais simples primeiro. Eu imagino que você deve usar um banco de dados em modo servidor, ao invés de um BD embarcado. Sendo assim, instale o programa na filial e configure-o para acessar o banco de dados da matriz diretamente. Uma vez que a configuração esteja pronta, é só acompanhar o pessoal usando o sistema para saber se a responsividade está satisfatória.

De qualquer maneira, não há como fugir da infra-estrutura de rede necessária.

Eu não diria embarcado…pois não seria um banco em cada máquina…mas sim um banco de dados em cada loja, ou seja em cada “lan”…e sincronizar os bancos de tempos em tempos…

Pensei nisso também…deixar na “matriz” a base de dados… e instalar na filial somente o programa… depois, por consequencia, configurar um endereço no-ip para que a filial acessar a base de dados na matriz, configurar o modem-roteador da matriz o redirecionamento de portas para o pc que possui base de dados central… + config de firewall…e por aí vai…

Mas assim o sistema não ficará “instável”?
e o sistema na filial não ficará lento…?

mas seria a solução mais rápida…creio não não dará problemas…

Já estou com um nó na cabeça…o que não quero é que o sistema fique instável…caindo toda hora… nunca implementei com redes externas…o que tenho medo é que aconteca o que já presenciei em farmácias e em outros tipos de lojas…que o cara vai comprar uma coisa…e quando vai fazer uma consulta de preço ou estoque… ou até mesmo fazer um pagamento (em determinados casos)…e o atendente fala lá que o sistema caiu e que tem que esperar voltar…kkkkkkkk…e lá se vão 10,15 minutos esperando…

Cara, resolva um problema de cada vez:

Veja bem, esse tipo de infra-estrutura você vai precisar montar de qualquer maneira. Eu pensaria seriamente na VPN, mas isso depende SO que você vai usar, acho que as versões mais caseiras do Windows não permitem você montar VPNs, em compensação, acho que qualquer distro Linux suporta esse recurso.

Como eu disse, 1 problema de cada vez. Eu acho bastante complicado fazer suposições sobre o comportamento do sistema. Como eu disse, uma vez que a infra-estrutura de rede esteja pronta, instalar a aplicação é simples, é só configurar os dados de conexão. Você só vai saber se o sistema vai ficar lento ou não colocando ele em uso.

De fato, seria tolice ignorar o fato de que a conexão pode cair. Nesse caso, eu não vejo solução melhor do que manter uma base auxiliar na rede local e sincronizar os dados. Mas por exemplo, você não precisa replicar toda a base, mas apenas as tabelas necessárias para manter o processo de venda. Dados gerencias podem ficar apenas na matriz.

Mas resumindo, você não precisa resolver todos os problemas de uma vez. Implante a infra-estrutura necessária, coloque o sistema em produção e trabalhe para implementar a tolerância a falhas no nível desejado. É provável que no meio do caminho surjam outros problemas sobre os quais você nem pensou ainda.

Também teria uma outra solução… uma espécie de “sincronização assíncrona” he he he…
no qual entraria uma terceira máquina… que poderia ser o server daqui da empresa, já que este tem funcionalidades de gerenciar as atualizações dos sistemas nos clientes, já implementaria mais um programinha server pra ficar rodando direto…no qual ficaria um esquema assim…

A matriz com seu BD Local e a filial com o seu BD Local…
Então de tempo em tempo a filial geraria um arquivo com os registros pertinentes, (Dados excluídos, alterados e incluidos como Vendas , clientes, produtos, contas recebidas, etc) e mandaria esse arquivo para uma terceira máquina , que seria o server daqui da empresa…
Entao o server daqui da empresa guarda esse arquivo
Então a matriz de tempo em tempo também consulta o server para ver se não tem nenhum arquivo de sincronização…se tiver…atualiza os dados da filial na base da matriz…

também funcionando de maneira reversa… onde a matriz gera o arquivo e as filiais consultam as atualizações…

Prós que visualizei de inicio.
1)Velocidade do sistema nas filiais, e matriz, pois o banco seria local
2)Abriria mão de configurações de roteadores, modens, firewal, locação de ip fixo… e por aí vai
3)Eliminaria o problema de a rede cair e o sistema travar nas filiais

Contras
1)Implementar um módulo para importar dados modificados podem dar conflitos e varios outros problemas de inicio
2)Dependendo do tempo definido para sincronização, a consulta de estoque , por exemplo não estaria “correta”
3)Essa terceira máquina o qual faria o meio de campo… seria um tendão de aquiles para o sistema…

Matriz <-----> Server <-----> Filial

Cara, antes de mais nada, leia este artigo. Do contrário, você corre um grande risco de começar a correr atrás do próprio rabo …

Na verdade , seguindo esta última lógica, o sistema não seria basicamente um sistema com uma base de dados distribuída…mas sim um sistema com redundância de dados, no qual eliminaria várias formas de possíveis falhas… inclusive a falha na internet… se assim como o mecanismo automático de atualização, poderia fazer uma sincronização manual…

Voltando a discução deste tópico… postarei aqui o que foi implementado…e como funcionou

Implementei da maneira mais prática para verificar como o sistema se comportaria…
(Não sei se seria a mais correta para este caso, mas é bom colocar em prática para ver realmente como funciona)

Implementei da seguinte forma…

Na loja matriz fica a base de dados e a filial só fica instalado o sistema no qual acessa via internet a base de dados situada na matriz…
Então o sistema associa cada registro armazenado a sua filial, cada produto tem sua filial, cada venda tem sua filial, facilitando assim consultas, relatórios e visulizações pelos funcionarios…

*Um problema que notei é a lentidão tanto nas consultas quanto nos cadastros quando acessado via internet… (não instalei ainda no cliente, porém montei um server aqui e acessei o sistema de uma outra rede através do notbook)
Bom onde estava instalado a base de dados tem uma banda razoável de internet uns 5 M e de onde acessei o sistema tem uma banda de 2 M…portanto, creio que não seja o problema de baixa taxa de transferencia da internet.

*Em rede local não possui essa lentidão (claro he he he)

Estou pensando seriamente em fazer como citado em posts anteriores…em instalar uma base de dados em cada loja e fazer um módulo de “sincronização” das bases de tempos em tempos…creio que resolveria os problemas de queda repentina de internet e o problema de lentidão do sistema…

O que voces acham…?

Obs:Meu sistema é desktop, (a pedido do cliente) claro que se fosse um sistema web seria bem mais prático e sem tantos problemas…

lendo todos os posts eu senti falta de 1 pergunta:

O que precisa ser sincronizado ?

a necessidade de trabalhar com matriz e filial levantou quais requisitos ? Quais informações a filial precisa passar para matrix e vice-versa ? Com que frequência ?

A menos que você esteja lidando com lojas que compartilhem um estoque único (a filial vende, mas quem entrega é a matriz) eu não vejo motivo para que a comunicação seja atômica. E se for esse mesmo o caso, você pode trabalhar com algumas sincronizações diárias, sei lá, duas ou três vezes por dia, ou então uma vez por dia fora do horário do expediente.

Se a filial não tem dependência da matriz para efetuar as atividades, então sugiro que trabalhe com os dados localmente e depois em um determinado horário faça os sincronismos necessários.

Ainda assim podem existir casos onde seja necessário uma comunicação síncrona, mas você reduz muito a dependência da matriz pois apenas precisaria consumir serviços em algumas situações e não passar um código de barras e aguardar a matriz devolver o nome e o valor do produto.

Isso mesmo…

Claro que o cliente quer chegar no final do dia…entrar no sistema e ver o que foi vendido na matriz e filiais, quanto de estoque tem em cada uma e gerar relatórios de movimentação, custos, etc… mas no fim do dia…

Estava pesquisando sobre a tal 'sincronização" e estou vendo que vou ter dor de cabeça com isso,me refiro as chaves primárias …

Isso mesmo…

Claro que o cliente quer chegar no final do dia…entrar no sistema e ver o que foi vendido na matriz e filiais, quanto de estoque tem em cada uma e gerar relatórios de movimentação, custos, etc… mas no fim do dia…

Estava pesquisando sobre a tal 'sincronização" e estou vendo que vou ter dor de cabeça com isso,me refiro as chaves primárias …

usa chave composta, no servidor da matriz vc faz uma parte da chave AUTOINCREMENT ou um identificador para a filial e na outra parte da chave a chave da tabela da filial

Isso mesmo…

Claro que o cliente quer chegar no final do dia…entrar no sistema e ver o que foi vendido na matriz e filiais, quanto de estoque tem em cada uma e gerar relatórios de movimentação, custos, etc… mas no fim do dia…

Estava pesquisando sobre a tal 'sincronização" e estou vendo que vou ter dor de cabeça com isso,me refiro as chaves primárias …

Olha, isso pode ser mais fácil ou mais difícil, dependendo de como você trabalha com chaves primárias e quais são as entidades que precisam de sincronização.

Na minha opinião, a melhor abordagem para trabalhar com entidades é usar, sempre que possível, chaves simples, de auto-incremento. E nunca usar chaves naturais como PK, justamente porque em dado momento, um registro pode ter sua chave natural alterada, trazendo complicações na hora de fazer merge entre bases de dados ou então alterar o valor da PK.

Olá a todos…
Continuando…

Então… a chave composta seria uma alternativa… porém terei que modificar todo o sistema para trabalhar com chaves compostas em vez das de autoincremento que atualmente ele está trabalhando…
Além disso…estou fazendo todo o mapeamento das tabelas no hibernate…e pelo que andei lendo…não é muito prático a utilização de chaves compostas no hibernate…não sei se estou enganado…

Mas seguindo a idéia que me foi passada

Ok…mas então ficaria chaves diferentes no sistema da filial e matriz…

*Uma outra alternativa, seria dividir a geração das chaves…continuando com o auto incremento, porém em faixas de numeração diferentes para cada filial…
Ex.: Matriz trabalharia com cadastros de produtos de 0 a 1000.000, na filial 1 trabalharia com a numeração de 1000.001 a 2000.000 e assim por diante…isso valeria para todas as tabelas do sistema … assim quando fizesse a sincronização nunca daria conflito de chaves… e os bancos ficariam réplicas idênticas…

*Mais uma alternativa seria usar na geração de chaves um dígito identificador … os que iniciarem com 1 é da matriz os que iniciarem com 2 é da filial 1 e assim por diante…
Ex: cdProduto = [telefone removido] seria um produto da matriz e cdProduto 200000025 seria um produto da filial1

Seria uma boa opção? sim? não?

leopoldof:

Olá a todos…
Continuando…

Então… a chave composta seria uma alternativa… porém terei que modificar todo o sistema para trabalhar com chaves compostas em vez das de autoincremento que atualmente ele está trabalhando…
Além disso…estou fazendo todo o mapeamento das tabelas no hibernate…e pelo que andei lendo…não é muito prático a utilização de chaves compostas no hibernate…não sei se estou enganado…

Mas seguindo a idéia que me foi passada

Ok…mas então ficaria chaves diferentes no sistema da filial e matriz…

*Uma outra alternativa, seria dividir a geração das chaves…continuando com o auto incremento, porém em faixas de numeração diferentes para cada filial…
Ex.: Matriz trabalharia com cadastros de produtos de 0 a 1000.000, na filial 1 trabalharia com a numeração de 1000.001 a 2000.000 e assim por diante…isso valeria para todas as tabelas do sistema … assim quando fizesse a sincronização nunca daria conflito de chaves… e os bancos ficariam réplicas idênticas…

*Mais uma alternativa seria usar na geração de chaves um dígito identificador … os que iniciarem com 1 é da matriz os que iniciarem com 2 é da filial 1 e assim por diante…
Ex: cdProduto = [telefone removido] seria um produto da matriz e cdProduto 200000025 seria um produto da filial1

Seria uma boa opção? sim? não?

Cara, eu acho que trabalhar com chaves compostas só vai de trazer dor de cabeça.
Você tem que pensar que o sistema é um só! Sendo assim, entidades são únicas para o sistema todo. Por exemplo, se você tem um cadastro de clientes, por exemplo Cliente{id:1, nome:João} ele tem que ser único para todo o sistema, independentemente de onde ele foi cadastrado. Ou seja, você tem que pensar no banco da filial apenas como um cache.

Eu acho que só compensa incluir um campo para identificar se uma entidade é da matriz ou da filial em entidades onde isso faz realmente sentido, como no estoque, registro de vendas, ou seja, nas movimentações de maneira geral, e mesmo nestes casos, eu não colocaria esse campo como parte da PK. Por outro lado, acho que não compensa fazer essa distinção em cadastros como clientes, fornecedores, até mesmo produtos.

Só uma pergunta, o seu cadastro de produtos é separado do controle de estoque, certo ?

Cara, eu acho que trabalhar com chaves compostas só vai de trazer dor de cabeça.
Você tem que pensar que o sistema é um só! Sendo assim, entidades são únicas para o sistema todo. Por exemplo, se você tem um cadastro de clientes, por exemplo Cliente{id:1, nome:João} ele tem que ser único para todo o sistema, independentemente de onde ele foi cadastrado. Ou seja, você tem que pensar no banco da filial apenas como um cache.

Eu acho que só compensa incluir um campo para identificar se uma entidade é da matriz ou da filial em entidades onde isso faz realmente sentido, como no estoque, registro de vendas, ou seja, nas movimentações de maneira geral, e mesmo nestes casos, eu não colocaria esse campo como parte da PK. Por outro lado, acho que não compensa fazer essa distinção em cadastros como clientes, fornecedores, até mesmo produtos.

Concordo…só que daí ocorreria um problema…
Citando o exemplo de clientes…claro que … o cliente vai ter um só registro para todas as filiais…
Mas veja a seguinte situação…
O leo chega na filial1 e faz o seu cadastro e efetua uma compra… o código de cliente dele é 25…por consequencia, no registro de venda, o cdCliente vai ser 25, nas contas a receber vai ser 25, no recebimento vai ser 25 , e assim por diante… e se quando for sincronizar com a matriz…já tiver na matriz um cliente cadastrado com o código 25??? …vai ter que mudar sua codificação em várias tabelas antes de inserir os novos registros na matriz… e a partir daí acontece outro problema… pois o funcionario sabe que o leo tem o codigo 25 hoje e que amanhã ele pode der o 30…entende…

O mesmo pode acontecer para as vendas… hoje a venda pode ser a 1550 e amanhã ele pode ser a 1552 por caso da sincronização…(se não tiver um identificador de filial)

Claro que em casos como nas tabelas de clientes e fornecedores e outras não prescisa ter distinção de filial… só ficaria essa numeração no ID para não dar conflito de PK na hora da sincronização e sempre manteria a mesma numeração independente da filial em que está… e nunca daria conflito e mudança de PK…

Pior que não… atualmente está tudo numa tabela só… tem uma coluna a mais no produto em que informa a quantidade… tenho que mudar isso também…separar para não dar redundância de registros… mas estou indo por partes…he he eh… primeiro a parte de comunicação Matriz-Filiais

E WebService? Nada impede de você ter um cliente desktop acessando um servidor que disponibiliza as suas operações de persistência e backend através de serviços. Acho muito mais simples e flexível do que sincronizar bds…

Seria uma boa opção…
Mas não consigo visualizar a lógica da idéia de webservice sujerida…
Como ficaria?

A filial enviaria para o WS os registros alterados e a Matriz requisitaria do WS os registros alterados?
Depois seria feito o caminho inverso?

Eu pensei em um servidor na matriz somente, todos acessam o mesmo WS consequentemente com a mesma base… Quando um registro do banco é alterado, todos os clientes automaticamente estarão atualizados pois todos se conectam na mesma base através dos mesmos serviços…

Ué, mas aí ele até piora o problema de latência que ele tem. Ao fazer a comunicação com o banco de dados, os dados são trocados em um formato binário, que é muito mais econômico em termos de banda de rede do que um protocolo baseado em texto como o HTTP/JSON/XML.

Acho que a melhor maneira de resolver esse problema da numeração é reservar faixas de numeração para cada filial. Não sei se o banco de dados que você usa suporta esse recurso nativamente, caso contrário, você vai ter que fazer esse controle manualmente através de uma tabela auxiliar.

Ué, mas aí ele até piora o problema de latência que ele tem. Ao fazer a comunicação com o banco de dados, os dados são trocados em um formato binário, que é muito mais econômico em termos de banda de rede do que um protocolo baseado em texto como o HTTP/JSON/XML.

Acho que a melhor maneira de resolver esse problema da numeração é reservar faixas de numeração para cada filial. Não sei se o banco de dados que você usa suporta esse recurso nativamente, caso contrário, você vai ter que fazer esse controle manualmente através de uma tabela auxiliar.
Piora o problema?

E se o objeto for compactado depois de serializado (tanto na ida como na volta)? Com GZIP por exemplo… Tenho sistemas assim e rodando em uma rede lenta e a performance bate de longe um sistema web… E como eu disse antes, você não fica preso a uma arquitetura de um banco de dados específico

Primeiramente quero agradecer as opiniões, ajuda, sujestões…estão sendo de grande valia…pois estou chegando a conclusões concretas…problema está saindo do papel e está quase transformando em solução he he he…e espero que esse tópico ajude muita gente mais adiante que estiver implementando algo parecido ou passando por alguma dificuldade parecida…

Então vamos lá…

Mas esse esquema de webservice seria para sincronização ou para a comunicação direta com a base de dados…??

Se for para comunicação direta, a cada registro, ele enviaria para a base central? a cada consulta seria feita uma requisição?

Pois fiz um teste aqui se conectando diretamente na base de dados central através de uma rede externa a da base…e fica lento para listagens, etc…
Se conectado diretamente fica lento… será que com WS não ficaria ainda mais? Somente pergunto…pois não manjo muito de WS…

Se for para sincronização…seria uma boa até…porém teria que ter um terceiro elo na ligação entre matriz e filial para isso… uma máquina em que momento em momento matriz e filiais ficariam enviando as modificações e requisitando as modificações feitas por outras filiais…

Como ficaria a lógica… Seria como mensagens compactadas?

O banco que estou usando atualmente é o postgres…e para a geração das PK uso sequences

Como seria “suportar o recurso de reserva de faixas nativamente”? Seria setar na sequence de cada filial o início e fim de numeração? ou trabalhar com triggers ou functions??

Ué, mas aí ele até piora o problema de latência que ele tem. Ao fazer a comunicação com o banco de dados, os dados são trocados em um formato binário, que é muito mais econômico em termos de banda de rede do que um protocolo baseado em texto como o HTTP/JSON/XML.

Acho que a melhor maneira de resolver esse problema da numeração é reservar faixas de numeração para cada filial. Não sei se o banco de dados que você usa suporta esse recurso nativamente, caso contrário, você vai ter que fazer esse controle manualmente através de uma tabela auxiliar.
Piora o problema?

E se o objeto for compactado depois de serializado (tanto na ida como na volta)? Com GZIP por exemplo… Tenho sistemas assim e rodando em uma rede lenta e a performance bate de longe um sistema web… E como eu disse antes, você não fica preso a uma arquitetura de um banco de dados específico

Ué, mas aí você está comparando um protocolo Web compactado com um protocolo Web não compactado, daí a velocidade tende a ser maior mesmo. Pelo que eu entendi, a aplicação do nosso colega conecta-se diretamente com o banco de dados através da Internet, ou seja, não há nenhuma camada ou protocolo intermediário entre os dois. Nesse caso, eu dúvido muito que um protocolo Web, mesmo que compactado com GZIP, seja mais econômico do que protocolos nativos dos bancos de dados.

Nos sistemas que desenvolvemos aqui na empresa utilizamos o mesmo banco que você utiliza, PostgreSQL, e acredite, já tentamos sincronizar bases através do slony e (na época, uns 4 a 5 anos atrás) foi uma dor de cabeça enorme…

Tínhamos o problema de performance e nossos sistemas eram desktop, o que fazer?

1. Tentamos conexão direta ao banco (sem camada intermediária): Somente o banco ficava no servidor e os clientes rodavam a aplicação que se conectava diretamente ao banco.

• Vantagem: Fácil implementação.
• Desvantagens: Lentidão em pesquisas, inviabilidade de controle de transações (impossível tratar commits e rollbacks se quem faz o acesso direto não é o próprio servidor), baixa segurança e tolerância à falhas.

2. Sincronismo de bases: Acredito que seria talvez a forma mais performática, como o rmendes08 comentou. Não implementamos a solução por completo devido à inviabilidade de reconhecimento das bases pois somente o servidor tinha IP fixo e não entrava em questão mascarar o IP através de serviços como NoIP ou DynDNS.

• Vantagem: Performance, se levarmos em conta os protocolos nativos (que vai depender de banco para banco). Altamente escalável e tolerante à falhas, se uma das bases parar, as outras continuam normalmente.
• Desvantagem: Difícil implementação (acredito eu, pelo que posso falar da época que lidei nisso). Inflexibilidade, se levarmos em conta que para cada banco de dados o processo é diferente. Todas as bases devem se conhecer diretamente (o que significa cada uma delas ter visibilidade na WAN)

3. Web service: É a solução que encontramos e usamos até hoje. Atualmente utilizamos o Axis e implementamos nosso próprio ‘protocolo’ para comunicação, que exige autenticação, controle de sessão própria (para os clientes Desktop), pool de conexões, criptografia e compactação dos bytes serializados. Só para ter uma ideia, temos base de dados com fotos cadastradas diretamente no banco e acessadas por clientes em diferentes cidades e a performance é muito boa (levando em conta a compactação)

• Vantagens: Controle unificado de transações, Pool de conexões, acesso à banco local, segurança, maior controle devido ao fato de você poder criar os seus modelos e padrões de conexão. Perfomance boa e consistente em redes lentas através do reenvio de pacotes implementados do jeito que você precisa. Escalável.
• Desvantagem: Necessita servidor de aplicação no servidor. Por não ser tolerável à falhas, deve ter controle de contingência se o servidor cair.

Claro, isso na minha opinião levando em conta a experiência que tive com esses 3 modelos.

Nesse caso do WS , o que não entendo é como funcionaria a parte de transferência de dados entre a filial e a matriz, pois teoricamente seria mas lento com WS do que se eu setar na filial o ip direto do servidor bd na matriz. Mas isso teoricamente…não posso afirmar nada concreto, pois só testei conexão direta…

Tipo… se por exemplo eu quisesse fazer uma consulta de clientes, me retornando uns 3000 registros… qual seria a forma?
Seria algo assim?

1. Filial gera, compacta e manda requisição de pesquisa para a matriz,
   2)A matriz recebe, descompacta efetua a pesquisa, gera a mensagem de resposta, compacta e envia
   3)Filial recebe a mensagem de resposta, descompacta e envia os dados para a tela de visualização de pesquisa

Seria mais ou menos isso…? Então o segredo da velocidade estaria na compactação dos dados antes do envio??? Pois o volume a ser enviado seria brutalmente reduzido durante a compactação

leopoldof:

Nesse caso do WS , o que não entendo é como funcionaria a parte de transferência de dados entre a filial e a matriz, pois teoricamente seria mas lento com WS do que se eu setar na filial o ip direto do servidor bd na matriz. Mas isso teoricamente…não posso afirmar nada concreto, pois só testei conexão direta…

Tipo… se por exemplo eu quisesse fazer uma consulta de clientes, me retornando uns 3000 registros… qual seria a forma?
Seria algo assim?

1. Filial gera, compacta e manda requisição de pesquisa para a matriz,
   2)A matriz recebe, descompacta efetua a pesquisa, gera a mensagem de resposta, compacta e envia
   3)Filial recebe a mensagem de resposta, descompacta e envia os dados para a tela de visualização de pesquisa

Seria mais ou menos isso…? Então o segredo da velocidade estaria na compactação dos dados antes do envio??? Pois o volume a ser enviado seria brutalmente reduzido durante a compactação

Vamos supor que a filial requisite todos os produtos da matriz. O processo que realizo aqui nos sistemas é esse:

No cliente (filial):

1. Compõe o objeto do filtro da pesquisa desejada (pode ser um objeto Produto vazio, por exemplo, indicando que você quer trazer todos os produtos);
2. Compacta e criptografa os bytes serializados do objeto Produto;
3. Inicia processo de envio do pacote, que nada mais é que a chamada ao método list do WebService, passando o filtro por parâmetro. Obs.: Este método list que o cliente irá consumir retorna uma lista de byte[];
4. Se não receber resposta do servidor em um tempo X, o cliente reenvia o pacote;

Servidor (matriz):

5) WebService recebe acesso ao método list;

6) Desserializa, descompacta e descriptografa o(s) parâmetro(s) (neste caso o filtro);

7) Realiza a operação de banco de dados local (pois o BD está localhost);

8) Com a lista de produtos retornada do banco, serializa, compacta e criptografa cada objeto Produto contido na lista;

9) Inicia devolução da lista de bytes[] resultante que o cliente está aguardando;

Aqui eu abstraí, mas ainda fizemos uma validação a partir de um token do cliente, não permitindo que acessos desconhecidos.

Parece demorado? Faça um teste comparando com acesso direto e via WebService e veja você mesmo. Claro que tudo vai depender do seu algoritmo de compactação e implementação do seu WebService, mas assim você tem todas as vantagens que citei no post anterior…

quando faz comunicação via ssh os dados são compactados também?

que eu saiba só são criptografados, mas o que isso tem a ver?