Comunicação entre interface java e banco de dados web

Olá mundo! Antes de tudo quero dizer que sou novo neste fórum e venho há muito tempo acompanhando e estudando vários tipos de funções em varias linguagens no GUJ e foi sucesso! já consegui desenvolver alguns programas e me ajudou muito, oque eu puder passar e compartilhar estarei disponível! voltando-se assunto…

Estou planejando construir uma interface em java que envia informações para um banco de dados web, cujos dados teria uma chave/identificação criptografada. A interface geraria um arquivo jar que, executado em outro computador, pegaria todas essas informações deste determinado banco e executaria algum tipo de função(no outro computador), ou seja, envio dados para um banco, e outro computador recebe esses dados… e é justamente por isso que quero enviar dados com uma chave única que identificaria de onde está vindo a informação, podendo reconhecer esta informação e capturar, tudo isso pra não ocorrer nenhum conflito entre outros sistemas.

Criar interface que gera o arquivo executável já estou familiarizado, porém oque eu quero saber é, qual a forma certa e prática, ou quais procedimentos devo tomar pra enviar essas informações para um banco de dados de um website, e outro computador capturar essas informações? Eu imagino que deva ser uma conexão entre um servidor e um cliente, assim como já vi falar muito sobre HttpClient, já usei um pouco de innet4Address, pra descobrir informações de rede e ip do computador, e acredito que pode ser uma bela ajuda pra mim, porém não sei ao certo se é oque eu preciso. Oque eu devo usar ao certo? qual a função recomendada para esse tipo de ação? Oque devo configurar e quais são os cuidados ao realizar esse tipo de comunicação?

Me desculpem se teve alguma coisa errada que falei…
e obrigado a todos que me responder! aceito todas as dicas!

Que loucura mano… demorei um pouco pra tentar entender o que realmente você queria… Pois bem… vamos como jack, por partes…

1 - Imagino que você quer ter um banco de dados acessível pela internet. Eu vejo 2 formas acessíveis, a primeira é hospedar seu banco em uma empresa que oferece esse serviço, a segunda é hospedar seu banco no seu computador, se você escolher seu computador pode oferecer o serviço diretamente, ou indiretamente com um webservice por exemplo… escolhe ai que vou te dando dicas de como começar nessa ideia…

2 - não importa como seu banco foi liberado para a internet seu programa vai acessar;

Eu considero hoje a forma mais “certa e prática” de disponibilizar esses dados na internet é usando webservice, evite deixar seu banco exposto como disse acima (só falei porque é um opção), mas falando em segurança não é muito legal…

A ideia do webservice é disponibilizar seus dados por meio de um arquivo geralmente XML ou JSON e que normalmente vem pelo protocolo HTTP, sua interface vai ler esse arquivo e você terá seus dados como se tivesse acessado seu banco de dados diretamente, a grande vantagem do webservice é que ele torna facil o acesso a esses dados por plataformas diferentes como android, IOS, windows, Linux e etc… todos leem de forma bem mais simples um arquivo XML ou JSON do que a linguagem do seu banco, fora que acrescenta uma camada de segurança aos seus dados… O assunto é muito extenso, mas começa por esse conceito…

1 curtida

Eu agradeço muito por me ajudar Satangozo, amei as dicas e vou estudar mais a respeito do que você disse, eu já tinha ouvido falar do webservice e me senti a necessidade de me dedicar nesta parte. Pelo que eu entendi o webservice é um recurso que certas empresas de hospedagem que oferece para os clientes, tal serviço é gerar um arquivo xml para meu programa ler e capturar os dados obtidos do banco, conheço mais ou menos algumas classes que faz as leituras de um xml mas ainda não sei bem como usar -los, irei estudar sobre isso… agora , e o lance de enviar dados fazendo que outro sistema, outro computador pegue esses dados? Claro que outro sistema partiria do seu conceito para ler os dados porém a minha dúvida, é que vou gerar um arquivo executável pra executar em outro computador, este arquivo será como referência se conectando com determinada tabela do banco e capturando seus dados.A ideia central é: minha interface enviar uma informação pro banco e outro sistema receber e ler essas informações, e esse outro sistema tera que ter um arquivo executando, este arquivo sera a identificação do sistema que vai receber os dados. Será que pra isso exige algum tubo invisível? Uma forma de vpn? Uma conexao IP ou uma configuração de rede? O que você acha?

Pelo que entendi você quer criar um aplicativo com lado servidor e lado cliente, ambos acessam o mesmo banco de dados e se comunicam usando ele…

O banco de dados será substituído pelo webservice que será um endereço agora… Um webservice não faz somente select ele insere, atualiza, e exclui informações do mesmo jeito que um acesso direto ao banco, tudo que um crud precisa tem nele… O caso de como será distribuído cai muito mais pro seu gosto do que uma regra… Se você criar seu webservice em um endereço você somente precisa apontar o cliente e o servidor pro mesmo endereço que ambos vão acessar seus dados… Ah, mas como? Aí é outro assunto… DNS, IP fixo e dinâmico e por aí vai… Acho que sua arquitetura deve começar deixando disponível o webservice e colocar uma forma de autenticar pelo cabeçalho http, depois disso criar o visual do cliente e do servidor eh muito relax…

1 curtida

No meu ponto de vista a forma prática e mais coerente seria de fato trabalhar com uma camada de webservice acima do banco, até pra vc não expor o banco numa camada direta. Levando em consideração que N computadores podem acessar essas informações, pelo que entendi, indiferente da tecnologia usada, recomendo fortemente vc elaborar um contrato de serviço antes de desenvolver o serviço propriamente dito. Normalize o modelo de dados de entrada e saída e defina o comportamento do seu serviço. Princípio do contract first. Recomendo como leitura o autor Thomas Earl, referência quando o assunto é SOA. Enfim, ter o contrato de serviço vai te garantir como as coisas devem acontecer, sem delegar a responsabilidade de como fazer pros seus clientes, deixando a lógica de exposição do serviço para a camada de processamento do serviço (interface).

Não sei se de fato se aplica, mas consigo esboçar algo no Pattern Observer pra essa solução. Quando entrar dados, todos os clientes são notificados com a atualização das informações da origem XYZ . Não sei se é o caso é talvez haja um Pattern melhor pra isso.

1 curtida

@Satangozo é realmente isso, a resposta foi muito coerente pra minha situação, vou me dedicar no webservice pra armazenar os dados e atualizar, portanto irei criar um arquivo individual que a própria interface gerará, este arquivo será programado pra receber, enviar dados e fazer uma referência entre o cliente e o servidor, porém em relação ao “endereço”, o arquivo automaticamente tem que criar um endereço único e fixo para aquele cliente, isso significa que se eu gerar um outro arquivo para outro cliente que irá receber os dados, o endereço será diferente(uma forma de identificação), sobre as configurações de DNS e IP fixo, tenho que achar um jeito do arquivo configurar da forma mais automática possível. Creio eu que deve entrar muito O socket, HttpClient, innet4Address no java… Batch files individuais e infinitos “Runtimes”.

@raphaeloneves Sim, é uma boa prática essa, de fato que as informações poderia estar mais seguras, no entanto o número de computadores que poderão acessar são aqueles que terão o arquivo executável como referência, claro que os arquivos estarão configurados diferentemente com cada IP e outras coisas, essas configurações não serão manuais, a própria interface que vou criar vai fazer isso, isso evita de ter que ficar alterando o código permanentemente. Sobre suas recomendações, muito obrigado! com certeza irei pesquisar sobre isso e agir, creio que o contrato de serviço tornará tudo mais confiável e seguro.

Senhores, agradecimentos pelas ajudas, digamos que com essas ajudas, irá salvar muita gente e tornará a tecnologia da informação mais acessível e expandida, claro que de uma forma segura, obrigado!